Ask HN: Best tiny JavaScript framework?

29 points by levthedev ↗ HN
I'm deciding on a Javascript framework to use in building a real time chat application with a tiny footprint. I can't use React, Angular, Ember, or Vue because they are too large. I would build the app in vanilla Javascript, but I fear that it will become more and more difficult to maintain and I will end up reimplementing many already solved problems.

Some of the frameworks that I've seen that are small, fast, and well-liked are Preact, Inferno, Mithril, and Ractive. Does anyone have any experience with these, or even better, thoughts on a comparison between them?

45 comments

[ 5.6 ms ] story [ 125 ms ] thread
If you need tiny footprint best idea would be just to use Vanilla JS. But you can look here for some libs/frameworks for specific parts http://microjs.com/
Is there a maximum file size that you're looking for? Because Vue.js is pretty small, 23K after gzip:

https://gist.github.com/Restuta/cda69e50a853aa64912d

I love Vue and have used it before, but I would like to use an even smaller library if possible. I believe Inferno is 9kb and Preact is 3kb, so Vue isn't that far off, but I still would like to hear people's opinions on the truly tiny frameworks.
Preact's size for the amount of functionality and performance you get is unbeatable, I'd say.

If you do find something smaller, the amount of glue or performance related code you add will probably end up being more than Preact.

There are two that I know of that are truly tiny: Monkberry[0] and RE:DOM[1] which are respectively 1kb and 2kb in size.

[0]: http://monkberry.js.org/

[1]: https://redom.js.org/

Wow, these are very interesting libraries. I hadn't heard of either before today but they both look similar to what I am trying to find. Have you used either of them? I wonder if anyone uses them in production.
Why do you need such a tiny footprint?
I need a footprint that works well with mobile devices, slow internet connections, etc. Also, I prefer smaller frameworks as they have less cognitive load - I usually am more able to read the source code, understand the API, and so on.
I posted the suggestion above before reading this. I don't think you can get smaller than JavaScript + Handlebars. This is the route I took for pages that need to run in slow mobile devices.

You can even precompile your Handlebars templates as an optimization and include a smaller subset of the Handlebars library that is just the runtime without the compiler.

Yeah handlebars is not a bad thought. And that's cool about the runtime optimization, I didn't know that.
How big do you think your application code is going to be? There's not much point making your life a lot harder for the sake of about 15 extra KB for example. If their internet connection is that bad then the web page probably shouldn't contain a single medium sized image on it. That's a tiny amount of data to be worrying about.

You'd be better using something small and efficient like Vue to get it released and optimise it later if it's successful. Optimising now for extremely small file sizes doesn't sound like a good idea to me in terms of getting it finished.

The reality with side projects is they're much more likely not to be used because they're not finished, not because they're a few KB too big.

I designed tko (https://github.com/knockout/tko) to make it easy to re-use the best parts of Knockout using tree-shaking ES6 imports.

When experimenting with substituting a few modules, I've gotten it down to 4.5k gzipped.

It's still quite early on (alpha), but already some folks are using it in production. Plus, it's mostly backwards-compatible with Knockout.

While it might not be an ideal, usable solution for this problem yet, it's definitely moving in the direction of filling exactly this niche (among others).

How about basically no framework with svelte? https://svelte.technology/
Svelte is a framework... that disappears at build time.
Svelte is actually one of my top choices! I didn't include it by accident but I love the concept.
http://mithril.js.org/

Size < 8kb gzipped (includes routing and ajax)

Do you know of any good mithril projects out in the wild?
(comment deleted)
Vue is really small: 18kb min+gzip is tiny compared to the competition.

Check also http://riotjs.com/ 9.73KB (gzip)

Riot seems quite similar to Vue, and at half the size is pretty appealing. Have you used it in production before?
Have a Look at Backbone.js. http://backbonejs.org I have choosen the lib for similiar reasons and i loved it
Backbone rocks. As well as the source code, which is very easy to understand.
For virtual DOM I don't go full React, I just use Maquette with Jade templates.

http://maquettejs.org https://github.com/nextorigin/gulp-pug-hyperscript

For a small framework, I've been using SpineJS for years. https://github.com/spine/spine/

Example with Maquette:

https://github.com/nextorigin/maquette-mapper

Using focused, quality components has let me upgrade my stack piece by piece over the years while retaining backwards compatibility.

Ooh, Maquette looks very interesting!
Do you need a framework at all? I think you could get away with just plain JavaScript and include Handlebars if you want a templating engine.

Maybe add Jquery if you want something just above plain JavaScript.

Edit:

Another benefit of Handlebars is that if you ever do decide you need a full framework, you can use Ember and leverage your Handlebars templates.

Yes, I am definitely considering just using plain Javascript. I just have a fear of maintaining plain Javascript applications - the hacks just seem to build up.

Then again, maybe I should just put the time in to make a well architecture and maintainable plain vanilla Javascript application. I'm definitely a fan of minimalism.

What "hacks" do you expect from using plain JavaScript? The biggest hack in plain JS is usually in my experience creating HTML elements dynamically based on data. That's where Handlebars would come in.
I just mean that over the course of building vanilla JavaScript applications, people often add layer of functionality that are implemented worse than libraries, are harder to maintain, or are not as compatible.

Like yes, I could build my own routing library, and that is probably fine, and yes I can build my own state management library, and so on, but at a certain point you are just rebuilding a framework from scratch, and oftentimes not very well.

We managed to survive and create functional websites for years without a "routing library" and without creating our own custom routing library.

But that's the beauty of using Handlebars. If at a later date you do need a full fledge framework, you can use Ember - that uses a superset of Handlebars.

My idea would be something like this.

Use any tiny View Library like Preact Inferno, etc. and use the Flux Architecture without any other framework, you implement the store by hand or using some immutable lib and use a simple dispatcher. That way you have a maintainable code since Flux is pretty popular and no big framework.

One option would be to custom build jQuery and omit the parts you don't need or like. The libraries posted all have their merits; but jQuery has so much traction. That means more folks ready to hit the ground running on what you're building ... https://github.com/jquery/jquery

Edit Gruntfile.js to do that or try a site like: projects.jga.me/jquery-builder/

You can get sub-20Kb builds with just what you need. I did that recently to inline the core parts ...

One tip, if you use the builder, take a screenshot! The file generated will have a comment block with - in front of omitted modules, e.g. -ajax if you prefer plain old fetch & other useful info. But the screenshot shows exactly what options you set.