re: Todo-MVP: Or 'Why You Shouldn't Use A Web Framework' - The Revenge VIEW POST

FULL DISCUSSION
 

I think you've got some really good ideas about a few things, and you've also missed (or not yet come to see) the problems that frameworks solve.

Writing everything from scratch is a great way to learn how things work. Maybe you want to understand what really goes on during the request-response lifecycle, or you want to write raw SQL queries instead of using a heavy ORM. The understanding that you get from doing this is super valuable, and every developer should certainly do it on some level. Also, because you have a deeper understanding of a concept it lets you debug other people's code more easily.

I think there are more and bigger downsides to writing everything from scratch though.

Writing from scratch is reinventing the wheel. Sure, you might come up with a better way to do it (maybe, but I probably won't, and definitely not the first time I do it). But practically every web application has a need to send requests and handle responses, and communicate with a database in some way or another.

Because these tasks are so common, people have written code to do the work for them. They have developed methods of dealing with them. You can think about the tasks as "problems" - they're things that need to get done in order for your application to work.

Using someone else's solution to handle requests and database queries just means that you're going to focus on solving different problems. The ones that your application has specific needs for, whatever that might be.

Learning how to solve these problems is valuable, but once you've built many applications, you may be tired of solving the same problems over and over again. This is why frameworks were developed.

Various frameworks might solve the same problems in different ways, but ultimately they do it so that you don't have to. Yes, you're limited to the choices the framework authors made, but in many cases that's okay because you're focusing on solving other problems. Yes, you have to learn how that framework solves those problems, but that's true every time you use code that you didn't write.

The main advantage I see to frameworks is standardization. this matters on bigger teams. You can hire someone that says "I know django and angular" and they can be productive on your project because they've already been exposed to the patterns that django and angular apps follow. They don't have to learn any new paradigms, they only have to learn your project's specific business logic.

I would also argue that frameworks (generally) scale better - not necessarily in terms of performance, but definitely when talking about code organization and design patterns. Having iterated and developed standards over time helps with this a ton. Working on a gigantic rails project is tough (though manageable), but working on a gigantic custom framework involves much more cognitive overhead, especially early on.

Anyway, no matter what you use, you're going to be solving problems. Which ones do you want to spend your time on?

 

Just about everything you're referring to is theoretical. It just doesn't work out in practice. Frameworks only have a small niche in which they're beneficial. In over a decade of programming, having made frameworks, used around a dozen, fixed many, modified many and have seen well over a hundred projects using frameworks I can conclusively say, they just don't work out 90% of the time minimum. Most of the time they're not necessary and are complete overkill.

This is what I've learned to come to expect from a project using a framework (the larger the framework the more so these things are....

Frameworks give you more to do, they reduce standardisation, they significantly degrade performance, they reduce maintainability, they reduce collaboration, they reduce testability, they reduce buildability, they reduce readability, they reduce debugability, they reduce reliability, they increase bugs, they increase the amount of code you need to write, they reduce developer quality, they inhibit learning, they reduce deployability, scale poorly, cognitive load increases, upgradability is inhibited by frameworks, reusability drops, compatibility drops, security is reduced by frameworks, they reduce interoperability, they increase the time it takes to do things, they increase complexity, they reduce configurability, they reduce organisation, etc.

Not a single claimed benefit of frameworks works out in reality even half the time. This isn't a discussion. I'm not talking about theory, I'm telling you the facts. If you go any sample what actually happens in reality that's what you'll get.

There are ample reasons for it and probably not a reason with a significant majority though one reason that stands out is that first and foremost the developer must be able to deliver all of the above and if they're relying on their framework to do it by magic then it'll never happen. It's a myth that a framework will solve all your problems. You have to solve your problems. Using a framework will likely just make things worse if it's on blind faith.

Frameworks causing a deficit in all those areas might be surprising at first but less so when you think about it in the sense that they introduce so much complexity it tends to completely overwhelm developers. Most of whom are afraid of the initial complexity then to solve that unwittingly include ten times more complexity and tend times more to contend with. Superficially and psychologically they might feel better but without a point of comparison they lack the ability to weigh up the additional cognitive cost or to realise that they're so over loaded that everything suffers. There's also a simple fact that frameworks often actually aren't that well written, documented and complicate things by trying to cater to every way of doing things and every use case including the most extreme and complex cases.

In often cases frameworks just give you more to worry about. Frameworks are like inventing a whole new set of languages. You start off having to worry about javascript or PHP and their common libraries or the specific libraries you need for you task. Before long with a framework those things have not only gone away but you also now have to worry about all the additional little languages the frameworks have introduced or created such as typescript, twig, yaml, extensions to HTML, all manner of code to configuration, etc so now basically you've gone from a few things to a dozen things. First you had five problems, now you've got ten problems. As in first you had to learn five things, now you have to learn a hundred, well done.

In terms of being poorly documented, while MDN and the PHP manual really blow a lot of things out of the water (language references tend to end up being quite good), framework documentation tends to be very poor which isn't surprising given just how large many tend to become. It's also a substantial myth that framework developers are better than you. They immediately are not because they do not know in a given point of time your specific requirements, they're not in your shoes, they don't know what you need and what you don't need. Further more they're not actually guaranteed to be good developers, they're only guaranteed to have time to make and share code. Library and framework code, even languages are deficient on multiple fronts all of the time. There's barely a language, framework or library I've used that hasn't had problems on some level including code quality and reusability.

"writing everything from scratch" is something you really need to qualify. I just "wrote everything from scratch" this week. How long does it take to write "everything"? About one or two days. In reality at least for PHP the average application only needs around 100 to 5000 lines of framework. That takes about an hour to month to write, however you don't have to do it all at once, just when you need. Basically you can expect the proportion of framework dev to business logic dev to drop off significantly from the start of building an application. Realistically custom frameworks tend to want to weigh in at around 500 to 1500 lines base on typical project sizes.

Given that's the case, it makes no sense to try to save writing 500 to 1500 or even 5000 lines of code by introducing a million lines of code framework which is a huge amount of additional complexity to maintain. In reality, you're going to spend as much time with your own framework as you are with any other in terms of time spent solely on that. For very small projects you might see a different but anything going for a quarter, six months and definitely a year you'll not receive a benefit from frameworks. If you're doing more lines than that then you're probably doing something more than writing your required framework. When you consider how large frameworks often are compared to the required framework then that should raise some questions.

A lot of people look at a million line framework and think that's how much they have to do. More worryingly, they think that's how much they save. That's not even a framework. That's an inner platform. It wont save you a million lines. In fact you're likely to have to end up writing more to cater to the framework making you have to do things you don't have to do.

"They don't have to learn any new paradigms", really, how long does that take? You're concentrating on the 1% to a few percent at best while ignoring the other 99%. This is the difference between theory and practice. In practice you actually have to quantify these things, it's not just more or less. No one in their right mind would scoff at the concept of making things twice as better 95% or more of the time at the expense of making things twice as worse 5% of the time. I smell here a case of this is not your real problem. You real problem is fear of not being permitted the lead time to get up to speed. That's the real problem we need to look at here and that's where we need to influence the industry towards reasonable expectations, influencing the industry to make frameworks mandatory is not a reasonable expectation nor does it really do anything to really address the root of the problem, in most cases it backfires.

Personally, I hope people continue overusing frameworks as it gives me a huge competitive edge being able to take the efficient path and far more superior path of not using them but the better part of me doesn't want this horror to be inflicted on anyone.

I'm going to conclude this with, I've seen frameworks kill businesses. When they are killed for other reasons, it's because of bad developers. Frameworks don't fix that but often people like to blame that being absent instead rather than blaming people for obvious psychological reasons.

 

Interesting stuff.

How have frameworks managed to kill businesses? was it due to having to refactor the code sitting under them to a new version?

Let me tell you my story.

I work for an online school and 3 attempts were made to rewrite the entire learning management system into symfony, codeigniter, and then laravel. The LMS was written in old school PHP 3 code that had just barely made it's way into 5.2 compatibility. The structure of the site was a loose set of scripts with a few global libraries and no object oriented stuff, relied on input globals, etc.

The codeigniter attempt had 2 super huge controllers but implemented at least 75% of the functionality before a wall was hit with that approach.

The laravel attempt only got 15% of the way there before the programmer gave up.

I got my job maintaining this legacy application and throughout the course of 1 year, refactored it to be compatible with 7.2 and beyond. Only until recently has it seen any object oriented code, which was just an experiment.

The other programmers sold the company on a rewrite by touting the benefits of these frameworks. Last time, the owner was told that we Laravel was great because it could do caching, easy APIs, database abstraction, and had an admin panel addon that would make redoing the backend easy.

None of this stuff materialized and the refactored LMS is running on a 1GB mem amazon instance without caching because it's written more like a C program and has the performance to match.

The laravel backend plugin was horribly buggy and crashy; but that might have been because we had a crap programmer. 100% of the laravel code was written off as a loss, because none of it could be used in the old system - it was too dependent on laravel.

I do wonder if the intense layering of abstractions and the scattering of tiny objects that have maybe 1 or two methods, adding up to 1000's of objects, is even comprehendable to the programmers trying to follow that ideologies.

I tried asking a SOLID devotee writing some popular upcoming forum software how he managed to trace execution in his program and he could not provide me with an answer..

I think a lot of people have these experiences in the business but it's a bit weird that it's opposite to how things like news works. People seem to be very motivated to dish out good news about frameworks but none of the bad news.

I think the people without the time on their hands and that have to actually deal with these problems don't have the time or energy afterwards to then blog about it.

An immediate problem with frameworks is that they want to solve complexity with complexity and if someone can't handle the initial level of complexity nothing will be achieved adding even more.

This might be deceptive as from certain angles frameworks look as if or give the impression as if they simplify things. Somethings with tricks like here's one we made earlier. It's all very well until you want something that's not exactly that.

After sometime between PHP 5.1 and PHP 5.3, frameworks have really never solved any problems, only good developers have. Before that as you go back PHP was increasingly limited and in some cases you might say well maybe there's a little scope. I think they also have some scope in some areas that aren't quite mission critical and can afford a little sloppiness (IE, it just needs to work) that frameworks can empower.

It's a bad but common assumption that frameworks are well written and that the coder can't do better. It's also a bad assumption that frameworks can either contain or enhance a bad developer. A huge complex Gordian knot of a framework is only going to give a bad developer more rope.

without caching because it's written more like a C program and has the performance to match.

That's a story of my life. So often people just try to add another layer which is a problem with frameworks. Often the problem is deeper down and with frameworks the only way is up.

Most SOLID devotees don't understand SOLID. Prematurely inverting dependencies with interfaces and minimising the need for modification relying on extension instead is for public libraries like the Java library where the code is meant to be distributed to millions of people with every possible conceivable use case.

That doesn't need to be strictly applied to a mutable internal codebase. SOLID has also become a fad today, replacing OOP with an over the top militant if it's not following the most extreme all the things rules then it's not good, even if that means prematurely optimising for flexibility when there's no latency doing things on demand resulting in over half your code being unneeded.

The people adhering to these things are psychologically messed up. They want to be superior and that's it really but the fact is they either lack the benefit of intellect or programming experience. Not everyone is like that but for those starting at the bottom, who really want to start at the top, it really brings that nature out of them.

The JS environment has become a bit weird like that (functional programming maniacs send me up the wall) although I tend to worry a bit less as you can often more easily toss out a JS front end and replace it either wholesale or bit by bit. Backends tend to have critical datapaths shunted through then rather than being terminators. Basically, they're in the middle, stuff interdepends on them. It'll be more interesting when JS backends start to become more established though saying that webpack and gulp are a joke and are now pretty much a must have.

I'd just like to say @joeyhub and @theelectricdave that these are some quality comments that I've really enjoyed reading. Thanks!

Especially

Frameworks give you more to do, they reduce standardisation, they significantly degrade performance, they reduce maintainability, they reduce collaboration, they reduce testability, they reduce buildability, they reduce readability, they reduce debugability, they reduce reliability, they increase bugs, they increase the amount of code you need to write, they reduce developer quality, they inhibit learning, they reduce deployability, scale poorly, cognitive load increases, upgradability is inhibited by frameworks, reusability drops, compatibility drops, security is reduced by frameworks, they reduce interoperability, they increase the time it takes to do things, they increase complexity, they reduce configurability, they reduce organisation, etc.

I mean, this is brilliantly put.

I saw Ward Cunningham tweet this:

I feel the same way about frameworks and DSLs - they're designed to negate my generic programming skills and mentality.

You're welcome. I'm glad someone gets it. I've been afraid to even speak my mind on this topic because there is so much freaking resistance to not following php-fig dogma and object oriented fetishism.. It was reading joey's comments and noticing that he didn't get mauled that made me join.

It's a bad but common assumption that frameworks are well written and that the coder can't do better. It's also a bad assumption that frameworks can either contain or enhance a bad developer. A huge complex Gordian knot of a framework is only going to give a bad developer more rope.

This is the thing that sticks to me the most. Having had developed my own framework, i have a yardstick to measure other frameworks by, and they pretty much all fail to stack up to some of the pretty basic function libraries i've put together, in terms of how difficult the syntax is to type, how fast they perform, etc.

( the only framework i found respect for in this regard is the fat free framework )

I always come back wondering who finds these solutions acceptable.
A simple database call in laravel or symfony is about 3 times more complex than i'd like.

Perhaps these frameworks provide acceptable solutions for people who do not know better and are just average programmers. In this case, it might be better for them to be using someone else's solution.

With the code camps churning out hundreds of new programmers per day, i think the framework popularity will only continue over time. This may result in another phase of poorly written, unmaintainable php code - except this time, you also get to figure out what automagic is happening when you try to debug that mess after the original programmer hit a wall and walked away from / failed to complete the project..

 

Writing from scratch is reinventing the wheel.

If I want to correct one idea in this it's the idea that not using a framework means that I'll be reinventing the wheel. A lot of what you say about avoiding the duplication of effort applies to libraries. I like libraries. But why don't I like frameworks?

Use libraries so you're not 'reinventing the wheel' of HTTP message parsing. Maybe you'll use an ORM library to manage your database. Maybe you'll use a thin wrapper over SQL. But if you've abstracted the persistence layer correctly then you'll be able to change your mind depending on your needs and not the capability of the framework.

 

I agree that's true if you have the need to change things like that later. But in my experience, you have to go incredibly far down the road or have really extreme/specialized needs to not be satisfied with an off-the-shelf solution.

Your TODO-MVP has several good examples of how you can do some of these things with little code. I will posit an alternative - you can save yourself a ton of time by using a framework. You'll end up with more total code (maybe), but you'll also have more time to focus on other things.

You seem to be ignoring the time it can take to determine how a framework wants you to solve a given problem. We've spent considerable time on a CakePHP project trying to find the "right way" to solve a handful of problems which could have been solved with vanilla PHP in an hour.

code of conduct - report abuse