Hacker News Reader

Comment by pcr910303 | Hacker News Reader

I think hooks aren't really making React more of a black box, but just that it's invalidating a lot of people's incorrect mental models on how React works. (It's like C's undefined behaviors in that sense.) And the reason why a lot of people have these incorrect mental models is that React is a very thick abstraction.

For a long, long time, I thought that to provide the values that React brings, the UI framework being a black box is inevitable. Almost all React-esque libraries including but not limited to React, Preact, Mithril felt like a very thick abstraction over the DOM APIs.

But then I saw Crank.js[0], and that felt very intuitive and a thin abstraction, while retaining the good parts of React-esque libraries. I don't really know why it feels like that - I'm guessing it's because it uses native JS features that you already have a good understanding instead of some magic that happens in the React runtime.

I'm very looking forward to it, and I would like to urge everyone to try out Crank.js if you feel that React is now not intuitive enough.

[0] https://crank.js.org

View on HN

(disclaimer: mithril author here)

The point of an abstraction is to create a "black box" of sorts around some primitive. I think all it boils down to with what the author is saying is that the React team is changing how things work under the abstraction, and therefore some assumptions people made about leaked semantics are no longer true.

Mithril rendering semantics have always been more or less this: on an event, redraw everything. React semantics started that way too, but now there are a whole lot of other semantics under the hood (for example, the rule of hooks provides some semantic guarantees that enable a hot reload implementation to be more robust). Concurrent mode is another example of semantics that benefit from rule of hooks guarantees.

I think when I see people complain about the rule of hooks is that there's a dissonance between the strict semantics of hooks and the expectations of what the semantics should be (for some definition of "should", usually related to ability to reason about stuff in some specific way)

I'd say that overlapping several different compatible underlying functional semantics under one umbrella of very strict API semantics is an interesting and somewhat novel approach to supporting some cool infrastructure (i.e. ability to do deep hot reloading stuff, animate in IoT devices in a renderer-agnostic way, React Native, granular reactivity via memo, and the list goes on). Where I think React missed the ball a bit is that the API semantics don't always feel ergonomic for the use case they're meant to serve (for example, I've seen a few occasions where nested hooks ended up w/ long code review threads debating obscure minutiae)

When I see people praise Svelte, I think the reason is similar: since it doesn't need to artificially create constraints to support every use case under the sun, its API semantics are able to align very closely to people's expectations.

Hi, it's Jared (the OP)...

Well said. Perhaps my deeper point is that hooks and soon Concurrent Mode force devs to come to terms with the fact that they _don't_ understand React internals (hence my usage of black box) and that their mental models were wrong this whole time (although some might argue still pretty productive).

I also think Crank is SUPER interesting on so many levels. I built a few demos with it and am fairly impressed. However, practically speaking (and I'm putting my developer relations hat on), I think its generator API is just too intimidating to junior developers.

I usually explicitly tell devs to not worry about React internals. Let React decide when to re-render or how to batch state updates. React's API is small, developer time is better spent understanding the API than wondering how React works under the hood.

That said it's still a mental shift. Sometimes I feel like I'm writing React and not writing JavaScript.

I noticed at the end of the blog post you stated that you're very excited about the debut of the upcoming Concurrent Mode (CM) in React. I've read about the problem that Concurrent Mode is working to address; but I'm confused as to why React needs this additional feature set when I'm unaware of any other UI frameworks which have a feature set that seem to mirror that of CM. Vue or Svelte do not seem to need these additional features to achieve comparative rendering benchmark speeds to React, and I'm unaware of any holes in these frameworks that something like CM would adequately address. (?).

Is Concurrent Mode basically a way of addressing performance problems in React, or is this in some way a feature that adds something novel? Or is it just a side effect of an unwillingness to move away from functional programming?

I write React at work, but write Svelte or Vue at home, and I've always found React's abstractions to be the most hard to reason about, and from the looks of it CM will make this more challenging (??). Thanks.

Isn't the wider problem that people don't try to understand the internals? Some of us may read the code of modules we "require", but experience tells me this is a rarity.

For those that do, this isn't an issue, and for those that don't, this isn't an issue either. Their mental model may be flawed, but as long as the IO is the same, do they really care?

Concurrent mode isn't really a black box. Its just a shortcut to throw away work that would otherwise be invalidated.

Hooks are fine. The approaching ConcurrentMode though is scary. Most of the global state solutions are suffering from various kinds of incompatibility with the concurrent mode that opens the door to various kinds of bugs:

https://github.com/dai-shi/will-this-react-global-state-work...

useMutableSource fixes these concerns. they all will light up green. some have it already as a draft or experimental, for instance zustand: https://github.com/react-spring/zustand/pull/160

with concurrent mode i think of what could be, web applications that can compete against native for the first time. as well as making making components that are resilient to async issues / making async a high level concept. there's a little churn for sure (for library devs, and a specific subset), but imo completely worth it.

> with concurrent mode i think of what could be, web applications that can compete against native for the first time

Native apps feel better than web apps because they have robust UI libraries that web apps do not. React concurrent mode will have zero effect on that.

If the argument is "React concurrent mode will make web apps faster so that they feel more native", my response would be to use something like Svelte, which is available today and is considerably faster than React. React is slow.

Concurrent mode may make React faster but it'll just be making up for React's past mistakes, not the web's.

It's really unfortunate that Web Components are utterly useless. They simply are not components. It's insane.

I am not sure what you mean. Youtube is built on web components. Github is using web components. There are various libraries that can do web components, including Preact, Vue, or Svelte: https://webcomponents.dev/blog/all-the-ways-to-make-a-web-co...

In what way are they not components? They have identity, state, can draw output, and accept user input.

What's your definition of component?

If you have an application that renders more items than Svelte can handle (not many, we're in the web, you have 15ms max per frame, on a single thread), it will simply keel over and die. Scheduling is natural in native systems, you have occlusion, prioritization and threading of course. Svelte has no means whatsoever to counter load.

With what React is attempting currently your app will render as much as it possibly can while maintaining stable 60fps, the rest gets deferred while it can differ between lesser and higher-priority updates. If you doubt how important scheduling is, look at practically any feasible list component, they're all virtualized. With React every aspect and corner of the application is like that. In theory it could outperform native apps.

Btw, there are countless of robust desktop apps being made with HTML: VSC, Whatsapp, Skype, Spotify, Notion, Hyper, Discord, Slack, ... thought most of them will still feel sluggish compared to a native counterpart. React will change that.

Half of the "robust" apps you mentioned including the context of performance are neither robust nor performant. On really good hardware.

That is my point. They are robust from a UI perspective, but none them can compete against native due to the slow nature of the dom. This is why React is building a scheduler.

> countless of robust desktop apps being made with HTML: VSC, Whatsapp, Skype, Spotify, Notion, Hyper, Discord, Slack

VSC: chokes on files larger than several mb Slack: eats all of your memory, often hangs and just whites-out while I figure out what to do. Skype: has this app ever actually been good? Spotify: not sure I'd call it robust, but it's functional...enough.

> In theory it could outperform native apps....thought most of them will still feel sluggish compared to a native counterpart. React will change that.

My understanding is that native apps hook into far lower-level functionality and run with _signficantly_ less overhead. They simply execute faster, and far more directly. I don't see how React and needing to go through react-framework -> JS -> V8 -> etc would possibly compete with that, let alone outstrip them.

These apps all fall flat, which is the point i'm trying to make. They're robust from a design perspective, the tools we have to build UI are good enough, but they can't compete against native. Do you think that using Svelte in any those would make a difference? This is why React is attempting to find a solution.

The problem is essentially the same. Native apps are also conflicted with load, they have better means than we have on the web to deal with it, but it's still low-level and complex to orchestrate, threading for instance. Any one of those means pushes your app into async issuee, race conditions that you need to reconcile. With concurrent mode scheduling is a first class concept, your components won't be subject to race conditions. React maintains 60fps, high-priority content (user input, animations, transitions) can be ran fluidly while lesser priority content gets deferred. It has a good chance of outperforming multithreaded native apps with that model.

This demo illustrates the issue: https://youtu.be/nLF0n9SACd4?t=172 which is universal. You run into this on native platforms as well as on the web.

> not many, we're in the web, you have 15ms max per frame, on a single thread

Isn't the likely way forward to move the computationally heavy parts of the app over to web workers and to keep the main thread almost exclusively for UI work?

It's funny you mention Mithril, because to me, that was the "minimum level of whiteness" box. I tried react fairly early, and when I did something wrong, it was completely unobvious to figure out by debugging the non-minimized code.

Mithril was sufficiently thin for me to drop into the debugger, say "oh, that's how it works" and fix.

I'll take a look at crank though. I do frontend dev only to make my hobby projects accessible to friends and family, so the less to remember, the better.

>I think hooks aren't really making React more of a black box, but just that it's invalidating a lot of people's incorrect mental models on how React works.

Isn't that exactly the point that the big image on the front page is making? If most people have a mental model of a technology that doesn't match what the company is putting out, it makes very little sense to blame the people who have the 'incorrect' mental model. If it wasn't so widespread, your point would be much stronger. But the fact that the core pieces of react are misunderstood, especially when React publishes documents explaining how all of this is supposed to work and how you're supposed to think about this is an indication that something is wrong with React, not the people who use it.

> If most people have a mental model of a technology that doesn't match what the company is putting out, it makes very little sense to blame the people who have the 'incorrect' mental model.

While you're right that we shouldn't "blame the people", I think blaming the company / library in this case doesn't fly either, given the specifics.

The "incorrect mental model" people have about React is based on two things:

1. the prevalence of OO concepts in programming education and in practice in most engineering teams

2. the introduction of class abstractions onto JS prototypes by the ES spec.

followed by:

3. React bundling things like `createReactClass` and encouraging class abstractions in their docs in the pre-hooks days

While the 3rd point above may have been a mistake on the part of the React team, I do think points 1 & 2 are much bigger factors here.

> something is wrong with React

The only thing "wrong" with modern React is that they're challenging the status quo in popular programming concepts with something they believe is a conceptual improvement.

You can disagree with them on whether it represents a true improvement, but saying they're "wrong" because their conceptual model is a departure from the status quo is pretty reductive.

> 1. the prevalence of OO concepts in programming education and in practice in most engineering teams

What makes this point tricky is that React did initially introduce their library with OO concepts for years.

Yup; mentioned that as point 3.

To put that in context: that was at the time ES was starting to introduce OO abstractions to the spec. and it was somewhat trendy to go in that direction. I never got the impression that the React guys were heavily invested in that paradigm, and they definitely moved away from it very quickly after first encouraging it in their API. Everyone makes mistakes.

As a side-note: I think class abstractions in ES are a feature that in retrospect is less of a great idea now than it may have seemed at the time. ES class abstractions obscure their own subtle issues (in a very similar way to the article's fake Twitter screenshot jokes about React hooks).

From my perspective, the sequence was:

- From 2008-2014, _everyone_ was writing their own "class-like" abstractions (see: Backbone, Class.js, five million other "inheritance" libs). So, the React team wrote `createClass` as their own implementation.

- When ES6 classes came out, the React team took that as an opportunity to drop maintaining their own abstraction and switch to something that was actually standardized, and reduce the amount of magic behavior (auto-binding, mixins, etc).

- Function components came out in React 0.14, and were initially limited to just rendering based on props - no state or effects possible

- Hooks now give function components the ability to have state and effects. In addition, encouraging a move away from classes dovetails into the React team's long-term plans for the React APIs.

Yeah, great rundown.

The class abstractions added to ES spec. didn't happen in a vacuum; it was very much on the back of community demand. Backbone especially had an outsized influence.

Perhaps that was a necessary step toward realising tools to solve problems without those abstractions, I don't know.

Perhaps React is just as complex as it needs to be solve the problems it tries to solve. Is that a true statement? Probably not. Close to true? Maybe.

Whatever the case, just because we wish solutions to those problems were easier to understand doesn't mean reality owes us that. I suspect React in particular, being in the web dev space, has a lot of people working with it who have very little CS background. Because they don't understand how React works under the hood or even above the hood is "something wrong with React"? I'm not sure I buy it.

I've seen a lot of really poor React code that breaks all kinds of best practices, many of them explicitly laid out in the docs. Even before hooks came along. In fact it's been hard to find examples of people who understand the dom well, much less React. I will continue to suspect there's something wrong with most of the people using React, not React itself, which from my perspective has only become better over time.

  > has a lot of people working with it who have very little CS background

This and so much this. This applies to "frontend development" in general. I work as a contractor in the frontend space (Europe, no where near FAANG like companies) and very often I meet other "devs" that have basically become frontend "engineers" out of being a webdesigner - like you know, creating nice html templates for wordpress, having decent CSS and photoshop skills and later in their career started to copy-paste some jquery plugins into their template to get nice animated toggles and alike. It is very common in "frontend teams" that people started to get into JS out of webdesign, and have never actually programmed in any other language.

Another issue is even with people with a CS or another STEM background, they only get taught in the "traditional" OOP sphere on top of blocking thread environments. Those usually have a hard time wrapping their heads around higher order functions or async-based development (and to be fair, I also had a hard time when I first encountered it).

Most rank-and-file development doesn't need async and HOF. If your framework does, it's either screwed up or for a special/rare niche. I've been in these debates many times, and when examples are given I can usually trace the "fault" down to the framework or limits of the language. I stand behind this claim.

At least in browser-world, most APIs (i mean the ones defined by the web standards) are built around async/Promise/callbacks/HOF, like it or not. There is no switching to other languages/framework when targeting the browser as a runtime.

This is largely because JavaScript has weak areas.

Crikey. Higher order functions are rare or niche?

To my mind they are oftentimes magic pixie dust that can turn a hideous, verbose and inflexible API into something humane and readable.

Not quite what I said. I said they are not needed for rank and file application (domain-centric) development, IF the tooling and programming language are decent.

If you bring up a scenario, I can probably poke holes in it. Done it many times in many debates. I don't mean to sound arrogant, but I keep winning THIS one for whatever reason.

> I've been in these debates many times, and when examples are given I can usually trace the "fault" down to the framework or limits of the language.

I don't disagree, but my follow-up question with that statement is "ok, now what?"

If you've got a weak/inexperienced developer who's stuck in a framework where they have have to start grokking async/HOF/whatever to solve the problem they've encountered, where do they go from there? It's fine and good to blame the framework they're operating in to be shitty, but they a) didn't have the skills initially to make a solid decision about the framework to use, and b) are now likely stuck with it (unless they're going to do a rewrite with something else).

I agree that our current tooling requires more "rocket science" than it should to do ordinary things. I'm not sure how to fix the entire industry, but the first step to solving a problem is admit there is one.

Early cars were hard to learn, drive, and maintain. Over time they got better via trial and error by manufacturers. The desktop IDE's of the early 90's were like this, but got better over time (until web ruined their market). However, the web is still stuck in 1903: simple things are esoteric. Perhaps because too many other things about "cars" keep changing? Something is wrong. CRUD web dev is a mess.

Most software engineers without a strong background in physics or CFD won't be able to reliably explain how an airfoil works either. Having a wrong mental model (equal transit time of air molecules resulting in lift) does not mean airplanes are not useful.

The question is not whether your mental model is incorrect, but whether the deficiencies in your model cause problematic consequences. For example if my model of how wings work is that "the slower you go the more lift you get", should I pilot a plane I'd probably end up getting in trouble.

See nearby for my early-car analogy.

After using hyperscript via Mithril, I don't think I can go back to writing JSX. Hyperscript should be the defacto way to template HTML in JavaScript in my opinion, it's just so much cleaner and readable.

It's been the way Elm describes its components; and I believe Andre Staltz has been criticizing jsx in favor of hyperscript since forever [0], and included hyperscript in cycle.js.

Lit-html, which is using template literals, is another good option.

[0] - https://staltz.com/some-problems-with-react-redux.html

Back when jsx was introduced people said so too but they weren't as loud as the other group. When you look at a completely new language, reasonml where they're still of the mindset that jsx bring familiarity it makes nosense. Just an excuse for some abitrary preference.

Someone might find these issues interesting on flutter regarding jsx:

https://github.com/flutter/flutter/issues/11609

https://github.com/flutter/flutter/issues/15922

I remember getting excited learning that I could do Xamarin Form in plain function calls in F#. Android is going similar journey simplify UI programming with Jetpack Compose. Jsx is backward and purely stylistic.

I love Mithril but I find hs to be noisy to read and tedious to write.

It's probably because I've been reading and writing HTML for +20 years though.

Yes, probably. I started using haml (then slim) a very long time ago and the hyperscript / elm type syntax is fairly intuitive to me.

What is the point of templating HTML? I really don't understand it. Just write HTML or HTML-like APIs like JSX. Is there some theoretical reason why this is wrong?

Subjective I guess. For me it’s just a reduction in noise and I prefer to read code with significant white space. Perfectly ok writing HTML, but given the option, and if it doesn’t screw with others, I prefer not too.

JSX is HTML templating

(mithril author here)

hyperscript is about as close to a middle ground as we can get. It's compatible with JSX for the folks that really really want to see angled brackets, while still being uniform javascript like other API variations (div(), html`<div></div>`, etc). The lit-html syntax is not bad either, but template strings did not have as widespread support back when mithril originally came out.

Yeah but why isn't it just HTML?

Why isn't what just HTML?

Is there a roadmap for mithril? As in, what are the current pain points, where development is headed, etc.

I've given stewardship of the project to the community. At this point, it's largely in maintenance mode. Most changes are tightening up loose semantics and the like. IIRC the last major was only a major by technicalities; it didn't really break anyone unless they were relying in weird obscure behaviors.

Since the framework isn't interested in chasing trends and since it provides extension points via lifecycle methods, there's really nothing novel that needs to come from the framework itself.

I know some of the more popular frameworks make it seem that webdev is constantly in churn/evolving, but if you look at React for example, other than the hooks paradigm shift etc, it hasn't really changed all that much in scope over the years either (the same can be said about other libraries as well).

For example, Mithril could easily be used w/ coffeescript when that was still a thing, and people use it with typescript these days too without much fuss since TS is also a project that decouples well. And this is with zero changes to the framework. You can integrate dragula or plupload or google maps or whatever via lifecycle methods as you always could too.

So, TL;DR: I think the focus still remains on making it as stable and robust as possible

This was helpful. Thanks!

Does mithril provides typescript function signatures for its API?

They're on definitely-typed

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/87f2...

To me Reagent is the ultimate answer to the markup/code mix. A single language, ClojureScript. Nothing is done in strings except text. I absolutely love it, but haven't been able to use on a production project yet.

[0] https://github.com/reagent-project/reagent#examples

I really like clojurescript in theory, but have a dumb practical reason for not being able to use it. I do a lot of programming in common lisp, and am way too used to a lisp-2.

I literally can't write more than 100 lines of clojure without accidentally shadowing a function binding with a variable binding. I think the only way to break the habit would be to abstain from common lisp for 6 months or longer.

I have the opposite issue trying to write in emacs-lisp after doing lots of clojure. I try to:

  (mapcar my-func my-list)

and it throws void-variable and then I remember that I have to add the #' reader macro to have it read as a function not a variable.

  (mapcar #'my-func my-list)

It just takes some time to switch the mental model over each time. Clojure did get me in the habit of using unique names for all functions and values because accidentally shadowing a function binding is that more difficult mistake to debug.

In practice I haven't missed the flexibility of a lisp-2, if anything it's just made my code more readable because my names are forced to be more descriptive

using hiccup to write html has been a godsend. I find it much easier to visualize the html that hiccup will generate vs JSX, and I can do arbitrary manipulations on it just like I can with any other clojure data structure.

> I find it much easier to visualize the html that hiccup will generate vs JSX,

Can you elaborate on this? On first glance it seems the same, just with a syntax that uses different symbols than HTML?

the bummer about reagent is that it allocates so many immutable data structures on render. I've not figured out a way to ergonomically write hiccup without paying this constant performance tax, which is felt on a lot of large reagent apps.

I've done a few projects in mithril, and having used both jsx and hyperscript, I tend to lean jsx.

That comes with some very real downsides - mostly getting jsx to work requires a bunch of extra (ugly) tooling. On the other hand, very complex components look very clean.

Hyperscript when you have a relatively nested dom element gets quite messy and hard to visually parse for me.

Combined with coffeescript it's even nicer since you can ditch the parentheses and have a very clean indented syntax.

As with every issue around javascript front end library, the solution is of course... a new javascript front end library.

- jQuery - Backbone - Ember - React - ???

javascript /s/java/churn

MooTools!

The only two that I'd put on the same level are jQuery and React. And people are still happily using jQuery to this day (maybe happy is the wrong word). So I don't think React is going anywhere for a long time but if something better comes out then why is that a bad thing?

It is more about the relative instability of Javascript as a platform versus nearly any other platform out there.

Skills I learned in college about writing SQL are still relevant today, several decades later. Skills I learned coding for iOS (even Swift!) years ago are still relevant today. CSS and HTML skills I learned decades ago are still relevant, etc etc. Python/ Django knowledge from 10 years ago is still largely relevant. React/ jQuery/ EmberJS/ Vue/ Angular/ Grunt/ Gulp/ Webpack/ Underscore/ CoffeeScript/ etc... damned near every Javascript library I've ever worked on has an extremely limited lifespan in terms of relevance. Even within React, it's hard to keep relevant. Class based React? We're doing Hooks now!

> why is that a bad thing?

It's only bad if you have to try and maintain 10 year old Javascript and in order to do it, you have to learn a whole new paradigm. IMO it's doubly bad right now since so many people are abandoning semantic HTML and more or less rolling everything as their own custom components.

Not exactly the case for protects like Crank built in the JSX "paradigm".

Vue (solving for not not enough batteries included / ecosystem fragmentation)

To be fair React is now seven years old. So even in the unlikely event that it’s going to be replaced by something else, the old cliche that the JS ecosystem is always churning too fast seems a bit overblown. It’s on track to be the dominant tool for the best part of a decade.

> It’s on track to be the dominant tool for the best part of a decade.

My post was in response to a suggestion that the fix for all the React issues was in fact replacing React entirely.

I love the way crank is using generators to get rid of the react complexity.... Did not know about crank, thanks for the link.

For something even more "clear box" (it's not even a framework) that you can understand in a single sitting, check out Meiosis:

https://meiosis.js.org/

Crank looks super cool, thanks for sharing. Using generators for stateful components makes a lot of sense.

I took a quick look at the docs and I'd say the API looks to be pretty similar to mithril.js. Not sure why you think mithril would have a thicker abstraction in comparison.

I feel similarly with Nomad vs Kubernetes

Crank looks interesting, thank you! I was going to try solidjs[1] (which feels pretty close to crank) in my next project, will look more into crank first.

[1] https://github.com/ryansolid/solid

I cant understand how a developer can be aware of existence of Svelte (https://svelte.dev/) and still have React problems.

Just start with creating web components in Svelte, include them in existing React code, and slowly phase out slow, and old tech that React is. This is just frontend lib, why are people so religious about this. You still use Node, JS/TS, etc.

Im I troll? Don't know, but that is just what I did year ago. Now I just laugh when I see articles like this, buy I also feel sad for small entrepreneurs that have to pay big $ for code in "dated tech" - thinking "they are on the edge".

React's big enough that large dev orgs have made big investments into it and can't switch to Svelte on a dime.

It's not only that, but there's always dragons in scaling a framework to accommodate teams of hundreds of devs and supporting millions of users. Svelte is less known in this regard. Marginally better along one or two dimensions is not enough to justify the risk.

I'm interested in this - do you recommend any documentation or writing on mixing React and Svelte codebases?

Svelte is be recommended left and right as the "solution to React" but I think it's still way too young of a project to be the cure-all that people think it is.

It's promising, especially for smaller projects/MVPs, but I still have no idea how well it will scale with app size/team size (and have yet to see good evidence that it does it well).

I just find it ironic that people dog on React for being the "default", but then also can't recommend Svelte fast enough, seemingly because its just "not React".

Svelte is so pleasurable to work with. I'm still a beginner but making my own components that can interact with dom elements (for things like three.js/d3.js/peaks.js) was clear from the documentation almost immediately. I'm in the process of reworking some static sites with Svelte because I can re-use the components I make everywhere and the build pipeline is so simple.

We just tried Svelte in a small project at work, and it was a pleasant experience. Like its small api footprint and closeness to plain html/js and its small bundle size.

In our setup with parcel we didn't get good error messages and line numbers (it spit up internal compiler errors), but it might have to do with our setup. Trying it at home with snowpack it gave comprehensible error messages.

Omg, a promise based render chain? I'm in love.

is this a thinly veiled ad?

Good old XKCD 927 applies [1].

"This system is hard to work with" -> {Abstraction created} -> {Abstracted extended to support new features} -> GOTO 10

Now you have n+1 systems to learn & reason through.

[1] https://xkcd.com/927/

This was my thought as I counted 9+ React alternatives mention in this thread alone.

This is the stuff I've counted so far (I know they are not all React alternatives): Preact, Mithril, Crank.js, Hyperscript, Reagent, Closurescript, Elm, Cycle.js, Lit-html, Haml, Slim, Jsx, Meiosis, Svelte, Formik, Vue...

Reply on news.ycombinator.com