Hacker News Reader

Comment by joshstrange | Hacker News Reader

Spoken like someone who doesn't need and/or understand SPA-style features. Look I get it, I've been developing with PHP for close to 2 decades but let's not pretend that PHP+jQuery (or whatever you are using for frontend interaction) is anywhere near as powerful as a SPA+SSR. And yes, not every site needs to be a SPA but there are some sites where that absolutely is the right call and pairing it with SSR can get you "the best of both worlds".

View on HN

If you're building an SPA for an Ecommerce site you've seriously misunderstood the web.

These days you can slap together a very capable PHP based Ecom solution using Livewire for those sections that need interactivity.

People really need to realise just how detremental to the user experience it is to have mountains of JS being needed just for an ecommerce site.

Who does need an SPA?

People who sell advertising for a living.

This is a joke, right?

No. From what I can tell the whole reason for a SPA is so that people don't leave your site. You throw away a lot of good things (like urls to content) so that you can push more ads at people.

Ah, I see your argument; SPAs are a preferred way to 'suck folks in' to a page and just have them stay there since they can't navigate in and out to the specific piece of content they want with URLs.

That about sums up everything wrong with our industry. Engagement over usefulness.

yes but none of that has anything to do with SPA as a technology.

the point of an SPA is so that i can share code and data for different pages in the browser without having to get it from the server for each new page.

it does not at all prevent me from using links to the outside or even within the site. (i just built an SPA where all navigation is done via regular links, each view has a different url, they all can be bookmarked, and history works too so you can go back and forth using the standard browser buttons, and links to certain resources take you out of the app)

> the point of an SPA is so that i can share code and data for different pages in the browser without having to get it from the server for each new page.

You still have to get it from the server for each new page, you just do it in the background.

i don't need to get the code. nor the markup. that's already loaded in the browser. if i need to get anything, it's raw data. i also don't need to send anything back so i can manage state. being able to load data in the background can also improve the user experience. and for those apps that don't need a backend, i won't need to get anything ever after the first load. SPAs can, if written right, function completely offline, once loaded.

> also improve the user experience

It doesn't. Most users don't actually notice.

Well, not long ago I made an in-browser WYSIWYG mouse-based diagram designer. I redefined a huge share of the default browser behavior.

It was also the first SPA I made, in a career of decades. I also think I do not regularly use anything that benefits from being an SPA (I don't regularly use that diagram designer either).

People/stakeholders who want use the browser as an application platform.

Think data analysis tools, Intranet tools, e-commerce, and a host of B2B stuff?

I know, it all starts with a filterable list or a shopping basket, where page reloads or ajax "sprinkles" (regardless of what they're loading, HTML or JSON) are absolutely OK.

Especially the fully old-school approach with the page reloads - it can work and scale for simple and predictable requirements.

Until it doesn't - the first page with 5 interdependent autocomplete inputs takes weeks to develop and fix, the modals can't have routes without piles of jQuery hacks, and so on and ao forth

E-commerce is an example that clearly does not need SPA features. It needs great performance and SEO, not flying bells and whistles.

If a five input form takes week to fix, you have engineering problems beyond any choice of framework…

SSR and SSG+hydration are a thing though.

everything i built in the past few years only needed a generic CRUD backend, if it needed a backend at all. there is no application specific code in the backend, and the latest app i am working on is completely static as far as the backend is concerned. it could even be served locally via file://

all the application and interface logic is in the browser. this is only possible thanks to SPA.

Do you persist any data? Where does business logic reside? How do you validate inputs?

with a backend, data persistence is simply CRUD. for the backendless app, it's all in localstorage, and it can be downloaded into a file as backup. all the logic is in the browser, just like any desktop application. you should not need a server to manage personal data that is stored on your computer.

of course it is a tradeoff. if the user wanted to save their data outside the browser every few minutes then that would not be practical or if there is to much new data being generated so it doesn't fit into localstorage. i'd either need a server (even if running locally) that can save that data without user intervention or i should not use the browser as a development platform. in such cases a browser based SPA would have been the wrong choice. maybe electron, or a traditional desktop framework

Excuse me while I go to my screaming room to imagine Google Maps as an MPA.

You don’t remember MapQuest?

I do, and that's why I moved to Google Maps as soon as it came out. The performance and UX of MapQuest was terrible.

That sounds pretty cool actually.

My company does. It is a desktop level app written for the browser. And it is mostly done in Vanilla JS. No SSR since time to first load is irrelevant. They are about to sit down for an hour of solid work on a trusted platform, not buy a pair of shoes from an unknown site where waiting 500ms might make them change their mind.

Main side project of mine is a Strava-like web app to upload bike rides. It’s intended for personal use, so I don’t care how long it takes to load for random visitors arriving for the first time. I don’t care if search engines can properly load the page for content previews. I don’t care if someone’s ten year old Android device chugs on the JavaScript. I don’t care about dealing with the headache of making whatever JS library I’m using work with hydration.

This is a weird comparison. You can use PHP to power an SPA with SSR. It's not an either or.

I never said it either/or, in fact I’m using PHP to power an SPA right now. I was saying that pretending that PHP alone was sufficient (for both customers or dev speed) was silly.

My own website is a kind of hybrid SSR/SPA in PHP. Navigating pages with JS enabled (JS is entirely optional) seamlessly updates the relevant DOM nodes with an AJAX call (and uses the history API etc), but going to a page fresh is entirely PHP.

It was fun to write. Relevant code is here:

https://github.com/ldyeax/jimm.horse/blob/master/j/j.php

https://github.com/ldyeax/jimm.horse/blob/cb6a1c03504cbe6b63...

I actually uncovered a niche bug across multiple browsers with this PHP code. In at least Firefox and Edge, if a page is cached with a fetch using accept:text/json, the response will be shown from view-source of the html page you have open, even if the content is different when you fetch the page with accept:text/html

SSR usually means doing the front end JS browser render on the server, not just the more generic task of producing an initial HTML from a server.

The idea is the same code can work on front end and backend. On NextJS it will run your React on the backend but useEffects will not be called. Just the initial render is saved and piped to the browser.

Reply on news.ycombinator.com