Are web frameworks actually useful?

Yes, most apps get a performance boost when they don't use a framework, and yes, more importance is placed on coders building products efficiently rather than coders building efficient products.

In most cases, this is the right choice. According to the TechEmpower benchmarks [1], a simple Django webapp can serve about 500 RPS on a c3.large EC2 instance, which will cost you about $54/month [2]. Adding an extra engineer will cost you about $15K/month (fully loaded). Therefore, for the cost of one engineer, you can pay for about 275 EC2 instances, which can serve 140K RPS, or about 12M hits/day.

Very few sites get that sort of traffic. Go work on speeding up the other bottlenecks in your app (like queries that lack indexes, or recursive queries), and don't make things harder on yourself than they need to be.

[1] https://www.techempower.com/benchmarks/#section=data-r10&hw=...

[2] http://aws.amazon.com/ec2/pricing/

This is very helpful, thank you

As you may know, programmers are notoriously bad at building anything and most applications are riddled with holes. There's so much you can get wrong, especially if your app is meant to communicate over the internet and be accessible from the outside. Not just crypto, though that is the most prominent one but Middleware, form protection, upload handling, traffic monitoring, authentication and caching without blowing up the RAM, etc.

I also don't think your app would get more scalable. You might have less code overall in your app but how well documented is it? Is it as well documented as the frameworks? For whom one of the most important concerns is usability and making sure others understand the code? Overall I doubt your code would be very readable. Many people write awful code and I doubt there's a lot of in depth code review in most companies, requires too many resources.

Another point when it comes to scalability is interfaces. Interfaces to talk to other instances, interfaces for pluggable modules, interfaces for the database, interfaces to different frontends. If you want your app to be scalable and possibly distributed and/or extensible you need good interfaces and programmers are also notoriously bad at designing those. (That's why JavaScript is the way it is) The only reason why those of frameworks are somewhat workable, is because they made a lot of mistakes before and learned from it (mostly). Good interfaces require constant and incremental improvement. A maintenance effort hardly any company would like to bear.

Such a great answer.

Time is the ONLY issue for me. I really appreciate having a well known shared vocabulary and patterns in which to apply to projects.

Not every project is suitable to use a framework thought, and sometimes you'll outgrow them. But, by then you'll know that the project is worth changing.

If you are paid by the job and not the hour, and you don't have any expectation of supporting the product, using a framework would be most tempting. It gets it done quick, looks acceptable, you'll get paid and move on.

Now if you are long term or expected to support, then you have to weigh the additional work of supporting the framework along with the app. The app you know; the frame work, while well supported now, may not survive web 3.0 or whatever. And if that happens you probably have a more complex migration than if you had built it all in the first place.

I've seen stuff developed on earlier Drupal DB now languishing because the effort it will take to update (and it wasn't really all that great in the first place, so it will be double work for them to update and re-factor).

would you rather have a team of engineers worrying about performance or building features rapidly?

there is many shops that would rather have some percentage of less performance if that means software is being built faster and usually with less bugs. these places may need some extra servers even but the cost of a server or two is nothing compared to a developers time.

this doesn't scale of that cost ends up being millions of dollars to run the slower code of course. but by that time you will have written your own in house framework likely anyways.

That's a very good point. Costs certainly are a hugely significant factor that I overlooked. I suppose it would come down to how much of the in house framework you could write up front (so you wouldn't necessarily need to hire as many engineers and could cut some of those labor costs preemptively) and how well that framework is actually written. I think that there are probably too many variables to have a one size fits all solution to this question, however.

From a security perspective, frameworks are theoretically superior. Much like how you should not roll your own crypto, instead opting for well tested libraries, a good web framework will be built with rigorous security in mind.

That's the theory, anyway. Your mileage will vary depending on how security savvy your engineering team is regardless, but at least with a framework it's usually straightforward to fix well classified bugs.

I guess that the most apps that are created with frameworks don't need any special speed but are more a special business case of some kind of e-commerce/marketplace/blog/forum and so on

The point of using frameworks is that time IS an issue, and you'd rather not waste it by reinventing the wheel every time.