5 ms·

Wow, such an elitist comment. So you mean endless webpack configurations with tons of javascript libs are more maintainable? The reverse can be said for SPA-l

Wow, such an elitist comment. So you mean endless webpack configurations with tons of javascript libs are more maintainable? The reverse can be said for SPA-like frontends in which you put forward as the better choice. It's unnecessarily complex and one error and the whole page becomes unresponsive and crashes. How many times haven't we all clicked on a button and because the developer didn't handle some error in a good way the entire page must be reloaded and all state is lost? You want a good placement on search engines? Well, good luck chuck. Unless you utilize server rendered pages you are out of luck basically. This is also a big hassle. Also server rendered pages are usually slow as fuck compared to a normal multi page app. I am using lit-html myself and like it, but it's not necessarily better than dom based templating imo. For some things I believe it to be worse. Right now I am on a slow and shaky connection and will be for a while, sites like HN which is a classic multi page app without any javascript loads fast and works great. Pages like youtube and the new reddit (old works great) works like total shite.

eyelidlessness 7y ago
Wow, you responded to a pretty thoughtful post with insults, hyperbole and strawmen, and FUD. > So you mean endless webpack configurations with tons of javascript libs are more maintainable? I don't think that's what the comment claimed at all. However, I think the answer to the less hyperbolic version of this question is: maybe. It's pretty orthogonal to the discussion though. > The reverse can be said for SPA-like frontends in which you put forward as the better choice. It's unnecessarily complex and one error and the whole page becomes unresponsive and crashes. How many times haven't we all clicked on a button and because the developer didn't handle some error in a good way the entire page must be reloaded and all state is lost? I have no idea where you got the idea that this is some defining feature of SPAs, but this is something that can happen with jQuery spaghetti and it's something that almost never happens with React. > You want a good placement on search engines? Well, good luck chuck. Unless you utilize server rendered pages you are out of luck basically. This is also a big hassle. Also server rendered pages are usually slow as fuck compared to a normal multi page app. 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.
- ecmascript 7y ago
  > 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.
lf-non 7y ago
I didn't mean to imply that everyone should start using SPAs or people should eschew server-rendered pages. While search engines have gotten quite better handling javascript, but that was not the point of my comment. I was mainly outlining my own subpar experience working with libraries having similar approaches in medium-size teams (~30 devs, about 60% of them juniors). I just hope that people evaluate the potential drawbacks of this approach before jumping into this because it is convenient to get started with. Angular 1 was also pretty popular in its glory days and as I have learnt the hard way popularity is not a good indicator of either longevity or quality. I also suggested some alternatives that I have found in my experience to be better suited towards the task of enhancing server-rendered markup. If one has evaluated related alternatives, weighed pros and cons and settled on alpine, well, power to them.

eyelidlessness 7y ago

Wow, you responded to a pretty thoughtful post with insults, hyperbole and strawmen, and FUD. > So you mean endless webpack configurations with tons of javascript libs are more maintainable? I don't think that's what the comment claimed at all. However, I think the answer to the less hyperbolic version of this question is: maybe. It's pretty orthogonal to the discussion though. > The reverse can be said for SPA-like frontends in which you put forward as the better choice. It's unnecessarily complex and one error and the whole page becomes unresponsive and crashes. How many times haven't we all clicked on a button and because the developer didn't handle some error in a good way the entire page must be reloaded and all state is lost? I have no idea where you got the idea that this is some defining feature of SPAs, but this is something that can happen with jQuery spaghetti and it's something that almost never happens with React. > You want a good placement on search engines? Well, good luck chuck. Unless you utilize server rendered pages you are out of luck basically. This is also a big hassle. Also server rendered pages are usually slow as fuck compared to a normal multi page app. 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.

ecmascript 7y ago
> 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.

lf-non 7y ago

I didn't mean to imply that everyone should start using SPAs or people should eschew server-rendered pages. While search engines have gotten quite better handling javascript, but that was not the point of my comment. I was mainly outlining my own subpar experience working with libraries having similar approaches in medium-size teams (~30 devs, about 60% of them juniors). I just hope that people evaluate the potential drawbacks of this approach before jumping into this because it is convenient to get started with. Angular 1 was also pretty popular in its glory days and as I have learnt the hard way popularity is not a good indicator of either longevity or quality. I also suggested some alternatives that I have found in my experience to be better suited towards the task of enhancing server-rendered markup. If one has evaluated related alternatives, weighed pros and cons and settled on alpine, well, power to them.