This was downvoted but as someone not too familiar with modern frontend design I'm actually wondering about the comparison myself. When would you use this?
It is staggering to me the quantity of developers who are still made uncomfortable by the notion that you can construct a high-quality, modern web experience without pulling down a single 3rd party javascript or css dependency.
I really hope the pendulum starts to swing back the other way. It is so fast & easy now. MDN makes life a breeze. In 2022, there really isn't an excuse to not use direct DOM manipulation and bare-ass JS, other than pedantic ideological arguments such as "why is my hammer this shitty color?" and "My monster.com filter can't find 'vanilla js' skilled employees".
As noted by other posters, VDOM is essentially just overhead. It is both faster & easier to grab that element by its id and change it directly. Playing around with intermediate UI representations, 3rd party frameworks and splitting state between client & server is where 99% of your hell comes from on web development.
When you understand 100% of your javascript, setting breakpoints and tracing things in devtools has a lot more power. Hiding from the realities of the open web is only going to cause a prolonged suffering for the junior web developer. Frameworks will come and go. document.getElementById() will be here until the end of time.
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.
