10 ms·

React Fire: Modernizing React DOM

287 points by radubrehar 8y ago

ericand 8y ago
I recently went through a framework selection between React, Vue and Angular. I ended up with React for reasons typified by this post. There is a massive community and a great dev team (Facebook) interested in evolving and improving React over time.
- WorldMaker 8y ago
  I'm working on rewriting an application from a React-like VirtualDOM approach to "ordinary" React components for a similar reason in that while my original approach had many things going for it (was theoretically more performant than React DOM, at least some of the time, according to benchmarks), it really is hard to beat the overall ecosystem around React today. Some things I never got around to doing with the old approach have out-of-the-box React controls and I don't really have to do anything to get those behaviors versus feeling like I was writing the whole world from scratch.
- umvi 8y ago
  We use Angular a little bit at work, and I've been meaning to try Vue or React, but every time I start to setup the tooling, I get this sense of fatigue that's hard to describe. I feel like I have to throw away my Angular investment and start from scratch again. So, I continue to stick with Angular, which doesn't seem too bad. On a side note, why is Angular CLI so big (71 MB)? Seems like I could write a couple hundred kilobyte python script that does the same thing (or maybe I'm only using like 10% of its features, idk).
  - acemarke 8y ago
    You're asking about `angular-cli`, but I see the same question all the time in regards to Create-React-App. I'll paste in my standard answer on that topic: The set of dependencies that CRA uses includes: - A compiler - A bundler/linker - An optimizing minifier - A linter - A development server with live reloading - A test runner All of those are isolated and scoped to that one project, and they are all build-time dependencies only. It's also important to understand that Javascript packages are effectively distributed as source, which affects the number of files on disk. (Granted, many NPM packages do include unnecessary files in the published artifacts, but Javascript itself is a major factor there.) Meanwhile, XCode is supposedly something like 8GB installed, Visual Studio is multiple gigs, and if you were to look at the actual file size on disk of any C++ compiler toolchain, that would be a minimum of several dozen megs - those are just usually preinstalled on Linux or Mac systems. So, context is pretty important here. 70MB for a complete JS build toolchain is perfectly fine :)
    - abhisuri97 8y ago
      For context CRA is 160 MB ish with all dependencies installed.
  - erokar 8y ago
    I worked with Angular 5 for about half a year. It get's the job done once you've learnt it — but the problem with Angular is that it has its own way of doing things and its own concepts. "The Angular investement" is an investment in just Angular, to me that felt like a dead end, it's not transferable knowledge. React is a much more lightweight library and you use mostly bare bones JS. Though I actually wish React was more of a framework in the sense that it enforeced, or at least encouraged, a certain folder structure and a curation of state management, Ajax libs etc. A bit more standardization would make it more convenient to use in teams.
    - MBCook 8y ago
      In some ways I would like react to be more of a complete framework like you, but I worry they would do it “wrong”. Wrong, of course, is defined as not what I want. I’m a long-time Java developer but I’ve just started using React. I, for example, would like to have the file layout be much closer to the standard maven layout. It’s what I’m used to and it works extremely well. But I completely understand why other people don’t do it that way. And since you don’t have to 100% follow some official way I’m free to set things up in a method that’s more convenient for me if I need to. Unlike other libraries I’ve come across in my career I do like that to react community seems to have settled pretty well. Straight react is there, and read access popular enough that it’s very easy to find what you nee unlike other libraries I’ve come across in my career I do like that to react community seems to have settled pretty well. Straight react is there, and redux is popular enough that it’s very easy to find what you want to know. When it comes to tools you have a very large number of choices, but the existence of create-react-app makes things easy. Even if you don’t use it to setup your project Babel, Webpack, and Jest are pseudo-official tools that most people seem to use. You don’t have to use them, but you also don’t have to evaluate five choices and try and pick one. Somethings aren’t quite as clear-cut, like flow versus typescript if you want type checking. But by and large all seems to work very well, it’s FAR better than I was expecting from the JavaScript ecosystem based on past (and admittedly very old) experience.
  - nicoburns 8y ago
    I would recommend basing your frontend "investment" around webpack. It's the common denominator that all the frontend frameworks use, and while it's fairly complex, it's complexity that only needs to be learnt once, and unlocks a lot of powerful functionality. The frameworks themselves aren't that difficult to learn. Since Angular 2, they all work in a pretty similar way...
    - chrisco255 8y ago
      If by similar you mean they all have some component paradigm...I guess. But the cost of learning Vue, React, and Angular to a high level of proficiency is significant.
- cryptozeus 8y ago
  I recently went through same thing at our company and decided on angular. I really appreciate the overall framework architecture angular provides. React doesnt really give that
  - chrisweekly 8y ago
    Angular is a batteries-included full-fledged framework. React is a small view lib. Apples:oranges. Or, rather, apple orchard:orange.
- robdachshund 8y ago
  No one ever talks about that little clause in the react terms that says fb can revoke your license if they feel you are infringing on their parents. That's right, fb can legally block your access to react if they determine you are a threat to fb at large. For that reason, and the fact that it is owned by fb, I have very little interest in ever using it.
spankalee 8y ago
It's disappointing to see no mention of fixing the broken assumptions that lead to difficulties working with Custom Elements, like not being able to set properties from JSX: https://github.com/facebook/react/issues/11347 https://github.com/facebook/react/issues/11347 React is from an era where you could assume a relative static, closed-world, set of built-in DOM elements, with largely attribute and children-based configuration. Now we have open-world set of user-defined elements, and Layered APIs like <virtual-scroller>, that have rich property and method-based APIs. And it seems they will still be difficult to use from React.
- acemarke 8y ago
  Note that Dan specifically said: > At this stage, the project is very exploratory. We don't know for sure if all of the above things will pan out. .... If there's some area you're particularly interested in, please let me know and we'll work it out. So, I'd keep an eye on the discussions and bring this up as something that could be worked on as part of the overall effort.
  - spankalee 8y ago
    They're quite aware of this issue.
    - danabramov 8y ago
      To be honest — as I was writing this a few hours ago custom elements slipped out of my mind, but it's something we'd like to fix too. It would make sense to do as part of this effort so we'll keep this in mind.
- gb_ 8y ago
  > Now we have open-world set of user-defined elements Maybe this is true at Google, but I just don't see much demand for s/Web Components/Custom Elements.
ghayes 8y ago
I helped with one of the core issues being addressed (the "value" attribute)[0]. At the time, it looked like a small "beginner" issue, but clearly was touching on some important design decisions. I am glad to see the core team take a fresh look at these decisions and using this time to clear out technical debt. This maturity is certainly good for React. [0] https://github.com/facebook/react/pull/6406 https://github.com/facebook/react/pull/6406
- danabramov 8y ago
  Thanks! We appreciate any help. When doing changes to a part that interfaces with a platform API it's often difficult to forecast what will work out and what wouldn't. I actually made a spreadsheet a few days ago to track all merged PRs that were relevant, and which issues they fixed and broke. Only after that it became clearer in retrospect some decisions didn't really pan out and we need to walk back on them.
shawn 8y ago
Relevant: http://thecodist.com/article/the_programming_steamroller_waits_for_no_one http://thecodist.com/article/the_programming_steamroller_wai... “The Programming Steamroller Waits For No One“ Also: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ “Fire and Motion” The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Facebook. People get worried about React and decide to rewrite their whole architecture for React because they think they have to. Facebook is shooting at you, and it’s just cover fire so that they can move forward and you can’t, because this is how the game is played, Bubby. Are you going to support Saga? Flow? React Native? Are you supporting it because your customers need it, or because someone is firing at you and you feel like you have to respond?
- acemarke 8y ago
  Can you clarify what you're trying to say, specifically with the second link? The implication I'm getting out of it is that you feel the React team is deliberately reinventing things to force the web dev ecosystem to keep up with them (specifically per the sentence "The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features."). From my perspective, that's not the case at all. In the last couple years, they have: - Rewritten React's internal architecture completely based on lessons learned and long-running design goals, giving them a solid foundation to build new features (and without changing the public API) - Added new features and capabilities based on that new foundation, including many things the community has asked for (rendering arrays, improved context, etc) - Implemented most of a new feature set that should allow React users to simplify much of their async data loading logic, on an opt-in basis. - With that winding down, started tackling cleanup and technical debt issues to make behavior more consistent Sure, that process has all resulted in changes (such as the warnings about deprecated lifecycle methods), but it's been an incremental process, and they've offered up codemods to help with changes for things like lifecycles. The end goals here are better apps and more consistent behavior, not trying to beat down competition. edit Since the parent updated with a modified quote from the article that uses a bunch of React-related references instead, I'll respond to that. The suggestion here seems to be that Facebook is deliberately trying to waste everyone else's time keeping up. As Dan Abramov recently said (https://twitter.com/dan_abramov/status/1033806477306331136 https://twitter.com/dan_abramov/status/1033806477306331136 ): > There’s a common misconception that React is some sort of strategic investment and receives direction from the top. That’s not the case; pretty much all development and planning comes from the team itself. React is useful to FB but FB org is built around products rather than tech Also, I'll point out that "sagas" are a Redux ecosystem addon for managing side effects, and neither Redux nor Redux-Saga are owned by Facebook in any way.
pspeter3 8y ago
This is incredibly exciting. I'm glad they're focused on simplifying the model.
dmitriid 8y ago
`className` to `class` is a bad decision. React is a very thin layer on top of JS. `className` is JS. Specifically, it comes directly from DOM APIs. Changing it to `class` (while retaining all other DOM API-compatible prop names) is a really terrible decision that relies on “the wisdom of the crowds”.
- MBCook 8y ago
  It’s JS, but not HTML. And most of the time you see it you’re making JSX elements, where you would expect to use the word ‘class’. I think they’re right it’s more consistent with what people would expect to happen. The fact there is a special note in the docs calling out that everyone gets it wrong is a sign it was a problematic choice.
  - dmitriid 8y ago
    Exactly. It’s JS and not HTML. Because in JS that attribute/property is `className`. Because `class` is a reserved name in JS. Same goes for `htmlFor`, for example. So now you will have a situation where all props directly correspond to DOM APIs, and one prop that isn’t. A strange choice given how the stated goal is to be more consistent with DOM APIs.
    - angersock 8y ago
      And yet the entire reason for using JSX in the first place is that it looks like HTML. This is a reasonable change.
      - danabramov 8y ago
        So I wrote in detail why I think `class` is the right choice here. Hope it helps. https://github.com/facebook/react/issues/13525#issuecomment-417818906 https://github.com/facebook/react/issues/13525#issuecomment-...
        chrisweekly 8y ago
abhisuri97 8y ago
"className -> class" grumbles revises React lecture slides
- pcmaffey 8y ago
  more grumbles... `const class = foo`
  - lioeters 8y ago
    ..grumbles.. ({ class: className }) => <div class={ className } />
Nihilartikel 8y ago
So, I've only used react indirectly via Clojurescript and https://github.com/tonsky/rum https://github.com/tonsky/rum for a personal project... I don't spend much time in the front-end otherwise, but every time I read something about using React from JS as one would regularly it feels much, much more complicated. I.e. I just write functions that return hiccup-html lists, and @decorate a cursor into my immutable state structure for reactive updates, and that's pretty much all there is to it, apart from a few event handlers and decorations to do special DOM pre/post wrangling for odd cases. Could someone having experience with Rum or other Clojurescript React bindings, but a better understanding of React coming from more JS like languages chime in with their experience?
- e12e 8y ago
  I'm just getting my feet wet with react - but my impression from various blog posts and a bit of coding - is that in the beginning there was reasonml (ocaml dialect - mostly (but not only) targeting compilation to js target) - and react sort of "fell out" as a set of patterns/framework from doing functional programming of dom/gui/state. And react for js, ("react") is those patterns + patterns for js to make everything (sort of) work without as solid a language to steer one away from various cliffs. Which is one reason why I don't quite understand why there are class based components at all. At any rate - my current goal is to try some reasonml+react - and I think it'll feel better. And I'm not surprised cs+react feels more sane than js+react.
  - acemarke 8y ago
    ReasonML is a very new language variant, and wasn't part of React's original implementation. There's a really good history at https://stackshare.io/posts/the-react-story https://stackshare.io/posts/the-react-story .
    - e12e 8y ago
      Thank you (and @scns). I had a hunch it was (an) ml > more programmers > new programmers unfamiliar with syntax > js version and reasonml. I didn't realize they didn't start with ocaml, but sml.
icc97 8y ago
I find it quite interesting how much of the public face of React that Dan Abramov has become. I really like the openness with which he speaks via his blog, but it feels like all the important React announcements come through him and I'm sure there must be some other very senior FB developers who created React before he arrived who might not be so happy.
- jzelinskie 8y ago
  >I'm sure there must be some other very senior FB developers who created React before he arrived who might not be so happy. You might find that not everybody wants to be the face of something. It can be very stressful and people often dehumanize you in their communications as they associate you and the project as the same thing. Think of all the trouble that Lennart Poettering has dealt with as a result of the pushback to systemd.
  - icc97 8y ago
    Yes, a double-edged sword. It's to the credit of the React developers that they've welcomed him. I was just curious as to how the internal politics work there.
    - danabramov 8y ago
      People on the team who like to have presence on social media do that. People who don't like it that much, don't. I don't see much politics in this but maybe I'm missing something.
      - icc97 8y ago
        My apologies, I'm guess I'm just too used to seeing internal politics everywhere.
      - Rapzid 8y ago
        It's an interesting day when Github issues on an official project are considered "social media". I think that can be taken many ways and most of them interesting to ponder.
deleted 8y ago
[deleted]
imh 8y ago
When react already has to be "modernized" I become thankful that I don't work in JS land. I honestly don't think I could keep up and remain happy.
- Klathmon 8y ago
  You should read the link, these changes are less "modernizing" the API, and more doing the internals, many of which haven't changed since 2013. In that process there will probably be some breaking changes, but Facebook has some insane number of components they use internally, so they try to never make any breaking changes that can't be automatically migrated.
  - svachalek 8y ago
    Changing className -> class and onChange -> onInput is going to affect practically every React component ever written. They seem to have opposite rationales (class is less pedantic and onInput is more pedantic) and I expect at least one of them will get dropped along the way but we'll see.
    - Klathmon 8y ago
      They almost always provide codemods which can automatically convert a codebase for you, and they work pretty damn well. And while I'm not sure if I'm on board with all of the changes, I'm in no way worried about having to do anything instantly.
    - madeofpalk 8y ago
      The rationale seems to be "default to plain html/dom" where possible.
- boubiyeah 8y ago
  Not sure what you mean. React is 5 years old. Frontend development is more volatile by nature as devices changes, UX guidelines change, etc but overall React was very stable during these years. But even Java changed A LOT in 5 years... You always have to keep up as a developer.
boubiyeah 8y ago
I want to say Great work, even if it's not done yet. The react team obviously works well together, the vision is here and as an engineer who's been doing frontend work for 15 years (using flex, vanillaJS, various home-made frameworks, backbone, knockout, angular, etc) let me tell you I've never seen another framework/library come half way close to React. By the way, why not use this big, breaking release to start offering another way to write stateful components from functions? (ES6 classes, prototypes and anything that forces me to use "this" are still part of the very bad parts of JS, imo)
- acemarke 8y ago
  Because there's only so much the React team can tackle at once :) Yes, they've said several times they want to introduce a "stateful functional components" API, but based on comments I've seen, that's probably still about a year or so off.
coltonv 8y ago
I love the react team for what they're doing here, but I have a feeling that the className -> class change would be a huge mistake. It makes it so that the ({ class }) => ... syntax would no longer work since it's a reserved keyword. A simple find and replace is not going to work and a pretty sophisticated code mod would be required, and even then it still means convenient practical uses like the syntax mentioned above would never be possible. It also brings up significant package compatibility issues, if even a single package I use uses className I can't upgrade React, if a single one uses class I can't upgrade it. I'd rather not deal with a Python 2 -> 3 situation in React.
- rezistik 8y ago
  Yeah, that's the only change I'm not thrilled with.
- swrobel 8y ago
  No reason this couldn't be backwards compatible...
  - kylemh 8y ago
    > Note we can’t just allow both without warnings because this makes it very difficult for a component ecosystem to handle. Each component would need to learn to handle both correctly, and there is a risk of them conflicting. Since many components process className (for example by appending to it), it’s too error-prone. Unless you meant that there's no reason the code mod they release won't work - I agree with that.
- manigandham 8y ago
  The increased simplicity and straightforward API seems to outweigh the edge cases though. React has always been very good at backwards compatibility and slowly migrating though, and it'll likely be the case here. The recent lifecycle methods change is a good example.
- dasmoth 8y ago
  Yes, I’m disappointed by this too. It seems to be motivated by thinking about HTML/JSX, rather than the DOM where that attribute really is called className. To me, one of the appealing things about the React model is that the core is a relatively lightweight abstraction on top of the DOM, and other parts of the ecosystem (including JSX templating) are optional. This ends up being one more special case in the React core. Edit: babel-plugin-react-html-attrs seems like the right solution to people who want to use “class” in their templates.
ofirg 8y ago
Can someone with knowledge of the internals of react-native-web estimate the effect of these changes on the project? are other similar projects like ReactXp better immune?
nojvek 8y ago
className -> class. Finally! Also attaching events on the element rather than documenting. Seems like they are actually listening to devs. This was one of my reasons for only using Preact. Preact is a lot simpler mental model than react. It’s smaller, faster and arguably has less nuances.

287 points by radubrehar 8y ago

I recently went through a framework selection between React, Vue and Angular. I ended up with React for reasons typified by this post. There is a massive community and a great dev team (Facebook) interested in evolving and improving React over time.

WorldMaker 8y ago
I'm working on rewriting an application from a React-like VirtualDOM approach to "ordinary" React components for a similar reason in that while my original approach had many things going for it (was theoretically more performant than React DOM, at least some of the time, according to benchmarks), it really is hard to beat the overall ecosystem around React today. Some things I never got around to doing with the old approach have out-of-the-box React controls and I don't really have to do anything to get those behaviors versus feeling like I was writing the whole world from scratch.
umvi 8y ago
We use Angular a little bit at work, and I've been meaning to try Vue or React, but every time I start to setup the tooling, I get this sense of fatigue that's hard to describe. I feel like I have to throw away my Angular investment and start from scratch again. So, I continue to stick with Angular, which doesn't seem too bad. On a side note, why is Angular CLI so big (71 MB)? Seems like I could write a couple hundred kilobyte python script that does the same thing (or maybe I'm only using like 10% of its features, idk).
- acemarke 8y ago
  You're asking about `angular-cli`, but I see the same question all the time in regards to Create-React-App. I'll paste in my standard answer on that topic: The set of dependencies that CRA uses includes: - A compiler - A bundler/linker - An optimizing minifier - A linter - A development server with live reloading - A test runner All of those are isolated and scoped to that one project, and they are all build-time dependencies only. It's also important to understand that Javascript packages are effectively distributed as source, which affects the number of files on disk. (Granted, many NPM packages do include unnecessary files in the published artifacts, but Javascript itself is a major factor there.) Meanwhile, XCode is supposedly something like 8GB installed, Visual Studio is multiple gigs, and if you were to look at the actual file size on disk of any C++ compiler toolchain, that would be a minimum of several dozen megs - those are just usually preinstalled on Linux or Mac systems. So, context is pretty important here. 70MB for a complete JS build toolchain is perfectly fine :)
  - abhisuri97 8y ago
    For context CRA is 160 MB ish with all dependencies installed.
- erokar 8y ago
  I worked with Angular 5 for about half a year. It get's the job done once you've learnt it — but the problem with Angular is that it has its own way of doing things and its own concepts. "The Angular investement" is an investment in just Angular, to me that felt like a dead end, it's not transferable knowledge. React is a much more lightweight library and you use mostly bare bones JS. Though I actually wish React was more of a framework in the sense that it enforeced, or at least encouraged, a certain folder structure and a curation of state management, Ajax libs etc. A bit more standardization would make it more convenient to use in teams.
  - MBCook 8y ago
    In some ways I would like react to be more of a complete framework like you, but I worry they would do it “wrong”. Wrong, of course, is defined as not what I want. I’m a long-time Java developer but I’ve just started using React. I, for example, would like to have the file layout be much closer to the standard maven layout. It’s what I’m used to and it works extremely well. But I completely understand why other people don’t do it that way. And since you don’t have to 100% follow some official way I’m free to set things up in a method that’s more convenient for me if I need to. Unlike other libraries I’ve come across in my career I do like that to react community seems to have settled pretty well. Straight react is there, and read access popular enough that it’s very easy to find what you nee unlike other libraries I’ve come across in my career I do like that to react community seems to have settled pretty well. Straight react is there, and redux is popular enough that it’s very easy to find what you want to know. When it comes to tools you have a very large number of choices, but the existence of create-react-app makes things easy. Even if you don’t use it to setup your project Babel, Webpack, and Jest are pseudo-official tools that most people seem to use. You don’t have to use them, but you also don’t have to evaluate five choices and try and pick one. Somethings aren’t quite as clear-cut, like flow versus typescript if you want type checking. But by and large all seems to work very well, it’s FAR better than I was expecting from the JavaScript ecosystem based on past (and admittedly very old) experience.
- nicoburns 8y ago
  I would recommend basing your frontend "investment" around webpack. It's the common denominator that all the frontend frameworks use, and while it's fairly complex, it's complexity that only needs to be learnt once, and unlocks a lot of powerful functionality. The frameworks themselves aren't that difficult to learn. Since Angular 2, they all work in a pretty similar way...
  - chrisco255 8y ago
    If by similar you mean they all have some component paradigm...I guess. But the cost of learning Vue, React, and Angular to a high level of proficiency is significant.
cryptozeus 8y ago
I recently went through same thing at our company and decided on angular. I really appreciate the overall framework architecture angular provides. React doesnt really give that
- chrisweekly 8y ago
  Angular is a batteries-included full-fledged framework. React is a small view lib. Apples:oranges. Or, rather, apple orchard:orange.
robdachshund 8y ago
No one ever talks about that little clause in the react terms that says fb can revoke your license if they feel you are infringing on their parents. That's right, fb can legally block your access to react if they determine you are a threat to fb at large. For that reason, and the fact that it is owned by fb, I have very little interest in ever using it.

spankalee 8y ago

It's disappointing to see no mention of fixing the broken assumptions that lead to difficulties working with Custom Elements, like not being able to set properties from JSX: https://github.com/facebook/react/issues/11347 https://github.com/facebook/react/issues/11347 React is from an era where you could assume a relative static, closed-world, set of built-in DOM elements, with largely attribute and children-based configuration. Now we have open-world set of user-defined elements, and Layered APIs like <virtual-scroller>, that have rich property and method-based APIs. And it seems they will still be difficult to use from React.

acemarke 8y ago
Note that Dan specifically said: > At this stage, the project is very exploratory. We don't know for sure if all of the above things will pan out. .... If there's some area you're particularly interested in, please let me know and we'll work it out. So, I'd keep an eye on the discussions and bring this up as something that could be worked on as part of the overall effort.
- spankalee 8y ago
  They're quite aware of this issue.
  - danabramov 8y ago
    To be honest — as I was writing this a few hours ago custom elements slipped out of my mind, but it's something we'd like to fix too. It would make sense to do as part of this effort so we'll keep this in mind.
gb_ 8y ago
> Now we have open-world set of user-defined elements Maybe this is true at Google, but I just don't see much demand for s/Web Components/Custom Elements.

ghayes 8y ago

I helped with one of the core issues being addressed (the "value" attribute)[0]. At the time, it looked like a small "beginner" issue, but clearly was touching on some important design decisions. I am glad to see the core team take a fresh look at these decisions and using this time to clear out technical debt. This maturity is certainly good for React. [0] https://github.com/facebook/react/pull/6406 https://github.com/facebook/react/pull/6406

danabramov 8y ago
Thanks! We appreciate any help. When doing changes to a part that interfaces with a platform API it's often difficult to forecast what will work out and what wouldn't. I actually made a spreadsheet a few days ago to track all merged PRs that were relevant, and which issues they fixed and broke. Only after that it became clearer in retrospect some decisions didn't really pan out and we need to walk back on them.

shawn 8y ago

Relevant: http://thecodist.com/article/the_programming_steamroller_waits_for_no_one http://thecodist.com/article/the_programming_steamroller_wai... “The Programming Steamroller Waits For No One“ Also: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ “Fire and Motion” The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Facebook. People get worried about React and decide to rewrite their whole architecture for React because they think they have to. Facebook is shooting at you, and it’s just cover fire so that they can move forward and you can’t, because this is how the game is played, Bubby. Are you going to support Saga? Flow? React Native? Are you supporting it because your customers need it, or because someone is firing at you and you feel like you have to respond?

acemarke 8y ago
Can you clarify what you're trying to say, specifically with the second link? The implication I'm getting out of it is that you feel the React team is deliberately reinventing things to force the web dev ecosystem to keep up with them (specifically per the sentence "The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features."). From my perspective, that's not the case at all. In the last couple years, they have: - Rewritten React's internal architecture completely based on lessons learned and long-running design goals, giving them a solid foundation to build new features (and without changing the public API) - Added new features and capabilities based on that new foundation, including many things the community has asked for (rendering arrays, improved context, etc) - Implemented most of a new feature set that should allow React users to simplify much of their async data loading logic, on an opt-in basis. - With that winding down, started tackling cleanup and technical debt issues to make behavior more consistent Sure, that process has all resulted in changes (such as the warnings about deprecated lifecycle methods), but it's been an incremental process, and they've offered up codemods to help with changes for things like lifecycles. The end goals here are better apps and more consistent behavior, not trying to beat down competition. edit Since the parent updated with a modified quote from the article that uses a bunch of React-related references instead, I'll respond to that. The suggestion here seems to be that Facebook is deliberately trying to waste everyone else's time keeping up. As Dan Abramov recently said (https://twitter.com/dan_abramov/status/1033806477306331136 https://twitter.com/dan_abramov/status/1033806477306331136 ): > There’s a common misconception that React is some sort of strategic investment and receives direction from the top. That’s not the case; pretty much all development and planning comes from the team itself. React is useful to FB but FB org is built around products rather than tech Also, I'll point out that "sagas" are a Redux ecosystem addon for managing side effects, and neither Redux nor Redux-Saga are owned by Facebook in any way.

pspeter3 8y ago

This is incredibly exciting. I'm glad they're focused on simplifying the model.

dmitriid 8y ago

`className` to `class` is a bad decision. React is a very thin layer on top of JS. `className` is JS. Specifically, it comes directly from DOM APIs. Changing it to `class` (while retaining all other DOM API-compatible prop names) is a really terrible decision that relies on “the wisdom of the crowds”.

MBCook 8y ago
It’s JS, but not HTML. And most of the time you see it you’re making JSX elements, where you would expect to use the word ‘class’. I think they’re right it’s more consistent with what people would expect to happen. The fact there is a special note in the docs calling out that everyone gets it wrong is a sign it was a problematic choice.
- dmitriid 8y ago
  Exactly. It’s JS and not HTML. Because in JS that attribute/property is `className`. Because `class` is a reserved name in JS. Same goes for `htmlFor`, for example. So now you will have a situation where all props directly correspond to DOM APIs, and one prop that isn’t. A strange choice given how the stated goal is to be more consistent with DOM APIs.
  - angersock 8y ago
    And yet the entire reason for using JSX in the first place is that it looks like HTML. This is a reasonable change.
    - danabramov 8y ago
      So I wrote in detail why I think `class` is the right choice here. Hope it helps. https://github.com/facebook/react/issues/13525#issuecomment-417818906 https://github.com/facebook/react/issues/13525#issuecomment-...
      - chrisweekly 8y ago

abhisuri97 8y ago

"className -> class" grumbles revises React lecture slides

pcmaffey 8y ago
more grumbles... `const class = foo`
- lioeters 8y ago
  ..grumbles.. ({ class: className }) => <div class={ className } />

Nihilartikel 8y ago

So, I've only used react indirectly via Clojurescript and https://github.com/tonsky/rum https://github.com/tonsky/rum for a personal project... I don't spend much time in the front-end otherwise, but every time I read something about using React from JS as one would regularly it feels much, much more complicated. I.e. I just write functions that return hiccup-html lists, and @decorate a cursor into my immutable state structure for reactive updates, and that's pretty much all there is to it, apart from a few event handlers and decorations to do special DOM pre/post wrangling for odd cases. Could someone having experience with Rum or other Clojurescript React bindings, but a better understanding of React coming from more JS like languages chime in with their experience?

e12e 8y ago
I'm just getting my feet wet with react - but my impression from various blog posts and a bit of coding - is that in the beginning there was reasonml (ocaml dialect - mostly (but not only) targeting compilation to js target) - and react sort of "fell out" as a set of patterns/framework from doing functional programming of dom/gui/state. And react for js, ("react") is those patterns + patterns for js to make everything (sort of) work without as solid a language to steer one away from various cliffs. Which is one reason why I don't quite understand why there are class based components at all. At any rate - my current goal is to try some reasonml+react - and I think it'll feel better. And I'm not surprised cs+react feels more sane than js+react.
- acemarke 8y ago
  ReasonML is a very new language variant, and wasn't part of React's original implementation. There's a really good history at https://stackshare.io/posts/the-react-story https://stackshare.io/posts/the-react-story .
  - e12e 8y ago
    Thank you (and @scns). I had a hunch it was (an) ml > more programmers > new programmers unfamiliar with syntax > js version and reasonml. I didn't realize they didn't start with ocaml, but sml.

icc97 8y ago

I find it quite interesting how much of the public face of React that Dan Abramov has become. I really like the openness with which he speaks via his blog, but it feels like all the important React announcements come through him and I'm sure there must be some other very senior FB developers who created React before he arrived who might not be so happy.

jzelinskie 8y ago
>I'm sure there must be some other very senior FB developers who created React before he arrived who might not be so happy. You might find that not everybody wants to be the face of something. It can be very stressful and people often dehumanize you in their communications as they associate you and the project as the same thing. Think of all the trouble that Lennart Poettering has dealt with as a result of the pushback to systemd.
- icc97 8y ago
  Yes, a double-edged sword. It's to the credit of the React developers that they've welcomed him. I was just curious as to how the internal politics work there.
  - danabramov 8y ago
    People on the team who like to have presence on social media do that. People who don't like it that much, don't. I don't see much politics in this but maybe I'm missing something.
    - icc97 8y ago
      My apologies, I'm guess I'm just too used to seeing internal politics everywhere.
    - Rapzid 8y ago
      It's an interesting day when Github issues on an official project are considered "social media". I think that can be taken many ways and most of them interesting to ponder.

deleted 8y ago

[deleted]

imh 8y ago

When react already has to be "modernized" I become thankful that I don't work in JS land. I honestly don't think I could keep up and remain happy.

Klathmon 8y ago
You should read the link, these changes are less "modernizing" the API, and more doing the internals, many of which haven't changed since 2013. In that process there will probably be some breaking changes, but Facebook has some insane number of components they use internally, so they try to never make any breaking changes that can't be automatically migrated.
- svachalek 8y ago
  Changing className -> class and onChange -> onInput is going to affect practically every React component ever written. They seem to have opposite rationales (class is less pedantic and onInput is more pedantic) and I expect at least one of them will get dropped along the way but we'll see.
  - Klathmon 8y ago
    They almost always provide codemods which can automatically convert a codebase for you, and they work pretty damn well. And while I'm not sure if I'm on board with all of the changes, I'm in no way worried about having to do anything instantly.
  - madeofpalk 8y ago
    The rationale seems to be "default to plain html/dom" where possible.
boubiyeah 8y ago
Not sure what you mean. React is 5 years old. Frontend development is more volatile by nature as devices changes, UX guidelines change, etc but overall React was very stable during these years. But even Java changed A LOT in 5 years... You always have to keep up as a developer.

boubiyeah 8y ago

I want to say Great work, even if it's not done yet. The react team obviously works well together, the vision is here and as an engineer who's been doing frontend work for 15 years (using flex, vanillaJS, various home-made frameworks, backbone, knockout, angular, etc) let me tell you I've never seen another framework/library come half way close to React. By the way, why not use this big, breaking release to start offering another way to write stateful components from functions? (ES6 classes, prototypes and anything that forces me to use "this" are still part of the very bad parts of JS, imo)

acemarke 8y ago
Because there's only so much the React team can tackle at once :) Yes, they've said several times they want to introduce a "stateful functional components" API, but based on comments I've seen, that's probably still about a year or so off.

coltonv 8y ago

I love the react team for what they're doing here, but I have a feeling that the className -> class change would be a huge mistake. It makes it so that the ({ class }) => ... syntax would no longer work since it's a reserved keyword. A simple find and replace is not going to work and a pretty sophisticated code mod would be required, and even then it still means convenient practical uses like the syntax mentioned above would never be possible. It also brings up significant package compatibility issues, if even a single package I use uses className I can't upgrade React, if a single one uses class I can't upgrade it. I'd rather not deal with a Python 2 -> 3 situation in React.

rezistik 8y ago
Yeah, that's the only change I'm not thrilled with.
swrobel 8y ago
No reason this couldn't be backwards compatible...
- kylemh 8y ago
  > Note we can’t just allow both without warnings because this makes it very difficult for a component ecosystem to handle. Each component would need to learn to handle both correctly, and there is a risk of them conflicting. Since many components process className (for example by appending to it), it’s too error-prone. Unless you meant that there's no reason the code mod they release won't work - I agree with that.
manigandham 8y ago
The increased simplicity and straightforward API seems to outweigh the edge cases though. React has always been very good at backwards compatibility and slowly migrating though, and it'll likely be the case here. The recent lifecycle methods change is a good example.
dasmoth 8y ago
Yes, I’m disappointed by this too. It seems to be motivated by thinking about HTML/JSX, rather than the DOM where that attribute really is called className. To me, one of the appealing things about the React model is that the core is a relatively lightweight abstraction on top of the DOM, and other parts of the ecosystem (including JSX templating) are optional. This ends up being one more special case in the React core. Edit: babel-plugin-react-html-attrs seems like the right solution to people who want to use “class” in their templates.

ofirg 8y ago

Can someone with knowledge of the internals of react-native-web estimate the effect of these changes on the project? are other similar projects like ReactXp better immune?

nojvek 8y ago

className -> class. Finally! Also attaching events on the element rather than documenting. Seems like they are actually listening to devs. This was one of my reasons for only using Preact. Preact is a lot simpler mental model than react. It’s smaller, faster and arguably has less nuances.