7 ms·

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 ju

by hbrn 4y ago

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.

ithrow 4y ago
What is your recommendation for web apps that are not highly interactive but need interactivity to improve the UX?
- hbrn 4y ago
  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.
- s__s 4y ago
  Something like Alpine JS or similar would make sense for a project like that. https://alpinejs.dev/ https://alpinejs.dev/
- Induane 4y ago
  HTMX & _hyperscript
jacobsimon 4y ago
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
- hbrn 4y ago
  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?
  - addicted 4y ago
    This is ahistorical. Proxies have been around for at least a decade (here’s a 2010 talk about it https://youtu.be/sClk6aB_CPk 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.
    - hbrn 4y ago
      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.
WorldMaker 4y ago
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).
- hbrn 4y ago
  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).
  - WorldMaker 4y ago
    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.)
davedx 4y ago
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.

by hbrn 4y ago

ithrow 4y ago

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

hbrn 4y ago
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.
s__s 4y ago
Something like Alpine JS or similar would make sense for a project like that. https://alpinejs.dev/ https://alpinejs.dev/
Induane 4y ago
HTMX & _hyperscript

jacobsimon 4y ago

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

hbrn 4y ago
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?
- addicted 4y ago
  This is ahistorical. Proxies have been around for at least a decade (here’s a 2010 talk about it https://youtu.be/sClk6aB_CPk 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.
  - hbrn 4y ago
    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.

WorldMaker 4y ago

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

hbrn 4y ago
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).
- WorldMaker 4y ago
  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.)

davedx 4y ago

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.