3 ms·

Yet none of the stuff you mention here will live beyond the next two years. Fun is as much as i would describe the js ecosystem, for more boring corporate use b

Yet none of the stuff you mention here will live beyond the next two years. Fun is as much as i would describe the js ecosystem, for more boring corporate use banking on these is the equivalent of getting a trojan horse in the application portfolio.

johnfn 6y ago
React won't live past two years? What? I'd be willing to stake money on React, Vue, next.js and Svelte surviving at least 2 more years - roughly in descending order of probability, though all three well above 50%.
asattarmd 6y ago
React was released in 2013, that’s 8 years.
- Chris_Newton 6y ago
  While that’s true, code using React in 2021 often bears little resemblance to code using React in 2013, and the ecosystem around it looks very different too. It’s easy to forget that hooks were only introduced in React 16.8, which was released just over two years ago. And yet today, if you visit popular forums for React devs like /r/reactjs, you’ll find no shortage of people who will tell you that class-based components are ancient history and anyone who isn’t using hooks for everything today is a dinosaur. This year, I’ve noticed a spate of online discussions about state management within the React ecosystem. Just like the hooks vs. classes debate of yesteryear, there is a striking contrast between those forever keen to do the new thing (sometimes using React’s own context and hooks, sometimes using relatively new libraries) and those who prefer to rely on more tried-and-tested tech like Redux and MobX. In any situation like this, it’s sensible to question how much real progress is being made, and how much of the change is just lost productivity due to churn in tools and “best practices”. If so many developers think it’s normal to swap out most of your tools and coding style every couple of years or less, you have to wonder how long they expect anything they ever build to be maintained for or how often they think longer-lived software should have big rewrites just to update the tools… In contrast, esbuild is shaping up to be an excellent tool. There seems to be a healthy focus on doing one common and important job well, it’s much better at it than the popular tools it potentially replaces, and it also seems designed to play nicely with others. It reminds me of the early days of 6to5/Babel, actually. This is what we need more of in the front-end web dev community right now.
qbasic_forever 6y ago
And I personally can't wait to see what amazing things the creators of these component systems will land on next... Next.js is pretty corporate-friendly. Very easy to split things up and have many folks and teams working on monoliths or services with it.
wishinghand 6y ago
That’s such an unqualified statement that I’d be embarrassed to say it out loud. Angular 1 apps are still in production. COBOL is still in production. I’d bet $100 that two years from this date, all three of those are still popular, being used by enterprise, and have tutorials written for them on blogs or produced on YouTube.

johnfn 6y ago

React won't live past two years? What? I'd be willing to stake money on React, Vue, next.js and Svelte surviving at least 2 more years - roughly in descending order of probability, though all three well above 50%.

asattarmd 6y ago

React was released in 2013, that’s 8 years.

Chris_Newton 6y ago
While that’s true, code using React in 2021 often bears little resemblance to code using React in 2013, and the ecosystem around it looks very different too. It’s easy to forget that hooks were only introduced in React 16.8, which was released just over two years ago. And yet today, if you visit popular forums for React devs like /r/reactjs, you’ll find no shortage of people who will tell you that class-based components are ancient history and anyone who isn’t using hooks for everything today is a dinosaur. This year, I’ve noticed a spate of online discussions about state management within the React ecosystem. Just like the hooks vs. classes debate of yesteryear, there is a striking contrast between those forever keen to do the new thing (sometimes using React’s own context and hooks, sometimes using relatively new libraries) and those who prefer to rely on more tried-and-tested tech like Redux and MobX. In any situation like this, it’s sensible to question how much real progress is being made, and how much of the change is just lost productivity due to churn in tools and “best practices”. If so many developers think it’s normal to swap out most of your tools and coding style every couple of years or less, you have to wonder how long they expect anything they ever build to be maintained for or how often they think longer-lived software should have big rewrites just to update the tools… In contrast, esbuild is shaping up to be an excellent tool. There seems to be a healthy focus on doing one common and important job well, it’s much better at it than the popular tools it potentially replaces, and it also seems designed to play nicely with others. It reminds me of the early days of 6to5/Babel, actually. This is what we need more of in the front-end web dev community right now.

qbasic_forever 6y ago

And I personally can't wait to see what amazing things the creators of these component systems will land on next... Next.js is pretty corporate-friendly. Very easy to split things up and have many folks and teams working on monoliths or services with it.

wishinghand 6y ago

That’s such an unqualified statement that I’d be embarrassed to say it out loud. Angular 1 apps are still in production. COBOL is still in production. I’d bet $100 that two years from this date, all three of those are still popular, being used by enterprise, and have tutorials written for them on blogs or produced on YouTube.