5 ms·

It's interesting that the original appeal of React was that it was "just a view library", but now apparently it's more like a "language". It really shows the bi

by lhorie 7y ago

It's interesting that the original appeal of React was that it was "just a view library", but now apparently it's more like a "language". It really shows the biases of the maintainers (the "just a library" thing being a philosophy I liked from vjeux, and the "language-likeness" being very obviously a heavy influence from sebmarkbage). The thing w/ "language-ness" (as opposed to "library-ness") is that additions and changes to a language tend to become more and more difficult to make over time because semantics deeply affect everything in the system, whereas well designed APIs in a library-oriented approach can be well encapsulated. I've said for a while, for example, that throwing promises for Suspense is using up "escape hatches" in JS. The rule of hooks is another one of those. Eventually, the React team will run out of escape hatches to implement "React language" semantics around the real JS semantics, and I suspect at that point sebmarkbage will move on to create a new view framework (as has been the case w/ e.g. sebmack and babel/rome, Rich Harris and ractive/svelte, etc). It'll be interesting to see if whoever steps up to maintain React at that point will be able to grok its internal complexity, and to see how the community reacts to a rift when their favorite view library team pushes for one vision but the moved-on "rockstar facebook engineer" pushes for a different vision. EDIT: fixed name confusion (thanks, swyx!)

swyx 7y ago
> and the "language-likeness" being very obviously a heavy influence from sebmack just a minor correction, you probably mean seb markbage, who works on React, not seb mackenzie, who made Babel and now Rome and i dont think was ever on the React team. i agree that when seb markbage leaves, it will be a big test of React's legacy. I've called it the "Ship of Theseus" moment for React.
- desert_boi 7y ago
  Got a link to Rome's docs? Babel is a little easier to google for.
  - holler 7y ago
    https://github.com/facebookexperimental/rome https://github.com/facebookexperimental/rome
  - pests 7y ago
    https://github.com/facebookexperimental/rome https://github.com/facebookexperimental/rome It's interesting. Everything is from scratch. No depa what so ever.
kiliancs 7y ago
Was it sold as "just a view library" from official sources? I understand "just a view library" might have been used to contrast it to full framworks that dictate a lot more than React, but it's important to note that the key React feature compared to other view libraries is precisely that it's not "just a view library": state is at its core. It's hard to disagree with the the pain of React having to leave the comfort of plain idiomatic JS to better fulfill its goal, but to me React's efforts are in a way an experiment to find some primitives that should be baked into JS engines to allow for these mature, fine tuned experiences without putting the burden on the library.
- lhorie 7y ago
  > Was it sold as "just a view library" from official sources? Yes, the "V in MVC" term came straight out its main page: > JUST THE UI > Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project. https://web.archive.org/web/20140321012426/http://facebook.github.io/react https://web.archive.org/web/20140321012426/http://facebook.g...
  - kiliancs 7y ago
    Thanks for finding that! Yes, it seems like this way of seeling it could cause false expectations. It is still true, though, that "React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project".
  - TomMarius 7y ago
    I don't see any contradiction - you still need controllers and models today. It's a front-end view library, so it manages state, but nothing else (unless you make your controllers and models a part of the view, which was possiblewith server side views just as well - remember PHP?)
nemothekid 7y ago
>It's interesting that the original appeal of React was that it was "just a view library", but now apparently it's more like a "language". I feel like that "appeal" was part of the marketing but the designers always wanted to create a new language. I switched a fairly large webapp from Angular to React pretty early on and I remember thinking that Flux (the design) was designed by someone that wished they were programming in OCaml instead. The whole "constants.js" for actions felt like a kind of defeat that they couldn't have unions and pattern matching in JS.
gotofritz 7y ago
> It'll be interesting to see if whoever steps up to maintain React at that point will be able to grok its internal complexity, and to see how the community reacts to a rift when their favorite view library team pushes for one vision but the moved-on "rockstar facebook engineer" pushes for a different vision. Kind of what is going on with Node / Deno... and like the chap who quit the Angular 2 team to start Aurelia hoped would happen to him (sorry buddy!). My guess is that he'll find out that there is more to a framework than rockstar developers. Like Facebook backing, or like UX designers being in love with your library because it reflects their approach to problem solving. Like CRA, hot module reloading and all that jazz. These are all things that put React where it is today
e12e 7y ago
> It's interesting that the original appeal of React was that it was "just a view library", but now apparently it's more like a "language" Well, it was prototyped in standard ml first[1], wasn't it? - then ported/re-implemented (shoehorned ;) into plain js. So some things that sml has, and made sense in sml, had to become part of the library/language/framework that is react? Later came reasonml (a ocaml dialect) which is a lot closer to sml than js - and I think the state handling reflects that, like the readme for reasonml variant of redux: https://github.com/reasonml-community/reductive/blob/master/README.md https://github.com/reasonml-community/reductive/blob/master/... "The code behind Reductive is incredibly simple. The first 40 lines include the entire re-implementation of redux. The next ~40 lines are a re-implementation of the react-redux library (without the higher-order component connect style implementation)." In a sense, react has always been a design pattern - and a library to support/enable that pattern in Javascript. [1] https://www.reactiflux.com/transcripts/jordan-walke#come-idea-react-directly-inspired https://www.reactiflux.com/transcripts/jordan-walke#come-ide...
- lioeters 7y ago
  Thank you for this latter link where the original author of React describes its beginning. After reading it, I finally feel like I'm starting to understand where React came from, why it's designed the way it is. The paradigm shift that React brought to JavaScript was to "bend the language" to implement concepts and design patterns from ML, a functional language with roots in Lisp, with static typing, algebraic data types, and foundation in lambda calculus and category theory. When you joked that it was "shoehorned" into JS, I got an insight into the reason why some design decisions in React feel awkward and strangely non-idiomatic. It explains, in part, the strong emotional reactions seen in this discussion thread, a number of justified opinions, its problems as well as benefits. I've been skeptical of the design of React Hooks, and still am, but now I'm interested in learning its influences, to understand the logic behind them. I wish that it had been implemented to be more "React-agnostic", like JSX, as generic extension to the JavaScript language.
  - e12e 7y ago
    You're very welcome. I do believe looking at reasonml and reasonreact is a good way to gain insight into reactjs. It's on my (so very long) to-do-list. Ed: as an example, I found this (oldish) post on hooks in reasonreact: https://dev.to/iwilsonq/reasonml-with-react-hooks-tutorial-building-a-pomodoro-timer-57h0 https://dev.to/iwilsonq/reasonml-with-react-hooks-tutorial-b... Compare as you will with a comparable one for reactjs: https://upmostly.com/tutorials/build-a-react-timer-component-using-hooks https://upmostly.com/tutorials/build-a-react-timer-component... Note - I would advice looking at the reasonreact documentation for up to date tutorials and guides... It's a quickly changing landscape. Eg: https://reasonml.github.io/reason-react/docs/en/usereducer-hook https://reasonml.github.io/reason-react/docs/en/usereducer-h... Finally I came across this - I thought maybe a sibling comment mentioned it - but a quick search didn't turn up anything - but imo it's a pretty strong argument for hooks (in js react) : https://tylermcginnis.com/why-react-hooks/ https://tylermcginnis.com/why-react-hooks/
csmiller 7y ago
I thought Jordan Walke created React, not Sebastian Markbåge, in which case he already moved on (to ReasonML)
- lhorie 7y ago
  Right, I meant that Sebastian is the current maintainer. Not to detract from Dan Abramov etc, but the feel I get is that Sebastian is the one who really sets the pace for where React is going these days (i.e. hooks, suspense, etc). Correct me if I'm wrong.
  - yawaramin 7y ago
    Well, you're factually wrong. Abramov is the current React maintainer. Markbage is obviously a core team member but contributing good ideas doesn't automatically transform one into being the project maintainer.
    - lhorie 7y ago
      Didn't mean it as an XOR. FWIW, looking at the github commit history one might get the impression that acdlite is the main committer in the repo these days, followed by trueadm and bvaughn (gaeron doesn't look all that active recently in comparison). I don't really hear those three core team members talk much about JS since their twitters tend to be less technical. My impressions come mostly from what I see the more technically-vocal react team members say publicly and I feel like gaeron often makes it sound like the bulk of react concepts are other people's contributions. Markbage certainly seems like the "vision" person in the team </shrug>
    - acemarke 7y ago
      Uh... there's not a _single_ React "maintainer". There's a React _team_, which currently consists of: - Seb Markbage: general deep thinking and vision, works on Suspense and some of the server rendering - Andrew Clark: implemented much of the Suspense and Concurrent Mode core - Dan Abramov: started Create-React-App, wrote the hooks and Concurrent Mode docs, works on various parts of the library and tooling - Brian Vaughn: rewrote the React DevTools, added the Profiler, recently implemented the upcoming `useMutableSource` hook - Dominic Gannaway: previously created Inferno, now works on a lot of the upcoming new event system and other optimizations - Nicolas Gallagher: previously created React Native Web, now also works on the event system - Luna Ruan: newer to the team, helped implement the `useOpaqueId` hook that just got merged - Rachel Nabors: currently working on revamping the docs and community outreach They have a team bio page here: https://reactjs.org/community/team.html https://reactjs.org/community/team.html
searchableguy 7y ago
isn't react created by jorde walke?

by lhorie 7y ago

swyx 7y ago

> and the "language-likeness" being very obviously a heavy influence from sebmack just a minor correction, you probably mean seb markbage, who works on React, not seb mackenzie, who made Babel and now Rome and i dont think was ever on the React team. i agree that when seb markbage leaves, it will be a big test of React's legacy. I've called it the "Ship of Theseus" moment for React.

desert_boi 7y ago
Got a link to Rome's docs? Babel is a little easier to google for.
- holler 7y ago
  https://github.com/facebookexperimental/rome https://github.com/facebookexperimental/rome
- pests 7y ago
  https://github.com/facebookexperimental/rome https://github.com/facebookexperimental/rome It's interesting. Everything is from scratch. No depa what so ever.

kiliancs 7y ago

Was it sold as "just a view library" from official sources? I understand "just a view library" might have been used to contrast it to full framworks that dictate a lot more than React, but it's important to note that the key React feature compared to other view libraries is precisely that it's not "just a view library": state is at its core. It's hard to disagree with the the pain of React having to leave the comfort of plain idiomatic JS to better fulfill its goal, but to me React's efforts are in a way an experiment to find some primitives that should be baked into JS engines to allow for these mature, fine tuned experiences without putting the burden on the library.

lhorie 7y ago
> Was it sold as "just a view library" from official sources? Yes, the "V in MVC" term came straight out its main page: > JUST THE UI > Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project. https://web.archive.org/web/20140321012426/http://facebook.github.io/react https://web.archive.org/web/20140321012426/http://facebook.g...
- kiliancs 7y ago
  Thanks for finding that! Yes, it seems like this way of seeling it could cause false expectations. It is still true, though, that "React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project".
- TomMarius 7y ago
  I don't see any contradiction - you still need controllers and models today. It's a front-end view library, so it manages state, but nothing else (unless you make your controllers and models a part of the view, which was possiblewith server side views just as well - remember PHP?)

nemothekid 7y ago

>It's interesting that the original appeal of React was that it was "just a view library", but now apparently it's more like a "language". I feel like that "appeal" was part of the marketing but the designers always wanted to create a new language. I switched a fairly large webapp from Angular to React pretty early on and I remember thinking that Flux (the design) was designed by someone that wished they were programming in OCaml instead. The whole "constants.js" for actions felt like a kind of defeat that they couldn't have unions and pattern matching in JS.

gotofritz 7y ago

> It'll be interesting to see if whoever steps up to maintain React at that point will be able to grok its internal complexity, and to see how the community reacts to a rift when their favorite view library team pushes for one vision but the moved-on "rockstar facebook engineer" pushes for a different vision. Kind of what is going on with Node / Deno... and like the chap who quit the Angular 2 team to start Aurelia hoped would happen to him (sorry buddy!). My guess is that he'll find out that there is more to a framework than rockstar developers. Like Facebook backing, or like UX designers being in love with your library because it reflects their approach to problem solving. Like CRA, hot module reloading and all that jazz. These are all things that put React where it is today

e12e 7y ago

> It's interesting that the original appeal of React was that it was "just a view library", but now apparently it's more like a "language" Well, it was prototyped in standard ml first[1], wasn't it? - then ported/re-implemented (shoehorned ;) into plain js. So some things that sml has, and made sense in sml, had to become part of the library/language/framework that is react? Later came reasonml (a ocaml dialect) which is a lot closer to sml than js - and I think the state handling reflects that, like the readme for reasonml variant of redux: https://github.com/reasonml-community/reductive/blob/master/README.md https://github.com/reasonml-community/reductive/blob/master/... "The code behind Reductive is incredibly simple. The first 40 lines include the entire re-implementation of redux. The next ~40 lines are a re-implementation of the react-redux library (without the higher-order component connect style implementation)." In a sense, react has always been a design pattern - and a library to support/enable that pattern in Javascript. [1] https://www.reactiflux.com/transcripts/jordan-walke#come-idea-react-directly-inspired https://www.reactiflux.com/transcripts/jordan-walke#come-ide...

lioeters 7y ago
Thank you for this latter link where the original author of React describes its beginning. After reading it, I finally feel like I'm starting to understand where React came from, why it's designed the way it is. The paradigm shift that React brought to JavaScript was to "bend the language" to implement concepts and design patterns from ML, a functional language with roots in Lisp, with static typing, algebraic data types, and foundation in lambda calculus and category theory. When you joked that it was "shoehorned" into JS, I got an insight into the reason why some design decisions in React feel awkward and strangely non-idiomatic. It explains, in part, the strong emotional reactions seen in this discussion thread, a number of justified opinions, its problems as well as benefits. I've been skeptical of the design of React Hooks, and still am, but now I'm interested in learning its influences, to understand the logic behind them. I wish that it had been implemented to be more "React-agnostic", like JSX, as generic extension to the JavaScript language.
- e12e 7y ago
  You're very welcome. I do believe looking at reasonml and reasonreact is a good way to gain insight into reactjs. It's on my (so very long) to-do-list. Ed: as an example, I found this (oldish) post on hooks in reasonreact: https://dev.to/iwilsonq/reasonml-with-react-hooks-tutorial-building-a-pomodoro-timer-57h0 https://dev.to/iwilsonq/reasonml-with-react-hooks-tutorial-b... Compare as you will with a comparable one for reactjs: https://upmostly.com/tutorials/build-a-react-timer-component-using-hooks https://upmostly.com/tutorials/build-a-react-timer-component... Note - I would advice looking at the reasonreact documentation for up to date tutorials and guides... It's a quickly changing landscape. Eg: https://reasonml.github.io/reason-react/docs/en/usereducer-hook https://reasonml.github.io/reason-react/docs/en/usereducer-h... Finally I came across this - I thought maybe a sibling comment mentioned it - but a quick search didn't turn up anything - but imo it's a pretty strong argument for hooks (in js react) : https://tylermcginnis.com/why-react-hooks/ https://tylermcginnis.com/why-react-hooks/

csmiller 7y ago

I thought Jordan Walke created React, not Sebastian Markbåge, in which case he already moved on (to ReasonML)

lhorie 7y ago
Right, I meant that Sebastian is the current maintainer. Not to detract from Dan Abramov etc, but the feel I get is that Sebastian is the one who really sets the pace for where React is going these days (i.e. hooks, suspense, etc). Correct me if I'm wrong.
- yawaramin 7y ago
  Well, you're factually wrong. Abramov is the current React maintainer. Markbage is obviously a core team member but contributing good ideas doesn't automatically transform one into being the project maintainer.
  - lhorie 7y ago
    Didn't mean it as an XOR. FWIW, looking at the github commit history one might get the impression that acdlite is the main committer in the repo these days, followed by trueadm and bvaughn (gaeron doesn't look all that active recently in comparison). I don't really hear those three core team members talk much about JS since their twitters tend to be less technical. My impressions come mostly from what I see the more technically-vocal react team members say publicly and I feel like gaeron often makes it sound like the bulk of react concepts are other people's contributions. Markbage certainly seems like the "vision" person in the team </shrug>
  - acemarke 7y ago
    Uh... there's not a _single_ React "maintainer". There's a React _team_, which currently consists of: - Seb Markbage: general deep thinking and vision, works on Suspense and some of the server rendering - Andrew Clark: implemented much of the Suspense and Concurrent Mode core - Dan Abramov: started Create-React-App, wrote the hooks and Concurrent Mode docs, works on various parts of the library and tooling - Brian Vaughn: rewrote the React DevTools, added the Profiler, recently implemented the upcoming `useMutableSource` hook - Dominic Gannaway: previously created Inferno, now works on a lot of the upcoming new event system and other optimizations - Nicolas Gallagher: previously created React Native Web, now also works on the event system - Luna Ruan: newer to the team, helped implement the `useOpaqueId` hook that just got merged - Rachel Nabors: currently working on revamping the docs and community outreach They have a team bio page here: https://reactjs.org/community/team.html https://reactjs.org/community/team.html

searchableguy 7y ago

isn't react created by jorde walke?