4 ms·

You don't need to rehash the marketing pitch of React here. It's the same old "virtual DOM fast, real DOM slow" that I've heard countless times from fanboys and

You don't need to rehash the marketing pitch of React here. It's the same old "virtual DOM fast, real DOM slow" that I've heard countless times from fanboys and repeated ad infinitum in any discussion about React. What's missing is that you can make complex web apps without any of these things, or the abstractions used can be something completely different. The reasons you stated just sound like ex-post facto rationalizations of what they did after they built it.

Vinnl 9y ago
No, the main point was that it's > significantly nicer to code for than DOM binding There are other ways to code this nicely, but _those_ are slower than virtual DOM. Real DOM _can_ indeed easily be faster, but that's not nearly as nice to program for.
- jchw 9y ago
  Simply saying "No" after a point and not rebutting it is not a good argument. A lot of people like to point out that the "real DOM" can be just as fast, but far fewer people have any good examples of this being done. Yeah, for making a button that signs you up to a mailing list or a simple SPA or something like that, you can just use the DOM. But if you have a complex app with a huge amount of data flow and many components, React (and Preact and etc.) absolutely will beat the naive answer because it will get rid of needless DOM updates. And it will do that without you having to do caching everywhere, because it's all done in one place at the lowest level before hitting the page. I'd love to see the horrible abomination of hand DOM updates that can magically beat a large React app. edit: Just noticed this wasn't a reply to me, but I think the points I raise here are still fairly valid, if I'm understanding your reply correctly. Sorry if that was confusing.
  - Vinnl 9y ago
    Yeah, we're agreeing :) "Real DOM" can be just as fast if you do all the work React does by hand, but it's bound to be a mess - resulting in the programmer making mistakes that makes it slower.
jasode 9y ago
>that I've heard countless times from fanboys If you're unaware, "fanboys" is a grenade to incite juvenile flamewars instead of collegial discussion. >What's missing is that you can make complex web apps without any of these things, To attempt better instructive discussion instead of arguing from vague and generic platitudes about "needless complexity", can you explain how your simulacra.js (~12kb) is better than reactjs (~130kb)? For example, does Simulacra have the same features that React? If so, how did you eliminate ~100kb of Javascript to accomplish it, or conversely, what redundant or incompetent code takes up additional ~100kb of wasted bytes in React? If Simulacra accomplishes its smaller 12kb footprint by having less features, which features in React do developers no longer need because of "modern browsers have standards-compliant DOMs". In other words, some concrete analysis would be a more productive discussion.
- daliwali 9y ago
  A paragraph of well thought out text will be ignored. A critical remark on the web framework du jour will be carefully deconstructed, rebutted, and shamed. Funny how that works.
  - jchw 9y ago
    Well for one thing, I really think you're taking this a bit too personally. I don't think anyone here is intending to 'shame.'
    - daliwali 9y ago
      If shaming isn't the purpose of downvoting, or the soft suppression of controversial opinions, then I don't know what is.
      - mst 9y ago
        Crying "shaming" in response to people pointing out your neither being constructive nor producing a substantive point to engage with is, honestly, rather missing the point of how HN works. The purpose of downvoting is to indicate that your comments mostly consist of assertions that "react is bad" without really making a proper case for it, and as such don't really contribute to the signal of the discussion at hand - especially since the discussion at hand is about an explainer of the architecture, not a critique of the architecture itself. If you look at e.g. discussions on vue vs. react posts you'll find that the "react is overcomplicated, here's a cost/benefit analysis" opinion is not controversial at all, and that a reasoned discussion of it will be responded to constructively (or that non-constructive responses will themselves be downvoted).
jchw 9y ago
Sure, the abstractions can be different. I didn't say React is literally the only answer. I said it's fast and it beats the naive approach (i.e. jQuery crap.) But even if binding is fast, I think most people who moved on from stuff like Knockout to React do not have any desire to move back. I know I don't. But if you're going to accuse React's value proposition as being just a marketing pitch, I'd love to hear what evidence that virtual DOM is in fact pointless, and then why Angular 2 and Ember are doing the same sort of thing despite this, even though they have vastly different programming models than React. Also, regarding your last point, I really doubt Facebook accidentally made DOM diffing without realizing it would improve performance of reactive programming in JS.
guscost 9y ago
Hey if you really feel this way, you might like my new "framework" even more, it does declarative UI in < 100 lines of UMD JavaScript: https://github.com/guscost/protozoa https://github.com/guscost/protozoa Performance optimizations, cross-browser events, and safety features not included. Good luck if you ever have to build a huge UI with it, you'll be the first person to try! Seriously though, while it's pretty cool for embedding interactive DOM nodes in a webpage, don't think that you always need "simple" when sometimes "easy" is a much better idea.

Vinnl 9y ago

No, the main point was that it's > significantly nicer to code for than DOM binding There are other ways to code this nicely, but _those_ are slower than virtual DOM. Real DOM _can_ indeed easily be faster, but that's not nearly as nice to program for.

jchw 9y ago
Simply saying "No" after a point and not rebutting it is not a good argument. A lot of people like to point out that the "real DOM" can be just as fast, but far fewer people have any good examples of this being done. Yeah, for making a button that signs you up to a mailing list or a simple SPA or something like that, you can just use the DOM. But if you have a complex app with a huge amount of data flow and many components, React (and Preact and etc.) absolutely will beat the naive answer because it will get rid of needless DOM updates. And it will do that without you having to do caching everywhere, because it's all done in one place at the lowest level before hitting the page. I'd love to see the horrible abomination of hand DOM updates that can magically beat a large React app. edit: Just noticed this wasn't a reply to me, but I think the points I raise here are still fairly valid, if I'm understanding your reply correctly. Sorry if that was confusing.
- Vinnl 9y ago
  Yeah, we're agreeing :) "Real DOM" can be just as fast if you do all the work React does by hand, but it's bound to be a mess - resulting in the programmer making mistakes that makes it slower.

jasode 9y ago

>that I've heard countless times from fanboys If you're unaware, "fanboys" is a grenade to incite juvenile flamewars instead of collegial discussion. >What's missing is that you can make complex web apps without any of these things, To attempt better instructive discussion instead of arguing from vague and generic platitudes about "needless complexity", can you explain how your simulacra.js (~12kb) is better than reactjs (~130kb)? For example, does Simulacra have the same features that React? If so, how did you eliminate ~100kb of Javascript to accomplish it, or conversely, what redundant or incompetent code takes up additional ~100kb of wasted bytes in React? If Simulacra accomplishes its smaller 12kb footprint by having less features, which features in React do developers no longer need because of "modern browsers have standards-compliant DOMs". In other words, some concrete analysis would be a more productive discussion.

daliwali 9y ago
A paragraph of well thought out text will be ignored. A critical remark on the web framework du jour will be carefully deconstructed, rebutted, and shamed. Funny how that works.
- jchw 9y ago
  Well for one thing, I really think you're taking this a bit too personally. I don't think anyone here is intending to 'shame.'
  - daliwali 9y ago
    If shaming isn't the purpose of downvoting, or the soft suppression of controversial opinions, then I don't know what is.
    - mst 9y ago
      Crying "shaming" in response to people pointing out your neither being constructive nor producing a substantive point to engage with is, honestly, rather missing the point of how HN works. The purpose of downvoting is to indicate that your comments mostly consist of assertions that "react is bad" without really making a proper case for it, and as such don't really contribute to the signal of the discussion at hand - especially since the discussion at hand is about an explainer of the architecture, not a critique of the architecture itself. If you look at e.g. discussions on vue vs. react posts you'll find that the "react is overcomplicated, here's a cost/benefit analysis" opinion is not controversial at all, and that a reasoned discussion of it will be responded to constructively (or that non-constructive responses will themselves be downvoted).

jchw 9y ago

Sure, the abstractions can be different. I didn't say React is literally the only answer. I said it's fast and it beats the naive approach (i.e. jQuery crap.) But even if binding is fast, I think most people who moved on from stuff like Knockout to React do not have any desire to move back. I know I don't. But if you're going to accuse React's value proposition as being just a marketing pitch, I'd love to hear what evidence that virtual DOM is in fact pointless, and then why Angular 2 and Ember are doing the same sort of thing despite this, even though they have vastly different programming models than React. Also, regarding your last point, I really doubt Facebook accidentally made DOM diffing without realizing it would improve performance of reactive programming in JS.

guscost 9y ago

Hey if you really feel this way, you might like my new "framework" even more, it does declarative UI in < 100 lines of UMD JavaScript: https://github.com/guscost/protozoa https://github.com/guscost/protozoa Performance optimizations, cross-browser events, and safety features not included. Good luck if you ever have to build a huge UI with it, you'll be the first person to try! Seriously though, while it's pretty cool for embedding interactive DOM nodes in a webpage, don't think that you always need "simple" when sometimes "easy" is a much better idea.