3 ms·

> So... I don't know how you're doing this, and admittedly I was away from frontend dev for a few years so I'm sure I missed some pain in the meantime, but I re

> So... I don't know how you're doing this, and admittedly I was away from frontend dev for a few years so I'm sure I missed some pain in the meantime, but I recently started a project with Next.js, and... this is the exact opposite of my experience. SSR is super fast, it only happens once, you get static HTML output and your site is basically as fast as your web server/CDN. All of this without any config. This is only partly true if you use a big framrework like Next or Nuxt but it also means you will heavily buy into whatever these frameworks choose for you. For example, a node backend. The pages are not faster, especially after adding some complexity like most websites require. The time to render is higher, input lag is commonplace. You're sending the html for that site + all the javascript that needs to be parsed to get that SPA-app that everyone wants. And as soon as you step outside what the framework requires you too, for example using another backend. Then you're back to a classical SPA-application. I like SPA-applications that are done well or when they are required, but the complexity to create one is a lot higher because the developers needs to reimplement what the browser originally did for you.

eyelidlessness 7y ago
> This is only partly true if you use a big framrework like Next or Nuxt but it also means you will heavily buy into whatever these frameworks choose for you. For example, a node backend. I mean this in the kindest way: I don't think you fully understand what you're talking about. Next may provide some batteries, but it's hardly a "framework". It does not require you to use any particular part of its functionality. For instance, the site I'm building does not have a backend, node or otherwise, at all. If your server-rendered pages don't need to perform anything asynchronously to render, it just spits out HTML files and you can use whatever you want for a backend. > The pages are not faster, especially after adding some complexity like most websites require. The time to render is higher, input lag is commonplace. You're sending the html for that site + all the javascript that needs to be parsed to get that SPA-app that everyone wants. This is simply not an accurate representation of what I am experiencing with Next. It produces static HTML files. They load as fast as any other HTML files. If you do need to dynamically load data on the server, yes you are constrained by the server's performance generating that data, but that is true of any server-rendered dynamic data on any platform. > And as soon as you step outside what the framework requires you too, for example using another backend. Then you're back to a classical SPA-application. Okay? Yes, using a tool for otherwise than its intended purpose is definitely more complex than using it for its intended purpose. But like... Next with another backend is basically Create React App with a simple built in router and some compilation optimizations that you don't have to configure. > I like SPA-applications that are done well or when they are required, but the complexity to create one is a lot higher because the developers needs to reimplement what the browser originally did for you. You really don't. To the extent SPAs "reimplement" anything, these things are all basically solved problems. - - - I just want to add that there are use cases for something like Next that aren't necessarily "single page app". I am using it as a static site generator that lets me express my components as React components, which is renderer-agnostic should I ever want to render to another target, and which has a huge ecosystem I can tap into (for example I am using mdxjs to produce most of this site's content in Markdown with the ability to customize how certainn parts of the MD content is rendered using... React components). This site is fully static. It's not "slow", it doesn't require a "framework" or a "backend". It is by far the best static site dev experience I've ever had.

eyelidlessness 7y ago

> This is only partly true if you use a big framrework like Next or Nuxt but it also means you will heavily buy into whatever these frameworks choose for you. For example, a node backend. I mean this in the kindest way: I don't think you fully understand what you're talking about. Next may provide some batteries, but it's hardly a "framework". It does not require you to use any particular part of its functionality. For instance, the site I'm building does not have a backend, node or otherwise, at all. If your server-rendered pages don't need to perform anything asynchronously to render, it just spits out HTML files and you can use whatever you want for a backend. > The pages are not faster, especially after adding some complexity like most websites require. The time to render is higher, input lag is commonplace. You're sending the html for that site + all the javascript that needs to be parsed to get that SPA-app that everyone wants. This is simply not an accurate representation of what I am experiencing with Next. It produces static HTML files. They load as fast as any other HTML files. If you do need to dynamically load data on the server, yes you are constrained by the server's performance generating that data, but that is true of any server-rendered dynamic data on any platform. > And as soon as you step outside what the framework requires you too, for example using another backend. Then you're back to a classical SPA-application. Okay? Yes, using a tool for otherwise than its intended purpose is definitely more complex than using it for its intended purpose. But like... Next with another backend is basically Create React App with a simple built in router and some compilation optimizations that you don't have to configure. > I like SPA-applications that are done well or when they are required, but the complexity to create one is a lot higher because the developers needs to reimplement what the browser originally did for you. You really don't. To the extent SPAs "reimplement" anything, these things are all basically solved problems. - - - I just want to add that there are use cases for something like Next that aren't necessarily "single page app". I am using it as a static site generator that lets me express my components as React components, which is renderer-agnostic should I ever want to render to another target, and which has a huge ecosystem I can tap into (for example I am using mdxjs to produce most of this site's content in Markdown with the ability to customize how certainn parts of the MD content is rendered using... React components). This site is fully static. It's not "slow", it doesn't require a "framework" or a "backend". It is by far the best static site dev experience I've ever had.