5 ms·

And what kind of problem do you solve with this approach? Your sites loading too fast?

by grishka 2y ago

xwolfi 2y ago
Gnehehehe
LegionMammal978 2y ago
At least for me, static page hosting costs me $0, whereas dynamic page hosting would very likely cost me > $0.
- manuelmoreale 2y ago
  You can use a SSG and get the same result if that’s your main concern.
- grishka 2y ago
  Where does your SPA pull its data from, if not from some sort of API that must be running on something that is capable of generating HTML as well?
  - LegionMammal978 2y ago
    Most of my personal projects haven't had any state that needs to be managed server-side: any needed data is either static or can be pulled from "someone else's" unauthenticated API. Which is how I prefer it, since all incoming data from users is a big liability these days.
- wfme 2y ago
  Dropping an SPA onto Cloudflare takes under 5 minutes including sign up and is completely free.
com2kid 2y ago
I do the same for personal projects. I love having deployment be "drop a folder of static files onto a server". Also scaling out SPAs is a non-issue. Servers have basically unlimited throughput for delivering static files, assuming you don't inline any 24MB uncompressed images. Or just throw it on Cloudflare, whatever, again, it is just static files.
- oliwarner 2y ago
  They made this thing called a static site generator about 25 years ago, and modern ones like Astro are better than ever. Just like your SPA, you have no server to look after, (eg) Cloudflare builds it all, hosts it all and there's no JS overhead for clients, no SEO hassle, etc, etc.
  - com2kid 2y ago
    The personal projects I tend towards are interactive and have animations and fancy transitions and application state and they make API calls. Which makes Astro the wrong tool for the job, and SPA frameworks like Svelte the right tool for the job. Doing these things server side makes no sense, it'd just make everything harder for me to debug!
    - oliwarner 2y ago
      I'm not saying SPAs are wrong. There is a very valid set of uses and it sounds like you're well in there, though if your state model is so fragile to won't survive me accidentally refreshing, you need to look at that. But many enthusiastic young developers start using a framework and decide to do everything with it. Same was true on server dynamic frameworks. Everyone's first project is technologically-inappropriate blog. These sites would be objectively better as SSG sites. Btw, Astro is surprisingly excellent at using frontend components from multiple frameworks, even in the same project. If your interactivity is in-page, or you have a mixed MPA-SPA domain, it's well worth a look. Even the DX, I prefer it to Next/Next projects where you're chained to a set of dev dependencies from the start. My last Nuxt upgrade took three weeks to unhook various deep integrations and fix things (Vue 2 to 3 too). Nightmare.
      - com2kid 2y ago
        > though if your state model is so fragile to won't survive me accidentally refreshing, you need to look at that. Highly interactive experiences are complex to manage full refreshes with, is it do-able? Sure. It is something I want to bother with for a project I work on 1hr a day after work? Not really! > Everyone's first project is technologically-inappropriate blog. These sites would be objectively better as SSG sites. I am amazed that Wordpress became the behemoth that it is for personal blogs, given that 99.99% of them would work well as statically generated pages. Honestly the move towards SSG that then embed some discussion component seems like the best combo for most small and medium use cases.
1vuio0pswjnm7 2y ago
For so-called "tech" companies that intermediate, surveil and attempt to profit from computer users accessing content the so-called "tech" companies did not create, that is actually a "problem". For example, as a "solution", Google intentionally adds delay to "loading" so that ad auctions can run. When these companies use some marketing slogan like "Make the web faster" it is quite amusing. Ads are what slows it down and dissemination of ads is their "business model". Parasites.
- grishka 2y ago
  I keep forgetting that there are ads on the internet.
  - deleted 2y ago
    [deleted]
chrisldgk 2y ago
Not that guy, but for highly dynamic and interactive sites, it’s actually easier to manage state if you‘re working on the client side only. Introducing SSR and data handling on the server side to an app can be much less productive if you don’t need the performance improvements that SSR brings.
- _heimdall 2y ago
  This is the crux of where I always landed on whether to render on the server or in the client. Render where the state lives. If a piece of state is stored on the server, and the server will have to be notified when it changes, rendee HTML there. For any part of the UI that really is temporary state that only lives in the client, just render that piece (or changes to that piece) in the browser and leave the server out of it. An all or nothing solution is rarely the right answer.
  - chefandy 2y ago
    Many developers fail to notice how colored their perspectives are by a) nostalgia for the technical simplicity of web 1.0, b) the curse of expertise, and c) confirmation bias. A website, just like any other application, exists to solve a problem. The right ratio of hassle/efficacy/reliability definitely isn't the same for every application, and often not even the same among different user groups. What developers consider to be a hassle or too complicated is dramatically different from most other groups. Doctors and children and mechanics and mechanical engineers and artists have more in common with the way they interact with software than any of those groups do with software developers. If you have a working mental model of what's happening behind each click, your perspective is totally different. To a developer seeing a form submit and waiting for a return is a set of actions with a story behind it. We know what's happening. To a typical user, it's a period of flickering and flashing and waiting after they clicked on a button. There's no meaning to it-- they just compare the action of button A which changes screen state instantly, to button B which seemingly dicks around for a while until something happens. What about on slow connections or devices? It depends on what problem you're solving. If you serving up nearly static content, using an SPA is absurd. If you're doing something interactive, it's way worse to have constant reloads than use a -----properly designed----- SPA that loads once, uses local storage efficiently, and only makes small API calls to the server once its loaded. If an SPA has poor architecture or is a bad solution for the problem, the problem is the developer that made those decisions, not SPAs. A 500% reduction in technical complexity is meaningless to most end users. If it comes at the expense of having to look at a page reload in between frequent operations, it's a big annoyance. Sure, I'd much rather put together a nice clean static site than do something dynamic, but what the hell is the point if it's not the best way for users to solve the problem they need it to solve? Beyond that, I guarantee you there are many sites that 'just work' the way you'd expect a website to work and you'd have no idea they were SPAs. Making a proper SPA requires a lot more technical design and expertise than making a traditional site, and using a poorly made SPA is a WAY worse experience than using a poorly made static site. That makes it really easy to notice when one is bad, so it makes SPAs seem bad, generally, which is just not true. For the same reason we can't leave all technical decisions up to designers, we can't leave all interaction decisions to developers. Obviously it will make development a lot easier and smoother if we do, but that's one of many factors, and quite often not the most important one.
tail_exchange 2y ago
I also prefer the client-side approach because the separation between server and client makes more sense to me: the backend serves data, the client renders it. It is also much easier to manage state. Unless the website is extremely simple, I always go for JS framworks. I never had problems with performance. React is less than 150kb, and as the backend is not a bottleneck, the website feels very snappy. SSR is not enough if you want an interactive page, you'll need some JS. If you do, instead of dealing with a ton of scattered JS scripts, I'd rather have a single React/whatever application.
- elktown 2y ago
  > the backend serves data, the client renders it SSR does this as well. The server serves data (HTML), the client (web browser) renders it.
  - tail_exchange 2y ago
    By data I mean a format for data interchange, like JSON.
    - elktown 2y ago
      So what makes sense to you is adding the additional layer of transforming the JSON data into HTML from an API - all of which are almost always in the end tailor made for the app anyway - using a significant chunk of code within a completely separate and bloated ecosystem and in a different language than what the server uses? A bonus "feature" of this, and a very important one, is that this now also requires different specializations on your team and the personnel costs and communication overhead that comes with that. Great, now adding simple CRUD functionality to a website is a two week project syncing between backenders and frontenders, for something that someone wanting to scratch their own itch could hammer out independently in a single day back in the SSR days.
      - tail_exchange 2y ago
        Large companies typically have dedicated frontend teams with designers to build a user experience that feels cohesive across their products, so managing different specializations and the communication overhead is already part of their workflow. Your argument suggests that SSR requires only one type of specialization, but that's not entirely accurate. SSR developers still need full-stack knowledge, since they must write HTML, CSS, and JavaScript alongside the backend code. This means their expertise already needs to cover multiple areas and languages. While it’s true that frontend frameworks introduce additional build tooling, developers today are generally familiar with this ecosystem. The backend developers I work with do have a good understanding of React and can work with it comfortably, and I have seen junior developers picking it up within a week or two. They don't need to be specialists in order to be productive. Yes, it is true that many backends are tailor-made for a frontend, but going exclusively HTML-first will lock you into this state, unless you are OK with revisiting it to add a JSON API later to support additional use cases. When I write an application, it usually comes with a CLI in case I need to use it from a server without access to a UI, and I hook it up with tools for integration tests using its JSON API. It's also common to see frontends that are powered by multiple backends, and in these cases, it makes sense to have a separate frontend application that uses APIs. So yes, it does make perfect sense for me to have a layer between presentation and application. edit: fixed a typo
threatofrain 2y ago
Can app makers in other ecosystems learn from the web here? Should mobile and desktop apps just be ultra thin clients with the next "page" being rendered on the server? Do you think this argument tickles the performance bone of other app communities?
- grishka 2y ago
  I'm an Android developer as well. Apps and websites are fundamentally different so no. Apps are by definition highly dynamic, while websites start out as static documents that some people put too much macros into to make them appear like (bad) apps.

And what kind of problem do you solve with this approach? Your sites loading too fast?

xwolfi 2y ago

Gnehehehe

LegionMammal978 2y ago

At least for me, static page hosting costs me $0, whereas dynamic page hosting would very likely cost me > $0.

manuelmoreale 2y ago
You can use a SSG and get the same result if that’s your main concern.
grishka 2y ago
Where does your SPA pull its data from, if not from some sort of API that must be running on something that is capable of generating HTML as well?
- LegionMammal978 2y ago
  Most of my personal projects haven't had any state that needs to be managed server-side: any needed data is either static or can be pulled from "someone else's" unauthenticated API. Which is how I prefer it, since all incoming data from users is a big liability these days.
wfme 2y ago
Dropping an SPA onto Cloudflare takes under 5 minutes including sign up and is completely free.

com2kid 2y ago

I do the same for personal projects. I love having deployment be "drop a folder of static files onto a server". Also scaling out SPAs is a non-issue. Servers have basically unlimited throughput for delivering static files, assuming you don't inline any 24MB uncompressed images. Or just throw it on Cloudflare, whatever, again, it is just static files.

oliwarner 2y ago
They made this thing called a static site generator about 25 years ago, and modern ones like Astro are better than ever. Just like your SPA, you have no server to look after, (eg) Cloudflare builds it all, hosts it all and there's no JS overhead for clients, no SEO hassle, etc, etc.
- com2kid 2y ago
  The personal projects I tend towards are interactive and have animations and fancy transitions and application state and they make API calls. Which makes Astro the wrong tool for the job, and SPA frameworks like Svelte the right tool for the job. Doing these things server side makes no sense, it'd just make everything harder for me to debug!
  - oliwarner 2y ago
    I'm not saying SPAs are wrong. There is a very valid set of uses and it sounds like you're well in there, though if your state model is so fragile to won't survive me accidentally refreshing, you need to look at that. But many enthusiastic young developers start using a framework and decide to do everything with it. Same was true on server dynamic frameworks. Everyone's first project is technologically-inappropriate blog. These sites would be objectively better as SSG sites. Btw, Astro is surprisingly excellent at using frontend components from multiple frameworks, even in the same project. If your interactivity is in-page, or you have a mixed MPA-SPA domain, it's well worth a look. Even the DX, I prefer it to Next/Next projects where you're chained to a set of dev dependencies from the start. My last Nuxt upgrade took three weeks to unhook various deep integrations and fix things (Vue 2 to 3 too). Nightmare.
    - com2kid 2y ago
      > though if your state model is so fragile to won't survive me accidentally refreshing, you need to look at that. Highly interactive experiences are complex to manage full refreshes with, is it do-able? Sure. It is something I want to bother with for a project I work on 1hr a day after work? Not really! > Everyone's first project is technologically-inappropriate blog. These sites would be objectively better as SSG sites. I am amazed that Wordpress became the behemoth that it is for personal blogs, given that 99.99% of them would work well as statically generated pages. Honestly the move towards SSG that then embed some discussion component seems like the best combo for most small and medium use cases.

1vuio0pswjnm7 2y ago

For so-called "tech" companies that intermediate, surveil and attempt to profit from computer users accessing content the so-called "tech" companies did not create, that is actually a "problem". For example, as a "solution", Google intentionally adds delay to "loading" so that ad auctions can run. When these companies use some marketing slogan like "Make the web faster" it is quite amusing. Ads are what slows it down and dissemination of ads is their "business model". Parasites.

grishka 2y ago
I keep forgetting that there are ads on the internet.
- deleted 2y ago
  [deleted]

chrisldgk 2y ago

Not that guy, but for highly dynamic and interactive sites, it’s actually easier to manage state if you‘re working on the client side only. Introducing SSR and data handling on the server side to an app can be much less productive if you don’t need the performance improvements that SSR brings.

_heimdall 2y ago
This is the crux of where I always landed on whether to render on the server or in the client. Render where the state lives. If a piece of state is stored on the server, and the server will have to be notified when it changes, rendee HTML there. For any part of the UI that really is temporary state that only lives in the client, just render that piece (or changes to that piece) in the browser and leave the server out of it. An all or nothing solution is rarely the right answer.
- chefandy 2y ago
  Many developers fail to notice how colored their perspectives are by a) nostalgia for the technical simplicity of web 1.0, b) the curse of expertise, and c) confirmation bias. A website, just like any other application, exists to solve a problem. The right ratio of hassle/efficacy/reliability definitely isn't the same for every application, and often not even the same among different user groups. What developers consider to be a hassle or too complicated is dramatically different from most other groups. Doctors and children and mechanics and mechanical engineers and artists have more in common with the way they interact with software than any of those groups do with software developers. If you have a working mental model of what's happening behind each click, your perspective is totally different. To a developer seeing a form submit and waiting for a return is a set of actions with a story behind it. We know what's happening. To a typical user, it's a period of flickering and flashing and waiting after they clicked on a button. There's no meaning to it-- they just compare the action of button A which changes screen state instantly, to button B which seemingly dicks around for a while until something happens. What about on slow connections or devices? It depends on what problem you're solving. If you serving up nearly static content, using an SPA is absurd. If you're doing something interactive, it's way worse to have constant reloads than use a -----properly designed----- SPA that loads once, uses local storage efficiently, and only makes small API calls to the server once its loaded. If an SPA has poor architecture or is a bad solution for the problem, the problem is the developer that made those decisions, not SPAs. A 500% reduction in technical complexity is meaningless to most end users. If it comes at the expense of having to look at a page reload in between frequent operations, it's a big annoyance. Sure, I'd much rather put together a nice clean static site than do something dynamic, but what the hell is the point if it's not the best way for users to solve the problem they need it to solve? Beyond that, I guarantee you there are many sites that 'just work' the way you'd expect a website to work and you'd have no idea they were SPAs. Making a proper SPA requires a lot more technical design and expertise than making a traditional site, and using a poorly made SPA is a WAY worse experience than using a poorly made static site. That makes it really easy to notice when one is bad, so it makes SPAs seem bad, generally, which is just not true. For the same reason we can't leave all technical decisions up to designers, we can't leave all interaction decisions to developers. Obviously it will make development a lot easier and smoother if we do, but that's one of many factors, and quite often not the most important one.

tail_exchange 2y ago

I also prefer the client-side approach because the separation between server and client makes more sense to me: the backend serves data, the client renders it. It is also much easier to manage state. Unless the website is extremely simple, I always go for JS framworks. I never had problems with performance. React is less than 150kb, and as the backend is not a bottleneck, the website feels very snappy. SSR is not enough if you want an interactive page, you'll need some JS. If you do, instead of dealing with a ton of scattered JS scripts, I'd rather have a single React/whatever application.

elktown 2y ago
> the backend serves data, the client renders it SSR does this as well. The server serves data (HTML), the client (web browser) renders it.
- tail_exchange 2y ago
  By data I mean a format for data interchange, like JSON.
  - elktown 2y ago
    So what makes sense to you is adding the additional layer of transforming the JSON data into HTML from an API - all of which are almost always in the end tailor made for the app anyway - using a significant chunk of code within a completely separate and bloated ecosystem and in a different language than what the server uses? A bonus "feature" of this, and a very important one, is that this now also requires different specializations on your team and the personnel costs and communication overhead that comes with that. Great, now adding simple CRUD functionality to a website is a two week project syncing between backenders and frontenders, for something that someone wanting to scratch their own itch could hammer out independently in a single day back in the SSR days.
    - tail_exchange 2y ago
      Large companies typically have dedicated frontend teams with designers to build a user experience that feels cohesive across their products, so managing different specializations and the communication overhead is already part of their workflow. Your argument suggests that SSR requires only one type of specialization, but that's not entirely accurate. SSR developers still need full-stack knowledge, since they must write HTML, CSS, and JavaScript alongside the backend code. This means their expertise already needs to cover multiple areas and languages. While it’s true that frontend frameworks introduce additional build tooling, developers today are generally familiar with this ecosystem. The backend developers I work with do have a good understanding of React and can work with it comfortably, and I have seen junior developers picking it up within a week or two. They don't need to be specialists in order to be productive. Yes, it is true that many backends are tailor-made for a frontend, but going exclusively HTML-first will lock you into this state, unless you are OK with revisiting it to add a JSON API later to support additional use cases. When I write an application, it usually comes with a CLI in case I need to use it from a server without access to a UI, and I hook it up with tools for integration tests using its JSON API. It's also common to see frontends that are powered by multiple backends, and in these cases, it makes sense to have a separate frontend application that uses APIs. So yes, it does make perfect sense for me to have a layer between presentation and application. edit: fixed a typo

threatofrain 2y ago

Can app makers in other ecosystems learn from the web here? Should mobile and desktop apps just be ultra thin clients with the next "page" being rendered on the server? Do you think this argument tickles the performance bone of other app communities?

grishka 2y ago
I'm an Android developer as well. Apps and websites are fundamentally different so no. Apps are by definition highly dynamic, while websites start out as static documents that some people put too much macros into to make them appear like (bad) apps.