Hacker News Reader

Comment by rtsao | Hacker News Reader

For folks who really care about performance, the easiest win is just switching to Inferno or Preact. You can pretty much leave your React code unmodified and get massive performance gains.

View on HN

Easiest win for me was trying out re-frame[1]. Not only do you get the best performance out of react, to the point where the actual virtual-dom implementation doesn't matter, but you also gain productivity and since it forces you to build apps made out of 95% pure functions and immutable data, reasoning even at scale is still incredibly easier than anything else I've ever tried to build GUIs with.

[1]: https://github.com/Day8/re-frame

I've maintained a ~20k LoC re-frame app for a year and a half. The performance of Clojure's persistent datastructures with pervasive sCU gives you generally good performance but it's not panacea. I've debugged a hundreds-of-milliseconds freeze on laptops from a poorly written hierarchical menu and I get pauses of 70-100ms if enough data comes in on our main view.

Using it with cljs-time and storing times in the app state is a really easy way to shoot yourself in the foot perf-wise since that's based on closure's date object and two equal date objects are not identical. This fails the fast identity check but will pass the structural equality check so no vdom gets generated but the check is not that much cheaper than a diff.

This is also a B2B app where we have no demand for mobile use so I haven't had to do load time or mobile perf optimization. If I did, the first thing I'd be concerned about is the bundle size since the cljs runtime plus React represents a fairly sizeable amount of overhead.

Not to say that reagent+re-frame is bad, it's just not so amazing you don't have to care about perf. I think Reagent would run particularly well on top of Inferno since the library provides lifecycle events to function components and I did experiments back in April and June on Inferno with persistent datastructures to good results. I just don't want to maintain it.

I tend to abuse the fact that subscriptions can compose in re-frame to lower the work needed in order to react to app-db changes. The fact that you can namespace keywords make it easy to scale as well.

Its also easy to optimize if you integrate day8/re-frame-tracer. I've lowered the number of views touched by updates quite a bit using it. I barely put any pressure on React anymore.

The bundle size usually isn't that bad with full optimizations enabled. An empty cljs project strips the entire cljs runtime for one, minus one defonce. You can also pass a compilation constant to react to strip its debugging features; that's saving you a few dozen kilobytes as well.

I'm currently building a small app to display Twitch chat as a personal side project and it handles GamesDoneQuick's chat effortlessly. Performance has been great so far.

re-frame might be technically interesting, but you're switching to writing in a lisp, which is a very niche choice. That's not going to be an overall win for many people.

Considering Clojure's impressive adoption I wouldn't call it a niche choice anymore; it even seems to be a win for most people adopting it.

Can you provide stats on "Clojure's impressive adoption"? By my understanding it's still a very niche language.

The TIOBE index [0] fwiw (please debate) suggests by going from JS to Clojure you'd be switching from the 7th most popular language to the 47th.

In that 'top 47' there are only 3 lispy langs present, 'Clojure', 'Lisp' and 'Schema'. That suggests programming in lisps is a very unpopular idea.

[0] http://www.tiobe.com/tiobe-index/

TIOBE is a terrible indicator generally. More activity doesn't mean more people are using a language. I wouldn't work for anyone using it to make decisions :)

The Cognitect website[1] lists quite a few success stories using Clojure. I would trust the names in that list far more than TIOBE.

But really what sold me on the language was the quality of the libraries, the incredibly helpful community and its shared focus on simplicity. Reading about a thing is no substitute for hands-on experience; its hard to judge the trade-offs you're making without it.

[1]: http://cognitect.com/clojure

A simple warning: switching to Inferno using inferno-compat can currently give worse performance than react. I tested this recently when Inferno 1 was released and think it's related to https://github.com/infernojs/inferno/issues/548 The techniques outlined by Netflix should apply to users of Preact and Inferno too, so it's still an interesting article.

It would be awesome if you could give the Inferno team your feedback so we can help improve Inferno. :)

Inferno sounds interesting, I wish I could use it for projects. But React has grown to the point where there are components for it you can npm install and import in whatever components you want.

Should the Inferno community start porting over stuff to their ecosystem it'll be easier to sell to clients.

You can point 'react' at Inferno at build time. I believe there's a Webpack plugin that does this.

Reply on news.ycombinator.com