Comment by hbrn | Hacker News Reader

Comment by hbrn | Hacker News Reader

Parent Full thread

There's React Stockholm Syndrome: downsides of React are often praised.

Somehow people think there's a lot of foresight and wisdom in JSX invention. There's just so many good properties JSX has. But JSX was merely an easiest solution to an immediate problem.

Think about how React was created:

1. DOM management complexity gets out of hand. You solve it by treating view as a function of state (great idea btw).

2. If you do it naively, it is going to be slow. You make it performant with VirtualDOM.

3. Now that you went with VDOM, writing HTML is a nightmare. You address it with JSX.

JSX is obviously a great replacement for manually written render functions. But you know what's even better? Not writing render functions at all.

Same with setState() vs MobX/VueJS approaches. setState() was (is?) a horrible way to manage state. But it was the easiest thing that allowed you to implement V = F(S) formula at the time.

setState() a cost, not a benefit. JSX is a cost, not a benefit. I wish people stopped praising it.

JSX wasn't created whole cloth for React. It had predecessors it drew upon and there was more "foresight and wisdom" than what you are dismissing. E4X was a direct syntactic forebear. "MVU" approaches (the pattern that results in "render functions") have been quite popular in functional programming languages for a few years before React adopted it. The performance benefits of Virtual DOM were almost incidental to implementing the "MVU approach". (They helped sell it a lot, and React wouldn't have lasted if it didn't yield good performance, but the approach existed outside of just the performance benefits, including the developer experience benefits.)

JSX is easy to dismiss as a "hack to solve problems", but there was more thought put into it than is immediately obvious. It's no less a template language than other template language. It has trade-offs and advantages. At least it's not pretending to not be a template language like Angular's pretends to "just be HTML" even though it is very much not just HTML (and is closer to ColdFusion, to be unjust).

My comment was in response to "JSX with TypeScript" being a great feature of React. We may debate whether it's actually great, but this feature is accidental, there was no foresight.

Facebook was using React in 2011, TypeScript was released in 2012 (and it's not like it was immediately adopted).

Facebook was using Flow at the time and even though they couldn't have predicted the convergent evolution that produced Typescript nor the tide winds that would have pushed Typescript to prominence over Flow, they still designed JSX for static types from the beginning.

Even the predecessor tech I mentioned E4X, which were the XML extensions to ECMAScript 4, the "lost" JavaScript version, were built on static typing. The most controversial feature that killed ES4 was static type hints. ES4 never directly showed up in browser support, but it did impact web development as ActionScript inside Flash and ES4 had influence on Typescript's syntax. (In some fun ways JSX with Typescript is almost a "Revenge of ES4". It's a lot better than what ES4 would have been, but it's so heavily influenced by ES4 there's a family resemblance and clues that language design is always more evolutionary than revolutionary.)

(Not to mention that the functional programming languages like OCaml and Haskell which inspired the "MVU" patterns are all about strong static typing.)

Flow "early version" (0.1.0) was released in 2014.

Now there's a chance that they had another version used internally at least 3 years prior, but at this point we're just speculating.

But IIRC nothing in React docs at the time mentioned how great JSX is with static types. It was all about render functions.

For now I'm sticking to Occam's Razor and the idea that JSX was a hack to make render functions usable.

JSX being more easily typed is not a coincidence though.

React was not built with JSX in mind. React was built with JavaScript in mind. JSX was simply syntactic sugar. In fact, JSX was entirely optional at the beginning and all the initial React documentation had examples with and without JSX.

https://web.archive.org/web/20131118055243/http://facebook.g...

The key point is that JSX being syntactical sugar on top of a system designed to return JavaScript is what makes it work so well with Typescript and Flow. The key insight here was that components should be described using JS and not HTML. JSX was invented as syntactic sugar to make this more palatable for scores of web devs who had only used HTML. It is this decision to settle on JS vs HTML that directly led to JSX fitting in so nicely with Flow and TS since those are designed with JS in mind.

I'm just speaking from my experience of working with other templating languages.

JSX has tradeoffs, but is way better for DX and for writing stable code. I've also worked with handlebars etc, Angular (significantly) and various other back-end cludgey templating languages. Nothing is as good as JSX.

To dismiss my experiences as "Stockholm Syndrome" is mildly insulting.

I don't care about the grimy details of its origin story, I care that it helps me ship good products.

Is setState() that bad? If you want the magic of vue’s reactive state, you can just use Proxy which is what it does under the hood. Not sure why React hasn’t standardized that but /shrug

Because Proxy wasn't supported when React was designed. I bet if they were to design it a year later, they would go with Proxy. But it wasn't an option at the time, Proxy is not something you can polyfill.

Now, the community doesn't know about that. So when you tell them that there's a better way to deal with component state, they immediately get defensive: "No, setState() is way better, there's no magic, it's very explicit".

But setState() was a necessary evil, not a genius invention. They made it super-explicit because it was the only way they could do it. Not because of some great foresight.

Is it bad? Probably not. I bet it's tolerable. But why settle for less when there are better alternatives?

This is ahistorical.

Proxies have been around for at least a decade (here’s a 2010 talk about it

https://youtu.be/sClk6aB_CPk

)

React hooks have been around for less than half the time as that.

Proxies for setState would be a terrible idea in React for the simple reason that non state variables also exist in React functional components and have dramatically different behavior than state variables. Proxies would make them both look basically the same after initialization which would lead to a ton of bugs as devs lost track of which variable was a state variable and which one wasn’t.

I don't think you're arguing in good faith.

> Proxies have been around for at least a decade

Having Proxy described in ES5 standard and having it supported in browsers is two different things. IE market share at that time was around 30-40%.

> non state variables also exist in React functional components and have dramatically different behavior than state variables

Stateful functional components were introduced in 2018 (React 16). I'm talking about 2011-2013.

What is your recommendation for web apps that are not highly interactive but need interactivity to improve the UX?

All the major frameworks require you to work off a foundation that's built for high interactivity, and I believe going with one of the major ones (except Angular) is still a good bet.

Technically you can use Vue as a library to add interactivity. It works ok, but you'll switch to compilation eventually.

Still in my opinion Vue strikes good balance between getting shit done and developer experience.

Svelte would be my next bet, I just don't have enough experience with it to recommend it.

Something like Alpine JS or similar would make sense for a project like that.

https://alpinejs.dev/

HTMX & _hyperscript

Reply on news.ycombinator.com