Hacker News Reader

Comment by capableweb | Hacker News Reader

As is common when people rant about SPAs, your dislike (at least as written here) is not actually about SPAs but other things

> Works terrible in bad networks

Yes, software traditionally works shitty under bad network conditions unless the developer actively tests under bad network conditions or has previous experience of handling bad network conditions. This is as much true for anything developed ever that touches a network.

> the shifting of images

This is simply developers missing to add width and height attributes to their <img/> elements. This has been happening since the dawn of the <img/> element and is unlikely to disappear. Also has nothing to do with SPAs, same happens with server-rendered HTML.

View on HN

> unless the developer actively tests under bad network conditions > This is simply developers missing

That's the whole thing. SPA = state. It requires a lot of dev time to properly handle everything. With stateless applications, you can simply refresh your browser.

The sluggishness is not only because of bad network conditions, but it's multiplied by the huge application that has to be sent over the network, application initialization, and the many subsequent network requests.

> The sluggishness is not only because of bad network conditions, but it's multiplied by the huge application that has to be sent over the network, application initialization, and the many subsequent network requests.

A "huge" application can be broken up with code splitting/dynamic imports. Initialisation can be seeded with serverside data or saved in browser storage between pages.

The only semi-unavoidable part is the "subsequent network requests", but even these can be sped up with caching, batching, etc.

> It requires a lot of dev time to properly handle everything.

But yeah, these things take effort

The network requests could be done with more intelligent apis

But if you take everything into account, you can also develop a really good native app.

This is not reality.

>Yes, software traditionally works shitty under bad network conditions

not everything is equally affected by bad network conditions, SPAs generally are very badly affected by bad network conditions, indeed what is a bad network condition for an SPA might be acceptable for a traditional static page.

SPAs can be built to work well offline. I've written them myself. There is nothing inherent in an SPA that make it poor at this, quite the opposite. SPAs have excellent tooling for offline use.

A SPA's network dependency or robustness totally depends on the product's design. Some types of applications lend well to offline first (anything where the user owns their content/data, todo, notes, documents, pictures, etc). Others are much more dependent on fresh data. Which pretty much means anything big enough it's unreasonable to replicate it to the device.

I'm a fan of "offline first" design and have been a proponent at various companies. To the point where I can build the feature in at very little additional cost if it is considered and decided in the design phase. Bolt-ons patterns are messy.

However, the reality is that very few customers see this as a significant advantage. Which means that it doesn't really translate to market success. If budget is the #1 priority I can't in good conscience advocate for offline first unless it's going to offer a significant win for the company somewhere.

I’m asking this from a genuine place of curiosity, because last time I checked a few years ago the answer was “terrible”. Has the “save a file locally and load it again later” story for SPAs improved any?

There is no universal local file system API, so "terrible" might be a reasonable description of this.

There is a Chrome-only local file system API.

Generally SPAs are limited to browser provided storage like IndexedDB.

I have implemented plenty of SPA (for years) that use the pattern of A) allow the user to download their current state as JSON/EDN and then B) allow the user to upload a new state from JSON/EDN file and continue from where they last downloaded their state.

This has been easy to implement for as long as I can remember, so not sure why'd you say it's terrible. What stopped you previous times?

Ok, so that’s kind of what I figured was the current state of things. Compared to being able to hit “Save” and have a local copy updated, that’s a pretty subpar workflow. I get why it’s like that (preventing a sandboxed website from being about to update files on the local filesystem) but...

Why do you write <img/> in authoritative tone? It's not 2000 anymore where we pretended XHTML or polyglot HTML is a thing. It's particularly odd to see that old cargo cult idiom (or, worse, with additional random spaces) used in a post lecturing users about HTML5-era SPA supremacy.

I don't know what you mean, self-closing tags are part of the HTML (5) standard: https://html.spec.whatwg.org/#self-closing-flag

? What's wrong with XHTML? <img /> is clearer than <img> for anyone familiar with XML, and XHTML documents are easier to parse (e.g. can be processed with XSLT stylesheets).

Nothing wrong with XHTML per se (did an internal site using XSLT in early/mid 2000s), but XML/XHTML has been on the way out for the better part of this millenium on the web at least. If you're developing web content and/or browser apps, you should know HTML IMO, and XML is the least of your concerns. Not looking forward to apps mixing XSLT and JavaScript ;)

Can't stand "<bla />" though with that pointless/clueless space. The only place where I've encountered these are older JSP, FreeMarker, or Thymeleaf/Spring MVC apps (ugh).

JSX (React's default markup language) expects all tags to be closed, and self closing tags are valid. If you spend a significant time writing React apps (with JSX) then it becomes pretty second nature to write self closing tags. It's not exactly XHTML (I can't think of any other of XHTML's idioms it uses).

Reply on news.ycombinator.com