Avoiding the use of a framework does not preclude someone else from duplicating your work in two months by using a framework. It just means that you wasted a whole lot of time hand-rolling things that didn't need hand-rolling.

Most businesses are not successful by virtue of the technologies they choose. Facebook is probably the foremost example here; they started with PHP and moved over time to leverage additional technologies (some homegrown like hack and react, others just additional languages like C++).

There are plenty of facebook clones in plenty of languages. The technology isn't the reason Facebook hasn't been supplanted by a competitor with the exact same product.

No, it's not "simply false". It's something that many of us have repeatedly observed happening and probably done ourselves at some point. There are of course exceptions, but it's not really fair to bluntly dismiss it.

One of your greatest desires should be to have strong propietry technology that you control

Yes – and you should be investing your time in making that "strong proprietary technology" more effective, and spending as little time as possible doing all the bits that your competitors didn't have to do because they picked an off-the-shelf solution that did most of it to a "good enough" level.

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.

What often ends up happening is you have to do a lot of useless work to get around the limitation of the framework you decided to use at the start.

Since most people on HN are in the web space, framework often refers to things like "Django" or "Redux". These beats always cost way more than they provide.

For a web server, a library like the standard "net/http" in Go is way more useful than a "framework".

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.