4 ms·

It became so steadily imprinted into minds of developers that very few realize how nuts it all is. Back in 2000 nobody in their mind would take seriously these

by wruza 4y ago

It became so steadily imprinted into minds of developers that very few realize how nuts it all is. Back in 2000 nobody in their mind would take seriously these perverted constructs loaded with footguns to create a form. And even if you are aware of what’s going on, this thing itself struggles to solve trivial tasks in non-twisted ways. Sigh.

plantwallshoe 4y ago
Creating all but the most basic of forms with plain html/css/js is loaded with footguns too. Add in conditional fields, multi-page flows, loading and error states, etc then it becomes clear why solutions like React were created and why they have become so popular.
- Escapado 4y ago
  I could not agree more. At my current gig we have forms spanning 6 pages, where the state of each sub-form needs to be preserved, pretty much half of the form fields are conditionally loaded across all pages. There is tons of dynamic data displayed and sometimes that needs to be transformed client side, has loading and error states and there is heaps of validation happening, some of it asynchronously and it involves calling other services. Some of the inputs should be also preserved for other parts of the page regardless of whether the user fully completes all forms or not and then there is a whole basket of custom tracking that the marketing team insists needs to happen. You could of course argue that this is bad UX or that the problem starts with the requirements but that’s usually not something engineers a lot of have control over so I am actually quiet grateful that we have a framework that lets me solve this (imho) more sanely than if I were to hack away in vanilla JS.
- infamia 4y ago
  It is very true that the types of situations you mentioned are very painful with just HTML/CSS/Vanilla JS. However, React is no longer the only game in town for the things you mentioned. LowJS frameworks like Unpoly with a good server side rendering framework can handle the things you've described and a lot more. For example, you can use Unpoly with a server-side framework to allow layers to either act independently or to cascade information down to lower layers for multi-page/modal window flows that need to share information all without full page reloads. [1] Using layers you could build some pretty decent sized apps, Unpoly gives an example [1] showing (conceptually) how you could build large parts of Gmail with layers. You can also do things like dynamic forms with a bit of code on the back end. You get all this without needing to keep state in sync between the front end and the back end. There will be cases where Unpoly (which can do quite a lot) only does 95% (or whatever) of your requirements. In those cases you can sprinkle in a bit of Vanilla JS to help fill the gap. Additionally, there will be some cases where Unpoly isn't at all suitable, like if you're building something that is extremely interactive (i.e. the next Google Docs/Maps or similar). However, those cases keep getting smaller as these LowJS Frameworks improve. Everyone's case is a very particular set of circumstances and this might not apply at all to your situation, but others are finding success with using HTML over the wire types of approaches. [3] One final thing to note that's often overlooked is that CSS' capabilities are growing, and can do a more than in the past. All things to think about before reflexively defaulting to React. [1] https://unpoly.com/up.layer https://unpoly.com/up.layer [2] https://unpoly.com/tutorial https://unpoly.com/tutorial [3] https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/
  - erikpukinskis 4y ago
    > In those cases you can sprinkle in a bit of Vanilla JS to help fill the gap. I think this is where your proposition causes me to raise an eyebrow. If you can stay 100% within your framework then I can accept it will be simpler and more productive than React. But this architecture of “95% in-framework and 5% JavaScript spaghetti”… I don’t trust that. That sounds like a lot of days burnt trying to bolt that one feature onto a framework that doesn’t support them. And a lot of days debugging into the framework internals to try to understand which possible implementation of that feature won’t blow up by crossing some assumption of the framework. And I’m not sure you can argue as convincingly that’s less effort than the 100% React solution. IMO the beauty of React is you can do anything you’re asked to do. There’s alway a “React-y” way to do something. That’s because it’s lower level than a framework. It’s just a set of primitives. And pretty well thought out, battle tested primitives at that. And, when you do it right, you can have a very large piece of software that’s made entirely of small, functional modules. And there are simple rules for following the control flow. Once you understand those rules (and it does take a few years to really grok them) then you can drop in to any module in a massive system and follow the control flow easily. In a framework you don’t have that. There’s various points where your code calls into some declarative interface the framework has exposed, and then *magic happens* and the wrong behavior pops out on some other end of the application. It’s a debugging brick wall and in my experience it’s a massive time sink. Even in React many third party libraries also put you in this position, but that’s a whole other rant… But that is React’s superpower: when you use it correctly your time spent debugging any one defect is closer to O(1). With more “black box” frameworks your debugging time can be more like O(n), where n is the size of the codebase. For small codebases, there’s no difference, or maybe the framework is faster even. But for large codebases I think React has a massive productivity boost there. And all of this is predicated on that 5% number you quoted. If you can stay 100% within the framework, go for it. But in my experience business needs are always going be pushing 5%, 10%, 20% of the “special requests” and if you don’t plan for that, they can start taking up 50%, 60%, 70% of your time.
    - infamia 4y ago
      > There’s alway a “React-y” way to do something. There are ways to most anything. The question is whether it is a good or not. The best/worst thing React did to web development is taking a cleaver and splitting the front end and the back end down the middle. It is the best because it provided a clear answer to adding dynamic content that didn't end up a horrible mess like jQuery at scale. However, the worst thing it did was split the front end and the back end. The typical setup of, a front and developer and a backend developer, often on separate teams is a big problem spawned by React. Whenever you want to do anything new in these situations, you need to meet with the backend developers to build endpoints for you. This slows things down tremendously and creates friction during development. Even moderately interactive pages, going through all of this is way overkill and you're very likely wasting so much time (all other things being equal). With traditional server-side frameworks (e.g., Laravel, Django, Rails, etc.) you don't need to wait for anyone to build your endpoints or set up a byzantine labyrinth of JS tooling before you can code the first line. Don't get me wrong, React is a great tool and the best tool to building many SPAs, but it isn't the right tool for every job. There's a reason why so many people in this post are saying they've had it with React, which isn't something one used to see on this site. Now it's fairly commonplace to see people looking for greener pastures. > But this architecture of “95% in-framework and 5% JavaScript spaghetti”… I don’t trust that. That sounds like a lot of days burnt trying to bolt that one feature onto a framework that doesn’t support them. And a lot of days debugging into the framework internals to try to understand which possible implementation of that feature won’t blow up by crossing some assumption of the framework. And I’m not sure you can argue as convincingly that’s less effort than the 100% React solution. That's a pretty easy answer, you can drop in a React/VanillaJS Web Components or VueJS Components whenever you like. If you're still feeling unsure, just go with Hotwire, which has an small JS framework (Stimulus) for dealing with the odd bits of Vanilla JS to give your HTML a bit more interactivity. Now you have a belts and suspenders backstop to handle feature creep and increasing interactivity. There are other tools for doing similar things to Stimulus. > But that is React’s superpower: when you use it correctly your time spent debugging any one defect is closer to O(1). Nothing is for free. The tradeoff is that you're going to spend more time figuring out state sync issues/debugging/refactoring your API endpoints. > And all of this is predicated on that 5% number you quoted. If you can stay 100% within the framework, go for it. But in my experience business needs are always going be pushing 5%, 10%, 20% of the “special requests” and if you don’t plan for that, they can start taking up 50%, 60%, 70% of your time. In an effort gently persuade, I may have undersold just how little (i.e., 0%) Javascript you'll need to write for many types of common pages and patterns. HTML over the wire frameworks all came out around 2015-2016, which means they're all battle tested and have seen a lot of use cases. Turbolinks/Hotwire and Unpoly both came out of companies who are presently or started out as web agencies. Basecamp has been powered by HTML over the wire for years. Now Hey.com email is showing what this approach can do for a pretty ambitious application. Part of the founder's pitch for Unpoly is that he uses Unpoly and in his agency and supports his apps for a long time, so you need not worry about it going anywhere. Because of this, the number of use cases these frameworks have seen and handle is significant. Web dev shops constantly deal with exactly the sort of feature creep you mentioned. If these frameworks were a big problem or had huge limitations that you're concerned about, their founders supporting companies would have abandoned them long ago, to say nothing about all their users. Time is money in web agencies, so I would be surprised if they experience the situation you're describing. I'm not saying HTML over the wire is the end-all-be-all, only that they are good enough today to remove the always default to React mindset for many shops and situations.
- Existenceblinks 4y ago
  I wonder you have ever tried doing all of this in vanilla js. Of course you will end up with your own tiny lib, but it's definitely not as hard as React.
  - isbvhodnvemrwvn 4y ago
    It is much harder when you are working with other people and need to learn everyone's "tiny libs".
thrashh 4y ago
Most of these mistakes are programming mistakes. You’d be in trouble doing the && shortcut in a lot of places. And second, not at all. E4X existed in the 2000s and was widely implemented in Firefox (then the biggest modern browser) and Flash (the other de facto runtime). E4X let you embed XML directly in JS and you basically were able to build React-style templating without the preprocesor that React requires. So basically the world has been working on something like React for 2 decades. React just is so far the best version of SGML in code.
worldsayshi 4y ago
I'm a fairly seasoned react developer and I've been thinking about this debate that have been going on lately. Meanwhile I'm writing a fairly involved front end app in vanilla JavaScript and a bit of jQuery. It's a blast from the past for me. I went into this period of debate with what I feel is an open mind. Open to the possibility that react really is overrated and more trouble than it's worth. But after writing this app I'm very well reminded of why I was so enthusiastic about react way back when. Handling state updates in vanilla JavaScript is quite messy. Then again, react is far from a perfect solution to the problem. It adds about as much complications as it takes away. I hope we can find better solutions. But I'm not sure how to move forward when it seems so hard to agree on what the problem is.
- wruza 4y ago
  As I see it, the problem is that: (1) react tries to teach everyone new bizarre ways of writing code instead of being a toolkit, (2) web is historically so focused on old-crazy-web <-> new-crazy-web dichotomy that cannot see past it. (1a) is the web’s desire to mix “ui rendering” with “state management” which are two different things.
  - frodowtf 4y ago
    State management has lead to a bunch of different frameworks (e.g. redux, mobx, zustand). They are also not really pleasent to use and sort of mix into UI rendering. How would your approach at seperating state from UI look like?
    - strokirk 4y ago
      If they are not pleasant to use, why are you using them? It’s literally the value they are supposed to introduce.
      - frodowtf 4y ago
        I'm not using them for said reason
rad_gruchalski 4y ago
No, of course. Back in 2000 we loved handling our own window.__mynamespace variables. The world was so much better with document.forms[0].submit. Those beautiful days of document.write, document.elementid.property. I’m nostalgic.
- wruza 4y ago
  Web was always less disciplined in this regard, compared to desktop. Being a desktop app developer back in 2000 you’d just pack some widgets together, set handlers for single-value widgets to fire into a controller object, set up data sources for tables and that’s it. No markup concatenation or implicit on-return behavior. There were thousands of pre-react desktop apps on frameworks from turbovision to *tk to appkit and not a single one of them mismanaged focus because of a missing “key” or required to “update state through slicing an array” nonsense. This old pain you feel is historically self-inflicted and doesn’t exist elsewhere. I made a bunch of apps and user interfaces with these frameworks myself. It was natural and straightforward. Sometimes it could get clunky and hack-y due to limitations, but usually it was the level when a whole react team would be fired for economical reasons (think of multi-tab forms with settings, dialogs, master-details, complex table input, etc). Edit: “slicing”
  - rad_gruchalski 4y ago
    But it all sucked big time because what we all wanted, was to run those apps in the browser and on the desktop. Adobe Flex was the first real thing that came close: you could have loaded a swf file into an air wrapper. But Flash is dead, Flex is dead. And now we have what we have. It could have been worse. Frankly, Flex did s lot of things right. The layout and the default widget library was top notch. The grid was a killer feature. The IDE was really helpful.
- Existenceblinks 4y ago
  You know js now has modules and better DOM API.
  - rad_gruchalski 4y ago
phailhaus 4y ago
Nobody's telling you to use React when you have a static HTML page. But if you ever worked on an app of even medium complexity, you would understand what React is solving for developers. State management is the problem, and your vanilla JS forms are not going to cut it.
- wruza 4y ago
  The problem is, I worked on these, half of my life. And while I agree that declarative rendering has its upsides, I am not blind to downsides and bait-and-switch-complexity tricks. React is pretending to be a functional “not your concern how it’s done” language without any safety nets or execution models these usually provide.
  - phailhaus 4y ago
    If we agree that declarative rendering has its upsides, then it is ridiculous to keep moaning that the complexity is "nuts" and that everyone's just insane for no reason. React is what a declarative model looks like. It eliminates an entire class of UI, state, and behavior management issues, in exchange for working within its rendering engine. If you're looking to build a complex frontend, that is extremely attractive.
    - porker 4y ago
      > If we agree that declarative rendering has its upsides, then it is ridiculous to keep moaning that the complexity is "nuts" and that everyone's just insane for no reason. React is what a declarative model looks like. Are you saying that Vue isn't a declarative model?
- strokirk 4y ago
  I’ve actually replaced a bunch of static HTML pages with React, to benefit from TypeScript. I’m horrible with spelling and it helps me a lot.

by wruza 4y ago

plantwallshoe 4y ago

Creating all but the most basic of forms with plain html/css/js is loaded with footguns too. Add in conditional fields, multi-page flows, loading and error states, etc then it becomes clear why solutions like React were created and why they have become so popular.

Escapado 4y ago
I could not agree more. At my current gig we have forms spanning 6 pages, where the state of each sub-form needs to be preserved, pretty much half of the form fields are conditionally loaded across all pages. There is tons of dynamic data displayed and sometimes that needs to be transformed client side, has loading and error states and there is heaps of validation happening, some of it asynchronously and it involves calling other services. Some of the inputs should be also preserved for other parts of the page regardless of whether the user fully completes all forms or not and then there is a whole basket of custom tracking that the marketing team insists needs to happen. You could of course argue that this is bad UX or that the problem starts with the requirements but that’s usually not something engineers a lot of have control over so I am actually quiet grateful that we have a framework that lets me solve this (imho) more sanely than if I were to hack away in vanilla JS.
infamia 4y ago
It is very true that the types of situations you mentioned are very painful with just HTML/CSS/Vanilla JS. However, React is no longer the only game in town for the things you mentioned. LowJS frameworks like Unpoly with a good server side rendering framework can handle the things you've described and a lot more. For example, you can use Unpoly with a server-side framework to allow layers to either act independently or to cascade information down to lower layers for multi-page/modal window flows that need to share information all without full page reloads. [1] Using layers you could build some pretty decent sized apps, Unpoly gives an example [1] showing (conceptually) how you could build large parts of Gmail with layers. You can also do things like dynamic forms with a bit of code on the back end. You get all this without needing to keep state in sync between the front end and the back end. There will be cases where Unpoly (which can do quite a lot) only does 95% (or whatever) of your requirements. In those cases you can sprinkle in a bit of Vanilla JS to help fill the gap. Additionally, there will be some cases where Unpoly isn't at all suitable, like if you're building something that is extremely interactive (i.e. the next Google Docs/Maps or similar). However, those cases keep getting smaller as these LowJS Frameworks improve. Everyone's case is a very particular set of circumstances and this might not apply at all to your situation, but others are finding success with using HTML over the wire types of approaches. [3] One final thing to note that's often overlooked is that CSS' capabilities are growing, and can do a more than in the past. All things to think about before reflexively defaulting to React. [1] https://unpoly.com/up.layer https://unpoly.com/up.layer [2] https://unpoly.com/tutorial https://unpoly.com/tutorial [3] https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/
- erikpukinskis 4y ago
  > In those cases you can sprinkle in a bit of Vanilla JS to help fill the gap. I think this is where your proposition causes me to raise an eyebrow. If you can stay 100% within your framework then I can accept it will be simpler and more productive than React. But this architecture of “95% in-framework and 5% JavaScript spaghetti”… I don’t trust that. That sounds like a lot of days burnt trying to bolt that one feature onto a framework that doesn’t support them. And a lot of days debugging into the framework internals to try to understand which possible implementation of that feature won’t blow up by crossing some assumption of the framework. And I’m not sure you can argue as convincingly that’s less effort than the 100% React solution. IMO the beauty of React is you can do anything you’re asked to do. There’s alway a “React-y” way to do something. That’s because it’s lower level than a framework. It’s just a set of primitives. And pretty well thought out, battle tested primitives at that. And, when you do it right, you can have a very large piece of software that’s made entirely of small, functional modules. And there are simple rules for following the control flow. Once you understand those rules (and it does take a few years to really grok them) then you can drop in to any module in a massive system and follow the control flow easily. In a framework you don’t have that. There’s various points where your code calls into some declarative interface the framework has exposed, and then *magic happens* and the wrong behavior pops out on some other end of the application. It’s a debugging brick wall and in my experience it’s a massive time sink. Even in React many third party libraries also put you in this position, but that’s a whole other rant… But that is React’s superpower: when you use it correctly your time spent debugging any one defect is closer to O(1). With more “black box” frameworks your debugging time can be more like O(n), where n is the size of the codebase. For small codebases, there’s no difference, or maybe the framework is faster even. But for large codebases I think React has a massive productivity boost there. And all of this is predicated on that 5% number you quoted. If you can stay 100% within the framework, go for it. But in my experience business needs are always going be pushing 5%, 10%, 20% of the “special requests” and if you don’t plan for that, they can start taking up 50%, 60%, 70% of your time.
  - infamia 4y ago
    > There’s alway a “React-y” way to do something. There are ways to most anything. The question is whether it is a good or not. The best/worst thing React did to web development is taking a cleaver and splitting the front end and the back end down the middle. It is the best because it provided a clear answer to adding dynamic content that didn't end up a horrible mess like jQuery at scale. However, the worst thing it did was split the front end and the back end. The typical setup of, a front and developer and a backend developer, often on separate teams is a big problem spawned by React. Whenever you want to do anything new in these situations, you need to meet with the backend developers to build endpoints for you. This slows things down tremendously and creates friction during development. Even moderately interactive pages, going through all of this is way overkill and you're very likely wasting so much time (all other things being equal). With traditional server-side frameworks (e.g., Laravel, Django, Rails, etc.) you don't need to wait for anyone to build your endpoints or set up a byzantine labyrinth of JS tooling before you can code the first line. Don't get me wrong, React is a great tool and the best tool to building many SPAs, but it isn't the right tool for every job. There's a reason why so many people in this post are saying they've had it with React, which isn't something one used to see on this site. Now it's fairly commonplace to see people looking for greener pastures. > But this architecture of “95% in-framework and 5% JavaScript spaghetti”… I don’t trust that. That sounds like a lot of days burnt trying to bolt that one feature onto a framework that doesn’t support them. And a lot of days debugging into the framework internals to try to understand which possible implementation of that feature won’t blow up by crossing some assumption of the framework. And I’m not sure you can argue as convincingly that’s less effort than the 100% React solution. That's a pretty easy answer, you can drop in a React/VanillaJS Web Components or VueJS Components whenever you like. If you're still feeling unsure, just go with Hotwire, which has an small JS framework (Stimulus) for dealing with the odd bits of Vanilla JS to give your HTML a bit more interactivity. Now you have a belts and suspenders backstop to handle feature creep and increasing interactivity. There are other tools for doing similar things to Stimulus. > But that is React’s superpower: when you use it correctly your time spent debugging any one defect is closer to O(1). Nothing is for free. The tradeoff is that you're going to spend more time figuring out state sync issues/debugging/refactoring your API endpoints. > And all of this is predicated on that 5% number you quoted. If you can stay 100% within the framework, go for it. But in my experience business needs are always going be pushing 5%, 10%, 20% of the “special requests” and if you don’t plan for that, they can start taking up 50%, 60%, 70% of your time. In an effort gently persuade, I may have undersold just how little (i.e., 0%) Javascript you'll need to write for many types of common pages and patterns. HTML over the wire frameworks all came out around 2015-2016, which means they're all battle tested and have seen a lot of use cases. Turbolinks/Hotwire and Unpoly both came out of companies who are presently or started out as web agencies. Basecamp has been powered by HTML over the wire for years. Now Hey.com email is showing what this approach can do for a pretty ambitious application. Part of the founder's pitch for Unpoly is that he uses Unpoly and in his agency and supports his apps for a long time, so you need not worry about it going anywhere. Because of this, the number of use cases these frameworks have seen and handle is significant. Web dev shops constantly deal with exactly the sort of feature creep you mentioned. If these frameworks were a big problem or had huge limitations that you're concerned about, their founders supporting companies would have abandoned them long ago, to say nothing about all their users. Time is money in web agencies, so I would be surprised if they experience the situation you're describing. I'm not saying HTML over the wire is the end-all-be-all, only that they are good enough today to remove the always default to React mindset for many shops and situations.
Existenceblinks 4y ago
I wonder you have ever tried doing all of this in vanilla js. Of course you will end up with your own tiny lib, but it's definitely not as hard as React.
- isbvhodnvemrwvn 4y ago
  It is much harder when you are working with other people and need to learn everyone's "tiny libs".

thrashh 4y ago

Most of these mistakes are programming mistakes. You’d be in trouble doing the && shortcut in a lot of places. And second, not at all. E4X existed in the 2000s and was widely implemented in Firefox (then the biggest modern browser) and Flash (the other de facto runtime). E4X let you embed XML directly in JS and you basically were able to build React-style templating without the preprocesor that React requires. So basically the world has been working on something like React for 2 decades. React just is so far the best version of SGML in code.

worldsayshi 4y ago

I'm a fairly seasoned react developer and I've been thinking about this debate that have been going on lately. Meanwhile I'm writing a fairly involved front end app in vanilla JavaScript and a bit of jQuery. It's a blast from the past for me. I went into this period of debate with what I feel is an open mind. Open to the possibility that react really is overrated and more trouble than it's worth. But after writing this app I'm very well reminded of why I was so enthusiastic about react way back when. Handling state updates in vanilla JavaScript is quite messy. Then again, react is far from a perfect solution to the problem. It adds about as much complications as it takes away. I hope we can find better solutions. But I'm not sure how to move forward when it seems so hard to agree on what the problem is.

wruza 4y ago
As I see it, the problem is that: (1) react tries to teach everyone new bizarre ways of writing code instead of being a toolkit, (2) web is historically so focused on old-crazy-web <-> new-crazy-web dichotomy that cannot see past it. (1a) is the web’s desire to mix “ui rendering” with “state management” which are two different things.
- frodowtf 4y ago
  State management has lead to a bunch of different frameworks (e.g. redux, mobx, zustand). They are also not really pleasent to use and sort of mix into UI rendering. How would your approach at seperating state from UI look like?
  - strokirk 4y ago
    If they are not pleasant to use, why are you using them? It’s literally the value they are supposed to introduce.
    - frodowtf 4y ago
      I'm not using them for said reason

rad_gruchalski 4y ago

No, of course. Back in 2000 we loved handling our own window.__mynamespace variables. The world was so much better with document.forms[0].submit. Those beautiful days of document.write, document.elementid.property. I’m nostalgic.

wruza 4y ago
Web was always less disciplined in this regard, compared to desktop. Being a desktop app developer back in 2000 you’d just pack some widgets together, set handlers for single-value widgets to fire into a controller object, set up data sources for tables and that’s it. No markup concatenation or implicit on-return behavior. There were thousands of pre-react desktop apps on frameworks from turbovision to *tk to appkit and not a single one of them mismanaged focus because of a missing “key” or required to “update state through slicing an array” nonsense. This old pain you feel is historically self-inflicted and doesn’t exist elsewhere. I made a bunch of apps and user interfaces with these frameworks myself. It was natural and straightforward. Sometimes it could get clunky and hack-y due to limitations, but usually it was the level when a whole react team would be fired for economical reasons (think of multi-tab forms with settings, dialogs, master-details, complex table input, etc). Edit: “slicing”
- rad_gruchalski 4y ago
  But it all sucked big time because what we all wanted, was to run those apps in the browser and on the desktop. Adobe Flex was the first real thing that came close: you could have loaded a swf file into an air wrapper. But Flash is dead, Flex is dead. And now we have what we have. It could have been worse. Frankly, Flex did s lot of things right. The layout and the default widget library was top notch. The grid was a killer feature. The IDE was really helpful.
Existenceblinks 4y ago
You know js now has modules and better DOM API.
- rad_gruchalski 4y ago

phailhaus 4y ago

Nobody's telling you to use React when you have a static HTML page. But if you ever worked on an app of even medium complexity, you would understand what React is solving for developers. State management is the problem, and your vanilla JS forms are not going to cut it.

wruza 4y ago
The problem is, I worked on these, half of my life. And while I agree that declarative rendering has its upsides, I am not blind to downsides and bait-and-switch-complexity tricks. React is pretending to be a functional “not your concern how it’s done” language without any safety nets or execution models these usually provide.
- phailhaus 4y ago
  If we agree that declarative rendering has its upsides, then it is ridiculous to keep moaning that the complexity is "nuts" and that everyone's just insane for no reason. React is what a declarative model looks like. It eliminates an entire class of UI, state, and behavior management issues, in exchange for working within its rendering engine. If you're looking to build a complex frontend, that is extremely attractive.
  - porker 4y ago
    > If we agree that declarative rendering has its upsides, then it is ridiculous to keep moaning that the complexity is "nuts" and that everyone's just insane for no reason. React is what a declarative model looks like. Are you saying that Vue isn't a declarative model?
strokirk 4y ago
I’ve actually replaced a bunch of static HTML pages with React, to benefit from TypeScript. I’m horrible with spelling and it helps me a lot.