So, look, I get it. There’s a lot of JS frameworks out there right now. You have your React with its virtual DOM and mind-boggling synthetic events; Angular that tries to be your whole existence; Vue which is good but still another framework whose author has very strong opinions about how code works; and then JsBlocks that just leaves you alone but still offers you the benefits of MV* architecture (yeah, I know it’s not a real “*” but this is the blog, so whatever). To me, they all try to solve the same problem with mostly orthogonal but oftentimes overengineered solutions. There’s no “better” in here. It’s just…different.
What sold me first was performance. JsBlocks doesn’t use a virtual DOM because you don’t need one if you just track your dependencies. It manipulates the real DOM directly, but only the parts that changed. Which sounds kind of trivial but then you realize that a lot of frameworks abstracted themselves so hard they forgot browsers are actually pretty decent at DOM manipulation these days. And sure enough, after testing it in some performance benchmarks, I was getting React-like component mentality with much less overhead. And if you’re actually building websites that load quickly (not just look pretty in demos and starter projects), the performance difference becomes pretty critical, especially on mobile.
Meet JsBlocks, if you somehow have managed to live under a rock. JsBlocks is MV-ish (yes, they say that, probably on their changelog) JavaScript framework, or just a JavaScript framework that focuses on MV part of the whole shebang. It is quite barebones, or at least tries to be. The sales pitch is two-way databinding without too much overhead. Write your HTML, then use some declarative attributes to tell it how to work, wire up JavaScript model, and have it reflect the state of your UI. And vice versa, when DOM changes (usually due to user input), your data changes as well. No virtual DOM diffing, re-rendering of entire component subtree when user types a single character in a text field. If that doesn't scare you a bit as a performance freak, I don't know what will.
Templates are similarly sensible; no need to invent a new language when one already exists and works just fine. It’s HTML with some handlebars-style syntax thrown in. Sure, some folks like to scoff and say handlebars is passé, but it’s easy for your designer to read, junior devs can work on the templates, and you’re not forcing your entire dev team to learn JSX or FrameworkX’s-thing-that-shall-not-be-named templating DSL. And their binding syntax actually makes sense; data-query for attribute bindings and event listeners, if/each/with for basic control flow. Simple. No magic, no confusion, no deciphering some engineer’s “brilliant” one-liners.
Syntax-wise, if you have ever used Angular, Vue, or that old ish but still kicking around Knockout, you will be right at home. There is data-query attributes, to bind values, loops, each, conditionals, if, all that jazz. It is all declarative in your HTML, which some people love (helps to separate concerns) and some people hate (mixing logic with presentation, they wail). I, for one, think it's fine, not a big issue. You can see what's happening without jumping between ten different files, which is especially helpful for smaller projects, smaller internal widgets, UI-intensive stuff. Where this can actually be a win.
Just one more thing, not one that was promised in the headline, though. JsBlocks… is not really maintained anymore, or at least not actively. Last big release was some time ago. GitHub repository exists, documentation is still available, but the community is just not there. And that, in my honest opinion, is a pretty big red flag if you are looking at this to do something serious, some big production-grade app. Because having no active community behind something is bad. If you have weird edge cases, or if you need plugins, chances are, you are on your own. Stack Overflow has… like a dozen questions on JsBlocks total (might be an exaggeration, but not by much). So, yeah, solo.
Routing and Single Page Application support is a thing (SPA-frameworks without a router are just silly, amirite? ), but it’s not something you’re suddenly forced to use after the Hello World tutorial. You can, if you like, just use JsBlocks for one little widget on a mostly-static HTML page. Framework doesn’t try to shame you for that, which is…refreshing, actually. Router is also refreshingly simple. You define some routes, associate them with components, optional parameters, and query strings, integrate with the browser history API if you want. No magic here either, just…works.
Bundle size is not bad either, even with all that magic. I don't remember exact numbers, but probably something between 20-30kb minified or something, definitely less than what React + ReactDOM weighs. Framework that also gives you templating, databinding, computed properties, basic component model, and even supports Virtual DOM manipulation is not that bad at all. Not as small footprint, of course, still a few kilobytes larger than hyperscript, or raw DOM API, but much more ergonomic. Few kilobytes for a ton less boilerplate.
Learning curve is, really, where I see the biggest “bang for buck” for teams. You can get a junior dev up to speed on a project in a day or two because the concepts map closely to what they already know; HTML, simple JS, very familiar data-binding concept. It’s an open-source project, no opaque, “one-click, six hours of dependencies you don’t know about and if I tell you the full file tree you’ll faint” build step required for dev (though you can add it yourself, with Webpack or whatever you like); if you prefer that, that’s great, use it. No require you to install and configure and make sure it works on your machine before you even write hello world. Just add the script to your page, start building stuff, and add a build process if and when your project outgrows the easy start. And those projects, surprise, are not uncommon.
Component system is also good. You just define components as plain objects, with template, viewModel, and some lifecycle events/hooks. Not as slick as modern React hooks, or Vue's Composition API, but is quite serviceable and mostly straightforward. State is stored in your viewModel, updates propagate automatically. Child components can communicate via properties/events. Nothing earth-shattering, but nothing broken either, just solid, predictable, and reasonably straightforwards patterns to use that get you where you need to be without forcing specific architectural dogma on you.