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

TOP OF THREAD FULL DISCUSSION
re: 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...
 

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..

code of conduct - report abuse