Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React Fire: Modernizing React DOM

github.com

Post reply on HN
Print view View original

11–20 of 113 posts

Re: React Fire: Modernizing React DOM

#11

Post by acemarke »

shawn wrote: post #7

Relevant: 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/ “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 Reac…

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

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

Re: React Fire: Modernizing React DOM

#12

Post by MBCook »

dmitriid wrote: post #9

`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”.

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.

Re: React Fire: Modernizing React DOM

#13

Post by acemarke »

umvi wrote: post #10
ericand wrote: post #2

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.

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 hundre…

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

Re: React Fire: Modernizing React DOM

#14

Post by spankalee »

acemarke wrote: post #6
spankalee wrote: post #4

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 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-…

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.

They're quite aware of this issue.

Re: React Fire: Modernizing React DOM

#15

Post by ben_jones »

acemarke wrote: post #11
shawn wrote: post #7

Relevant: 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/ “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 Reac…

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…

I wouldn't be surprised if at least a couple of React's innovations and release cycles correspond with Facebook's bonus incentives for their engineers. There's nothing wrong with that, but I find it highly more likely then some great conspiracy to soak up the dev time of completely unrelated companies.

Re: React Fire: Modernizing React DOM

#17

Post by erokar »

umvi wrote: post #10
ericand wrote: post #2

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.

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 hundre…

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.

Re: React Fire: Modernizing React DOM

#18

Post by nicoburns »

umvi wrote: post #10
ericand wrote: post #2

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.

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 hundre…

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

Re: React Fire: Modernizing React DOM

#19

Post by dmitriid »

MBCook wrote: post #12
dmitriid wrote: post #9

`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”.

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.

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.

Re: React Fire: Modernizing React DOM

#20

Post by abhisuri97 »

acemarke wrote: post #13
umvi wrote: post #10

Earlier quoted context omitted.

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 hundre…

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 dep…

For context CRA is 160 MB ish with all dependencies installed.
Post reply on HN