Just to clarify my question, there are clear social benefits to knowing multiple frameworks for your career, especially when working in large corporate group settings; for instance, you will benefit from being able to build apps quicker if you learn a good one and you will also benefit from a well-documented elitism that exists amongst web developers (see PHP vs Ruby on Rails debate, for example)…<p>However, wouldn’t all web-apps that are built using heavy web frameworks get a performance boost if they were not built on those frameworks? And if so, is more importance being placed on coders building products efficiently rather than coders building efficient products?<p>Assuming you can build any product you want from scratch, time is not an issue, your code is scalable in the sense that it can be understood by other coders in a reasonable amount of time, and your goal is to build the best, fastest, and most efficient possible product, when should you use a web framework and why?
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.<p>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.<p>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.<p>[1] <a href="https://www.techempower.com/benchmarks/#section=data-r10&hw=ec2&test=fortune" rel="nofollow">https://www.techempower.com/benchmarks/#section=data-r10&hw=...</a><p>[2] <a href="http://aws.amazon.com/ec2/pricing/" rel="nofollow">http://aws.amazon.com/ec2/pricing/</a>
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.<p>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.<p>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.
Time is the ONLY issue for me. I really appreciate having a well known shared vocabulary and patterns in which to apply to projects.<p>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.<p>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.<p>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?<p>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.<p>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.
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.<p>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