Waaaait a minute - what kind of frameworks are we talking about here? You can build loads of things with Django. I can build VERY unique sites with backbone... i don't understand the opening comment. Hell, even bootstrap can be tweaked beyond recognition without terrible code.
Edit:
> They use a framework, and might not even use it correctly.
That's a shitty company or developer, not a symptom of the framework.
Surely you would rather work on an established documented framework than a custom undocumented mess from the same shit company?
It's also a nightmare to go into someone else's poorly written framework code and try to maintain it, especially because frameworks have "magic" where functions are not explicitly invoked, so it's almost impossible to trace the control flow.
Every time I've been maintaining someone else's framework code, the project was a mess. I don't see how frameworks are so awesome if so many people use them incorrectly.
For example, at my last job, they were using angular.js. Every 30-60 minutes the website just randomly crashed. There were all sorts of weird "$digest in progress" errors and bizarre errors. I know they weren't using angular correctly, but if a group of average developers are using angular incorrectly, do you blame them or blame angular?
That's why I prefer to use microframeworks over full blown frameworks. I can make it get out of the way if I want to by swapping out parts I dont like.
If a group of average people can't use angular correctly, then maybe angular isn't so great.
The average woodworker probably doesn't know how to properly use a lathe, but they don't go on WoodHacker News saying that lathes suck.
You're assuming the average woodworker knows about WoodHacker News.
> once you go outside the stuff that comes with the framework, they start to hold you back more than they help you
If you're talking something like angular, you are correct. If you're talking about something such as Django, not so much.
> nightmare to go into someone else's poorly written framework code and try to maintain it
Try doing it with undocumented custom code.
> especially because frameworks have "magic" where functions are not explicitly invoked
It is your duty to read the source code when all else fails. If you start doing this you will also most likely start seeing a distinct difference between the acceleration of your career vs. your coworkers.
> Every time I've been maintaining someone else's framework code, the project was a mess
you have been working with or following behind poor developers. their custom code would most likely have been equally terrible and rife with bugs.
> I don't see how frameworks are so awesome if so many people use them incorrectly.
So are guns, drugs, genitalia and cars but people use that stuff wrong all the time.
Frameworks are nice for these reasons:
1. they can help you learn how to build your own frameworks
2. they are typically documented (hopefully well-so)
3. the fact that you can identify which mistakes your coworkers made quickly ("oh, they should have used this class, function or file structure because it says so in the docs", vs trying to track down the original dev or read through mountains of source code to figure out what some undocumented thing does).
Edit: i wish i would get told why i'm getting down voted on this rather than just down voted for an unknown reason. Is it the snarky remark that contains the word "genitalia"?
Wait? I have to read the source to use a framework? Which is it? Frameworks are awesome because they are well-documented? Frameworks are awesome because you can read the source when you're fighting some obscure bug?
The problem with reading the framework source is that, the bits of the framework being used are usually only 1%-5%, so now I'm digging through some mountain to find the tiny bit I'm looking for.
If I have a problem with GCC or PHP, I don't (normally) have to read the GCC source or PHP source. Why should I have to read the framework source in order to find out how it works?
Well, I said "when all else fails". If for some reason you are unable to find the answer to the issue you face within the documentation, then as a developer you have to dive into the source code.
> now I'm digging through some mountain to find the tiny bit I'm looking for
What is the reverse case? Why is custom code different?
> If I have a problem with GCC or PHP, I don't (normally) have to read the GCC source or PHP source. Why should I have to read the framework source in order to find out how it works?
Correct, but if you have a problem with a PHP website, you typically do open up the website's PHP source code and read it. I don't understand how custom code solves the problem of needing to read source code.
My boss wants the bug fixed in a couple hours. I can't spend a couple weeks reading the framework source so I can fix the bug. (For the zend form example, I wound up writing my own form instead of reusing what was already there.)
If I have a problem with a website written in PHP, I read the PHP source and can fix the problem. If I have a problem with a website written in PHP plus a framework, now I'm expected to read the PHP code PLUS the code for the framework? That's several orders of magnitude more work.
Perhaps you feel I am saying that you must exhaustively read the framework's source code to understand it. I am not. You should have the ability to quickly open up your framework of choice's source code, navigate to the portion that contains the relevant bit of info you need and go from there.
"going from there" sometimes entails referencing a few base classes or figuring out what the result of some custom methods or functions do. It shouldn't require understanding every line of code of the framework.
> now I'm expected to read the PHP code PLUS the code for the framework?
Only if the framework's documentation or the internet fail to answer your question faster, yes.
OK. Sure.
Less sarcastically, tooling is often very helpful when you have to dive into the source of a library.
That's barely ever the case though. A framework guarantees consistency. You can complain about the Zend framework, but it has documentation you can look up. If an outsourcing company wrote it from scratch you'd have no-one to ask and no further information to pick the code apart.
You're complaining about a framework that doesn't have the feature you wanted, but that doesn't invalidate the concept of frameworks.
The documentation for other frameworks I read was similar.
Actually, they have another project written in a custom framework, which is also a nightmare, but it's less bloated and I was able to figure out how it works by reading the source.
I'm not saying every framework is amazing, I'm saying that using public, known frameworks means there is a lot more support available for you out there. Not least because these frameworks have had many eyes review them - the custom framework you used was less bloated this time, but there's literally zero guarantee of quality there.
Huh?
On that project, the outsourcing company had some custom framework they wrote that lived on top of zend, so it was the worst of both worlds.
You might say "They were using the framework incorrectly!", but if it's too easy to use a framework incorrectly, then I don't see the value it provides.
Without a framework, it's much easier to trace the control flow. If the code is in 2-5 files that are explicitly included, that's a lot easier to understand than when files get magically included from all over the place.
I can't agree more with all your comments here but I've been downvoted into oblivion for saying the same things.
MVC frameworks I have tried at work:
Java/Spring/jsp/beans
Ruby on Rails
angular.js
zend
All were awful.
I do like libraries, things you can plug and play and use where you want (like jQuery). A framework demands that your whole application be written in its style.
For example, the Ruby on Rails project used a legacy database, which was not written in primary key autoincrement integer Rails style. That project was a disaster and that startup failed. With financial data, demanding the primary key to be autoincrement integer forces a lot of unnecessary joins, when you already have natural keys like Ticker or CUSIP.
Another downside of frameworks is maintenance. A company hires an outsourcing company to make a website. They use a framework, and might not even use it correctly. The incentive is for the outsourcing company to use a framework, because that lets them ship a website that sort of mostly works quickly, so they can get paid.
The contract is over and now some other programmer (such as me) is now supporting it. Now, making changes is several of order of magnitudes harder, because you're fighting the framework in addition to the code that was already written (especially when they didn't use the framework correctly).
For example, I was working on a website that used Zend forms. Now I needed to modify the form so that it was pre-populated with the data (an edit page instead of a submit page). I spent a couple days looking at the code and the zend documentation, and I just couldn't figure it out. The form had some javascript on it also, so I couldn't just use value="" to pre-populate the data.
It it was plain HTML/PHP, I could have just used value="" to pre-populate the data and be done in 5 minutes. The framework make a 5 minute task almost impossible.