Blog

In the last example I put online, we’ve noticed that it was difficult to achieve a good separation of concerns in the front end if we are building UI directly through DOM. Apart from the fact that it’s very inefficient, manipulating DOM directly makes it very difficult to structure your front-end logic. You quickly realize you need a framework for that.

And here I come to a big fat point I want to make once again, that I made in my session, too: don’t build a new framework; pick one off the shelf.

The thing is, in the JavaScript world there are ridiculously many frameworks. This article on Hackernoon is an introduction into this total insanity: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f. There are memes, jokes, comics, websites, even Alexa skills that address the fact that people keep creating new JavaScript frameworks all the time. Guess what? A tiny fraction of them generate any traction at all, and only a few stick.

And don’t get me wrong – I am totally for improving things; “the room for improvement is the largest room in the world” they say. But I am not quite convinced that building a yet another framework will benefit the posterity all that much. If you want to improve on what we have, most of the leading frameworks are open-source, contribute away.

As with previous (and future) posts in this series, there is a GitHub repo + branch that accompanies this blog post, and you can find it here: https://github.com/vjekob/supercharged_01/tree/02-framework

(The featured image used under CC license from https://worldpece.org/content/how-standards-proliferate)