I think you've got some really good ideas about a few things, and you've also missed (or not yet come to see) the problems that frameworks solve.

Writing everything from scratch is a great way to learn how things work. Maybe you want to understand what really goes on during the request-response lifecycle, or you want to write raw SQL queries instead of using a heavy ORM. The understanding that you get from doing this is super valuable, and every developer should certainly do it on some level. Also, because you have a deeper understanding of a concept it lets you debug other people's code more easily.

I think there are more and bigger downsides to writing everything from scratch though.

Writing from scratch is reinventing the wheel. Sure, you might come up with a better way to do it (maybe, but I probably won't, and definitely not the first time I do it). But practically every web application has a need to send requests and handle responses, and communicate with a database in some way or another.

Because these tasks are so common, people have written code to do the work for them. They have developed methods of dealing with them. You can think about the tasks as "problems" - they're things that need to get done in order for your application to work.

Using someone else's solution to handle requests and database queries just means that you're going to focus on solving different problems. The ones that your application has specific needs for, whatever that might be.

Learning how to solve these problems is valuable, but once you've built many applications, you may be tired of solving the same problems over and over again. This is why frameworks were developed.

Various frameworks might solve the same problems in different ways, but ultimately they do it so that you don't have to. Yes, you're limited to the choices the framework authors made, but in many cases that's okay because you're focusing on solving other problems. Yes, you have to learn how that framework solves those problems, but that's true every time you use code that you didn't write.

The main advantage I see to frameworks is standardization. this matters on bigger teams. You can hire someone that says "I know django and angular" and they can be productive on your project because they've already been exposed to the patterns that django and angular apps follow. They don't have to learn any new paradigms, they only have to learn your project's specific business logic.

I would also argue that frameworks (generally) scale better - not necessarily in terms of performance, but definitely when talking about code organization and design patterns. Having iterated and developed standards over time helps with this a ton. Working on a gigantic rails project is tough (though manageable), but working on a gigantic custom framework involves much more cognitive overhead, especially early on.

Anyway, no matter what you use, you're going to be solving problems. Which ones do you want to spend your time on?

I think the "Vanilla JS" approach shouldn't even use any backend. The way you've set up the projects with the backends feel very reminiscent of 90s stuff where every action you took was sent and the page refreshed (I haven't run the code, so I can't say, but that was from reading the Node.js code). Having a global array storing the files, or even manipulating localStorage would be a 100x better way to compare this code to other frameworks.

Just some thoughts from glancing at the project.

A thoroughly interested read. It's nice to stand back every now and then and ask "why am I doing it this way?" Usually the answers are terrifying "we've always done it this way" or "it made sense at the time". I'm totally for a proportional solution. Why build a rocket when you're only going to the supermarket?

I think you should differentiate opinion and facts, the most reason framework are used is for good common standards that is hard to get as solo developer something like security stuff, I think if you are creating a simple toy app then that is cool as you can kill anytime.

"why shouldn't use a framework" pretty much tags frameworks as bad news. As a developer who can code with or without a framework, I would say that it depends on what you are coding. Some of the frameworks are unnecessarily cumbersome, yes, but that in itself is not a valid basis for an argument.

For instance, if you to code a clone of a system like Yelp, a framework like Laravel in PHP would 100% be better off than coding it from scratch if you have limited a budget! A biography page shouldn't need an angular scafolding when vanilla Js or jQuery should suffice!

You can move 20 tons in a shot with a 18-wheeler, or you can make about 6-8 trips with an average family truck for the same loads.

You always use a framework when coding. The difference is whether it's written by you or someone else.

Ill paraphrase Uncle Bob, "frameworks should be a plug-in and not the basis of an architecture".. if the first thing you do when discussing your architecture is pick the framework, you're already wrong. You also are "buying in" to said framework which could theoretically change at any time. You are at the mercy of the author(s). IMO, and how I design systems, architectures are just a tool that is lovely coupled to the core business logic.

Interesting stuff.

How have frameworks managed to kill businesses? was it due to having to refactor the code sitting under them to a new version?

Let me tell you my story.

I work for an online school and 3 attempts were made to rewrite the entire learning management system into symfony, codeigniter, and then laravel. The LMS was written in old school PHP 3 code that had just barely made it's way into 5.2 compatibility. The structure of the site was a loose set of scripts with a few global libraries and no object oriented stuff, relied on input globals, etc.

The codeigniter attempt had 2 super huge controllers but implemented at least 75% of the functionality before a wall was hit with that approach.

The laravel attempt only got 15% of the way there before the programmer gave up.

I got my job maintaining this legacy application and throughout the course of 1 year, refactored it to be compatible with 7.2 and beyond. Only until recently has it seen any object oriented code, which was just an experiment.

The other programmers sold the company on a rewrite by touting the benefits of these frameworks. Last time, the owner was told that we Laravel was great because it could do caching, easy APIs, database abstraction, and had an admin panel addon that would make redoing the backend easy.

None of this stuff materialized and the refactored LMS is running on a 1GB mem amazon instance without caching because it's written more like a C program and has the performance to match.

The laravel backend plugin was horribly buggy and crashy; but that might have been because we had a crap programmer. 100% of the laravel code was written off as a loss, because none of it could be used in the old system - it was too dependent on laravel.

I do wonder if the intense layering of abstractions and the scattering of tiny objects that have maybe 1 or two methods, adding up to 1000's of objects, is even comprehendable to the programmers trying to follow that ideologies.

I tried asking a SOLID devotee writing some popular upcoming forum software how he managed to trace execution in his program and he could not provide me with an answer..

Your node.js implementation doesn't sanitize static file path, allowing an attacker to load any file from disk. Framework would have likely prevented that :)

That said, I also prefer to plug in individual libraries into my own architecture rather than hack around some framework's quirks or, God forbid, try to glue several of them together. Especially in the node ecosystem, which lacks real batteries included mega-frameworks a-la .NET.

Your approach in that todomvc code of doing everything from scratch is going a bit too far for my taste, though.

Thoughts

I think you may be missing a huge factor as well. A huge reason to even use a framework to begin with is standards. Everyone knows how to interact with the code and bringing on new employees is as simple as advertising the framework. They will be able to integrate nicely with it very quickly if they are familiar with it. If they are not familiar with but know the language it might take 3 months or so on a large codebase, in my experience.

If you are building your own applications from scratch and you expect your employer to higher people to come in and learn an entirely new application that was built from scratch with no prior knowledge or being able to work with it then you are going to cost your employers thousands if not tens of thousands of dollars when you leave.

You might not see it now because everyone knows the codebase but try to get some new people into it who may have never coded an application before. You're going to make their life hell and they are going to ask 1000 questions they don't need to which also takes away time, money and resources from other parts of the company. Again, talking from experience here. My first company I worked for did this and it was hell but she (the lead dev) thought nothing of it because she was the one who built it.

Bad Premise

Your entire argument is based off of the premise that a framework calling your code is inherently bad. You say your code calling the library is good but the framework calling your code is bad but you have no supporting argument to back that up? Why is a framework calling your code bad?

If you say it's because it makes you too restricted to how the framework does things then why is that bad? If you say it's because of the structure of the code or the methods you use is forced on you then why is that bad?

New Features

Also when you use a framework you have the benefit of tens or hundreds (sometimes thousands) of contributors working around the clock just for you and your software. New features? Sure! just check the roadmap and when new features will be added to your application.

Documentation

When coming to a new framework you have the advantage of having 100's of pages of documentation to come through. Masonite has ~550 pages. This allows new developers to reference the docs instead of ask all those questions. Noone needs to fire off a slack message "how do you set a session again? I can't figure it out".

They can:

* Read the docs
* Check stack overflow questions
* Read community articles about how others did it.
* join official lines of community like framework discords, slacks, email lists etc.

There is much more to using a framework than being forced to code a certain way.

Frameworks are a result of an incredibly fast and competitive industry, with a lot of passionate people finding new ways of solving problems and sharing them. I like to see no-framework talk, but I think it's so important to know how much frameworks help when building dynamic web apps. Your server-only approach would probably be unaccepted nowadays, if the goal is to have a fast app with rich and dynamic user experience.

Things today are tough for sure. New developers have so much in front of them and jumping to a framework before being comfortable with basic web principles is a terrible approach. But things don't have to be that complicated. Getting started with a framework and seeing which problems it solves does not take a long time at all. Also, there are less opinionated frameworks (React!) that don't enforce architecture, besides the usual component structure that most frameworks nowadays adopted.

Edit: I just realised, that you assume, that every developer you will meet is a highly capable, very well educated person (probably with decades of experience) who spends hours and hours thinking about every single line of code he/she writes. Meanwhile in the real world we have people with nearly zero experience, who try to achieve results after checking the first tutorial (probably even some portion of it) they find on stackoverflow or google. And this is OK, because most probably the end user need something to get their job done and they need it now, not a decade later.

I carefully read the article and didn't find any real argument against using frameworks. Yes I dismiss all your arguments especially the only real one: that we don't need them, but in fact they save lot of time and this is basically the most precious thing we have in our life. You can do something small like a To-Do list in any language, but when you keep adding more and more featured you will end up writing tons of code and solving problems, that others did before you. Most probably you will need other people to help you. The bigger your codebase is, the harder it will be for them to figure out how it works. This is why framework popularity matters - it's easier to find someone to help you.

Great article. I like the advice that you give here, and I am fully on board with you regarding JavaScript frameworks. Some frameworks are good and mostly necessary (ie., ASP.Net MVC, etc.) but these are backed by huge corporations and have support, tons of documentation, and will be around for quite some time.

I think that if someone knows how to write a web application from scratch, using only libraries, then they can easily pick up and learn a new web framework. (Well, I guess 'easily' is relative. Some of those frameworks have quite a learning curve, even for an experienced coder).

However, if a young developer learns web development using a framework, and then moves on to a new project where that framework isn't in use, then he/she needs to either learn a new framework, or actually learn how to code without relying on a framework. How to manage state? How to manage history? How to manage binding? Frameworks have implemented a lot of the boilerplate code to do these things, but they all do them differently.

However, one of my biggest hangups about web frameworks is their transient nature. What happens to that big enterprise project five or ten years from now when FrameworkX has gone out of style and no one knows it or wants to work on it anymore?

How many devs are out there struggling to maintain a big Angular.js application written five or more years ago, which was too big and complicated to convert when version 2 came out, and besides there was no compelling business case for management to allow for a conversion effort?

Now the rest of the world has moved on to the completely rewritten, new and improved Angular, and the company has to try to find developers willing to work on an old, out-of-date framework that no one wants to work on. I suppose this isn't so different from other frameworks of the past, but at least they had a longer shelf life (e.g., ASP WebForms).

And how does one find decent documentation when the frameworks change so fast the documentation can't keep up?

And please don't get me started on the thousands of dependencies these frameworks rely on. It seems to me like a house of cards ready to fall.

I get the arguments about standardization, etc. But that argument only holds so much water. The standards change so fast that the word barely has any meaning.