Hacker News Reader

Comment by gedy | Hacker News Reader

This is very cool, but the nagging issue I have with React is this desire to reimplement everything in JavaScript and bypass the Browser, DOM, CSS, etc. I've lost track of what benefits this really offers?

View on HN

Could you elaborate? All React.js "reimplements" are components for DOM elements and custom event dispatcher that allows you to don't worry about browser quirks and differences in handling events.

There's also large difference between what DOM and VDOM mean and VDOM's not DOM reimplementation.

Why write every component in 3 different languages artificially forcing it split into multiple sections when you can just develop it in one cohesive unit using the most powerful one?

Well partly because React is not that fast, and things like incorporating CSS animations are not particularly easy.

I appreciate FB is working on improving these areas, but original point is that maybe a lot of this optimization would be unnecessary if worked with the browser capabilities vs outside it in JS.

Its batch DOM writes of virtual DOM diffs ends up being a lot faster than previous SPA development models which can be further optimized with Pure Renderer. It has room for improvements but that doesn't invalidate React's approach.

Its batch DOM writes of virtual DOM diffs ends up being a lot faster than previous SPA development models which can be further optimized with Pure Renderer.

Sorry, but that isn't necessarily so. React is a lot faster than many of the other front-end frameworks, but that's because most front-end frameworks are horribly, horribly slow. However, all that rerendering and DOM diffing isn't free, and React can easily still be much slower than applying manual DOM updates if you have the patience and accuracy to write the code to do them, even if you use pure renderers and write shouldComponentUpdate everywhere.

They're taking a comprehensive look at how imperative (React) or declarative-autotranslated-into-imperative (JSX) code for describing a View actually becomes that View (which is currently either (V)DOM, or some native UI toolkit with React Native).

This process occurs in browsers, libraries, and UI toolkits today; React gives you an alternative. This means that you can render in the client, render on the server, render wherever starting from the same code.

I believe the ultimate goal is web apps with 60 fps gestures and animations.

I agree. All in the name of writing code that makes it easier to do what? Not lose track of your own javascript?

As if "losing track of your own Javascript" is something that:

a) does not happen

or:

b) is OK?

Might as well have written your sneer like: "All in the name of writing code that makes it easier to do what? Simplify development?"

Well it doesn't simplify development and that's the point, it's not a clean separation of concerns. It defies the whole purpose of using CSS, the DOM API and keeping your javascript's structural patterns cohesive. This is why Webcomponents are now part of the living standard. The browser runtime nullifies whatever React was trying to achieve.

>Well it doesn't simplify development and that's the point, it's not a clean separation of concerns.

On the contrary, it's very clean.

The real separation of concerns is between business logic and view code, and React does that perfectly.

Not between HTML, CSS, DOM etc which are artificial inflated concerns due to how the browser ended up as an ad-hoc application coding platform (from it's "document" viewer beginnings, which is where the "D" in the DOM comes from).

(And of course nothing stops you from using CSS and external styles with React, separating style from behavior).

>This is why Webcomponents are now part of the living standard.

Web components only solve the non-interesting parts of what React does. Namely, isolated components. All the state and management mess for the entire app is still yours to deal with. Even React alone does more, nevermind React+Redux/FLUX etc.

Which is also the reason React caught like wildfire, and nobody much cares for Webcomponents (e.g. not any statistically significant numbers).

I generally agree with your position here, but I think you're giving React a bit too much credit for separating business logic and view code. In practice, anything complicated probably requires shouldComponentUpdate for acceptable performance. Writing reasonably efficient shouldComponentUpdate in turn requires underlying data that can be compared quickly, hence for example the current interest in immutable data structures that can be tested for equality by checking a single reference. And so the choice to use React for rendering does have implications for how the underlying data is stored as well, which undermines any claims about truly separating the view logic from the business logic.

Sure, all abstractions are leaky one way or another, but in the end React gives you much better separation than what we had before.

Having to deal with shouldComponentUpdate is a blessing compared to having to juggle 4-5 different concepts and web technologies, plus manage state, plus separate logic yourself, etc.

Heck, in Backbone, which is as bare as it gets, and you needed to wrap your data in specific classes...

And that's IF (and it's a big IF) you have some very complex performance case. In most cases I never needed it, and tons of stuff can just be a pure render function.

Again, I generally agree with your comments here. I just think it's important to point out that this particular leak exists, because a lot of React advocacy completely glosses over the point. The need to have a data model that supports quick diffs one way or another has profound implications for the scalability of your front-end code and it's an architectural decision that will be expensive to change later if you get it wrong initially and learn that the hard way.

Not lose track of your own javascript?

No, not lose track of the current state of your DOM.

Reply on news.ycombinator.com