The Pros And Cons Of JavaScript Micro-Frameworks


The concept of the JavaScript micro-framework has always existed, tackling tasks ranging from client-side templating through compact solutions for MVC-architecture and beyond. With an increased recent interest in combining such focused solutions into a custom modularized framework for your production needs (as opposed to say, using a larger library that tackles broader concerns), I thought it would be interesting to take a look at micro-frameworks to find out what the true pros and cons of using them might be.

Before we get started, I should mention that whilst I have an involvement in the jQuery Project, I subscribe to the notion of using the best tool for the job at the end of the day, whether that happens to be an established library/toolkit/framework (eg. jQuery, Dojo) or an alternative micro-solution. Hopefully this post will come across as balanced in that respect.

Why consider micro-frameworks?

It's no secret that with each subsequent release, well-established libraries, frameworks and toolkits increase in size and this has some developers questioning whether the entire stack of functionality provided is required for the average site or project. We live in an age where performance and page-load time are constantly under scrutiny and thus, a developer couldn't be blamed for attempting to cut down unused code from their site's overall load.

The reality is that you may only wish to use a subset of features offered in a library like jQuery (eg. selection, animation) but may not require support for ajax, DOM-associated data storage, deferreds and others. The library may also not provide everything your project needs (it's naive to think it ever would), however we can appreciate a developer asking whether that 30KB+ download of the library could be replaced with something significantly more modular that does cover more of their own needs.

This is an area where using micro-frameworks can potentially offer the greatest benefit to a project (especially where mobile is specifically targeted).

Thomas Fuchs has been attempting to make developers more aware of micro-frameworks through efforts such as (which you should check out) and there certainly appears to be enough interest in modularized frameworks for a broader discussion on micro-frameworks to keep going.

Some prominent JavaScript developers certainly have strong feelings about them on both sides of the debate. The release of Ender.js (a package management system for creating your own modular library) has also prompted developers to consider giving micro-frameworks a shot and may be worth a cursory look.

The pros and cons of micro-frameworks

Let's now take a look at what I consider the pros and cons of micro-frameworks:


  • Micro-frameworks generally encourage building small, tight and loosely coupled components that can then be assembled by the developer.
  • In many of them, a focus on solving specific problems means that a great deal of manual optimization must be done to ensure code is as DRY and focused as possible. The result of this is that you're unlikely to have large chunks of code in the framework with solutions to problems that won't be utilized.
  • All-encompassing frameworks and libraries have a problem: if they don't support the behaviour you require, you'll either need to find a solution around the walls of the framework, write in what's missing yourself or you may be out of luck. Using jQuery as an example, one could argue that because modular builds are not available, a developer wishing to use it would require the entire library (including those parts they don’t wish to use). They would then also need any additional micro-frameworks to be padded on top followed by their application logic, rather than having a modular solution *just* containing solutions to what they need. That said, bear in mind that current modular solutions such as Ender have had issues trying to get completely independent libraries working together. It’s tricky smoothing out the rough parts of mixed micro-frameworks but this situation may improve with time.
  • As micro-frameworks usually attempt to solve specific problems rather than larger concerns, a custom modular library could be put together consisting of a few <5-8KB micro-frameworks. Whilst size is something often promoted as a reason for using such frameworks, it’s very important to note that size is an unsophisticated way of selecting frameworks. It isn’t an indication of code quality, functionality or just how appropriate it is for what you’re trying to solve. Size may not matter, but modularity is, however, key. This is in my opinion the biggest draw towards using micro-frameworks as opposed to larger libraries.
  • Modular code could very well be the future with micro-frameworks being capable of easily plugging together as needed using a common unified API. Something both modular, well documented and cross-browser would be ideal for developers concerned about these issues.
  • Ease of understanding: some micro-frameworks contain significantly less code than their library/toolkit brethren and whilst this may mean fewer features, they offer an unparalleled opportunity to understand how a minimalist implementation of a solution to a problem might be approached. A very important note to bear in mind here however is that this is certainly not always the case – there are framework developers that place more emphasis on file-size over functionality, readability and compatibility and if a micro-framework jumps on the pre-minification bandwagon, it can mean that this benefit is lost. Ideally, minification should always be left to your build-process to handle so that your code is as kept as readable as possible.


  • Larger libraries have a number of benefits which not all micro-frameworks may be able to provide.
    • They typically offer a greater deal of cross-browser coverage, due to the number of browser quirks and edge-bases that are worked around beneath the bonnet. Micro-frameworks are not always able to offer this due to the fact that the codebase needs to be kept as minimal as possible (many micro-frameworks are also quite young, so there could still be a significant number of issues yet to be discovered). In this respect, there may be a greater risk of you or your team having to work on patching issues with the framework itself.
    • They're generally more heavily tested. Each feature and major change in well-established  solutions requires unit tests and the entire library test suite to pass  in order for the changes to make it into a final release. Whilst some  micro-frameworks do thoroughly test their solutions (and should be  commended for it), it's important to be wary of those that do not (sometimes just due to lack of time by the project owner). Well-tested production-ready code is only as good as the components helping to provide it's structure and functionality.
    • If modules aren't going to  be interoperable, we may well see a significant amount of redundancy  because none of them will be dependent on each other. The issue here is  that the separation of concerns/focus may well result in much  duplication on 'core' level helpers.
    • Your modular framework may grow. At the moment one of the most compelling reasons being pushed to use micro-frameworks is size. Your codebase (and it's requirements) may well grow with time and one has to ask oneself just how long it may take before a framework composed of many different modules might well surpass the size of a library.
    • Some micro-frameworks (certainly not all) are what could be considered one-man operations. Whilst a single individual (with or without community contributed assistance) may well be able to maintain a framework, bug tracker and docs, the reality is that were they to move on, someone else would need to be found who could take over the day to day handling of the project.This isn't the case with larger libraries as they typically don't rely on a single individual, but rather a larger group of developers to maintain the codebase and handling of the project.
    • Centralized documentation and bug-tracking is often not possible with micro-frameworks. When using 5-10 solutions to create a custom modularized framework of your own, each component project is likely to have it's own repository, it's own documentation and each of these will need to be checked separately should you require assistance when writing code. Whilst this could be considered a moot point, it is one that is relevant when considering the amount of time available to actually develop a project.
    • Outside of jQuery, other libraries and frameworks such as Dojo, MooTools and YUI already heavily emphasize modularity and code reuse, allowing you to use only what you need. These solutions are mature, have been tested and used in production and may offer a more reliable alternative for those searching for modular solutions than something custom based on micro-frameworks.


So, should you consider dropping that large library for a micro-framework?

As the majority of developers I've spoken to regarding micro-frameworks have brought up jQuery's filesize as their reasons for considering a switch to the micro-approach, I'll address a few concerns here. Bear in mind this is my personal opinion and may differ with those held by other members of the community:

By selecting an option such as Ender’s Jeesh starter-pack (a fraction of jQuery's 30KB), you actually may lose quite a significant amount of cross-browser stability and consistency. Edge-cases actually account for some of the smaller quantities of code in jQuery core, but it’s smoothing out issues with WebKit and IE that are most highly catered for behind the scenes. I’m not attempting to finger-point Ender out at all, but it is essential you’re aware of what you may be gaining vs what you may be losing.

In addition (and something quite important to note) most of what we've used micro-frameworks for in the past are features which jQuery doesn't (and may well never) provide in the future: MVC helpers, browser state management/routing, pub/sub, baked-in templating, cross-browser storage, (a)synchronous script loading and more.

If you don't require it’s features, there is absolutely nothing wrong with falling back on vanilla JavaScript (or another library) for your selection needs. Just as long as you're *sure* that's all your project demands.

Remember that jQuery's biggest strengths lie in being the best cross-browser DOM-manipulation and selection option out there at the moment. It's mature and for the most part, reliable. Whilst I know developers would like something more modular, John Resig has said on multiple occasions that a truly modular version of the library would be very difficult to put together and likely won't be on the cards anytime soon.

With this in mind, if you absolutely know what you're doing (and what to look for) you can of course select a more modular-suitable substitute, but you should heavily test whatever you replace it with to ensure it's on par with both Sizzle and the rest of the library's capabilities you'll require.


When deciding on which option works best for you, bear in mind both your current and future needs, level of browser compatibility required and the level of confidence you have in deploying a custom baked solution to production.

At the end of the day, it's up to each individual developer to make a judgement call here on which option makes the most sense for them (and their team) will ultimately depend on which solution satisfies the majority of your needs the best.


  1. Why does this read like jquery vs a microjs lib?

    it's not about jquery's modularity or its replacement with a micro framework. Look at mootools, for example – it allows COMPLETE dependency based control over what components of the library you need to use.

    Need to use it serverside? No worries, add array, function, object, class only. Just the Slick selector engine? No problem.

    What Resig may have said will be hard to achieve in jQuery has long been a feature in mootools:

    • I disagree. In my opinion, jQuery's modularity (or lack thereof) does relate to it's similar lack of intelligent dependency management based on what is used.

      For example, if jQuery was more modular, adding in the ability to only load what is used may in fact be more feasible. Right now (to the best of my knowledge) it's still quite tightly coupled so neither modularity nor complete dependency management are really that possible.

      Also, the reason why it compares jQuery vs micro-libs is (as mentioned later on in the post) because most developers that speak to me about this subject look at the broader spectrum of custom libraries fashioned from several micro-frameworks vs it as the option for their front-end JS stack.

      We all *know* that you can use microlibs/frameworks for a dozen other things that have nothing to do with just DOM manipulation or libraries like jQuery, but this post attempts to address the questions and concerns my readership have had about this topic recently.

    • What about Sencha’s frameworks – ExtJS covers all these micro frameworks and has Sencha Cmd which allows you to remove what you don’t need from the framework, giving you the best of both worlds and tonnes more features.

  2. What jQuery (and other large libraries) gets you is the plugins. When I don’t have time to write my own code, they save my day.

  3. Yeah, about modular JS libraries such as MooTools or jQuery UI. Select a handful of components, and watch as their dependencies add up to a significant proportion of the full library. And then you have to worry about remembering which components you selected. Might as well just use the whole library from the start. No, jQuery doesn’t lose anything by being monolithic.

  4. Great article! I think that the problem of those micro frameworks is the lack of commitment that the dev may have with it, therefore I wont use it on corporate projects.

  5. Interesting article Addy.

    Two things that occur to me:
    1. As libraries get to a certain size – and the popular ones inevitably do – they should adopt a more modular design. It just makes sense.
    2. If everyone used google's cdn (or cdnjs) for the popular libs like jquery, would the browser caching not negate the file size argument?

    • I completely agree with 1. and as for 2. this is something that's actually come up in discussion many a times when I've been debating micro-frameworks with colleagues. It does negate the file-size argument.

      Where the discussion goes beyond that is probably areas where jQuery doesn't provide the behavior needed (and there are plenty of places where it doesn't). Micro-frameworks are of most use here.

  6. "everyone used google's cdn (or cdnjs)… would the browser caching not negate the file size argument"

    File size is indeed not that big an issue in this case. With an expiration of one year, the browser/proxy cache is leveraged to an extent that I personally don't mind adding a 30KB lib won't be downloaded that much. If it's not in the cache, then you get the advantage of having it server on another domain so concurrent downloads are possible.

  7. Your article doesn't actually discuss microframeworks that much—you mostly talk about why you think jQuery is awesome; and throw in tons of reasons to make it appear that micro-frameworks are just toys and shouldn't be taken seriously.

    Your argumentation is not sound in many places.

    Statements like "may lose quite a significant amount of cross-browser stability", "an unsophisticated way of selecting frameworks", "there may be a greater risk of you or your team having to work on patching issues" and "there are framework developers that place more emphasis on file-size over functionality, readability and compatibility and if a micro-framework jumps on the pre-minification bandwagon, it can mean that this benefit is lost" are all creating FUD towards micro-frameworks; and have various implications such as people that promote micro-frameworks being unsophisticated.

    My main reason for is that people actually learn JavaScript as a language, by being exposed to other people's code; and make active choices when writing software; as opposed to just going with whatever is this year's "established" or "mature" library (all the big frameworks have bugs and issues all the time, ftm).

    However, my biggest gripe is with "the level of confidence you have in deploying a custom baked solution"—this insinuates that developers can't be trusted to make decisions in their own projects, and that they need to be hand-hold.

    How can we ever learn, progress and ultimately build awesome stuff when everything has to be about caution and "maturity" and hand-holding?

    • Must say I'm growing less and less impressed with your bedside manner. You seem to address everyone with a snarky tone and sometimes indirect snide remarks. Your completely committed to micro js being the sole answer going forward and often berate larger frameworks, especially of the mvc nature. You don't seem to give any true credence to the idea that things could go many ways here, and that higher abstraction may win (again) because it can ultimately deliver more with less code (nice when building larger applications.)

      You really need to relax and learn some manners and realize you are not the authority on all these matters.

      • Where do I use a snarky tone or say I'm an authority?

        How am I completely committed to micro js?

        I use big frameworks every day. I wrote some of the most popular big frameworks being used on the web.

        I'm pointing out fallacies in the author's argumentation; and I'm charged with having no manners.

        But I'm sure you just want to "help" by telling me how I'm wrong.

    • Thomas, whilst I don't agree with your take on the post, I do value your input to the discussion. With that in mind, let me try to augment my position with respect to micro-frameworks a little better:

      I agree that developers can learn a lot from the frameworks posted on – it's an excellent resource and if you check, I actually mention the educational value of MFs in the post for just this very reason. I've also been trying to get people to use many of the more (now) well-established MFs since their conception, so I certainly don't believe they are all unsophisticated at all.

      Where my concerns lie are not with well experienced developers who are aware of what is needed to 'custom bake' a complete solution (obviously they know what they're doing).

      I'm concerned for those who are at a beginner or intermediate level in this industry and may see micro-frameworks touted as a viable *replacement* for any existing (and slightly larger) solutions that have been tried, tested and are easier for them to use without as much risk as a custom-baked solution in production (whilst some of them are at this level, there are those that aren't).

      I feel that micro-frameworks are best used as utilities *in conjunction* with these existing frameworks as a means to fill in behaviour that isn't already provided. It isn't about extending the lifespan of libraries like jQuery, but rather appreciating that their ability to smooth out cross-browser inconsistencies makes them worthy of the additional download.

      I do still encourage developers to try out micro-framework solutions in their projects – heck, we all need to learn somehow.

      Many of those frameworks offer a great number of advantages (especially where things like jQuery simply can't handle what is needed) *however*, surely you can agree that walking down the path of DIY solutions with MFs is something which requires care and significant testing if a developer is trying to replace something like a library for DOM selection or manipulation.

      If a developer feels confident they can craft something reliable bearing testing in mind, then they're free to use whatever they're comfortable with, whether it's a completely custom baked MF solution or something else.

  8. In my view, jQuery is also a microframework in what features it offers and should never be compared with app-frameworks like MooTools, Ext, Dojo, SproutCore etc.

    As someone who build applications, not web sites, I’d never ever go the micro-route, macro frameworks FTW!

    My 0.02 SEK

  9. As the co-creator of Ender and the Jeesh (and several other Ender modules) I can vouch for its x-browser stability. Saying it's young is one thing — saying it's unstable or buggy is falicious. All software has bugs — and fwiw, The Jeesh has over 175 test cases passsing in all Grade A browsers. Plus considering it covers 95% of jQuery's API for only 25% of the size – it's a pretty big win.

    • @ded Addy wrote

      > By selecting an option such as Ender’s Jeesh starter-pack (a fraction of jQuery's 30KB), you actually may lose quite a significant amount of cross-browser stability and consistency.

      Ender/Jeesh are very young. The problem comes down to bumping versions w/o testing Browser compatibility. This creates releases versions like Bean @0.0.35 or earlier that fail in Firefox 3/Opera, Ready @0.0.2-0.0.4 fails w/ syntax errors, or @0.0.5 that fatal errors in IE. Bugs are one thing, but these are critical errors in major browsers that find their way into versioned/released code.

      Addy continued:

      > Edge-cases actually account for some of the smaller quantities of code in jQuery core, but it’s smoothing out issues with WebKit and IE that are most highly catered for behind the scenes.

      This is true too. For example currently Qwery will error in IE < 9 with selectors like `html *`, and fails to consistently return elements in source order from browser to browser.

      More mature projects usually don't release versions that critically fail in targeted browsers and have processes in place to ensure that doesn't happen.

  10. Pingback: The Pros And Cons Of JavaScript Micro-Frameworks | Keefr

  11. Pingback: Linkdump for June 9th | found drama

  12. Nice post @Addy. I feel that choosing Micro-Frameworks is a choice thing for the developer.

    Ive used YUI, Mootools and even JQuery UI. Even though I know that alot of code is redundant, the fact that I don't have to worry about dependencies when I want to add another piece of functionality is enough reason to stick to Libraries. as for JQuery's size, for God's sake its only 90kb for Jquery 1.6.1. Thats packs the most amount for bang per buck Ive ever seen.

    The way I think about the plugin architecture is Jquery's way of implementing modularity

  13. I think comparing jQuery isn't a bad idea, it has after all, become the most ubiquitous framework available on the web.

    On its homepage, there is an explicit statement : "jQuery is designed to change the way that you write JavaScript" – I think this is where the danger lies. Whilst it silently fixes a lot of the issues you may come across, for new coders this is quite obviously a problem. I personally struggled with JavaScript until I found jQuery.

    Recently I've been using Ender, and where it doesn't cater for my needs, I've fallen back on traditional JavaScript. Having a modular framework that leverages smaller frameworks is a fantastic way to work, and I know that Dojo, YUI also do this – but where Ender excels is that it opens the door to open source and external frameworks that haven't been specifically designed for Ender itself. It does need some more work, but given time, I think it will patch up where it lacks. As is the case with every framework, just like jQuery used to be.

  14. Well,about modular JS libraries such as MooTools or jQuery UI. Select a handful of components, and watch as their dependencies add up to a significant proportion of the full library. And then you have to worry about remembering which components you selected.

  15. Pingback: JavaScript micro frameworks | Farkas Máté

  16. Typical Ender quirck I stumbled upon while trying it on a small and personnal project : the keypress event in Bean (its default event provider) don’t do cross-browser normalization to charCode like Jquery : IE8 and below send a good old keyCode.

    I like Ender and its 30kb shaved, but I would not risk it on a paid project.

  17. I see so many folks bloggnig on file-size arguments as being the brunt of their library-decisions …but is 30kb really THAT big a deal? Instead of micro-analyzing file-size and/or selector-speeds maybe we should limit how much functionality is being pushing into a single page? Maybe I’m wrong…but…if you’re using AMD alongside lazy-loading techniques I don’t see many problems. I dunno…maybe that’s where I need to be corrected?

Leave a Reply

Required fields are marked *.