Live data from Hacker News

If Not SPAs, What?

macwright.com

31–40 of 456 posts

Re: If Not SPAs, What?

#31

Our app ( https://domestica.app/login ) is a pretty good (IMO) example of a blazing fast SPA. It uses Mithril and copious amounts of chunking to make the bundle size extremely small.

This is one of the worst SPAs I've ever seen, simply because it causes an infinite redirect loop when clicking the back button and/or tampers with the browser history to make using the back button impossible.

Re: If Not SPAs, What?

#32

Earlier quoted context omitted.

On my browser (Firefox, on OSX) it loads /loading then /login. When I go back, that takes me back to /loading, which forwards me to /login again immediately. Going back requires holding down the back button so I can skip that history record. Illustrated: https://imgur.com/a/zFaGw4a (Quite a few sites screw this up. It's very annoying.)

This is great, thank you for sharing. We primarily test in Chrome which doesn't seem to display this for whatever reason. Should be an easy fix to remove the history for the loading page.

For what it's worth, the same happens in my Chrome.

(Maybe you're logged in and don't get the behavior because of that?)

Re: If Not SPAs, What?

#33

The future is Next.js with SSR first and selective client side hydration. Ignore the jamstack, it's going to lose and go away. Requiring a JS download first to show a dynamic site is a recipe for bad performance.

You can use much of the J and the A during the SSG stage that then delivers the M to the user. And very user-specific and/or dynamic things will have to remain some sort of generated shell and the content fetched on the client anyway.

JAM has other problems. I don't think that's one.

Re: If Not SPAs, What?

#34

Maybe this is more suited to stackoverflow but, how do you load with turbolinks when the two pages use different assets? Let's say each page have different js script tags.

Turbolinks gives you a few options, depending on if you want the script evaluated once or each time that page is loaded:

https://github.com/turbolinks/turbolinks#working-with-script...

Re: If Not SPAs, What?

#35
post #12

My argument for SPAs rests on the completely subjective yet I feel incredibly powerful impact of latency. When anything takes more than 50ms to react, it becomes mentally jarring to the user. Whether it is typing in an SSH session, clicking a menu with a mouse, auto-completing a box, etc - all these things generate a completely different human response and relationship with the application if they get below that thre…

That's not possible for SPAs outside localhost. Every single SPA i know is clunky, including gmail which is probably one of the most barebones. The lack of visual indication that something is happening or downloading alone is infuriating with SPAs. Most of them reinvent the browser in a very poor substitute that invariably fails to both be practical , and to mimic a native mobile app (i think the latter is the reason for so many SPAs.

Almost never had a problem with HN either

Re: If Not SPAs, What?

#36
post #12

My argument for SPAs rests on the completely subjective yet I feel incredibly powerful impact of latency. When anything takes more than 50ms to react, it becomes mentally jarring to the user. Whether it is typing in an SSH session, clicking a menu with a mouse, auto-completing a box, etc - all these things generate a completely different human response and relationship with the application if they get below that thre…

I thought 100ms was basically the threshold for feeling "instant"?

But totally agree with your position on this in general!

Re: If Not SPAs, What?

#37
I've always felt this problem from the first time I touched Angular. It was just so much more complex and fragile without actually a lot of benefit unless you wanted to make a really interactive async application like Google Docs or Facebook Chat.

When SPA's became the norm and even static web pages needed to be build with React, developing became more and more inefficient. I saw whole teams struggling to build simple applications and wasting months of time, while these used to be developed within a couple of weeks with just 1 or 2 developers, on proven server side opinioated frameworks. But that was no longer according to best practices and industry standards. Everything needed to be SPA, micro services, distributed databases, Kubernetes etc. These components and layers needed to be glued together by trial and error.

I am really happy that common sense is starting to return and more developers are starting to realize that integrated end to end frameworks are very useful for a lot of real life application development scenario's.

Re: If Not SPAs, What?

#38
post #19

The missing link, IMHO, is the lack of client side SQL and a sync mechanism. IndexDB is okay, but nobody is going to use it server side. So you kind of always have to end up writing things twice.

You want a web browser talking directly to an RDBMS of some kind?

Re: If Not SPAs, What?

#39
post #12

My argument for SPAs rests on the completely subjective yet I feel incredibly powerful impact of latency. When anything takes more than 50ms to react, it becomes mentally jarring to the user. Whether it is typing in an SSH session, clicking a menu with a mouse, auto-completing a box, etc - all these things generate a completely different human response and relationship with the application if they get below that thre…

Displaying a loading spinner in under 50ms while waiting for a 500ms request to complete doesn't necessarily build a strong relationship.

SPAs can start off with the good intention of being low-latency and responsive. But when you're backed by a web server, you still have to account for it though optimistic rendering, prefetching, and loading states. Getting it right can be an excellent UX, but it's easy to get very wrong.

Re: If Not SPAs, What?

#40
post #19

The missing link, IMHO, is the lack of client side SQL and a sync mechanism. IndexDB is okay, but nobody is going to use it server side. So you kind of always have to end up writing things twice.

You want a web browser talking directly to an RDBMS of some kind?

Yes, like we had with WebSQL until it was deprecated. Basically a SQLite db per site.
Post reply on HN