| HN Mirror

> Wow. I am clinging to the past JS development model? I said nothing of technical substance?

Yes and this reply hasn't got any better, which mainly consists of dumping meaningless cliche's that are meant to sound clever but have very little connection in justifying any of your assertions.

> What you're misunderstanding is the basic foundations of solid software principles. Popularity does not equal tried and true. That's not logical.

Case-in-point, this is a very weak and transparent argumentative style. Focus on technical merits not dumping meaningless cliches which only adds negative value to your argument. I can already tell the rest of your comment is going to have very little substance.

> I understand React, or else how could I possibly nail it to the wall?

You haven't done anything of the sort, your baseless points shows the exact opposite that you have no idea how React works or the benefits it provides.

> You assume I use some sort of JQuery paradigm to develop UI applications, that a pretty presumptive claim on your part and it is absolutely not true.

Then show something else where modifying the DOM directly offers a better programming paradigm as you've claimed. jQuery at least made DOM mutations bearable, which was a much better improvement than what was available before it.

> If you want to develop a large and "simple" application look at Aurelia.

Yeah that's an example of another non-jQuery modern SPA that saves you from modifying the DOM directly.

> The whole point of a web app, large or small is to keep it simple.

No the point of a web app is to deliver value for its intended purpose, the benefit of a FX is to manage complexity which React's declarative one-way data flow architecture lets you do by leaving you to just focus on how your App looks for any given state instead of handling all the imperative mutations for implementing your App's functionality and all its interim DOM state, which is what old-school development of modifying the DOM directly forces you to do. This doesn't scale for large Web Apps and is one of the reasons why React has become so popular.

> What do you think you're doing when you manage the state of a React component?

Exactly what it says, you're just managing your Apps state, React takes care of batching the required DOM mutations so the DOM matches the declarative view of your App's component.

> If you cannot debug your app and understand its and runtime state.

You can absolutely inspect your Component state at any point in time, which React excels at as you only need to look at your App's state and not the state of the DOM which is much harder to debug/analyze/maintain.

> you need to look at your complexity bottlenecks

You need to lookup complexity bottlenecks

> The browser runtime is an event-driven framework. Custom events avoid implicit calls and runtime race conditions.

More factoids that does nothing to serve your argument. Seems you're just looking for spaces to shove meaningless points in.

> What I am clinging to is the living standard and a clean separation of concerns in software development.

Imperatively mutating the DOM suggests otherwise. You come off as clinging on to old school development and are fearful of any new development paradigm that threatens your existing knowledge.

React separation of state and view and easy encapsulation offers the ideal componentization model. Encapsulation and easy composition are vital in building large Apps composed of isolated and reusable components.

> I am standing on the shoulders of giants.

Another disconnected cliche, you're now resorting to using blind faith to guide your thoughts rather than any sound technical points or are able to offer any alternatives that show where something else is comparatively better - deflecting it now as: it's different to what was built before, so must be bad.

> I cannot help what choices developers make and what shortcuts they make to understand the browser's inherent technology.

You should make an effort to understand what value a technology provides before you can discount it and you should definitely have in-depth knowledge about something before you can discredit it.

> I've actually built enterprise SPAs and I have been doing it for the last 16 years, since the DOM was actually introduced.

Doesn't sound like you know what an SPA is, which was only coined in 11 years ago that only became popularized and a viable choice after JS VM's got fast. "Enterprise SPAs" would be the last place they were being adopted in any meaningful way. The years you've spent using old-school technologies is likely contributing to your fear of considering alternative development models.

> Decompose React yourself.

I've already developed several React Apps after having tried all leading JS FX's - I consider React by far the best development paradigm for building large SPAs (and UIs in general) as I have a preference for its small, but very powerful surface area. React/Redux lets you focus on a higher class of abstraction making it trivial to build certain classes of Apps that would otherwise take an order of magnitude more effort, leaving you with a much more complicated and harder to reason about code-base.

It may not be your preference which is fine, but you should have actual reasons before discrediting it.

> I've laid out my argument. It's not a rant, it's reality.

You've really not laid out any arguments, just baseless statements without justification.

> React may have attractive advantages, but I don't think its adoptees understand the seriousness of the trade-offs they're making.

Yes React's development model has several advantages, and I'd expect the teams putting in the effort and investment to rewrite their large JavaScript code-bases know exactly the benefits it provides, given their experience with short-fall of existing technologies.