The ground is shaky in the web development realm. The React ecosystem is turbulent, currently dominant paradigms are being questioned and old ones, revisited. Overall, developers just don't seem to be happy with the state of things.
I'm one of them. React is pretty much all I've ever known to a deeper extent in web development. Though I grew to appreciate it over time, I've been concerned about React lately. It's changed. Now it is best used within frameworks, supposedly. There's Next.js, Remix, Gatsby... Just what we all needed: more tools on top of tools on top of tools. Each with its own sets of standards.
Web development has become too complex over the years. There aren't just a dozen different libraries, there are frameworks and meta-frameworks to each of these. We've abstracted so far from God the browser and the DOM that switching from one library, framework or meta-framework to another can be a hassle; that being actually good at any of these requires so much time that there's little time left to explore others. So much so that "React developer" (not front-end or web developer) has become a thing. Now, I have to fear for a future where there are Next.js developers, Remix developers, Gatsby developers and more.
Mark Erikson addressed the increasing complexity complaint on his response to Matteo Frana's post "React, where are you going?" by claiming that you can still use React whichever way you like. This is true for small personal projects, but not so much for others. The expectations and trends set by the React team matter, as Frana himself rebutted:
I can assure you that many potential customers, especially digital agencies, have expressed that they would not even consider using our React Bricks library if they couldn't use it with the Next App folder. So, the FOMO pressure is high.
It's not a coincidence, I don't think, that HTMX gained so much traction in 2023. It offers us a glimpse of a simpler past and what could (if only maybe) be a simpler, more hypermedia-driven future for the web. Do we really need all these complicated libraries and frameworks to handle DOM manipulations on fat clients? If this question didn't resonate with developers, having only heard about HTMX from others I myself would probably have never found out about it. But here we are.
It's no surprise web developers aren't happy. Instead of making things simpler, the largest part of the established ecosystem is further escalating the complexity, as React morphs into a framework dependency, throwing web developers a curveball. For one, if I just need to put a nail on a wall, I'd rather do it with a hammer than a battering ram. More than ever, I'm considering other approaches to web development and I sure hope others are too.
Top comments (64)
Yeah, to be clear, I totally sympathize with the "keeping up with expectations" aspect. We've had our own issues trying to deal with problems that the App Router have caused for Redux Toolkit and React-Redux , so I'm pretty familiar with that aspect. My point was that existing usage patterns are not being removed. Yes, there's the new shiny, but that does not automatically make an existing app obsolete or prevent you from even starting a new app that is a pure SPA with a Webpack config.
Thanks for your reply, Mark! I see your point, these changes indeed don't deprecate existing patterns. It's just a bore that now we're expected to be skilled at and support various different frameworks in order to work with React.
Keep in mind that Redux was made when only class components existed. Its purpose was to separate business logic from rendering. Classical OOP makes that difficult to do, hence the need for Redux. With the advent of hooks, Redux is no longer necessary for separating business logic from rendering. Custom hooks neatly encapsulate business logic that can be reused in any component.
Some of the trendy frameworks are trying to do too much, and in doing so break the cardinal rule of separation of concerns. Client side logic should not be in the back end, and back end logic should not be in the front end. Every new generation of frameworks seems to believe they can ignore that, to their own demise.
APIs are the key to separation of concerns. Write a solid API and consume it in the client. Go back to the basics, use React directly in the client, and your code will regain sanity. While there are rare cases where SSR is needed, it shouldn't be used as a cudgel in the entire app.
NextJS has demised? This is news to me.
SSR is essential when building apps that need good SEO. The longer a page takes to draw the first content on the screen, the lower your SEO score will be.
An app doesn't need SEO. The company landing page should cover the necessary search terms, and if that isn't enough, the login page can be made static with necessary keywords. A search engine can't crawl authenticated pages anyway so that's a moot point.
If you're building a company landing page with NextJS, you're doing it wrong. There are better tools to create those.
I'm not singling out NextJS specifically. It's one of many trendy frameworkds that bit off more than it can chew. NextJS has a big installed base but the more people use it, the more obvious its shortcomings. It will be around for a while simply due to legacy numbers, but momentum is not on its side.
there's a lot more than the company landing page that needs SEO =P typically you want good SEO for each product page as well, product categories, special pages for black firday sale for example and thats just talking about retail apps, there are plenty of other uses-cases where SEO is necessity...
As for your predictions on NextJS and other NextJS style frameworks, i'll have to take your word for it... I'm seeing something completely different from where I'm sitting. Vercel is getting a lot of traction right now because they jumped on the AI train pretty early and they have one of the only frameworks (NextJS) that supports streaming AI responses with only a few lines of code :)
E-commerce sites are a notable exception requiring app SEO because they don't hide pages behind authentication. That's one of the exception cases where SSR is useful.
However that's still overkill IMHO. Search crawlers don't need the entirety of every page rendered into static HTML. They just need the right keywords on a mostly blank page. A more efficient approach would be to pre-generate static, minimal SEO pages for each app equivalent page. I recall reading about that approach in the past but don't have a name handy since I don't use that architecture.
Search crawlers have gotten better about digesting JS apps. That should be the place to make changes instead of hacking the app code to accommodate crawlers.
"Search crawlers don't need the entirety of every page rendered into static HTML. They just need the right keywords on a mostly blank page".
Ummmm, not entirely true. SEO is more than just keywords. In fact, Google uses many other factors to give you a ranking.
If you want good SEO score (not just have your page indexed), the main content above the fold needs to render quickly. You can have award winning keywords on that page, but if it takes too long for their crawler, those keywords won't matter much.
And the time to load the content should be within a second or two.
As for pre-generated static pages (Static Generation) Next and others can do this on build. When possible, it is the better approach as there's no processing, just serving the content.
Next's pre-generated pages are a handy feature. It would be great if they focused on that. However Next announced that they're going exclusively SSR. Sounds great in theory until you hit the corner cases, and they get ugly really fast. Debugging those is a downright nightmare.
I think now with the client and server side components, Next is a nightmare to develop with.
Was loving Next up until that point (and the idea of SSG). But now have now given up on it.
Will still use React for pure client side apps (but not sites).
They're not going away from staticly generating pages. I think you misunderstood what they mean by focusing on SSR.
Next still does SSG and ISR. Server components don't change that, they just make it even better, because now parts of that statically generated page don't need to hydrate on the client anymore which is great for bundle size.
NextJS is ideal for statically generating pages for good SEO yes.
If your website doesn't display anything without executing JavaScript I don't want anything to do with it.
I hate when websites do pure client rendering. Where I live internet connection sucks, and doing an initial SSR vs nothing is the difference between me being able to use your website or having to wait for a full minute to even see the header.
React as a whole is flawed which is why I never use it, but ditching the SSR entirely as well? You end up with the worse piece of software one could ever build.
It's true, web development has become way more difficult. It's also annoying, because most frameworks require NPM or NodeJS to use them. And then those have frameworks' dependencies have other dependencies. It's nice to come across a framework that has little complexity.
For me it is just hype. Not more. I saw many repos when developers added react on landing. I am not sure if that was a joke. Usually you can resolve tasks using simple tools but when you google how to solve this problem, you can find an overingenering article.
Yeah, I'm one of them! About a year ago I was tasked with recreating a landing page made with jQuery and went with Next.js out of all things. I thought I was doing something that was "state of the art" by using React on a hot modern framework. Only now I realize the errors of my way.
I think this is a common mistake by new web developers and it is related to the "React Developer" phenomenon I mentioned above. In this vein, I'd disagree that it's just hype. Many people (myself included) were and still are being introduced to web development solely through React. To many, React is web development and vice-versa. It becomes a silver-bullet when it's really not. I think developers that do this don't do this because the hype got the best of them, but because they just don't know any other way.
There's also "portfolio pressure". Many developers think companies expect them to have projects with their stacks. So, if they expect to land jobs with React, it's probably a good idea to have a React project even though there is no reason at all to use React. It's a trickle down of the overwhelming corporate adoption of React.
I was thinking a few days ago: "why react? what is it doing?" I'm a tester and I use JS, I learned and used React, and I'm diving in our team's Next.js/Nest.js app since I'mtrying to get back into development, but what resonates with your point is my feeling about the truth that React is just a way to write JS, so maybe we should write JS when possible. I started my career as hybrid apps intern ~7 years ago and learned JS and other stuff, and I always felt like using Vanilla JS whenever possible (I even felt jQuery was unnecessary since you could do its job using Vanilla JS and the document object)
I even came across the following article a few days ago that tells a similar story:
dev.to/danielbergholz/from-nextjs-...
I'm a programmer at heart and I feel the pain.
Sorry for the rambling.
Yeap, bro
I’ve have extensive experience with angular, react and vue. Have some experience with Svelte and Solid too. Never understood what the hype with react is. The ecosystem is a mess, documentation is sparse, community is all about jobs and mostly clueless, performance is the worst of all alternatives and the routing and context/global state fiascos are just ridiculous. I can adapt and hammer a screw or strew in a nail with no problem and that’s fine. However when I get to choose the tools/stack for developing a real web application my bet is solidly in modern composition Vue. It’s the most balanced of the options and the easiest to maintain and grow. Add in Quasar and the speed of developing production ready code deployed in various environments is second to none. It’s hard to explain how flexible, simple, intuitive and painless this setup is. Reminds me that I need to get back to enjoying my power tools while watching you guys pouring concrete with forks :)
I'm new to all of this and was hoping react would just go away, I think it's just jsx itself that bothers me but when looking at what qwik, it's how I thought data worked on the web I had no idea this whole hydration thing was such a drag. Do you think that's a paradigm that will flourish? It's the only reason I considered learning react along with js. Am I right to assume other frameworks through lazy hydration, hybrid,etc are more of a hack around this and they'll fundamentally need a rewrite? Am I placing too much value into something like qwik represents, and as far as scaling goes it's unrealistic to assume most mainstream projects require it and they'll be just fine. Not sure which way to go, I know I definitely prefer something like vue over react and others like svelte feel more simple, not sure if things like astro solve that problem enough as far a performance and allowing to one to author components the way they prefer.. react just makes me cringe
The question you need to ask is "Do you really need hydration?". If you are building an application behind a login than SEO is out of the picture, so what does the hydration do for you?
And if you are building a public facing website where SEO is relevant, than why aren't you using a CMS?
I guess, there is a use case for social media, streaming, etc apps where hydration could still be relevant. However, one - this feels like a niche use case and two - there are other approaches like pre-rendered CDNs, that could solve the problem more efficiently and scalable.
And once you realize that hydration is not a thing, than all these SSR, SSC, etc become irrelevant. The problem is that these patterns are blurring the line between the backend and the frontend. And there are plenty of reasons this line exists: separation of concerns, performance, security, cost, encapsulation, documentation, maintainability, complexity, etc... the list goes on and on. Don't blur the line!
yeah, i am #teamQwik all the way. They have weekly meetings with Misko to talk about the future of Qwik, answer questions, etc. Highly recommend joining them. They have been previewing Qwik 2.0 in the last few, and that eliminates like all of the random comments its adding to the html currently, so it will blow everything else out of the water, even more so than they already do. Its gonna be amazing
Lol, this was about to be my comment exactly. Just watching you all try to keep up with React fads and fanboys is exhausting. Vue 3 is always my first pick when I have the option to choose.
Now that Create-React-App is officially no longer supported and will probably not receive updates, I hope people maintain the front end react ecosystem by supporting projects like Vite. It would be great for everyone if Vite's plugin ecosystem were better supported by the community as well as Vitest. Keep non-ssr front end development alive!
Personally, and as I fortunately can choose the stacks I work with, I never had to dive deep into the React ecosystem - I did some components for some products and despite the final result being interesting, I feel that we are stuck in a way of doing things that ends up harming us in technical debt, especially as the library evolves and we have to be constantly updating work that was already done to keep up with the state of the art. Perhaps that's why I consider that I have an external view of this issue, which allows me to have a broader view of other solutions. What I feel is that React provides an interesting solution for some problems, but once you enter the ecosystem to gain that benefit, you become stuck to the solution, becoming increasingly trapped as new problems arise. Not wanting to directly compare the two solutions because, in their entirety, they provide answers to different problems, I have already developed some things in HTMX and it indeed has benefits because it allows improving the user experience by adding interactivity and reactivity, without the need for any transpilation, while maintaining the state on the server and in the DOM itself, while also allowing graceful degradation or the complete removal of the library and the choice of an alternative path. It may not be a substitute for everything that React does (without some work), but it responds to many of the problems, closer to the backend, DOM and vanilla JavaScript.
Hear, hear! In regards to React, I feel this pain point too. React might actually be a white elephant to some projects. HTMX is certainly not a replacement, but it's good to have a mindset of: do I really need React for this? Turns out, maybe not. HTMX just makes it more obvious that not all websites and even web apps need React's complicated reconciliation algorithm and all that comes with it just to have some basic reactivity.
I've been using github.com/kitajs/html and htmx for a greenfield project and it's going pretty well thus far. I find myself making more small components to make it more readable, compared to the size/number of components in a React app I might be writing. Using something like htmx allows you to focus on your business logic because that's mostly all that's "left" to write. There's no JSON API to design or client-side glue to implement. Same with websockets.
I'm still getting my bearings, but htmx has helped me have much faster velocity. I'm doing things like repainting the whole screen in most cases, which is obviously not scalable, but it makes it so I don't have to stop and design how some part of the UI should be rendered separately, and all connected clients always have correct up-to-date information.
On the other hand, I'm using nextjs in a project my coworker started, and it is turning out to be a huge learning task for me. It seems like quite the vendor lock-in with vercel.
I started long before React; hell, I started 10 years before the first web browser. So I've been through them all, and I can't help but feel React was a mistake. It was an attempt to AVOID doing a full framework, but rather provide a simpler "library", but one that was so completely inadequate that they had to eventually add the whole hooks system and build a huge ecosystem around with third-party completers like Next.
In the meantime, other more complete frameworks took the best of React and completed it as part of their design (VueJS, SolidJS, etc). And while Vue has probably taken too much in Vue 3, SolidJS has excelled with a much more consistent and easy-to-learn complete system. SolidStart will do Next, but better, but I personally feel the whole "combine FE and BE into SSR" has gone a bit too far.
Suddenly "lite frameworks" are all the rage. I think the universe tends to try to find equilibriums between extremes, and I can't help but think it might settle down on SolidJS in this case. There's a whole community out there who seem to reject React as a productivity sink, and in recent interviews, I suggested "anything but React" and in at least two cases was told by the employer that I could use anything I wanted except React.
Frankly I think those still using React are doing so because they have already taken the tough hits and learned the lessons and it's just too comfortable for them. React has been around long enough now that many developers probably never experienced the JavaScript Framework Fatigue that also sparked so much innovation and growth in the JS community. But there are some really fantastic alternatives out there that are hands-down better. Not one, or two, but many. Look around folks. Come up for air and take a breather!
I haven't used React myself. I've always gone with a "less is more" approach when it comes to web development. When I needed to deliver a simple page, server-side templating with a cache and CDN worked just fine. When I wanted to add the ability to add rows to a table without reloading the page, I added a little bit of js to construct rows. When I wanted to start accomplishing more complex things and get rid of duplicates code, I extended my server-side templating engine to allow it to export front-end constructors for components I'd like to reuse.
My entire library is 26 kb uncompressed and I can accomplish much of what react can for me (though I should clarify I don't build SPAs but more conventional crud applications).
Web development has been getting unnecessarily complex for a long time, this newest round is just another uptick.
I like that HTMX has made a splash the way it has. It will help demonstrate that there are indeed other options, that React's complexity isn't due to the inherent complexity of building things for the web, but accidental complexity caused by patching over issues React itself creates.
If I hear one more time "Web development has become too complex"... seriously? What's complex about it? Modern frontend frameworks are really great and becoming better and allows devs to move fast and enjoy it.
There will probably forever be an ebb and flow of complexity and accessibility in this domain.
Speaking as someone whose first website was a personal homepage in 1994, I can testify that this has all happened before. There was a time when you had to practically have a different source code for each browser out there, CGI stood for Common Gateway Interface and they were written in C, Pearl, and later PHP. Everything was much harder to code with very few libraries. Access to help and docs only existed at the public library. Things got so complicated that I thought I might never learn to be a professional web developer. Decades later things are more dynamic and easier than ever. I took an online boot camp, and BOOM I'm caught up. Yet I see the old patterns emerging again. Dependencies on top of dependencies on top of dependencies, frameworks on top of frameworks, an so many options and paths. So many skill sets, backend vs front end, front end vs UX/UI design. You really do need a map to navigate your career path. So make a map and get on with it, because honestly things have never been more achievable.
Yes, it´s so damn simple:
Just install React, a database of your choice, configure the react router, install Redux, Storybook, Axios, Material-UI, Tailwind, Jest, Install the React Dev-Tools, get an GitHub-Account, learn all about hooks.
Oh, I forgot, you need to learn some Javascript first. And some Typescript. You are not a CSS professional? Poor boy. Just read the next 20.000 pages of frustrating documentation and you are up and running in a minute.
Same can be said about backend or game dev or any kind of programming.
...but who said, game development is simple?
Today we see new tools popping up every half year. I totally agree whith Mattheus that we use a pile of tools each stacked ontop of another to solve any specific issue. And each tool implements a new thinking, a new syntax and a new bunch of problems.
What do you do with React alone?
So, what's the problem? Modern programming is a complex job with many different tools. Otherwise we would be making games of 1990 with primitive graphics, and who wants that? Same thing goes for web dev, you couldn't have modern, interactive, large-scale web apps if frontend wasn't complex. That's just the natural evolution of things.
If you are a programmer, you have plenty of options and the effort scales well to your task. But what do you do, if you do not work at Amazon or Meta and you need to build a small scale web app, which anyway should still meet modern standards? Write plain HTML again?
What do you do if you don't work at EA Sports and want to build a small 3D game? That is also a complex task. As a frontend developer, I think it is VERY easy to create a small, modern web app using frameworks like Nuxt because it takes care of all the details for you under the hood. You still need to know how to code though.
So, but what are you considering?
Maybe the web has simply grown too far to have a single solution that fit´s all needs.
Lately I've been exploring, experimenting with tools outside the React ecosystem, like Svelte, and learning more about server-side approaches. I don't want to suggest one is better than the other, to be clear, which is why I didn't go into specifics on that regard. There sure is no silver bullet and every tool has a place on the web.
One of the main problems is, that most tools are "exclusive", they are islands with their very own rules: If you go with React, all your learning and all your effort will be lost if you switch to Svelte. You will start at zero again.
Maybe we should focus on tools and solutions that are kind of "inclusive" (which React is not). This would allow to use the right tool for every task. Webcomponents may be one element in this puzzle.
To just display just some text, HTML / CSS is perfectly fine. Why use React to build the whole page? Why not use HTMX to add some fine grained reactivity to a part of a page, use Vue to build the menues and use some server side framework to do all the database stuff?
I know, things are not like this today, but this is a nice fiction
If you've been a developer for only as long as React exists you may not even really remember a time when "web developer" was a thing, as opposed to "front end developer". And before that, amazingly, "computer programmer" was a thing. And before that, "engineer"! Granularity is the outcome of progression, as systems become ever more layered and complex, so don't be afraid of the idea that you may no longer be required to engineer everything and will have to specialize. We've all had to.
There really is a rabbit hole of javascript frameworks. I stick to vanilla JS/TS to get the job done! Although from what I’ve seen React is great.
React is great for single page applications. If you need a high degree of interactivity without complete page refresh react is the way to go. React combined with a server side framework like flask or express is extremely flexible and powerful, and with a bundler like Vite, its fast and efficient. Learning Vue for simple applications and UIs and React for larger applications is going to be my strategy for now Next.js may be a nice option when you need something really huge really fast, but I don't grasp what it can do that React/Express can't accomplish. The whole SEO argument makes me cringe because most effective SEO is simply about finding a way to cheat, paying for referals, rather than anything that has to do with coding or even content.
The existence of "cheating SEO" doesn't mean that common-sense SEO, like pages that render basic content fast, doesn't matter.
Though in general, I mostly agree with the idea that React isn't ideal for things other than single page applications, and single-page applications theoretically shouldn't need SEO that badly. But in practice, sometimes what theoretically makes sense doesn't work for every individual instance.
I’m quite new to SEO. I understand what it aims to achieve but what are the ways to get there?
SEO is a huge topic, and I am not an SEO expert, but I do think all web devs should know a few basic principles about it. I wouldn't worry too much about getting into the weeds of it if it's not your specialty, but I'll just say that good HTML markup is part of it - and even more importantly, good HTML markup should make your site more accessible to those using assistive technologies such as screen readers. For example, use heading elements (
h1, etc.) in a descriptive way (do not use headings for decoration, but for conveying the main point of the section they're in front of, and do not skip headings) and make sure images have analtattribute that accurately describes the image.This is pretty far from the subject of this article, but I can't miss an opportunity to encourage semantic HTML!
So from what I gather, don’t neglect the basics of a structured HTML layout? That sounds insightful, I’ll keep it in my when making my next page!
Thanks for the reply. May I ask why you wouldn’t consider React to be a good choice for multi-page applications? And what your ideal tech stack for web development looks like in 2024. ❤️
The biggest problem for React is not Technology.
The biggest problem is Meta/Facebook is not a member of the WHATWG, so they have no stake in what Web Browsers run.
Long read: stackoverflow.com/questions/643043...