> The problem is, if I inherit an application created with a well-known framework, I'll have a much easier time figuring out what is what, and looking for answers when something goes awry.
Unless they spend most of their code fighting the framework to accomplish their actual task. Which happens rather often.
Not to mention that learning a new framework is not fundamentally different from learning some person's approach to doing things. Whether or not it's easy depends on the quality of code and documentation. Given equal size of the code that does the job, reasonably written framework-free code is probably going to be easier to understand, because it doesn't have external dependencies.
I never understood why after years of dealing with dozens of competing and rather poorly constructed web frameworks in Java, PHP and now JavaScript people still believe that those things have some kind of inherent value. Remember Struts, anyone? PHP Nuke? WebForms? Would you rather maintain something that used either of those over something that was written in vanilla Java/PHP/C#?
> Unless they spend most of their code fighting the framework to accomplish their actual task. Which happens rather often
I think this is just confirmation bias - you won't notice all the times you are not fighting the framework, but you do when you are.
> Not to mention that learning a new framework is not fundamentally different from learning some person's approach to doing things
Only if "some person" is real fastidious with documentation, StackOverflow answers and tutorials. You aonly have to learn Laravel[1], but catching up with Greg/Peter/Jane/Paula's framework at every new job will get old fast.
> Remember Struts, anyone? PHP Nuke? Would you rather maintain something that used either of those over something that was written in vanilla Java/PHP?
Those projects were fantastic for their time. Let me put it this way - I would rather maintain something that used those projects and not some custom solution written by a nameless developer in the same era. At least PHP Nuke had (I'm hoping) a clear migration path to PHP v4 and v5 and you won't have to do it manually.
> Let me put it this way - I would rather maintain something that used those projects and not some custom solution written by a nameless developer in the same era
I wrote a very large PHP application around that era.
You are absolutely correct. Even I have a hard time maintaining that code.
> Not to mention that learning a new framework is not fundamentally different from learning some person's approach to doing things.
I don't think this is true.
If you're learning a framework, you have the entire community - which has probably written blog posts, asked and answered StackOverflow questions, and likely has some members who can answer your question at odd hours.
If you're learning one person's approach, you have exactly one person you can ask about it: Greg. Who might quit, or go on paternity leave, or get hit by a bus. If you're lucky, you might also have some coworkers who understand parts of that system.
>If you're learning a framework, you have the entire community - which has probably written blog posts, asked and answered StackOverflow questions, and likely has some members who can answer your question at odd hours.
You're assuming that learning the framework will make understanding actual workload code completely effortless. In non-trivial applications this is never the case. You still have to understand... stuff like this, for example:
When someone writes code from scratch the quality of the code depends on their ability. When someone uses a framework the quality of the code depends on their ability, the quality of the framework and fitness of the framework for a particular problem.
If the developer is not very experienced but sufficiently disciplined, and the framework is well-designed and fits the chosen task well, than yes, you end up with better code. If any of those conditions fail, the code is usually just as bad or worse than vanilla.
More often than not, when I have inherited a project built on a common PHP framework the documentation and community knowledge available is limited because the framework used is, most commonly, not the latest version. So you are basically wading through the tall grass of online resources trying to ascertain what knowledge applies to what version, which for some frameworks can differ tremendously between major releases.
Many developers love a particular framework and they use it as often as possible and it works well for them, one reason being that over time they become familiar and accustomed to it's strengths, patterns, flaws and idiosyncrasies. But I personally find no pleasure in having to familiarize myself with a crusty old framework that I will never touch again in my career versus well-organized vanilla PHP.
Unless they spend most of their code fighting the framework to accomplish their actual task. Which happens rather often.
Not to mention that learning a new framework is not fundamentally different from learning some person's approach to doing things. Whether or not it's easy depends on the quality of code and documentation. Given equal size of the code that does the job, reasonably written framework-free code is probably going to be easier to understand, because it doesn't have external dependencies.
I never understood why after years of dealing with dozens of competing and rather poorly constructed web frameworks in Java, PHP and now JavaScript people still believe that those things have some kind of inherent value. Remember Struts, anyone? PHP Nuke? WebForms? Would you rather maintain something that used either of those over something that was written in vanilla Java/PHP/C#?