React Fire: Modernizing React DOM
github.com
React Fire: Modernizing React DOM
1–10 of 113 posts
Re: React Fire: Modernizing React DOM
#2I 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.
Re: React Fire: Modernizing React DOM
#3I 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.
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.
Re: React Fire: Modernizing React DOM
#4It'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-defined elements, and Layered APIs like , that have rich property and method-based APIs. And it seems they will still be difficult to use from React.
Re: React Fire: Modernizing React DOM
#5I 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.
Re: React Fire: Modernizing React DOM
#6It'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.
Re: React Fire: Modernizing React DOM
#7Relevant: 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 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?
Re: React Fire: Modernizing React DOM
#8This is incredibly exciting. I'm glad they're focused on simplifying the model.
Re: React Fire: Modernizing React DOM
#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”.
Re: React Fire: Modernizing React DOM
#10I 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 hundred kilobyte python script that does the same thing (or maybe I'm only using like 10% of its features, idk).