Original author here, thanks for the comment! I also think that backend would be an interesting subject to try and reduce, if only to not constantly wade through 100s of Dependabot pull requests... It's a very different scenario where you will want to optimize different things (code size usually does not matter as much, for example) and you have various deployment options (serverless, containerized, edge, ...) etc. so quite the Pandora's box, I think. Interesting nonetheless!
I find "web platform poorly designed, therefore frameworks with 100s of dependencies" a bit too easy, especially when the user experience suffers in the end. I also believe that not every complexity needs to be solved with code. Isn't it a worthwhile exercise to figure out if something can be solved with (significantly) less code?
> It has to be somewhere.
I tend to agree; I think I'm just trying to not shift it to the user device's runtime.
One method of a simpler web is, ironically, porting traditional applications to the web. I mean compiling C or C++ apps to WASM and then running them.
Typically, then you get extremely rich and complex user interfaces with less work. The problem is though that this is still janky. It's not a smooth, or even viable, experience sometimes.
But it goes to show that making applications via the Web IS unnecessarily complex. Because the tools, being HTML, JS, and CSS were never intended for applications but rather documents. Personally, I think it's a sliding-scale type thing between documents and applications. Anyway, the standards have been expanded to try to address the application use cases but it's all "bolted on" stuff. And the document stuff also has to stay because that's still a primary use case.
Like, I would rather shoot myself than try to replicate photoshop in the Web. I'd much rather use Qt for an application like that.
Original author here. No, you don't need all of it; everything is optional (as stated in the article). It's just a boilerplate with some tools and conventions, so "using it" has little implications, I think. Other than that, I'm just trying to have fun out here :)
Thanks for this, gives my intuition some words to back it up!
I find especially compelling how the author separates concrete problems like reconciliation (hard to argue against) from the abstract principle of "everything should be a component" (can be argued more easily IMO).
Shamelessly plugging https://github.com/morris/vanilla-todo here; in this try-hard-to-stay-vanilla case study there are similar conclusions: Reconciliation is hard, CSS global namespace is problematic, etc. - I also did not use web components, but could not explain/justify that decision well (until now!).
Original author here, thanks for sharing! The case study has been discussed back in 2020 [1] but there have been quite a few updates (ES2020, local dev, testing, etc.) since then. Happy to chat!
> The point is requirements change, features are added, and when an abstraction becomes wrong, tear it out.
I like this phrasing a lot, thanks for this!
I'm still wondering if there's also potential in avoiding the wrong abstractions in the first place. For that we'd need a "cheap" way to decide whether an abstraction is good/bad/something else.
Is there generally applicable, widely accepted principles or research around this? A quick search only revealed random blog posts; nothing I'd consider widely accepted.
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.
I've heard the Assembly vs. C analogy a couple times now, and find it hard to apply:
Assembly languages come in many flavors whereas C is a single, standard abstraction over these.
DOM is a single, standard API whereas frameworks/libraries come in many, ever-changing flavors and provide different abstractions over the DOM.
It's a very different situation. Also, the level of abstraction that C provides over assembly is amazing. The level of abstraction that React provides over the DOM is comparably low (they are based on the same programming language).
Thanks to everyone who took the time to read it, and thank you all so much for all the feedback! I'm quite overwhelmed by the response :) looking to address as much of the feedback as possible by the end of the week.
A major weakness seems to be my choice of ES5. I wanted an almost absolute minimum, which ES5 seemed to be at the time. I was lead by the fact that most bundlers produce ES5 by default, which may very well have been a mistake.
Interestingly, if ES5 is really dead (which it might be, I'm not sure) and ES6 is the minimum target, the study's results would actually improve drastically (less verbosity, actual modules, etc.) and further support the claim that vanilla can be maintainable (even without build steps). For anyone interested, let's continue the discussion here: https://github.com/morris/vanilla-todo/issues/6
