Wow. I am clinging to the past JS development model? I said nothing of technical substance? If you want to develop a large and "simple" application look at Aurelia. The whole point of a web app, large or small is to keep it simple.
What you're misunderstanding is the basic foundations of solid software principles. Popularity does not equal tried and true. That's not logical. I understand React, or else how could I possibly nail it to the wall? 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.
>Working directly with the DOM means mutating it in-line and your state and you have to become a manual book keeper to make sure your App state and DOM mutations stay in-sync. It's slower, more tedious to maintain, harder to debug and visualize your App's state, etc. There's a reason why the world and all major SPA fx's has moved on from jQuery, you're clinging on to the past JS development model.
No, this is not what it means, this is your opinion. What do you think you're doing when you manage the state of a React component? If you cannot debug your app and understand its and runtime state, you need to look at your complexity bottlenecks. The browser runtime is an event-driven framework. Custom events avoid implicit calls and runtime race conditions.
What I am clinging to is the living standard and a clean separation of concerns in software development. I am standing on the shoulders of giants. I cannot help what choices developers make and what shortcuts they make to understand the browser's inherent technology. I've actually built enterprise SPAs and I have been doing it for the last 16 years, since the DOM was actually introduced.
Decompose React yourself. I've laid out my argument. It's not a rant, it's reality. React may have attractive advantages, but I don't think its adoptees understand the seriousness of the trade-offs they're making.
You need to look into what separation of concerns really is and isn't. Switching back and forth between your highly coupled data model and view is not separation of concerns.
> 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.
lol dude, you're a riot. Have a discussion. How far you want to drift away from the issues that have been laid it is not a discussion. Everything you write is just one big red-herring and the proof of that is laid out right on this thread.
There are direct responses to each of your baseless assertions. You've provided no proof and its your meaningless cliches that are the red-herring, likely used to cover up your lack of knowledge about React and SPAs in general. Walls of text that's not close to demonstrating one iota of proof.
What you're misunderstanding is the basic foundations of solid software principles. Popularity does not equal tried and true. That's not logical. I understand React, or else how could I possibly nail it to the wall? 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.
>Working directly with the DOM means mutating it in-line and your state and you have to become a manual book keeper to make sure your App state and DOM mutations stay in-sync. It's slower, more tedious to maintain, harder to debug and visualize your App's state, etc. There's a reason why the world and all major SPA fx's has moved on from jQuery, you're clinging on to the past JS development model.
No, this is not what it means, this is your opinion. What do you think you're doing when you manage the state of a React component? If you cannot debug your app and understand its and runtime state, you need to look at your complexity bottlenecks. The browser runtime is an event-driven framework. Custom events avoid implicit calls and runtime race conditions.
What I am clinging to is the living standard and a clean separation of concerns in software development. I am standing on the shoulders of giants. I cannot help what choices developers make and what shortcuts they make to understand the browser's inherent technology. I've actually built enterprise SPAs and I have been doing it for the last 16 years, since the DOM was actually introduced.
Decompose React yourself. I've laid out my argument. It's not a rant, it's reality. React may have attractive advantages, but I don't think its adoptees understand the seriousness of the trade-offs they're making.