7 ms·

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 l

• Ralfp 10y ago
  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.
• sarahappleseed 10y ago
  I agree. All in the name of writing code that makes it easier to do what? Not lose track of your own javascript?
  • coldtea 10y ago
    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?"
    • kensign 10y ago
      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.
      • coldtea 10y ago
        >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).
        • Silhouette 10y ago
          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.
          • coldtea 10y ago
            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.
            • Silhouette 10y ago
              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.
  • Silhouette 10y ago
    Not lose track of your own javascript? No, not lose track of the current state of your DOM.
• niftich 10y ago
  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.
• acdlite 10y ago
  I believe the ultimate goal is web apps with 60 fps gestures and animations.
• mythz 10y ago
  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?
  • gedy 10y ago
    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.
    • mythz 10y ago
      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.
      • Silhouette 10y ago
        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.
• kensign 10y ago
  I absolutely agree! React is quite possibly the worst anti-pattern I have ever seen in my 20 years of internet programming. JSX is HTML and HTML in javascript is a horrible, horrible idea. Webcomponents have been added to the living standard for a reason, to avoid crap like this. I truly wonder if those people espousing virtual DOM really understand that DOM rendering is the same no matter how you create nodes. There is no way to bypass the DOM API. Using React because it's "declarative" is an advantage? You've just added extra processing to the javascript runtime as now, React has to be processed and then the browser can actually handle manipulation of the DOMS nodes. This is complete nonsense. The ONLY way to get closer to working with the DOM dynamically is to use its API. I feel like I am on crazy pills because I know I will get downvotes. I'll say this pretty much for the last time: React is the dumbest idea any frontend architect and developer could possible choose. Use ES6, look at how to properly use HTTP, browser networking and server-side events and look at what's already been written by the many brilliant people contributing to NPM. Damn.
  • omegaworks 10y ago
    Have you actually used React to create a web application?
    • Ralfp 10y ago
      React's popularity makes it popular target for (sometimes uneducated) criticism. JSX is one of common targets. Library's size is other. Misconception that its just VDOM is another. And then there's popular FUD about how FB may nuke your project on a whim due to patent clause in its license.
      • sotojuan 10y ago
        It's hard to believe people say so much random bad stuff about React when it actually has a really good track record with developers and companies and various scales.
    • kensign 10y ago
      Do you actually understand how it really works?