6 ms·

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

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. :)
      - nawgz 6y ago
        >React is stable? Yes. Despite what you're trying to imply about them "updating" too often, my code from 2016 still works correctly against the newest versions of React. That's pretty much the definition of stability to me. > the change was far less abrupt, and you can still use functional views if you want to So you are hating on React because you don't know this, but this exact optional progression has always been how they have introduced new features into React. Again - old code works with new React versions. > do we really need to ... expect them to know True, this is a weakness, but the documentation is pretty explicit on this front. It's not like there isn't a big community around the library to address this. Anyhow, I respect your points here, and concede that writing server-side code in Node is probably not what you want to do; I reach for tools like Hasura in this case regardless. With low-code backend tooling and React, I can promise you I can make a better website than with just Python no matter how much Django template wizardry one can muster.
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.

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. :)
    - nawgz 6y ago
      >React is stable? Yes. Despite what you're trying to imply about them "updating" too often, my code from 2016 still works correctly against the newest versions of React. That's pretty much the definition of stability to me. > the change was far less abrupt, and you can still use functional views if you want to So you are hating on React because you don't know this, but this exact optional progression has always been how they have introduced new features into React. Again - old code works with new React versions. > do we really need to ... expect them to know True, this is a weakness, but the documentation is pretty explicit on this front. It's not like there isn't a big community around the library to address this. Anyhow, I respect your points here, and concede that writing server-side code in Node is probably not what you want to do; I reach for tools like Hasura in this case regardless. With low-code backend tooling and React, I can promise you I can make a better website than with just Python no matter how much Django template wizardry one can muster.

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.