Ask HN: Best tiny JavaScript framework? | Hacker News Reader

Ask HN: Best tiny JavaScript framework?

29 pointslevthedev44 comments

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?

View on HN

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).

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.

http://mithril.js.org/

Size < 8kb gzipped (includes routing and ajax)

Do you know of any good mithril projects out in the wild?

https://en.lichess.org

https://voyager.cancoin.co/ is a bitcoin block explorer using Mithril with Websockets (and an Elixir/ZMQ backend). https://github.com/cancoin/bitcoin-voyager-web

Flarum is a good one - like Discourse but nice: http://flarum.org/

Memrise.com use it for their apps.

Guild Wars 2 uses it for in-game UI.

More here: https://github.com/lhorie/mithril.js/wiki/Who-Uses-Mithril

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/

I like the dom wrapper this guy came up with: https://hackernoon.com/how-i-converted-my-react-app-to-vanil...

I adapted it for myself here: https://gitlab.com/heycato/domjs/blob/master/dom.js

"VanillaJS is a framework written many years ago by a dude called Brendan that is rarely used anymore."

That is the funniest thing I've read all day.

oldy, but a goody: http://vanilla-js.com/

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?

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.

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.

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!

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.

Try https://github.com/wavesoft/dot-dom

It looks like tiny React and is just 511b gzipped.

Shilling my own library here: http://simulacra.js.org

No template syntax to learn, one function API, 5kb gzipped.

Choo! https://github.com/yoshuawuyts/choo

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.

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.

Roughly 6/7ths of the world have slow devices and slow connections.

"The web sucks if you have a slow connection"

https://news.ycombinator.com/item?id=13601451

https://danluu.com/web-bloat/

PX2: https://github.com/burtonsamograd/px2

A better designed version of Backbone with a small footprint.

NoJS (posted few days ago):

https://news.ycombinator.com/item?id=13816429

intercooler.js may fit the bill: http://intercoolerjs.org/

http://mithril.js.org/

Reply on news.ycombinator.com