MDX is another neat step, it's markdown + react components and fits in very well with next.js: https://github.com/hashicorp/next-mdx-remote
Vue, and Svelte to just get an idea of what other components systems are like. They're all equally capable and just have different tradeoffs and styles. Keep an eye on Svelte in particular as its next.js-like system (SvelteKit) is working on a major revamp to be serverless-first and is quite interesting. Once you learn one component system it's easy to switch between them all--they're all cribbing and building on top of each other's ideas. The whole space is innovating in a great way.
Web components are good to learn and compare to component frameworks above. It's still a changing space but points to a nice future where we can all just publish and share components.
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%.
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.
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.
Suggesting more bleeding edge tech is not a good argument to demonstrate that front end development got better.
In my experience, it changed, it improved on many aspects, but it's still a pile of unstable crap running on the power of hype and over-enthusiastic junior engineers.
My point is that there has been a lot of evolution and improvement, but developer sanity is one of the few things that have just gone worse.
It is dishonest to look only at the bright side of modern frontend coding and forgetting the node_modules nightmare, the incredibly obtuse language, the slow compilation times, the myriad of CSS frameworks that are invented because CSS is an absolute pain in the arse for modern design, etc., the fact that every JS tool either is core to the whole circus and is maintained by a stressed out, underpaid person in the middle of nowhere, or has a minimum of 5k Github issues and a major version released every 3 months, and every time you get a problem you're told "haven't you tried the new alpha release of the big rewrite we've just started?".
It is absolute madness, not just frustrating. But yeah, React is cool.
It's amazing what browsers can do these days without any build step!
[0]: https://starboard.gg