Live data from Hacker News

SPAs Are Dead?

leastprivilege.com

91–100 of 118 posts

Re: SPAs Are Dead?

#91
I did web dev professionally for seven years until I started writing Swift a year ago. The learning curve for native iOS development is a little steep because Apple doesn't write adequate documentation, but resulting application delivers a superb user experience with extremely low power consumption.

Web apps and APIs are not the answer to the biggest problem we have today, which is the lack of open alternatives to Apple's App Store and Google's Play Store. While it is true that Apple cripples their browser to make web apps second-class citizens, browsers will always add a layer of indirection. Even if the performance loss were made negligible, it would encourage the creation of user interfaces that target the lowest common denominator available on all platforms.

In my opinion, the best way to fix this situation in the long-run is to design completely open mobile devices. I'd love to replace my iPhone and iPad with devices that are repairable and run a mobile-optimized version of Haiku. We're not as far off from that as you might think; metal 3D printers such as the Markforged Metal X will make it easier and cheaper than ever to make cases that turn a pile of parts into a working phone.

What does this have to do with web apps? Well, if you're spending all your time keeping up with web development, perhaps it's time to learn some new skills and push things forward in a different direction.

Re: SPAs Are Dead?

#92

Earlier quoted context omitted.

You can also store a JWT in localStorage and require an additional secure signature for it within a cookie (http-only). Best of both worlds.

If doing that, why not go full-mode and store JWT in cookie with http-only flag?

There are good uses for page content to know what's in the JWT (display username, show logged-in status, etc). Cookies also have stricter size limits. Additionally, cookies by themselves are uniquely vulnerable to CSRF, although I guess these days using SameSite property correctly mitigates that.

Re: SPAs Are Dead?

#93
post #2

Maybe I'm missing something, but this seems like a very narrow definition of SPA. A SPA can just sit on a different path from the API server and cross-site cookies aren't a problem. For instance, www.example.com/app and www.example.com/api

Indeed, the intended audience seems to developers of SPAs which only use third-party authentication and data. The article even mentions "pretty much every authentication protocol – like SAML, WS-Fed and OpenID Connect." I'm obviously not in this intended audience, because in my experience this is an extremely niche SPA use case. I can't even think of a website that does this or would want to do this. Maybe if you want to build a third-party web client for something like Gmail or Apple Music?

Re: SPAs Are Dead?

#94
post #90
post #68

Earlier quoted context omitted.

> I want my history, link copying, bookmarking, middle-clicks and Ctrl/Cmd-clicks to work as intended. In a well designed SPA, these will all work.

It's like with C or C++. Most people that do write it shouldn't, because they are not good enough or the process is broken and they will shoot their leg. SPAs are the same way, because you have to implement all those normal website things again by yourself. There will be casualties.

Exactly, the problem is that you don’t get these baseline features for free. SPA, in my experience, is a lot of people poorly reimplementing the wheel.

Re: SPAs Are Dead?

#95
post #79

Earlier quoted context omitted.

If you have a history with multiple pages each with their own URI then it is not a SPA. SPA means "single page application".

You’re getting a downvote treatment but I kinda agree with you that SPA shouldn’t change history. But also, that was like the first versions of SPAs. The name stuck around (hello AJAX) while the underlying infrastructure and mechanisms great improved.

Single page load is the definition. The page never reloads. Even the first SPAs would uses url hashes to change the url before pushState was adopted.

Re: SPAs Are Dead?

#96
post #85
post #70

Earlier quoted context omitted.

They work perfectly fine under a SPA. SPA pushes history which lets the back button work and you can bookmark the URls. They have real URLs so you can create tabs. Go look at https://www.target.com/ and see if you can tell difference between SPA and regular web page except for the speed aspect.

Long ago Ruby on rails had a feature that sort of cached all links on the current page to make navigating to them faster. What happened to that? Would that not provide the same speed benefit? I'm ignoring the inefficient use of data here, ofc.

It's still a thing: https://turbo.hotwire.dev/

HTML fragments are not all that less efficient than JSON on the wire, and they are much more CPU efficient for low-powered client devices.

Re: SPAs Are Dead?

#97

Earlier quoted context omitted.

> I want my history, link copying, bookmarking, middle-clicks and Ctrl/Cmd-clicks to work as intended. Solutions for all of those for SPAs have been around for quite a while. Whether any particular SPA uses them or not is, of course, variable, but there is nothing inherent to SPAs that prevents them from working.

In fact, in every modern JavaScript framework or rendering library I'm aware of, you have to go out of your way to make links that don't work with middle-click or page navigations that don't work with history and bookmarks.

I should start noting all those bugs, because I see them almost every day. But to be honest even "regular" web sites are guilty, especially with ctrl/cmd-click.

Re: SPAs Are Dead?

#98
post #85
post #70

Earlier quoted context omitted.

They work perfectly fine under a SPA. SPA pushes history which lets the back button work and you can bookmark the URls. They have real URLs so you can create tabs. Go look at https://www.target.com/ and see if you can tell difference between SPA and regular web page except for the speed aspect.

Long ago Ruby on rails had a feature that sort of cached all links on the current page to make navigating to them faster. What happened to that? Would that not provide the same speed benefit? I'm ignoring the inefficient use of data here, ofc.

I think you're referring to TurboLinks. TurboLinks is still around. Building on that technology and moving towards HTML over socket is https://hotwire.dev/

Re: SPAs Are Dead?

#99
post #85
post #70

Earlier quoted context omitted.

They work perfectly fine under a SPA. SPA pushes history which lets the back button work and you can bookmark the URls. They have real URLs so you can create tabs. Go look at https://www.target.com/ and see if you can tell difference between SPA and regular web page except for the speed aspect.

Long ago Ruby on rails had a feature that sort of cached all links on the current page to make navigating to them faster. What happened to that? Would that not provide the same speed benefit? I'm ignoring the inefficient use of data here, ofc.

That would be TurboLinks. It's going strong, and has seen significant improvements over time. Especially when paired with something like Stimulus and/or Reflex and/or Hotwire, you can make some _very_ snappy feeling server-side rendered HTML. At this point, I won't even consider making SPAs for anything unless the product owner has an incredibly compelling reason.

If you're curious what the modern state of server-side HTML Rails can be from the user's perspective, head over to hey.com and sign up for their free trial.

Re: SPAs Are Dead?

#100
post #9

I prefer using cookies, but most SPAs actually use JWTs.

Cookies and JWTs are not alternatives to each other. You can store a JWT in a cookie.

True, although in the vast majority of cases JWTs are sent via HTTP headers (specially if you're making requests to multiple domains).
Post reply on HN