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.