6 ms·

This is the typical "we didn't spend any time thinking about our architecture therefore we're going to blame our framework" article. React is a great choice fo

This is the typical "we didn't spend any time thinking about our architecture therefore we're going to blame our framework" article. React is a great choice for certain use-cases, but when low-quality developers are allowed to pick it up and apply it to everything you end up in a mess. The same thing happens with literally any tool. If you want speedy initial interaction times and manageable codebases, (and requirement X) use the right tools for the job, and instil better, thoughtful, development culture.

piranha 6y ago
This is typical "I drink React kool-aid so I'll never give benefit of the doubt to anybody who's not supporting my point of view" comment.
Udik 6y ago
In general, these posts sound a bit like this: I tried jQuery, and after a while it all became a mess; took up a Backbone project, and was good for a while, but eventually it became too complex; then I worked on Angular and that seemed a big improvement, but then... and finally with React my architectures are clean. While the reality is more like this: I had 6 months of programming experience and used jQuery and made a disaster; with 1.5 years of experience I used Backbone and I fared better; with 3 years of experience I tried Angular and I was able to build a decent size application but ultimately shot myself in the foot; and now that I have 6 years of experience my software quality has improved a lot, it must be react!
- mgkimsal 6y ago
  I would change it a bit and suggest that after angular, they did react, and after 18 months of that it was too convoluted, but 'hooks' solved everything, and then 12-18 months after that, things are just way too complex, and they're now investigating svelte or something else. I rarely see any decent architecture survive growth and real world use beyond a couple years. It's usually either 1) "no one could possibly have foreseen this new use case/requirement" (from less experienced folks) or 2) "YAGNI!" when trying to build in some abstraction levels to handle use cases you know will happen down the road.
  - nkozyra 6y ago
    In reality these often become the scapegoat for a need to refactor. I know refactor is a four letter word to some, but the truth is we grow as developers and architects and learn from our mistakes. There's a tendency to blame the tools. You can build a big, high quality app in almost any language and framework.
- tom_walters 6y ago
  Pretty much. It's similar to discovering the power of salt and pepper in cooking. When you first use it everything tastes better. But the next step is not to increase the amounts you use in every dish, it's to explore the much wider world of cooking with herbs/spices/etc. If your mindset is persistently "this framework/tool will solve all our problems" you're always going to have a bad time. Understanding the pros/cons of each element is essential to becoming a good developer.
  - AtlasBarfed 6y ago
    It's almost like all "modern JS" are written by new programmers hired on the cheap by companies to work on their new hip UI frontends. IMO UI is generally something new programmers like because of the visual/visceral "I built that", but once you get exposed to the sheer annoyance of UIs, programmers will migrate to backend. So the most experienced people don't want to be constantly undercut in price by the incoming "talent", realize that WebUIs get chucked every 3-5 years anyway due to browser tech churn, and move to data monopolization.
    - collyw 6y ago
      The JavaScript world changes so fast that no one is ever going to be very experienced in the the they are using. I imagine that is partially to blame for all the crap we see in the front end.
      - AtlasBarfed 6y ago
        I agree, the JS ecosystem is reflective of constant new programmers redoing the UI every couple years, although I need to grit my teeth and admit that React did at least standardize/structure the ecosystem for the last few years.
    - jokethrowaway 6y ago
      This can be generalised to all software that is perceived to be revolutionary. Sooner or later a big company that wants to retain and attract engineering talents will arrive, with a horde or junior engineers led by an engineer looking to justify a promotion or to embellish a CV. API generators had the same thing. Strongloop was a decent frameworks before they started throwing 10'000 juniors to fix issues and made a mess of the codebase. If you look at the jungle the React codebase is and you compare it with Preact (it's smart, concise and performant) you'll understand why code quality matters. And I'm not talking about stupid metrics.
- dangoor 6y ago
  I disagree with the reality you present. There are a lot of people, myself included, with a considerable amount of experience who found that maintaining jQuery/Backbone code to be complex and error-prone and React presented a solution to this problem with a programming model that looks more like an immediate mode GUI (even though it ultimately paints to a retained mode DOM). I don't think it's worthwhile to minimize the actual, useful impact React has had for web apps.
christkv 6y ago
React has been god sent for us as we slowly modernise an application that is a mess of server rendered html and hacked together frontend code. Slowly we are rewriting individual pieces as embedded React components (no SPA here) and moving to a proper API layer that the components talk to. The separation of concern has made it a loot easier to increase code coverage and ensure a controlled rollout of new features. We also just bit the bullet and paid for syncfusion to use on our frontend to avoid reinventing the wheel for a lot of the functionality we need.
- toddmatthews 6y ago
  godsend
- _fat_santa 6y ago
  Honest question. As someone whose only worked with open source tech in React such as Bootstrap, Semantic UI, Material UI, etc, what is the advantage of a paid UI framework like this? Maybe stability? Besides Semantic UI I found that other frameworks are nowhere near as mature. I guess if you're a big company its a small price to pay but it also seems like you're paying a grand + per month for something with tons of free alternatives.
  - christkv 6y ago
    700 usd a year for the library for a developer. It saves us a ton of time as its a B2B business and we use a lot of stuff like a calendar view, gantt diagrams and scheduling. Rewriting it from scratch of adapting a random set of components would be more expensive in time and resources.
  - softawre 6y ago
    You're paying for the support you need when your developer can't fit requirement X into the component, or when they run into a bug, or whatever other reason.
- mixedCase 6y ago
  > The separation of concern has made it a loot easier to increase code coverage and ensure a controlled rollout of new features. This can be achieved (and more easily) by separating your templating from your business logic at the package level. If you know what you're doing you can keep things separate and your import graph non-cyclical, if you don't know what you're doing you're going to recreate the mess in your components and API anyway. Source: Tired of seeing this happen again and again and again and again. And fixing it.
untog 6y ago
IMO it’s unfair to blame “low quality developers”. The industry has coalesced around React as the one stop answer to everything. Coding boot camps focus on it to the detriment of broader web technologies. It’s worth calling out when it actually fit a use case.

piranha 6y ago

This is typical "I drink React kool-aid so I'll never give benefit of the doubt to anybody who's not supporting my point of view" comment.

Udik 6y ago

In general, these posts sound a bit like this: I tried jQuery, and after a while it all became a mess; took up a Backbone project, and was good for a while, but eventually it became too complex; then I worked on Angular and that seemed a big improvement, but then... and finally with React my architectures are clean. While the reality is more like this: I had 6 months of programming experience and used jQuery and made a disaster; with 1.5 years of experience I used Backbone and I fared better; with 3 years of experience I tried Angular and I was able to build a decent size application but ultimately shot myself in the foot; and now that I have 6 years of experience my software quality has improved a lot, it must be react!

mgkimsal 6y ago
I would change it a bit and suggest that after angular, they did react, and after 18 months of that it was too convoluted, but 'hooks' solved everything, and then 12-18 months after that, things are just way too complex, and they're now investigating svelte or something else. I rarely see any decent architecture survive growth and real world use beyond a couple years. It's usually either 1) "no one could possibly have foreseen this new use case/requirement" (from less experienced folks) or 2) "YAGNI!" when trying to build in some abstraction levels to handle use cases you know will happen down the road.
- nkozyra 6y ago
  In reality these often become the scapegoat for a need to refactor. I know refactor is a four letter word to some, but the truth is we grow as developers and architects and learn from our mistakes. There's a tendency to blame the tools. You can build a big, high quality app in almost any language and framework.
tom_walters 6y ago
Pretty much. It's similar to discovering the power of salt and pepper in cooking. When you first use it everything tastes better. But the next step is not to increase the amounts you use in every dish, it's to explore the much wider world of cooking with herbs/spices/etc. If your mindset is persistently "this framework/tool will solve all our problems" you're always going to have a bad time. Understanding the pros/cons of each element is essential to becoming a good developer.
- AtlasBarfed 6y ago
  It's almost like all "modern JS" are written by new programmers hired on the cheap by companies to work on their new hip UI frontends. IMO UI is generally something new programmers like because of the visual/visceral "I built that", but once you get exposed to the sheer annoyance of UIs, programmers will migrate to backend. So the most experienced people don't want to be constantly undercut in price by the incoming "talent", realize that WebUIs get chucked every 3-5 years anyway due to browser tech churn, and move to data monopolization.
  - collyw 6y ago
    The JavaScript world changes so fast that no one is ever going to be very experienced in the the they are using. I imagine that is partially to blame for all the crap we see in the front end.
    - AtlasBarfed 6y ago
      I agree, the JS ecosystem is reflective of constant new programmers redoing the UI every couple years, although I need to grit my teeth and admit that React did at least standardize/structure the ecosystem for the last few years.
  - jokethrowaway 6y ago
    This can be generalised to all software that is perceived to be revolutionary. Sooner or later a big company that wants to retain and attract engineering talents will arrive, with a horde or junior engineers led by an engineer looking to justify a promotion or to embellish a CV. API generators had the same thing. Strongloop was a decent frameworks before they started throwing 10'000 juniors to fix issues and made a mess of the codebase. If you look at the jungle the React codebase is and you compare it with Preact (it's smart, concise and performant) you'll understand why code quality matters. And I'm not talking about stupid metrics.
dangoor 6y ago
I disagree with the reality you present. There are a lot of people, myself included, with a considerable amount of experience who found that maintaining jQuery/Backbone code to be complex and error-prone and React presented a solution to this problem with a programming model that looks more like an immediate mode GUI (even though it ultimately paints to a retained mode DOM). I don't think it's worthwhile to minimize the actual, useful impact React has had for web apps.

christkv 6y ago

React has been god sent for us as we slowly modernise an application that is a mess of server rendered html and hacked together frontend code. Slowly we are rewriting individual pieces as embedded React components (no SPA here) and moving to a proper API layer that the components talk to. The separation of concern has made it a loot easier to increase code coverage and ensure a controlled rollout of new features. We also just bit the bullet and paid for syncfusion to use on our frontend to avoid reinventing the wheel for a lot of the functionality we need.

toddmatthews 6y ago
godsend
_fat_santa 6y ago
Honest question. As someone whose only worked with open source tech in React such as Bootstrap, Semantic UI, Material UI, etc, what is the advantage of a paid UI framework like this? Maybe stability? Besides Semantic UI I found that other frameworks are nowhere near as mature. I guess if you're a big company its a small price to pay but it also seems like you're paying a grand + per month for something with tons of free alternatives.
- christkv 6y ago
  700 usd a year for the library for a developer. It saves us a ton of time as its a B2B business and we use a lot of stuff like a calendar view, gantt diagrams and scheduling. Rewriting it from scratch of adapting a random set of components would be more expensive in time and resources.
- softawre 6y ago
  You're paying for the support you need when your developer can't fit requirement X into the component, or when they run into a bug, or whatever other reason.
mixedCase 6y ago
> The separation of concern has made it a loot easier to increase code coverage and ensure a controlled rollout of new features. This can be achieved (and more easily) by separating your templating from your business logic at the package level. If you know what you're doing you can keep things separate and your import graph non-cyclical, if you don't know what you're doing you're going to recreate the mess in your components and API anyway. Source: Tired of seeing this happen again and again and again and again. And fixing it.

untog 6y ago

IMO it’s unfair to blame “low quality developers”. The industry has coalesced around React as the one stop answer to everything. Coding boot camps focus on it to the detriment of broader web technologies. It’s worth calling out when it actually fit a use case.