6 ms·

I read the comments here first before reading the blog post, and I was expecting a very different type of (and lacking) blog post based on the combination of di

I read the comments here first before reading the blog post, and I was expecting a very different type of (and lacking) blog post based on the combination of dismissive and defensive attitude permeating a lot of the comments here. To be honest, there isn't a lot the author is wrong about. Sure, having a .NET team adapting to React is harder but nothing seemed egregious in the way they tackled things. 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. Granted, a lot of that criticism holds true for the entire JS scene where the churn is simply ridiculous and you have to cross all your appendages and hope for the best before you try to build a year old project. But React is especially problematic in that regard only because there are so few batteries included (which is great for small/mid sized projects, but the opposite if you are looking for stability). Ultimately though, I just shudder to think about writing large, complex, enterprise Apps in the latest and greatest JS/front-end frameworks due to the crazy levels of churn in frameworks, libraries and APIs. React now looks completely different from React from 1-2 years ago. Libraries fall in and out of favor. Some keep up with the ever changing API of the parent frameworks, others die off. It's like an entire ecosystem that has ADHD and as someone who has built several small to mid-size React and React + Electron apps in the past, that ultimately turned me off the entire endeavor (I'm an ML Engineer, but I love software engineering and building stuff for fun). I would much rather take "boring", stable languages and frameworks and spend my time honing skills that actually matter and help me as a software engineer throughout my career, rather than spend a week trying to get webpack figured out, till the next big webpack update when I'd start over from scratch again.

interlocutor 6y ago
> I would much rather take "boring", stable languages and frameworks I would argue that you don't need a heavy framework to make maintainable JavaScript application. For large enterprise applications that must last a decade or more you want to use standards (such as Web Components) implemented by the web browser itself instead of third-party libs such as React.
- nicoburns 6y ago
  I suspect React has a much greater chance of being around in 10 years time than web components. Simply because there are a lot more people using React than web components. React is a boring, stable framework at this point.
  - flowerlad 6y ago
    > Simply because there are a lot more people using React than web components. Couldn't you have said that about React vs Angular 5 years ago? > React is a boring, stable framework at this point. And that's why it won't be the most popular framework in 10 years time. React started off as a simple and straightforward library. The React team didn't want to stand still, so they improved it. The "improvements" are making React big, fat, bloated and complex, and failures and perf issues harder to debug
    - nicoburns 6y ago
      1. 5 years ago no: React was already the #1 JS frontend framework at that point. In terms of mindshare if not project volume. 2. I think the key difference is that Angular was a nightmare to work with, especially on larger projects. Whereas React is fairly simple, and tends to be easily maintainable over time. > React started off as a simple and straightforward library. It still is. The implementation is kinda complex at this point, but the API is still super simple.
      - flowerlad 6y ago
        > In terms of mindshare if not project volume. Regardless, you missed the point. Which was that, frameworks come and go. The DOM and other APIs implemented by the browser, on the other hand, are here to stay. Very few things built into the browser have been taken away (such as blink and frameset). > The implementation is kinda complex at this point Right. And that makes failures and perf issues hard to track down. If you know how to program using APIs and components built into the browser, that is easier at this point.
protonimitate 6y ago
> 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.
cratermoon 6y ago
You probably don't want to know about MEAN (https://en.wikipedia.org/wiki/MEAN_(solution_stack) https://en.wikipedia.org/wiki/MEAN_(solution_stack)) then.
arcticfox 6y ago
> React now looks completely different from React from 1-2 years ago. Libraries fall in and out of favor. Is that true? Can you give me an example of what you're thinking of? I've used React since pretty much the beginning and the only "completely different" looks I can recall is class-based components -> functional components + hooks. And even that evolution was pretty comfortable and backwards-compatible.
- _coveredInBees 6y ago
  I think the large things in my admittedly limited experience were hooks and context API. Which in a sense isn't a massive change, but the problem is that just like the author of this article mentions, now there are more ways for things to be done, and moreover, because React is a small framework itself, all your 20+ dependency libs have probably moved on and implemented everything with hooks. So now you pretty much need to learn hooks, the context API and throw out your prior domain knowledge from 2018 because whether you like it or not, you gotta still adapt to hooks, because that is the new thing now and the libraries you rely on are now using the new API and approach. If I was a full-time web-developer, I'd maybe be willing to live with the churn of the JS ecosystem, but as someone who enjoys software engineering and building fun projects, the churn is simply exhausting and a big turn-off. I spent a year doing a lot of intensive React + Electron + D3 + MobX and all the associated stuff (webpack, npm, node, etc) in 2018, and then at some point I realized its like being on a hamster wheel and you gotta keep going frantically just to stay up to date with the newest libs and toys and APIs and current group think. Meanwhile, a year spent just writing and learning good software in Python (for example), gains me so much more transferable skills to anything I touch as a software engineer in the future. I still like the power of being able to make user-interfaces easily and there are plenty of things I enjoyed about developing web/electron-apps, but ultimately I was just turned off by how much continuing investment of your time it requires just to stay relevant in the field without imho adding any real value to actual software engineering skills.
  - nawgz 6y ago
    >I spent a yea rdoing a lot of intensive React + Electron + D3 + MobX in 2018 Right, and that code still runs and compiles exactly as it did then, correct? The fact that other tools move on doesn't mean you have to. Actually, out of what you just said, D3, MobX, and React all have not removed any of the APIs you could've used back in 2018. Did people maybe rewrite some tools to support hooks, and in doing so find that hooks were a more concise and readable solution? Yeah, they did, so we moved to hooks. > a year spent just writing and learning good software in Python gains me so much more transferable skills to anything I touch as a software engineer in the future How so? This is a complete non-sequitur. If you consider data science / ML to be the entirety of software engineering, then maybe you have a point, but since you even put (for example) beside Python it just looks to me like you hate JS and will pretend it's not software engineering so you can avoid it. Any time you've spent tweaking build systems or updating libraries for no reason is on you, not on JS.
nawgz 6y ago
As a React dev for half a decade, I strongly disagree with many of your points. > React [includes] so little that you become reliant on a ton of external dependencies React, since hooks, includes a full state management solution - Context, Provider, and hooks. Second, even if you want an actual state management library, both mobx and Redux are quite stable. Applications I have built in 2016 are still running and building with no pain points today, except maybe that the tooling is way better now. Third, all this noise about "the JS scene has so much churn" is kind of crazy. I don't know what kind of library evaluation techniques everyone else has, but React is backwards compatible with techniques they've been saying they'll deprecate for years, version pinning works perfectly fine, and with TypeScript there's less and less churn and mystery than ever before. > Ultimately though, I just shudder to think about writing large, complex enterprise Apps in the latest and greatest This is a comical take. Facebook is powered by React. Large, complex, enterprise, and fully powered by the cutting edge of JS frameworks. > React now looks completely different from React 1-2 years ago But still fully supports the previous way of working, meaning not only has none of your knowledge been invalidated, but you have additional tools at your disposal. > Libraries fall in and out of favor react-router-dom has been my goto for quite some time, as has mobx. Again, you can version pin and stick with any solution as long as you want to - my things powered by react-router 3 are fine still. > I would much rather take "boring", stable languages and frameworks > I'm an ML Engineer Is it not true the entire ML ecosystem has been reinvented in the last 5 years? My React code still builds & runs from 2016. I really feel like this is a case of "external person overestimates complexity in external domain, underestimates complexity in internal domain" because everything you're saying sounds like you dipped your toes, and didn't actually build applications. Final thoughts: you don't need to update Webpack to resume building your old project. Your build scripts work just fine. Better yet, don't eject from Create-React-App or some other build provider and you never even need to think about this stuff. React is boring and stable, speaking as someone who has used it for half a decade and sees no reason why that won't just become a full decade.
- _coveredInBees 6y ago
  > React, since hooks, includes a full state management solution - Context, Provider, and hooks. Sure, but that hasn't been around even 2 years. Prior to that, there was a different approach and philosophy to doing things. I remember when higher order components were all the rage till suddenly they weren't. I'm not advocating for stagnation, but at the same time, everything in JS land feels experimental, even in established frameworks, and the entire community keeps marching along as things keep changing. Which if you are a full-time developer doing that, is fine I guess, but it is not the norm compared to pretty much any other software engineering field. > Second, even if you want an actual state management library, both mobx and Redux are quite stable I cannot say enough nice things about MobX (although I was using it back when it didn't use Proxies so you had to deal with a lot of cloning back to native JS objects which got a bit ugly at times), and I don't disagree with you on this point for state management, although I personally could not stand redux despite 90% of the community vehemently singing its praise. > This is a comical take. Facebook is powered by React. Large, complex, enterprise, and fully powered by the cutting edge of JS frameworks. I should have perhaps qualified that better. Yes, I know there are people writing complex apps, but I was viewing it from the POV of a non FAANG type place with tons of engineers to throw at a problem. If I was a single person or a very small team trying to develop something complex, I would place a much higher emphasis on a more stable development environment/language/framework. > Is it not true the entire ML ecosystem has been reinvented in the last 5 years? My React code still builds & runs from 2016. I really feel like this is a case of "external person overestimates complexity in external domain, underestimates complexity in internal domain" because everything you're saying sounds like you dipped your toes, and didn't actually build applications. Let's take Pytorch as a comparison framework. It's had tons of releases, but at a fundamental level, the core API has stayed the same. I've ported 3 year old code to the latest version with pretty much negligible effort. And at its heart, it is because APIs are kept very stable and people aren't deciding each year that they need an entirely new way of doing ML or performing automatic gradient estimations, etc. Similarly with Python... there have been a bunch of Python 3 releases in the past few years but they each add new things that are useful without making big changes that suddenly change how everyone would tackle building a new piece of software. On the other hand, porting a 2+ year old React app to the latest version of React (along with bringing dependencies along) would be a very painful process. I know this, because we've done this at the company I work at. There is also this implicit assumption in JS/React land that you are going to come marching along with all the latest changes. Heck, less than 2 years back, their documentation site wouldn't even let you view older versions of React documentation, so the moment they released a new version of React, the docs would only ever show you the new docs. What's funny, is that today they supposedly have links to their older docs...but every fucking link is broken :-/ example: https://reactjs.org/version/16.8 https://reactjs.org/version/16.8 And nobody probably even knows that, because there is a general expectation in the field that everyone just keeps staying up to date with the latest and greatest and deals with whatever pain points come along with that and no one has probably even tried to access older documentations or raise issues about it. Which is fine, like I've said many times before if you've made your peace with it and that is your full-time job, but it is not the expectation or norm in most other fields. Finally, I should state for the record (because you stated otherwise in another reply to me), that I actually love javascript...well at least ES6+ JS. I greatly enjoy(ed) JS, JSX, developing in VsCode, and even building things with React, Mobx, etc. I'm not a software engineering snob who looks down on JS and the ecosystem. But I also have a more diverse viewpoint because I work at a small company and get to wear many hats and have been able to do lots of different things (ML Engineer, Front-end work, write and deploy pretty complex software, etc.). And while I have a lot of fun doing front-end stuff, It still feels like there is a lot of constant overhead to it, and that is pretty unique to this one field compared to most everything else.
unphased 6y ago
To pile onto your point, webpack is clearly on its way out, it's all about snowpack now (afaik). I never got a chance to get into learning webpack, and I'm glad now. Throws hands up
- postalrat 6y ago
  Just recently I had to switch a project from snowpack to webpack because adding the features I needed to snowpack added up to too much additional work. Like parcel snowpack works great when you can use it. Hoping it catches on because I really loved how fast it was.
firebaze 6y ago
This is the most upvoted controversial, and in my eyes, trolling post i ever saw on HN. I'd at least expect a look-forward element, like "use Svelte" or whatever. But a simple and pure (and from my point of view totally wrong) flame just against React without mentioning any of the competing frameworks feels simply awkward. One could substitute React with almost anything js-related, and the post would still incite flame.
- mmmeff 6y ago
  I prefer the criticism raw and plain. No need to muddy the waters with a biased recommendation. The author’s criticism stands on its own.
  - firebaze 6y ago
    Fair enough. The js ecosystem has quite some room for improvement, this is what I definitely agree on.
- worik 6y ago
  Most criticism I see here is of the JS frame works generally, rather than React in particular. I, for one, am glad to see the push back against the mad craziness that has dominated the Node.js/Framework word. It is easier to speak than listen, easier to write than read, and easier to build than test... Hence Node.js, and JS Frameworks. I do love programming in Javascript, have not done it for a while, as I cannot abide the ignorance and arrogance that goes with the ecosystem. I love plain old vanilla JS....

interlocutor 6y ago

> I would much rather take "boring", stable languages and frameworks I would argue that you don't need a heavy framework to make maintainable JavaScript application. For large enterprise applications that must last a decade or more you want to use standards (such as Web Components) implemented by the web browser itself instead of third-party libs such as React.

nicoburns 6y ago
I suspect React has a much greater chance of being around in 10 years time than web components. Simply because there are a lot more people using React than web components. React is a boring, stable framework at this point.
- flowerlad 6y ago
  > Simply because there are a lot more people using React than web components. Couldn't you have said that about React vs Angular 5 years ago? > React is a boring, stable framework at this point. And that's why it won't be the most popular framework in 10 years time. React started off as a simple and straightforward library. The React team didn't want to stand still, so they improved it. The "improvements" are making React big, fat, bloated and complex, and failures and perf issues harder to debug
  - nicoburns 6y ago
    1. 5 years ago no: React was already the #1 JS frontend framework at that point. In terms of mindshare if not project volume. 2. I think the key difference is that Angular was a nightmare to work with, especially on larger projects. Whereas React is fairly simple, and tends to be easily maintainable over time. > React started off as a simple and straightforward library. It still is. The implementation is kinda complex at this point, but the API is still super simple.
    - flowerlad 6y ago
      > In terms of mindshare if not project volume. Regardless, you missed the point. Which was that, frameworks come and go. The DOM and other APIs implemented by the browser, on the other hand, are here to stay. Very few things built into the browser have been taken away (such as blink and frameset). > The implementation is kinda complex at this point Right. And that makes failures and perf issues hard to track down. If you know how to program using APIs and components built into the browser, that is easier at this point.

protonimitate 6y ago

> 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.

cratermoon 6y ago

You probably don't want to know about MEAN (https://en.wikipedia.org/wiki/MEAN_(solution_stack) https://en.wikipedia.org/wiki/MEAN_(solution_stack)) then.

arcticfox 6y ago

> React now looks completely different from React from 1-2 years ago. Libraries fall in and out of favor. Is that true? Can you give me an example of what you're thinking of? I've used React since pretty much the beginning and the only "completely different" looks I can recall is class-based components -> functional components + hooks. And even that evolution was pretty comfortable and backwards-compatible.

_coveredInBees 6y ago
I think the large things in my admittedly limited experience were hooks and context API. Which in a sense isn't a massive change, but the problem is that just like the author of this article mentions, now there are more ways for things to be done, and moreover, because React is a small framework itself, all your 20+ dependency libs have probably moved on and implemented everything with hooks. So now you pretty much need to learn hooks, the context API and throw out your prior domain knowledge from 2018 because whether you like it or not, you gotta still adapt to hooks, because that is the new thing now and the libraries you rely on are now using the new API and approach. If I was a full-time web-developer, I'd maybe be willing to live with the churn of the JS ecosystem, but as someone who enjoys software engineering and building fun projects, the churn is simply exhausting and a big turn-off. I spent a year doing a lot of intensive React + Electron + D3 + MobX and all the associated stuff (webpack, npm, node, etc) in 2018, and then at some point I realized its like being on a hamster wheel and you gotta keep going frantically just to stay up to date with the newest libs and toys and APIs and current group think. Meanwhile, a year spent just writing and learning good software in Python (for example), gains me so much more transferable skills to anything I touch as a software engineer in the future. I still like the power of being able to make user-interfaces easily and there are plenty of things I enjoyed about developing web/electron-apps, but ultimately I was just turned off by how much continuing investment of your time it requires just to stay relevant in the field without imho adding any real value to actual software engineering skills.
- nawgz 6y ago
  >I spent a yea rdoing a lot of intensive React + Electron + D3 + MobX in 2018 Right, and that code still runs and compiles exactly as it did then, correct? The fact that other tools move on doesn't mean you have to. Actually, out of what you just said, D3, MobX, and React all have not removed any of the APIs you could've used back in 2018. Did people maybe rewrite some tools to support hooks, and in doing so find that hooks were a more concise and readable solution? Yeah, they did, so we moved to hooks. > a year spent just writing and learning good software in Python gains me so much more transferable skills to anything I touch as a software engineer in the future How so? This is a complete non-sequitur. If you consider data science / ML to be the entirety of software engineering, then maybe you have a point, but since you even put (for example) beside Python it just looks to me like you hate JS and will pretend it's not software engineering so you can avoid it. Any time you've spent tweaking build systems or updating libraries for no reason is on you, not on JS.

nawgz 6y ago

As a React dev for half a decade, I strongly disagree with many of your points. > React [includes] so little that you become reliant on a ton of external dependencies React, since hooks, includes a full state management solution - Context, Provider, and hooks. Second, even if you want an actual state management library, both mobx and Redux are quite stable. Applications I have built in 2016 are still running and building with no pain points today, except maybe that the tooling is way better now. Third, all this noise about "the JS scene has so much churn" is kind of crazy. I don't know what kind of library evaluation techniques everyone else has, but React is backwards compatible with techniques they've been saying they'll deprecate for years, version pinning works perfectly fine, and with TypeScript there's less and less churn and mystery than ever before. > Ultimately though, I just shudder to think about writing large, complex enterprise Apps in the latest and greatest This is a comical take. Facebook is powered by React. Large, complex, enterprise, and fully powered by the cutting edge of JS frameworks. > React now looks completely different from React 1-2 years ago But still fully supports the previous way of working, meaning not only has none of your knowledge been invalidated, but you have additional tools at your disposal. > Libraries fall in and out of favor react-router-dom has been my goto for quite some time, as has mobx. Again, you can version pin and stick with any solution as long as you want to - my things powered by react-router 3 are fine still. > I would much rather take "boring", stable languages and frameworks > I'm an ML Engineer Is it not true the entire ML ecosystem has been reinvented in the last 5 years? My React code still builds & runs from 2016. I really feel like this is a case of "external person overestimates complexity in external domain, underestimates complexity in internal domain" because everything you're saying sounds like you dipped your toes, and didn't actually build applications. Final thoughts: you don't need to update Webpack to resume building your old project. Your build scripts work just fine. Better yet, don't eject from Create-React-App or some other build provider and you never even need to think about this stuff. React is boring and stable, speaking as someone who has used it for half a decade and sees no reason why that won't just become a full decade.

_coveredInBees 6y ago
> React, since hooks, includes a full state management solution - Context, Provider, and hooks. Sure, but that hasn't been around even 2 years. Prior to that, there was a different approach and philosophy to doing things. I remember when higher order components were all the rage till suddenly they weren't. I'm not advocating for stagnation, but at the same time, everything in JS land feels experimental, even in established frameworks, and the entire community keeps marching along as things keep changing. Which if you are a full-time developer doing that, is fine I guess, but it is not the norm compared to pretty much any other software engineering field. > Second, even if you want an actual state management library, both mobx and Redux are quite stable I cannot say enough nice things about MobX (although I was using it back when it didn't use Proxies so you had to deal with a lot of cloning back to native JS objects which got a bit ugly at times), and I don't disagree with you on this point for state management, although I personally could not stand redux despite 90% of the community vehemently singing its praise. > This is a comical take. Facebook is powered by React. Large, complex, enterprise, and fully powered by the cutting edge of JS frameworks. I should have perhaps qualified that better. Yes, I know there are people writing complex apps, but I was viewing it from the POV of a non FAANG type place with tons of engineers to throw at a problem. If I was a single person or a very small team trying to develop something complex, I would place a much higher emphasis on a more stable development environment/language/framework. > Is it not true the entire ML ecosystem has been reinvented in the last 5 years? My React code still builds & runs from 2016. I really feel like this is a case of "external person overestimates complexity in external domain, underestimates complexity in internal domain" because everything you're saying sounds like you dipped your toes, and didn't actually build applications. Let's take Pytorch as a comparison framework. It's had tons of releases, but at a fundamental level, the core API has stayed the same. I've ported 3 year old code to the latest version with pretty much negligible effort. And at its heart, it is because APIs are kept very stable and people aren't deciding each year that they need an entirely new way of doing ML or performing automatic gradient estimations, etc. Similarly with Python... there have been a bunch of Python 3 releases in the past few years but they each add new things that are useful without making big changes that suddenly change how everyone would tackle building a new piece of software. On the other hand, porting a 2+ year old React app to the latest version of React (along with bringing dependencies along) would be a very painful process. I know this, because we've done this at the company I work at. There is also this implicit assumption in JS/React land that you are going to come marching along with all the latest changes. Heck, less than 2 years back, their documentation site wouldn't even let you view older versions of React documentation, so the moment they released a new version of React, the docs would only ever show you the new docs. What's funny, is that today they supposedly have links to their older docs...but every fucking link is broken :-/ example: https://reactjs.org/version/16.8 https://reactjs.org/version/16.8 And nobody probably even knows that, because there is a general expectation in the field that everyone just keeps staying up to date with the latest and greatest and deals with whatever pain points come along with that and no one has probably even tried to access older documentations or raise issues about it. Which is fine, like I've said many times before if you've made your peace with it and that is your full-time job, but it is not the expectation or norm in most other fields. Finally, I should state for the record (because you stated otherwise in another reply to me), that I actually love javascript...well at least ES6+ JS. I greatly enjoy(ed) JS, JSX, developing in VsCode, and even building things with React, Mobx, etc. I'm not a software engineering snob who looks down on JS and the ecosystem. But I also have a more diverse viewpoint because I work at a small company and get to wear many hats and have been able to do lots of different things (ML Engineer, Front-end work, write and deploy pretty complex software, etc.). And while I have a lot of fun doing front-end stuff, It still feels like there is a lot of constant overhead to it, and that is pretty unique to this one field compared to most everything else.

unphased 6y ago

To pile onto your point, webpack is clearly on its way out, it's all about snowpack now (afaik). I never got a chance to get into learning webpack, and I'm glad now. Throws hands up

postalrat 6y ago
Just recently I had to switch a project from snowpack to webpack because adding the features I needed to snowpack added up to too much additional work. Like parcel snowpack works great when you can use it. Hoping it catches on because I really loved how fast it was.

firebaze 6y ago

This is the most upvoted controversial, and in my eyes, trolling post i ever saw on HN. I'd at least expect a look-forward element, like "use Svelte" or whatever. But a simple and pure (and from my point of view totally wrong) flame just against React without mentioning any of the competing frameworks feels simply awkward. One could substitute React with almost anything js-related, and the post would still incite flame.

mmmeff 6y ago
I prefer the criticism raw and plain. No need to muddy the waters with a biased recommendation. The author’s criticism stands on its own.
- firebaze 6y ago
  Fair enough. The js ecosystem has quite some room for improvement, this is what I definitely agree on.
worik 6y ago
Most criticism I see here is of the JS frame works generally, rather than React in particular. I, for one, am glad to see the push back against the mad craziness that has dominated the Node.js/Framework word. It is easier to speak than listen, easier to write than read, and easier to build than test... Hence Node.js, and JS Frameworks. I do love programming in Javascript, have not done it for a while, as I cannot abide the ignorance and arrogance that goes with the ecosystem. I love plain old vanilla JS....