Riot.js & MicroJS, a misplaced initiative
I was recently asked for my opinion about Riot.js and what I thought about the MicroJS movement, as part of my residency for the wonderful Hacker Retreat initiative. Here's my thoughts.
Looking at the source, Riot.js is only a jQuery based event emitter you can attach to instances called observable with a trivial router that aliases to pushState. Everything else, you create, including the the CRUD abilities.
As someone who've recently tried to go Micro.js. I've actually given up on this rebuild from the ground up style approach. There is no support, no documentation, and no community to help you accomplish big prime time applications. Once you hit a wall, or try do to something that isn't included in the trivial amount of code there is, you're on your own, with no help besides "figure it out! that's what micro.js is about!".
This problem at it's core is about context. What Backbone, Ember, jQuery, and all the "monolithic" frameworks/libraries have in common, is that they have context, and with that context comes community, and with community comes support and sustainability. They all work well because they are a house built of bricks through a consistent process. Rather than a bunch of bricks, with a DIY process.
That being said, the underlying problem people have with monolithic libraries, is not that they don't do their job well, they do it incredibly well, but that you end up with the kitchensink, meaning you get things you don't need. The promise of MicroJS, is misplaced. It's not that people want to build their own homes with their own bricks by themself. But rather, people want control over the building process of their home.
The solution as I see it, isn't being left with a bunch of bricks and told to DIY (MicroJS), or with a house and saying your stuck with it (Monolithic), but rather with unbundled frameworks. To imagine this, it is Backbone being a specification, and then frameworks go about meeting that specification. You have a module for events, a module for models, a module for views, a module for routing, etc. Rather than one monolithic module, you have a bunch of bundled modules which make a suite.
This idea has been well executed with underscore. If you look at underscore as a spec, then you have underscore.js and lodash that meet it. With lodash you also have custom builds, making it as micro as you want. Same story with jQuery as a standard, implemented by jQuery and Zepto.
The closest I've found this to exist with full fledged frameworks, is just like how it's applied to underscore with lodash, the same is happening to backbone with exoskeleton.
This idea, has allowed me to use the conventions, support, and community (the eco-system together) of Backbone for webwrite/inlinegui, with the views/controllers and routing of SpineMVC. Which is working very nicely.
The analogies you use seem off. You are seeing the micro approach as discrete bricks. This is not at all the case - the micro approach is just another level down and no too dissimilar to the component based approach common to UI development. Your analogy should really be the full house prebuilt, whether you like it or not, versus the modular home kits you can pick up these days that you can quickly and easily customise.
To use the phrase ‘misplaced initiative’ also seems little off. The micro approach sets out to do exactly what it sets out to do, and claims to be only what it is. There is nothing misplaced, nor is there any lack of an appetite for its place in the scheme of things.
You claim a pro for frameworks due to their ‘consistent process’ and you say they are better documented. This is just not true as a blanket statement, at all. Any decent developer can form lines of code into block statements into object oriented abstractions into new libraries into totally consistent, optimised, fast and much easier to reason about codebases. Frameworks have no monopoly on consistency, and do not stand out as being better or worse in this regard (I'd say they are actually more consistent, but I am happy to just leave it neutral as it starts to get subjective).
The thing that really bothers me is this - your points make so a bit more sense when only one framework is needed in ones toolbox. The reality is that multiple frameworks are needed and used by nearly all web developers. This completely negates the point of ‘frameworks’ in the context you present them here - they are really just larger and more clumsy ‘micro’ pieces - but too big to do the job properly the way a ‘real’ micro piece would. Indeed, this is exactly what makes the micro approach so very much NOT misplaced. We are picking and choosing and slotting things here and there no matter what - aka the beauty of the micro approach.