[jchw]

React's complexity literally only exists for two reasons:

1. To sidestep problems with the DOM. The virtual DOM helps with performance, and fibers help with responsiveness.

2. To implement reactive components. Virtual DOM makes rebuilding sub trees of the DOM cheap, making it possible to have clean components that don't need to constantly attempt to tweak the DOM. Doing this style of programming without DOM diffing is possible, but much slower.

There are other approaches, but this one is significantly nicer to code for than DOM binding and is significantly faster than any naive approach.

Yes, you can extract the essence of React into a several kb bundle. It's been done to death. But why? React is fast, mature, has a great ecosystem, and it's nice to code for. It does nice things like seamlessly support SVG and intelligently batching changes. If you're truly making a complex app, it's worth the bump in bundle size.

The largest part of any web app is the browser. If the DOM wasn't so bloated and ridiculous, maybe we wouldn't need to spend all of our time minimizing our interactions with it. But if you try to count all of the work the browser has to do to layout and render one DOM element, suddenly React feels very tiny.

[daliwali]

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.

[jasode]

>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]

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]

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]

If shaming isn't the purpose of downvoting, or the soft suppression of controversial opinions, then I don't know what is.

[mst]

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).

[matthewmacleod]

You haven't really made any constructive comments though, beyond general belly-aching about how shitty frameworks are.

[RUTHLESS_RUFUS]

If you're taking this personally, you're not going to develop personally from the critical engagement. Remove your ego from the discussion.

[daliwali]

Why would I take comments from disembodied strangers on the Internet on a personal level, or "develop personally" from people replying only to copy and paste verbatim from marketing, doesn't make sense.

All I did was write the only critical comment in this thread. Everyone else who replied to the OP contributed, "great job, thanks A+".

[jchw]

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.

[Vinnl]

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]

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]

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.

[guscost]

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

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.