If you know the basics of php, you should grasp the fundamentals fairly quick.
But if you are also new to php it will be a steeper learning curve. I was able to retreive data from a database
and display results with a search and pagination in only a few minutes. However it took upwards of 3 days to
get a handle on Authentication. But I had used cake php and regular php prior, so not as big of a learning curve.

Google laravel tutorials, there are blogs and tutorials available.

@mikelovely, do you have any experience with other web frameworks? Do you know design patterns?

Maybe go through request lifecycle and read the code of what it is that Laravel does from start to finish (of a request).

@Xum - I have used CodeIgniter before, that's about it. I have spent years coding procedurally and I prefer it. I know I'm not supposed to say that. Actually, I even know I'm wrong - but I can't help the way I feel. I haven't seen any framework that makes OOP easier. CodeIgniter did an ok job but that doesn't really count.

I'm just tired of having to continuously stop coding and search (sometimes for a whole day) for the answer to very basic problems. Issues that aren't issues when coding out of a Framework. Like the trouble I had finding how to to simply switch databases; http://laravel.io/forum/03-26-2015-switching-database-connections-does-not-work.

Using Laravel is like using the internet for the first time - You know (or you're told) that it can do lots of things, but you have no idea what. So someone says "Google it". But what do you Google? "How can I use the internet?" No, that would be ridiculous. You have to Google something specific - but you don't know what, and you're back to square one. That's not a great analogy but it's the best I can do.

@jimgwhit - Yes. I have made CRUD like applications using Laravel. But that's not exactly impressive. It's taken weeks. Maybe my next project will be easier - a bit like.... when coding procedurally?

mikelovely said:

@Xum - I have used CodeIgniter before, that's about it. I have spent years coding procedurally and I prefer it. I know I'm not supposed to say that. Actually, I even know I'm wrong - but I can't help the way I feel.

Laravel 5 is my first proper attempt to switch to OOP and frameworks from procedural code. And it does require quite an investment of time upfront, not as much into Laravel itself, as into understanding design patterns behind it. Understanding design patterns makes the Laravel code click in your head faster and better. And then it's a joy to use.

There are several talks from Laracons (EU and US) that helped me with understanding some of the patterns.

But yeah, my first CRUD application was getting painful whenever I was deviating from the material covered in Laracasts tutorial (which are the best).

Diving into the actual code of the framework helped a lot. It's not overly complicated, although sometimes you have to drill through a few layers of abstractions to get to the concrete logic you were looking for.

A good text editor/IDE (I'm using Sublime Text) helps to dig through code faster. And for when you need to find a function definition, simple grep works fine. Say, for env() function in your example:

user@machine:~/myproject$ grep -r 'ion env('
./vendor/laravel/framework/src/Illuminate/Foundation/helpers.php:	function env($key, $default = null)

you can see straight away that the second parameter is the default value.

And finally, logging and debugging. I haven't yet picked up a proper PHP debugger, but even simple dds and logs work fine for exploring the framework and its peculiarities.

I'm just tired of having to continuously stop coding and search (sometimes for a whole day) for the answer to very basic problems. Issues that aren't issues when coding out of a Framework.

It gets better. But it takes time. Especially, if you take time to not just copy-paste an answer, but to understand it.

@mikelovely

Honestly, it's the way that you have been programming php until now that is the issue. If you were making this comment back during L4.0.0 I would agree with you to a large extent because the Laravel documentation made too many assumptions about people's knowledge and the pain was horrible.

Jeffery Way is really good and has gotten even better since I assuming he has taken some comments that people have written. I even like him better than the RailCasts guy. However, I doubt if everybody likes Jeffry"s style since everybody doesn't learn the same way.

Now back to your issues. Procedure coding is not wrong per say. Heck, even MVC is on the side of being wrong the past few years. What is wrong is that you are pounding your heading against a brick wall trying to work out how to understand Laravel. I made my major break through in understanding Laravel when I realized I was going about it all wrong. It's like working on cars; when I work on German cars I try to switch into a mode of thinking as to how I would make the procedure so nifty that only other Germans would get the joke, with American cars I go into WallMart mode and look for the easy way out answer and for Japanese cars I look for the answer that makes most Vulcan logical sense.

So, with Laravel -- you have to understand that it will do just about anything that you can throw at it. The beauty of it is that there is no "right" way to complete your project. What I do see is that a lot of people try to do it the Jeffery Way way, which is bad and actually is smart thing to do but ... you don't have to do it that way. There are some really smart people using Laravel and I have no freaking clue why they did things their certain way but I tend to leave it at that and appreciate the bits of code beauty that they have shared with us.

The reason why people poopoo on procedural programming is that it ends up one long wall of text and a single file will sure the purpose. Which means bug fixing requires digging through all those lines of code and hoping you don't break something on the way out.

The current "hipster" way which Laravel has possibly surpassed Rails is by really taking to heart the idea of breaking everything down to about 10 lines of code per file (well ... controllers will be about 1 line per function). I still find this crazy and wonder why do I have to create 10 extra files to perform a pretty old school MVC pattern.

Another feature which you can almost totally ignore if you want is Design Patterns. Laravel is full of them and many people like Jeffery Way just go with them ride like he stole them.

See, it's just learning a new way to do the same tasks that we have always been doing. And, like I said, I was having horrible issues trying to come to terms with Laravel. I know that I am a way better programmer after a year with Laravel than I was when I was working with older forms of coding.

To end this novel, don't stress it. Take laravel in piece by piece when you are ready for it and in the mean time do what makes sense to you without worrying about if your code looks like what you see on some blog. If it works then it works, you can always go back and refactor the mess :-)

I would not concentrate so much on the laravel way at first, rather at first learn the model, and how to use, then controller, then view. Don't get caught in the trap of just totally depending on eloquent. Learn the long way to write sql first then eloquent. Remember, you may get a job where they do not use laravel, and you may have to know regular php pdo, or even another framework. Before you learn anything else in laravel, google normalizing a database. A well designed database cuts down on some of those crazy queries I see floating around.