Someone once told me "If you're not using a framework, you're building one".<p>I thought a lot about the many implications of that sentence, one of which is relevant for this article. Understand that you _WILL_ always use a framework, whether it's an external one or your own. Knowing this, when choosing not to use an external framework, you must show consideration to the design of the one you're inevitably building, and chose to build it intently, rather than by accident.<p>I'm entirely in agreement with every sentiment of this article, not only does it make software that will last longer, but for some of us at least, makes for a much more fun, interesting and enjoyable development experience.<p>Writing a program from scratch actually feels like programming, it feels like doing the thing we're here to do, rather than laying the plumbing that ties together a multitude of third party, constantly-changing (if not just randomly disappearing from the internet) frameworks together.
I wrote a system in the 1980s in Turbo Pascal under MS-DOS to talk to a bunch of hardware, and keep a display updated. It did large water meter calibrations, for city size meters, 6" and up.<p>That software survived Y2k with no incident, the only reason I heard about it was in 2007 when one of the cards was replaced, it failed to restart.<p>It turns out they had the two cables swapped. As far as I know it's still going strong.<p>I followed most of the rules detailed in the article, it was simple, did the one thing (including a multitasking library I wrote), and just kept doing it.
> when you're dealing with a team of developers because then everyone will know that framework and understand the software<p>I can't name a framework I've ever worked with that <i>anybody</i> actually understood.
This is a low quality flamebait article.<p>> Very rarely is the added complexity of frameworks justified and the added risk of breaking stuff down the line makes it a NO GO for serious software deployments. Only toy software and very small applications can justify the usage of frameworks and the likes.<p>There are definitely downsides to using frameworks, but this statement directly flies in the face of evidence. There's a ton of commercially successful software using frameworks, just think of all the things that are powered by React, Ruby on Rails or Spring Boot.
The problem by not using a framework is that you're going to reinvent one. Will it be better than what's available depends on your talents but one thing is sure: you're going to have to maintain it and won't have as many eyes on it.<p>I guess your mileage may vary so it's a case by case decision.
"It's easy and quick to make junk! Quality requires time and deliberation."<p>This is the cause of most of the problems I have seen. Businesses want quick over quality. Sometimes this is the right business decision.
Write it in C and make sure it compiles on a POSIX system. Next question.<p>Evidence: most of you are running such software, the internet infra depends on it, etc...
I'd be comfortable with a halfway approach to this article.<p>- Ship and implement as much as you want when you need tight control.
- But build on solid foundations which are already well established, so that you don't end up reinventing the frigging wheel.<p>I have a Flask app which is nearing 8 years old and it's going fine. Nowadays, I'm starting my backend python APIs with FastAPI, and feeling very comfortable.
I think the author misses the obvious:<p>Write your code as if you actually expect your code to be still working and maintainable after decades in the first place.
I wonder as to what types of functions the author speaks of on "Make custom functions, don't rely on the platform".
The article mentions a "PHP 4.x. (application) which is now running on PHP 8.0". Does that mean that the author has avoided using portions of the PHP API? If so, is anyone able to think of something that the author could have done in this case?