Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SPAs Were a Mistake

gomakethings.com

Post reply on HN
Print view View original

141–150 of 637 posts

Re: SPAs Were a Mistake

#141

Post by embwbam »

Zanfa wrote: post #7

I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. For example, recently I had to deal with photo uploads on a Rails app, which works fine out of the box at first, until you want to show progress bars and uploaded previews etc. Then you add a couple of client-side…

I agree. I've been thinking about this lately, and have implemented something I think is interesting in Haskell.

https://github.com/seanhess/juniper

It's an implementation of Elm (imagine React if you're a JS dev), but all logic is executed on the server. State is passed back to the server whenever you choose to listen to an event. The view is then re-rendered and virtual dom diffed on the client. Non-interactive pages are just views. If you want them to be interactive, you add a Message an update function.

I used it on a client project and it was pretty delightful.

It probably isn't documented well enough yet to make total sense, but I think it's a step in the right direction.

Re: SPAs Were a Mistake

#143

Post by AtlasBarfed »

The issue is you need some of both for an "optimal" solution.

Unfortunately, Javascript and the basic "controller" capabilities of a web browser just aren't up to the task.

Here are your "controller" options:

1) the server is the controller

2) the web page is the controller of itself (which sucks)

When what is probably needed is:

3) a controller that lives as an extension of the browser.

Frames, for all their issues, basically enabled #3. A controller frame could manipulate the view frames, and those frames were scoped/contained web page "processes". There were issues of course, if you hard-refreshed the overall page (and the "controller" frame) it would lose state, so I don't want to say that frames were a complete solution.

Client storage is half of the equation, and that was added. Good caching infrastructure, multiple asset delivery, connection multiplexing, that seems to be working so you don't need a "big bertha" first page. Standardized DOM capabilities and the like seem to be fairly well solved, and maybe the "Javascript problem" will be solved once ... crap the thing where you have an IR bytecode so you can code in anything in a browser... well that will be solved.

Frankly this needs to be solved. Apps and app stores are a pox upon the land, and the web browser can still save us from that.

Re: SPAs Were a Mistake

#144

Post by todd3834 »

To me one of the biggest distinctions here is the overuse of the term "App". I agree that a lot of websites written as an SPA were the wrong tool for the job. There are tons of examples besides the mentioned media websites where SPA is the way to go. Most, but not all, of the applications I work on feel like desktop class applications and the traditional server side rendered approach simply would not work. This includes when I was on the iCloud Web team working on the iCloud Drive App, the Mail App and some others behind icloud.com.

I think a lot of companies that default to SPA would benefit from a very quick traditional website. However, some of the applications that I've been fortunate enough to work on would never be possible.

Re: SPAs Were a Mistake

#145

Post by kizer »

Also, more SPA framework logic needs to become part of the web platform; APIs beyond pushState, service workers, etc. You have to integrate it into the browser to really remove the confusion and the boilerplate.

Re: SPAs Were a Mistake

#146

Post by onaworkcomputer »

horsawlarway wrote: post #99
freedomben wrote: post #68

Earlier quoted context omitted.

Have you tried to use a heavily SPAed site from a slow, distant (high latency), or metered connection? A SPA that works and feels great from a big city quickly becomes unbearable when internet access isn't as ideal. There are ways to handle this nicely, but maybe 5% of devs actually think about and test that, and no PM will allocate sprint time for it.

Yes - that's literally exactly what I talked about. I can tell you - My app renders immediately in these cases, precisely because I lean heavily on a cache. I preload basically all the data a user might need at startup (prioritizing the current page) and then optimistically render from cache. I'm very familiar with these kind of situations (I have developed software designed explicitly to handle offline-only cases, a…

> I preload basically all the data a user might need at startup

This can be a great strategy when you're dealing with bounded data that's not sensitive, but it's important to recognize that this approach is often inappropriate. A web app may be allowing users to wander around terabytes of data, or it may need to make highly consistent authorization determinations before allowing a user to see specific data, or you may need to keep a highly detailed audit log of who requested what when (e.g., if the app targets healthcare or government users), which aggressive preloading would render useless.

Re: SPAs Were a Mistake

#147

Post by timr »

Zanfa wrote: post #130
ysavir wrote: post #113

Earlier quoted context omitted.

> Then you add a couple of client-side Stimulus controllers, maybe a Turbo frame here and there and it works fine, but then you get to browser navigation and you're screwed, because none of this works out of the box if somebody were to submit the form, then navigate back. Now you have to implement lifecycle handling to account for navigation and once you're done, you've basically implemented a SPA, except it's broken…

> Where in this process did you need to start adding navigation via JS? Did that functionality really require JS, or was it implemented that way just because other parts are JS, and the trend was continued? Could you have used Stimulus controllers to manage functionality on the page itself, but when it came time to navigate to a new page, just done a basic browser redirect? In my specific example, the navigation itse…

> In my specific example, the navigation itself didn't happen through JS, but you need to hook into navigation APIs to handle backing into a partially-filled form after submitting to rebuild the UI to reflect the state before the user hit submit.

I'm not sure I understand. The "conventional" solution to this is not to do it -- the reason browsers don't re-fill submitted forms is to prevent duplication. Give users the ability to post-backclick-repost and your DB will rapidly fill up with duplicate rows.

If you do need to back-navigate to a page that has been submitted (say, to edit the submission w/o requiring an edit-specific URL), you have the server re-render the form with the filled values.

If that isn't sufficient, you can always push your form state on the history stack using the history API, so even though this is a bad idea (IMO), you can still do it pretty easily without needing to resort to re-writing nav.

I hate to say it, but I feel like a lot of this stuff had server-side solutions that worked fine circa 2010, but have been almost completely forgotten.

Re: SPAs Were a Mistake

#148

Post by horsawlarway »

onaworkcomputer wrote: post #133
horsawlarway wrote: post #103

Earlier quoted context omitted.

> And just as often you can't know in advance what data will be requested by the user. This is a cop-out. Storage is insanely cheap, and abundantly available on most machines. Plus the browsers will usually give it to you. Can I know precisely what series of pages this user might hit? Nope. Can I load ALL the data this user might need to read? Probably.

> Can I load ALL the data this user might need to read? Probably. You can do that with HTTP/2 server push on a multi-page app, too. The main difference is that with an SPA, you get to reinvent it all yourself.

Yeah - there's a trade off here.

Server push gets you closer with a traditional app, but it doesn't really solve the problem (or rather - yes, you get to reinvent it yourself, but you can do it better, with the specific context of your app)

Basically - My argument is that developers tend to treat SPAs the same as "the website" but with a bigger js framework. And that's the wrong mindset.

Instead, you should think of the first load as an install of a native application. You want to push absolutely everything, not just the next couple of resources you might need (like imgs/css). Ideally you push the current page first, and do the rest in the background while the user can interact with the current page, since you're almost never CPU bound on terrible connections anyways.

You'll get one additional load at login (because now I'm pushing all relevant user data), but after that... basically everything is rendered from cache (including optimistic cache updates based on what the user might be adding/updating).

After that... unless you log out or have cache evicted, you're going to see immediate response times, even while offline.

---

This isn't easy, and most teams don't bother, so if the comment is "If you're treating an SPA like a traditional page - don't bother" then I tend to agree.

but an SPA genuinely opens up options for bad connections that otherwise just don't exist (or are so bad people won't use them)

Re: SPAs Were a Mistake

#149

Post by rosenjcb »

mattwad wrote: post #73
Zanfa wrote: post #7

I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. For example, recently I had to deal with photo uploads on a Rails app, which works fine out of the box at first, until you want to show progress bars and uploaded previews etc. Then you add a couple of client-side…

I feel like most people that hate SPAs never have to deal with this type of thing, or even only have to work on the backend. They just don't get it. Of course, if you're using a SPA for a static website, you're also doing it wrong but that doesn't mean SPA itself is a bad thing.

I agree. These people hating on SPAs are mostly not frontend developers. They're backend devs that think returning an HTML page is all you need to do. Modern websites are very complex.

Re: SPAs Were a Mistake

#150

Post by mdoms »

Zanfa wrote: post #7

I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. For example, recently I had to deal with photo uploads on a Rails app, which works fine out of the box at first, until you want to show progress bars and uploaded previews etc. Then you add a couple of client-side…

At the risk of a pile on, this is what jQuery was brilliant for. And frankly the native browser APIs have caught up enough that scenarios like what you want to achieve are simple to implement with just a script tag and a sprinkling of JS. I don't know what "Stimulus controllers" or "Turbo frames" are but they don't sound necessary.
Post reply on HN