Consider replacing react for something lighter

[KeeganMyers]

In an effort to trim some fat on the front-end I evaluated and removed as many dependencies from my cljs as I could. I noticed through this process that react is fairly large and began searching for other options. Of the wide variety of reactive JS appearing lately inferno seems like one of the most promising. It appears to be lighter and faster than react. https://github.com/trueadm/inferno

I was curious how feasible it would be to transition from react + reagent to inferno. I think the biggest challenges would be writing a layer to translate hiccup into inferno, and replacing the ratom. The first item should not be too difficult as inferno's components look similar to react's. The second issue may require more time.

I could see this being done in one of two ways. 1 re-frame brings necessary functionality into its core. This would break backwards compatibility and not be beneficial for all users. 2 re-frame could offer the choice of reagent or another similar library written around inferno. Depending on the time commitment involved I may be willing to work on the inferno cljs abstraction provided there is any interest in this initiative.

[mike-thompson-day8]

A few comments:

1. I'm all for React alternatives. React was a 1st attempt in a novel new direction and, historically, that means fast following alternatives will probably be better because they get to learn from React's mistakes. We've all seen that technical pattern play out before. But, having said that, Facebook has put rather a massive amount of effort into React, and given it a very clear future, so it is a very safe option right now. Any new alternative would want to be pretty damn good to justify the move away from "safety".
2. If you do want to use an alternative, then I'd be interested to know why inferno is better than, say, snabbdom or some of the other strong contenders. Although I can see that inferno is closer in API to React, which might be a consideration. I guess it will depend on your usecases: for some "smaller" is really important, whereas for others faster is what matters, or perhaps a more flexible API (easier to do animations?), etc.
3. This isn't really a re-frame issue - this is more of a Reagent issue. Reagent is a layer over React, and re-frame is a layer over Reagent. So swapping in an alternative to React will involve a new version of Reagent but there is every chance re-frame will be untouched. From your comments, you do appear to get this, but I thought it worth stressing.

As a next step, I'd fork Reagent and come up with a version which used your favorite virtual DOM library. If I were doing it, I wouldn't worry too much about keeping the same API as React, to quote Emerson ...

When you strike at a king, you must kill him

If you get a better version of Reagent happening, then re-frame will be easily adapted I'm sure.

[ghost]

I agree with all the above points. I'd also like to mention that any alternative, despite being "better" (however you qualify that; faster, fewer bytes, simpler api) must also contend with the huge offering of react-native. A very large amount of work has been poured into that project, and it introduces a whole new paradigm for multi-platform development. Addons and extensions keep cropping up, too: just last week react native for osx as an alternative to something like electron, but with even smoother web->native passage.

This might very well be another case of first-to-market / widest-adopted takes the cake.

[ducky427]

I think for re-frame, the most crucial bits are the r/atom and the r/reaction bits which come from reagent and not from React strictly speaking.

I maybe wrong.

Edit: I am wrong. its more complicated than my initial reaction.

[mike-thompson-day8]

I'm going close this due (1) reservations about the concept (2) a lack of apparent recent progress. But I'm always open to the new, so it can be reopened if there is compelling new information.