5 ms·

> The point about React including so little that you become reliant on a ton of external dependencies that see even more churn than the usual JS framework lands

> The point about React including so little that you become reliant on a ton of external dependencies that see even more churn than the usual JS framework landscape is a very valid pain point, especially when you are building a very large application for the long-term. It's a feature, not a bug. Not understanding this is a red flag that you're going to run into problems. > React now looks completely different from React from 1-2 years ago. Does it? I've worked in React, at enterprise levels, for close to 3 years now. Except for the addition of hooks, there hasn't been a whole lot of churn. React today is still the react of yesteryear, but with extras. Imo the biggest failure of the author was to jump headfirst into a stack they weren't familiar with it, and then blame it on the stack. I know it's en vogue to hate npm/react/js "because the ecosystem", but at this point, picking the ecosystem and then blaming it is a self inflicted wound that I don't really have patience for.

_coveredInBees 6y ago
This is again so dismissive of the author. He seems to have a substantial amount of experience with React. He isn't just some noob who jumped on some bandwagon and picked the latest sexiest thing for reasons. If anything, the entire team seemed to do far more due diligence in decision making than pretty much 90% of the move-fast and break things (TM) SV startups. > It's a feature, not a bug. Yes, a small, light-weight framework can be a good thing. No one called it a bug. But like everything in life, there are trade-offs involved. And I'm not entirely convinced that it is a good tradeoff in the crazy JS ecosystem where everything is changing and breaking all the time, especially if you are building more complex things and don't have an army of web-devs to keep the house of cards from falling down.
- protonimitate 6y ago
  > If anything, the entire team seemed to do far more due diligence in decision making than pretty much 90% of the move-fast and break things (TM) SV startups. Right, but this still isn't the fault of React. My gripe with this article, and view points like this, is that instead of taking ownership it's again the tool that gets blame and just further perpetuates the "js bad" meme. > And I'm not entirely convinced that it is a good tradeoff in the crazy JS ecosystem where everything is changing and breaking all the time, especially if you are building more complex things. Right, and if that's your opinion (and a perfectly valid one!) then don't pick the JS ecosystem and cry when it bites you.
  - ralmidani 6y ago
    I agree people should take ownership over their decisions, but it's more nuanced than "don't cry": if someone makes a mistake/bad decision, shouldn't they warn others so they don't do the same? And frankly, let's stop pretending the JS ecosystem is not problematic. Can anyone in good faith argue for a JS project which offers the stability, refinement, and elegance of projects available for Ruby (Rails), Python (Django), Elixir (Phoenix), etc? Even micro-frameworks like Flask, which don't include tons of batteries, are still much more dev-friendly than Node/Express/React/etc.
    - nawgz 6y ago
      >frankly, let's stop pretending the JS ecosystem is not problematic. Can anyone in good faith argue for a Node project React is a node project, so I can do so trivially. React is a top tier library when it comes to key features like stability, documentation, backwards compatibility, and extensibility / usability. I can also say TypeScript is one of the most amazing projects of all time. Last but not least - express is super easy to use. I don't know what "dev-friendly" means, as a criteria though. Keep in mind, though, since it's JS, it's really easy to wrap and extend. To me, you have to justify how Flask is superior to Express; I think you just like Python more.
      - ralmidani 6y ago
        React is stable? React.createElement -> Sub-classing the Component class -> "just use hooks everywhere" in the span of a few years? Sure, Django went from function-based to class-based views, but the change was far less abrupt, and you can still use functional views if you want to. As for TypeScript, I agree it's amazing, but it's neither a framework nor a library for building web applications. It's more of a superset/transpiler. It makes working with Node/React/Express better, but it doesn't replace them. With regard to Express, it's decent, but e.g. do we really need to torture newcomers by expecting them to know they'll need to also include/install and require body-parser? I mean, why would I be using a web framework, even a micro-one, if I'm expected to bring in a separate tool just for parsing requests? Regarding the suggestion that I like Python more, I would gladly choose TypeScript over Python (the typing tools there are still immature) if there was less churn in the JS ecosystem. Deno is promising. :)
- davorak 6y ago
  > If anything, the entire team seemed to do far more due diligence in decision making than pretty much 90% of the move-fast and break things (TM) SV startups. The author did not convince me that they had above average due diligence. It's common to go through the motions of required processes/procedures like: "create decision criteria, do research, validate findings by creating a proof of concept, present findings, document everything in the decision log" and not generate much value from the process as a result.
  - bitstan 6y ago
    There's so much cargo-cult mentality in react that it's difficult to perform DD and predict the technical landscape years into the future. So perhaps we're in agreement the author should have picked another technology. Personally I think the author's original architecture was most likely satisfactory, but there should've been design guidelines to enforce a single coding style. You don't have to re architect your app because dan abramov tweeted something. If there was no value added in adopting hooks then the architect shouldn't have wasted energy adopting it. And let's be real, there was no value added in adopting hooks lol.
commandlinefan 6y ago
> It's a feature, not a bug I'm not that familiar with React (although I have had the misfortune of working with Angular), but I've seen the horrific Spring "framework" defended that way: it doesn't actually include any functionality because it's designed to be open ended! What it turns out to be is the most useless thing that ever happened to programming: it's pure overhead, undocumented (surprising) behavior, unwanted defaults that you have to spend time working around without the benefit of actually simplifying anything. Not saying React is the same (like I said, haven't really spent much time looking at it), but it's adherents defend it the same way Spring's adherents defend it.
- crooked-v 6y ago
  In React's case, it's meant to pretty much entirely focus on the process of (input data -> output DOM nodes), plus the minimal set of wrapper functionality needed to handle user input and general asynchronous data loading (class-based component state, context loading, and most recently hooks). It intentionally doesn't handle a lot of stuff like dependencies (that's a job for your bundler), the actual data fetching, the actual specifics of your UI, centralized global data management, etc.
lhorie 6y ago
> It's a feature, not a bug. Not understanding this is a red flag that you're going to run into problems. This attitude smells of "you're attacking my way of doing things, therefore you're wrong". While there's truth in both your claims and the GP's, there _is_ churn and there _is_ a ton of garbage in the ecosystem, that much is very true. The nuance is that the distribution is not uniform: lodash has been stable for ages, axios is perfectly fine for HTTP requests, etc. Where it gets sketchy is when you get to the fringes of what a framework is expected to do. But at that point, not even Angular or Ember can save you. As for framework-specific churn, React itself is not the only cog in the equation. As part of my job, I see a lot of React codebases from various periods in time and honestly, yes, there's a lot of churn. Looking only at React's API churn, we have code using hooks, class components, HOCs, render props, heck even React.createClass. And then there's hipster libraries that willy-nilly break APIs to match each new React idiom, libraries that just can't make their minds about what their API looks like, abandoned libraries that uses the old Context API, libraries that depend on componentWillUpdate, libraries that read the shape of the virtual dom node, libraries that depend on those libraries, and on and on goes the rabbit hole. React Router, for example, is both extremely popular and notorious for having given people migration headaches. On top of that, there is of course the self-inflicted pain: redux-saga messes that no one wants to go near, misguided attempts at "functional programming" and other forms of over-engineering, etc. But here's the rub: Angular _has_ idioms for forms. You don't wrangle w/ random breaking changes in react-form there. Angular has a router. No need to worry if your favorite router lib will break APIs when Suspense comes along. Angular has HTTP requesting. No bikeshedding over axios vs isomorphic-fetch or whatever. Angular has state management idioms; no fussing over where async stuff goes in redux (assuming you're not still arguing redux vs mobx). Pluralization? Hope what you picked is maintained. CSP support? Yeah, go google that, I can wait. Etc. You can definitely become a competent React dev and spend many years on good, well maintained projects in React-land, but that doesn't mean there aren't problems directly attributable to the React's limited scope as far as "frameworks" go.
- barbarbar 6y ago
  Very thorough and thoughtful comment this was. Thank you for that.
worik 6y ago
"Does it? I've worked in React, at enterprise levels, for close to 3 years now..." So you are a beginner.
imbnwa 6y ago
> Imo the biggest failure of the author was to jump headfirst into a stack they weren't familiar with it, and then blame it on the stack. >I know it's en vogue to hate npm/react/js "because the ecosystem", but at this point, picking the ecosystem and then blaming it is a self inflicted wound that I don't really have patience for. I work in corporate, you wouldn't believe the infantilism in frontend development, always doing everything but modeling the problem and iterating that model. People are also not good at picking up on cohesive properties of libraries. But this is life in the name of holy velocity.
varrock 6y ago
> Does it? I've worked in React, at enterprise levels, for close to 3 years now. Except for the addition of hooks, there hasn't been a whole lot of churn. React today is still the react of yesteryear, but with extras. I have been using it since you could only track state in class components, and I personally think it looks drastically different with the evolution of hooks. I interpret components differently than before. The patterns for doing most things has changed, such as the inherent deprecation of the higher order component and render props pattern. I'm not implying that it's bad there have been changes (some are absolutely warranted), but rather explaining how I do believe the library looks different than it did before hooks.

_coveredInBees 6y ago

This is again so dismissive of the author. He seems to have a substantial amount of experience with React. He isn't just some noob who jumped on some bandwagon and picked the latest sexiest thing for reasons. If anything, the entire team seemed to do far more due diligence in decision making than pretty much 90% of the move-fast and break things (TM) SV startups. > It's a feature, not a bug. Yes, a small, light-weight framework can be a good thing. No one called it a bug. But like everything in life, there are trade-offs involved. And I'm not entirely convinced that it is a good tradeoff in the crazy JS ecosystem where everything is changing and breaking all the time, especially if you are building more complex things and don't have an army of web-devs to keep the house of cards from falling down.

protonimitate 6y ago
> If anything, the entire team seemed to do far more due diligence in decision making than pretty much 90% of the move-fast and break things (TM) SV startups. Right, but this still isn't the fault of React. My gripe with this article, and view points like this, is that instead of taking ownership it's again the tool that gets blame and just further perpetuates the "js bad" meme. > And I'm not entirely convinced that it is a good tradeoff in the crazy JS ecosystem where everything is changing and breaking all the time, especially if you are building more complex things. Right, and if that's your opinion (and a perfectly valid one!) then don't pick the JS ecosystem and cry when it bites you.
- ralmidani 6y ago
  I agree people should take ownership over their decisions, but it's more nuanced than "don't cry": if someone makes a mistake/bad decision, shouldn't they warn others so they don't do the same? And frankly, let's stop pretending the JS ecosystem is not problematic. Can anyone in good faith argue for a JS project which offers the stability, refinement, and elegance of projects available for Ruby (Rails), Python (Django), Elixir (Phoenix), etc? Even micro-frameworks like Flask, which don't include tons of batteries, are still much more dev-friendly than Node/Express/React/etc.
  - nawgz 6y ago
    >frankly, let's stop pretending the JS ecosystem is not problematic. Can anyone in good faith argue for a Node project React is a node project, so I can do so trivially. React is a top tier library when it comes to key features like stability, documentation, backwards compatibility, and extensibility / usability. I can also say TypeScript is one of the most amazing projects of all time. Last but not least - express is super easy to use. I don't know what "dev-friendly" means, as a criteria though. Keep in mind, though, since it's JS, it's really easy to wrap and extend. To me, you have to justify how Flask is superior to Express; I think you just like Python more.
    - ralmidani 6y ago
      React is stable? React.createElement -> Sub-classing the Component class -> "just use hooks everywhere" in the span of a few years? Sure, Django went from function-based to class-based views, but the change was far less abrupt, and you can still use functional views if you want to. As for TypeScript, I agree it's amazing, but it's neither a framework nor a library for building web applications. It's more of a superset/transpiler. It makes working with Node/React/Express better, but it doesn't replace them. With regard to Express, it's decent, but e.g. do we really need to torture newcomers by expecting them to know they'll need to also include/install and require body-parser? I mean, why would I be using a web framework, even a micro-one, if I'm expected to bring in a separate tool just for parsing requests? Regarding the suggestion that I like Python more, I would gladly choose TypeScript over Python (the typing tools there are still immature) if there was less churn in the JS ecosystem. Deno is promising. :)
davorak 6y ago
> If anything, the entire team seemed to do far more due diligence in decision making than pretty much 90% of the move-fast and break things (TM) SV startups. The author did not convince me that they had above average due diligence. It's common to go through the motions of required processes/procedures like: "create decision criteria, do research, validate findings by creating a proof of concept, present findings, document everything in the decision log" and not generate much value from the process as a result.
- bitstan 6y ago
  There's so much cargo-cult mentality in react that it's difficult to perform DD and predict the technical landscape years into the future. So perhaps we're in agreement the author should have picked another technology. Personally I think the author's original architecture was most likely satisfactory, but there should've been design guidelines to enforce a single coding style. You don't have to re architect your app because dan abramov tweeted something. If there was no value added in adopting hooks then the architect shouldn't have wasted energy adopting it. And let's be real, there was no value added in adopting hooks lol.

commandlinefan 6y ago

> It's a feature, not a bug I'm not that familiar with React (although I have had the misfortune of working with Angular), but I've seen the horrific Spring "framework" defended that way: it doesn't actually include any functionality because it's designed to be open ended! What it turns out to be is the most useless thing that ever happened to programming: it's pure overhead, undocumented (surprising) behavior, unwanted defaults that you have to spend time working around without the benefit of actually simplifying anything. Not saying React is the same (like I said, haven't really spent much time looking at it), but it's adherents defend it the same way Spring's adherents defend it.

crooked-v 6y ago
In React's case, it's meant to pretty much entirely focus on the process of (input data -> output DOM nodes), plus the minimal set of wrapper functionality needed to handle user input and general asynchronous data loading (class-based component state, context loading, and most recently hooks). It intentionally doesn't handle a lot of stuff like dependencies (that's a job for your bundler), the actual data fetching, the actual specifics of your UI, centralized global data management, etc.

lhorie 6y ago

> It's a feature, not a bug. Not understanding this is a red flag that you're going to run into problems. This attitude smells of "you're attacking my way of doing things, therefore you're wrong". While there's truth in both your claims and the GP's, there _is_ churn and there _is_ a ton of garbage in the ecosystem, that much is very true. The nuance is that the distribution is not uniform: lodash has been stable for ages, axios is perfectly fine for HTTP requests, etc. Where it gets sketchy is when you get to the fringes of what a framework is expected to do. But at that point, not even Angular or Ember can save you. As for framework-specific churn, React itself is not the only cog in the equation. As part of my job, I see a lot of React codebases from various periods in time and honestly, yes, there's a lot of churn. Looking only at React's API churn, we have code using hooks, class components, HOCs, render props, heck even React.createClass. And then there's hipster libraries that willy-nilly break APIs to match each new React idiom, libraries that just can't make their minds about what their API looks like, abandoned libraries that uses the old Context API, libraries that depend on componentWillUpdate, libraries that read the shape of the virtual dom node, libraries that depend on those libraries, and on and on goes the rabbit hole. React Router, for example, is both extremely popular and notorious for having given people migration headaches. On top of that, there is of course the self-inflicted pain: redux-saga messes that no one wants to go near, misguided attempts at "functional programming" and other forms of over-engineering, etc. But here's the rub: Angular _has_ idioms for forms. You don't wrangle w/ random breaking changes in react-form there. Angular has a router. No need to worry if your favorite router lib will break APIs when Suspense comes along. Angular has HTTP requesting. No bikeshedding over axios vs isomorphic-fetch or whatever. Angular has state management idioms; no fussing over where async stuff goes in redux (assuming you're not still arguing redux vs mobx). Pluralization? Hope what you picked is maintained. CSP support? Yeah, go google that, I can wait. Etc. You can definitely become a competent React dev and spend many years on good, well maintained projects in React-land, but that doesn't mean there aren't problems directly attributable to the React's limited scope as far as "frameworks" go.

barbarbar 6y ago
Very thorough and thoughtful comment this was. Thank you for that.

worik 6y ago

"Does it? I've worked in React, at enterprise levels, for close to 3 years now..." So you are a beginner.

imbnwa 6y ago

> Imo the biggest failure of the author was to jump headfirst into a stack they weren't familiar with it, and then blame it on the stack. >I know it's en vogue to hate npm/react/js "because the ecosystem", but at this point, picking the ecosystem and then blaming it is a self inflicted wound that I don't really have patience for. I work in corporate, you wouldn't believe the infantilism in frontend development, always doing everything but modeling the problem and iterating that model. People are also not good at picking up on cohesive properties of libraries. But this is life in the name of holy velocity.

varrock 6y ago

> Does it? I've worked in React, at enterprise levels, for close to 3 years now. Except for the addition of hooks, there hasn't been a whole lot of churn. React today is still the react of yesteryear, but with extras. I have been using it since you could only track state in class components, and I personally think it looks drastically different with the evolution of hooks. I interpret components differently than before. The patterns for doing most things has changed, such as the inherent deprecation of the higher order component and render props pattern. I'm not implying that it's bad there have been changes (some are absolutely warranted), but rather explaining how I do believe the library looks different than it did before hooks.