Sometimes Next.js seems to be adopted like it's some kind of silver bullet.
As demonstrated by Optimizing Core Web Vitals on a Next.js app it can take quite a bit of effort to (in this case) nudge the Time to Interactive from "moderate" to "good" with a Next.js application. Next.js's Achilles heal is that it performs full page hydration since most React applications do full page renders on the client side. Back in 2019 an experimental, heavily customized Preact/Next.js application demonstrated the benefits progressive hydration could bring (see also Partial Hydration in Preact).
experiences. Web. frameworks. future. me. puts forward an interesting perspective. React (Next.js) and Svelte (SvelteKit) are Generation 2 Web solutions (Gen 2) - but the challenges of client-side hydration limits the effectiveness of their respective SSR solutions.
Meanwhile there are already early indications of Gen 3 - JavaScript-based server-first architectures. Server-first differs from traditional dynamic server rendering as there still can be a significant client side capabilities (e.g. nested routes)—but the client no longer dictates key aspects of the server-client dynamic; while both are separate their interactions will be more tightly coupled (compared to SPA + API) to deliver a better user experience. Gen 3 MPAs will attempt to optimize for FCPandTTI to provide universally "fast page navigation"—with may even leverage "streaming HTML".
@guido_tech@remix_run A friend of mine (vswong.com) also made this network chart for his evaluation between Marko and Remix, which says a thousand words IMO:
Thanks for the pointers. I agree it isn't a silver bullet and these frameworks introduce their own problems. It's a delicate tradeoff for me between a slower less flexible solution like Next.js or run a bleeding edge less common setup. As an entrepreneur I also have to consider the cost of onboarding new developers , or the impact of a more obscure framework when I want to sell my business.
As an entrepreneur I also have to consider the cost of onboarding new developers , or the impact of a more obscure framework when I want to sell my business.
It's hard to argue with that reasoning but I think the mindset has gotten to the point where it is self perpetuating SPA/React/Next.js adoption—products are built with React because of developer availability and developers adopt React because of demand. Adoption based on popularity of authoring experience rather than suitability towards the product being developed (Responsible JavaScript refers to this as the bandwagon fallacy).
The typical developer framework discussion revolves around a framework's impact on the developer('s happiness and productivity) rather than the impact on the end user. That facet gets highlighted elsewhere:
The Cost of Javascript Frameworks:
"Good frameworks should provide a better starting point on the essentials (security, accessibility, performance) or have built-in constraints that make it harder to ship something that violates those.
That doesn’t appear to be happening with performance (nor with accessibility, apparently)."
"Try and retrofit any of them to your project and you’re going to have a bad time."
Responsible JavaScript:
"Frameworks don’t doom us to build shitty websites but to use them is to accept a certain amount of overhead you can never optimize away. You must step lightly, particularly since the ecosystem of installable plugins and off-the-shelf components available to such architectures can further compound their user-experience problems."
Your experience with Vue is unfortunate, especially if it lead to wasted effort. But disruptions like this aren't limited to the "smaller" frameworks; both Angular and React have had them:
Angular was a completely different from AngularJS. AngularJS had LTS until December 31, 2021 but many projects were cut off from modernizing in a gradual manner.
Meanwhile there are regularly complaints that React is changing too rapidly or simply changing for the sake of change (a symptom of Facebook's needs not overlapping with some of its OSS user base).
Etsy just recently completed migration from React to Preact - adopting React v16 would have required significant updates to their legacy code base.
It's a delicate tradeoff
Clearly it must be the pragmatic choice at times, it just seems that ecosystem/hire-ability considerations have made React the incumbent technology—despite the clear need for alternatives with different sets of priorities.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Sometimes Next.js seems to be adopted like it's some kind of silver bullet.
As demonstrated by Optimizing Core Web Vitals on a Next.js app it can take quite a bit of effort to (in this case) nudge the Time to Interactive from "moderate" to "good" with a Next.js application. Next.js's Achilles heal is that it performs full page hydration since most React applications do full page renders on the client side. Back in 2019 an experimental, heavily customized Preact/Next.js application demonstrated the benefits progressive hydration could bring (see also Partial Hydration in Preact).
Based on this Remix is gunning for Next.js with their interpretation of progressive enhancement while Astro does it with partial hydration.
experiences. Web. frameworks. future. me. puts forward an interesting perspective. React (Next.js) and Svelte (SvelteKit) are Generation 2 Web solutions (Gen 2) - but the challenges of client-side hydration limits the effectiveness of their respective SSR solutions.
Meanwhile there are already early indications of Gen 3 - JavaScript-based server-first architectures. Server-first differs from traditional dynamic server rendering as there still can be a significant client side capabilities (e.g. nested routes)—but the client no longer dictates key aspects of the server-client dynamic; while both are separate their interactions will be more tightly coupled (compared to SPA + API) to deliver a better user experience. Gen 3 MPAs will attempt to optimize for FCP and TTI to provide universally "fast page navigation"—with may even leverage "streaming HTML".
The weirdly obscure art of Streamed HTML
Taylor Hunt ・ Mar 15 '22 ・ 12 min read
Why Efficient Hydration in JavaScript Frameworks is so Challenging
Ryan Carniato for This is Learning ・ Feb 3 '22 ・ 9 min read
Thanks for the pointers. I agree it isn't a silver bullet and these frameworks introduce their own problems. It's a delicate tradeoff for me between a slower less flexible solution like Next.js or run a bleeding edge less common setup. As an entrepreneur I also have to consider the cost of onboarding new developers , or the impact of a more obscure framework when I want to sell my business.
It's hard to argue with that reasoning but I think the mindset has gotten to the point where it is self perpetuating SPA/React/Next.js adoption—products are built with React because of developer availability and developers adopt React because of demand. Adoption based on popularity of authoring experience rather than suitability towards the product being developed (Responsible JavaScript refers to this as the bandwagon fallacy).
The typical developer framework discussion revolves around a framework's impact on the developer('s happiness and productivity) rather than the impact on the end user. That facet gets highlighted elsewhere:
The Cost of Javascript Frameworks:
"Good frameworks should provide a better starting point on the essentials (security, accessibility, performance) or have built-in constraints that make it harder to ship something that violates those.
That doesn’t appear to be happening with performance (nor with accessibility, apparently)."
The Three Unattractive Pillars of Web Dev: accessibility, security and performance;
Responsible JavaScript:
"Frameworks don’t doom us to build shitty websites but to use them is to accept a certain amount of overhead you can never optimize away. You must step lightly, particularly since the ecosystem of installable plugins and off-the-shelf components available to such architectures can further compound their user-experience problems."
Your experience with Vue is unfortunate, especially if it lead to wasted effort. But disruptions like this aren't limited to the "smaller" frameworks; both Angular and React have had them:
Clearly it must be the pragmatic choice at times, it just seems that ecosystem/hire-ability considerations have made React the incumbent technology—despite the clear need for alternatives with different sets of priorities.