@MikeHopley and I used to think you were a serious dev too - how I was misled! You should go over to reddit and learn how the pro's do it... ;-p

@ohffs Very kind of you, but I'm certainly not a "serious dev". Very much an amateur in fact.

Serious dev is serious

No can haz frameworkz

Having dependencies you aren't using makes a huge difference when maintaining a project. It adds unnecessary complexity. Programming is all about taming complexity, so when unnecessary complexity is added it's never good.

Anyone who's worked on long term projects, been air-dropped into one, or has hired programmers to work in one understands this.

Having a project that is built with the correct necessary components is easier to understand, more decoupled, has less glue code to put things together, has less chance of failing in the future when components can no longer be found, etc...

Frameworks are for helping you prototype and deliver your app, they are not your app.

For devs who don't have experience designing and structuring apps, I can understand why Laravel is used more than the prototyping platform it should be used as. It's not easy to engineer something, to choose the right components, to make them work together properly, etc... Having one size fits all solutions to engineering projects attacks the problems the wrong way (top down instead of bottom up), but arduino and Laravel show that some people need that crutch. And, that's perfectly fine.

For many, having a maintainable clean code base 2 years down the line is not important. They just want a site rolling tomorrow.

MikeHopley wrote - "Seriously, no harm at all. It makes bugger-all difference to performance in most cases."

Performance is not something you should even care about when starting a project, except in the rare cases you are building a performance critical app. What you should care about is building a properly designed app. Performance optimization is something you do at the end of the app creation cycle.

Having a project that is built with the correct necessary components is easier to understand, more decoupled, has less glue code to put things together, has less chance of failing in the future when components can no longer be found, etc...

I can relate to that.

I use several packages in my application. I use them because it would take me much longer to write everything myself, and in many cases they are better designed than what I would have made.

For example, I use a markdown parser. It makes no sense for me to write this myself. It would take me ages, and I would never do as good a job as this package.

However, I don't like to install a million tiny packages for every little task. In several cases, I have found my application was improved by removing packages and reducing dependencies. It's about finding a sensible balance.

Now what about Laravel? Laravel is a bit different. As a web application framework, it solves many common problems. For example, almost any application will want a routing layer.

It's possible to decouple your application logic thoroughly from Laravel -- even in your controllers, by being strict about injecting services. I haven't bothered with this, but even so I don't think it would be horrendously difficult to swap Laravel for another framework, or indeed a collection of framework components (which is what Laravel actually is).

Here are two extremes of development:

• Use a package for everything. Avoid writing your own code whenever possible.
• Write everything yourself, even the framework stuff ("not invented here" development).

Both of these extremes are silly. Purely package-based coding is unlikely to fulfil the unique needs of your project, and creates a "house of cards" with too many unnecessary dependencies. But "not invented here" development means you do a huge amount of work solving common problems that have already been solved many times over.

but arduino and Laravel show that some people need that crutch.

Frankly, I think that is a patronising and pompous thing to say.

For many, having a maintainable clean code base 2 years down the line is not important. They just want a site rolling tomorrow.

I switched from my custom "spaghetti code" codebase to using Laravel precisely because I wanted a maintainable and clean codebase.

Now, Laravel didn't solve everything; I needed to learn to code better for that -- thanks Jeffrey! Laravel provided a useful foundation, and helped a lot with organisation.

You're making a false dichotomy between custom "spaghetti code" and Laravel. There's a huge world in-bewteen. Your pointing out the two extremes.

Custom "spaghetti code" is like trying to build a car by making all the parts yourself. Laravel is like building a car from another car.

You should not reinvent the wheel. That's bad. We agree. At the same time, your project should have as little dependencies as possible.

The reason I compared Laravel and Arduino is because they are prototyping platforms. They both have everything you need for plug and play.

The chances are your app will not require everything that is in Laravel, and there's also a huge chance that some modules don't give you the type of functionality your app needs. They are generalized solutions so that many people can use them, because of this, the code is more bloated to cover more corner cases. The auth for example is quite complex, has many files, etc.. Many you have an app that needs all that, maybe you have an app that only requires a very simple auth, in that case another package might be better.

Engineers build from the ground up using what they need for an app, This package + that package, etc... If you read the article I posted earlier it explains clearly how a framework is at the other end of the complexity scale. It's like starting with an app, then using only part of that + custom code to make another app.

I don't think it's pompous to say some people need Arduino or Laravel (perhaps I should not have used the word crutch, I'll give you that). Not everyone can build a circuit or roll out his own mini framework by assembling different packages. And for prototyping it makes no sense to do that. You want an app done as fast as possible to test the idea. In such a case, maintenance is not that important. You rewrite after using something like Slim3 + the packages you really need. Keeping this tight and maintainable for a long time.

About the serious dev bit. A quick way to know if you're a serious dev is to be honest with yourself and ask questions like:

Did I dabble with many different languages and frameworks before choosing PHP and Laravel for my web dev career, or did I just pick PHP cause it was easy, did some spaghetti code, then chose Laravel cause others said it was good. In other words, are you basing your career on choosing PHP + Laravel for valid reasons (I'm sure there are some) after having tried different alternatives?

After I decided to use Laravel as my main web dev framework, my bread and butter for my career, did I take many days to read Laravel's entire source code to understand it as much as possible?

A person who uses Laravel on a daily basis to make websites without ever having read Laravel's source is not a serious dev in my opinion. And, I'm sure many are doing just that.

All seems rather unhelpful and superior to me.

You're almost certainly a better and more serious dev than I am. Congratulations. Can I go now?

Talking about coding structures, best practice, etc... is extremely useful. Question whether a framework should be used or not, etc... extremely useful.

This is not a competition about who it better or not. Not sure why you think that? I'm by no means a great dev. I have tons of things to learn. Learning on a daily basis. There are good chances you are a much better programmer than I.

Of course you can go. No one is forcing you to have this discussion.

Were you offended because I criticized Laravel? I think that's healthy no? It's just a framework, not the be all and end all of web development. Just a tool. It has great advantages and great disadvantages like any other tool.

Choosing a framework can be a personality problem too.I recommend to choose the framework that you feel comfortable from the start.

@endian

Can I get you started on your thoughts about using Wordpress for a project?

It depends on the project. Wordpress certainly has its uses. You don't want to re-invent the wheel, so if Wordpress provides what you need for a certain project, go for it.

Choosing a framework can be a personality problem too.I recommend to choose the framework that you feel comfortable from the start.

Not really. I've learn only 3 framework, CodeIgniter, Zend Framework and Laravel.

My favorite is still Zend, maybe because i've used it for many years when i'm pretty new in the laravel world (start with version 4) but I still use it only because people say "laravel is the best framework". So like a sheep i go for it ^_^ .

@endian Most of the features Laravel offers are used in bigger-than-just-a-blog projects at some point of the project's development cycle. If you work on an ERP / CRM app for a while, you'll notice that.

The only reason I am using a framework is because I wanna finish the project on time before the deadline hits. I could build everything from scratch but it will take a lot of time and effort. I might get stuck at some point but the client won't be like "Good job man, you are a serious developer. You are not using a framework".

All clients care about is a working project, they don't really care about the technical stuff. It's up to the developers to make their life easier.

@Ruffles

No one is talking about starting from scratch. That is a very bad idea. You should never reinvent the wheel.

Most clients want a working project, that's true. That's why there is so much bad code out there. Most clients don't think of maintenance down the road.

I'm not saying you should never use a framework. I'm saying you should build ground up. You start from scratch or a micro framework, then you add the components you need. The best components for the job. Programming with Laravel is doing it the opposite way. You start with all theses components that you might or might not use. Laravel is great for prototyping for that reason. It's not all that great if you plan to create reusable maintainable good code.

I find laravel codebases considerably more maintainable than most others I've dealt with in my over 20 years of software engineering.

Certainly in some cases a 'microframework' lumen, silex, etc makes sense. But suggesting that all projects (aside from prototypes, which you seem to believe is the only thing laravel is good for) should start that way is either naive or disingenuous.

Most clients don't think of maintenance down the road.

A great many developers don't either.

I prefer productivity to fighting with the tools. Most clients, and employers, feel the same.

@willvincent

If your project makes use of most or all of Laravel components and they work to project spec, than of course using Laravel makes sense.

However, you must be aware that Laravel like the Arduino are design to cover many bases and cover them a certain way. They are one size fits all solutions.

Some components are coupled. Some overdone.

The vast majority of the time it's better to start ground up by adding the components you really need.

The vast majority of the time it's better to start ground up by adding the components you really need.

That statement simply could not be more untrue.

Some components are coupled. Some overdone.

Every bit of laravel's core components can be either disabled or swapped out for alternate options, and as has been said by others previously even if there are portions of the core framework sitting unused it literally hurts nothing.

Frankly, it seems that you've joined this community expressly with the intent of tearing down the framework. You've been a member here for a week and the vast majority of your involvement has been in this thread criticizing the framework, and disparaging it's users -- anyone not serious enough about their craft, who deign to use the framework for anything other than prototyping.

You are wrong. Accept it or don't. There's really no point in continuing to argue how and why you are wrong.

@endian said

You should not reinvent the wheel.

Which that expression is meaningless. If that were true, laravel would not exist. There were already frameworks.

Pardon me, but the "wheel" has been improved since the first stone wheel.

So some folks way of thinking is my car should have "stone" wheels. I am going to use modern aluminum alloy for my wheels with a modern rubber tire.

Taylor did a great job of putting together laravel, he invented nothing, but put things together and wrote code to make things work in a pretty neat way.

Having come from a CodeIgniter background I've been working with Laravel for 2 years now and I still consider myself a beginner. Comparison to CI Laravel is pretty dense however, I would never go back.

The only think that frustrates me is how I look into the Laravel source code and I see loads of great chainable functions many which are not in the docs.

So I hunt through the API hoping to find some explanations on how I might be able to use them as well, thus raising my own game. Often I find it a bit of a mystery how to use these functions. I would love better docs or least some advice on how better to search and find stuff in the API.

You misunderstand. Laravel is a great framework. It has its uses. It's great for prototyping which is why I use it. I love migrations.

But, and I'm quite sure Taylor would agree, when you want to create a great app which is maintainable, then you use the best components for that app. Laravel components may or may not be those ones.

Every app is different which is why you don't rely on one set of components for all of them.

This is not a critique. Just something to think about. I'm happy if everyone here uses Laravel, it means the framework will have a longer life which is great because I enjoy using it.

I'm just saying that a framework is a delivery mechanism. It is not your app.

The fact that you freak out when someone says something you deem negative about Laravel is alarming.

A framework is a tool, just like a computer language. None is perfect for every job. It's a bad sign when programmers defend a Framework or a language as if it were the holy grail.

You keep preaching a bullshit position that one should not reinvent the wheel, but also one should always start "from scratch"

You can't have it both ways, and budgets don't typically allow you to build something, throw it away and then build it over from scratch. That way of thinking indicates that you are either not really a professional, or maybe you work for the government.

Yes, I'm definitely a huge laravel fan. Is it right for everything? No, definitely not. But your position is bullshit.

I'm not saying to code stuff from scratch.

I'm saying you build up. You add the components you need. If you build a car, you don't start with a car. You find the right tires, use those. Find the right engine, use that, etc...

Laravel is nothing more than a whole bunch of components that have been chosen as a one size fits all solution, not a solution for your particular project. You can and should be looking for the right components for the job, not just lazily choose what Taylor chose for you when he doesn't even know what your project is.

You are aware we have composer now with PHP right? That means you can find PSR components to add to a project.

You should take the time to familiarize yourself with the multitude of PHP packages out there. There are so many.

You should take the time to familiarize yourself with the multitude of PHP packages out there. There are so many.

Stop assuming you know thing one about me or anyone else here. As I've stated, I have TWO DECADES of experience in this business. I'm well aware of what is available.

By your previous comments, it didn't seem you knew much of anything outside Laravel. If you do, then that's good. So, I would assume you agree with me that different projects require different components.

@dracool Don't forget, we can all view your profile. You've only watched 9 videos. There are 1500+ videos on here. Do more. ;)