Hacker News Reader

Hacker News

Comment by sarahappleseed | Hacker News Reader

Parent Full thread

sarahappleseed

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

View on HN

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