bare js, or bare DOM specifically has no way of doing declarative changes. if you're okay writing purpose-specific imperative dom manip logic, it gets quite tedius and long in the tooth. your app that could have been 2k lines with a framework is now 10k lines without one, and will grow at 5x the rate, and amount of JS parsed and executed needed to do the same thing.
bare DOM works fine up to a certain size/complexity app, and up to a certain size dev team in the single digits.
Did some research on this a while ago and I‘d wager that 5x in LOC & growth is a bit off: https://github.com/morris/vanilla-todo - probably it’s more around 1.5x (which can still be problematic). Would be interesting to rewrite the study declaratively and compare again.
Wow, I really love that experiment. Really explains a lot about frameworks to me, despite being an exercise in not using them. Thank you so much for making that.
When I look at what you've written under those restrictions, the biggest problem I flag as a general software engineer is how the events get created, defined, listened to, etc. This tells me that if I was building something "large" like that, the first third-party library I'd want to integrate is something for handling those event streams in a more rigorous and robust fashion.
It is regrettable that "vanilla JS" seems to imply a total lack of structure and abstraction.
In my view, the size or complexity of the app has nothing to do with whether or not you should use a javascript/css framework. I believe it's more about having the experience & leadership required to pull the team together on complex, open-web technologies relative to the problem you are trying to solve.
Once a pattern has been established, its exceedingly easy for the junior developer to catch on and help out. Starting from zero is where most seem to struggle with the web. I've never had someone come to me and complain about the difficulty around adding a new field to an existing web form.
We were using a blend of Angular JS, Riot JS and Blazor over a period of ~8 years before we had the experience & confidence to dive into a 100% vanilla JS product. I can't fault anyone for reaching for something off the shelf to get started. But make no mistake - If you have the team, opportunity & experience to pull it off, vanilla JS products are the most enjoyable to develop & maintain. It is incredibly empowering relative to managing something like an Angular 1.x/2.x codebase, or even a modern Blazor server-side app.
I will also say this - The state of the open web standards is amazing in 2022, so you might be able to shortcut the training wheels a whole lot faster. Imagine if you had CSS grid from the very beginning. There are a lot of self-professed web developers who don't even know about this today because of the layers of ridiculous abstractions they are buried underneath.
declarative templates are by no means a ridiculous abstraction. graphics programming, like GLSL shaders dont have to worry about what "was" to represent what "is", they simply rerender the entire scene because it's fast. you cannot do this with .innerHTML because it's slow, loses input state (form inputs, focused elements), resets dom text selection, breaks transitions / animations, undo history, video playback, layout cache, etc.
whatever method you choose to solve this in a uniform, non ad-hoc manner will be your invented version of existing vdom or dom template frameworks, which save you from this madness. i use direct DOM only for writing high per libraries and when there is a need to optimize beyond what is provided by the framework.
i would like to see an open source, large web app written by a dozen+ engineers that manages without any ui layer abstraction and only uses vanillajs + discipline (jQuery+structure style!); in my experience this "utopia" is mostly a pipe dream, and rarely well justified.
bare DOM works fine up to a certain size/complexity app, and up to a certain size dev team in the single digits.