I remember people saying this in a PHP days and almost without fail their code would be littered with security bugs. They don't a template language, and there would be a XSS vulnerability. They don't need an ORM, and there would be a SQL injection vulnerability. They don't need a form library, and there would be a CSRF vulnerability.

Now-a-days there are less security vulnerabilities and more buggy messes powered by Express.JS. API's with shitty query string parsers than crash the server.

The average developer should just be using a framework.

> The average developer should just be using a framework.

Yes, and the non-average shouldn't.

The tricky part is that many more developers think they're capable of handling all these issues than actually are.

Web app security is a genuinely tricky area with lots of edge cases. Good frameworks provide abstractions that mean you don't have to deal with a lot of those problems for most mainstream cases.

You're basically saying the average developer is grossly incompetent. Which I don't necessarily object to, but it's important to be aware that this is what you are saying, even though you are not using the exact phrase "grossly incompetent".

If the average developer is so incompetent maybe they should undergo further training before being allowed to touch production systems? I suppose this is what code reviews are for, but I don't see how it helps when incompetent developers review each other's code.

Are we all talking past each other? IME there is a time for using an off-the-shelf framework and a time to hand roll from scratch. (For varying definitions of scratch.)

Generally when a company's tech needs aren't very unique, and they seek to compete on time to market, then a shelf framework makes sense. Companies whose needs stretch the boundaries of shelf frameworks too much may be better served by building on a lower level platform like from a standard library--entirely or in part.

Yet building from scratch is costly. Depending on the stack / language chosen it may cost an "innovation token" or three. Small companies can't afford a lot of these tokens. And lots of eager engineers want to believe their problems are unique, dragons never before defeated. IME most problems aren't like that. They're boring, such as a codebase that's lost its fit as the market or company has grown, pivoted, or contracted.

> This notion that frameworks save you time is just ridicluous. Unless the framework is doing something really complicated and difficult (like, say, a 3D game engine such as the Unreal Engine), chances are it's costing you time and effort.

... Have you ever written a simple web app? Pull values from a db and present them somehow? Having something that just gives me places to plug in the business logic makes this pretty trivial.

> Have you ever written a simple web app? Pull values from a db and present them somehow?

Yes I have. A lot.

That is a pretty extreme take - that frameworks “always” cost more than they provide? On what do you base this categorical assertion? I’ve been in this industry a long time, and based on my experience that’s not true at all. “Sometimes” they cost more, if your problem is esoteric or a poor fit to a general framework. Most problems aren’t.

I was going to counter your claims, but I found a comment a couple days ago that perfectly sums up what I was going to say: https://news.ycombinator.com/item?id=33148071

Even if this were true (and sibling posts make compelling counterarguments), you've completely overlooked that the value of a unit of engineering time varies wildly. Spending weeks of engineering time re-implementing all the security features Django provides out-of-the-box is suicidal when you're trying to get off the ground. It doesn't matter that it could save months down the road if your project literally doesn't exist anymore.

If you think "net/http" is more useful and contains more functionality and less need to reimplement

* HTML forms * and admin * a plug-and-play security framework that's already worked out all the kinks of crypto libraries * an ORM and DB libraries for a half dozen production-ready DBs, with their kinks in transaction and connection management already sorted out

I have a bridge in Crimea to sell you.