[HN Gopher] If Not SPAs, What?
___________________________________________________________________
If Not SPAs, What?
Author : todsacerdoti
Score : 53 points
Date : 2020-10-28 16:27 UTC (6 hours ago)
(HTM) web link (macwright.com)
(TXT) w3m dump (macwright.com)
| stevebmark wrote:
| 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.
| Griffinsauce wrote:
| Isn't SSR (or even better SSG) the M in JAM? It's a marketing
| term anyway and it doesn't really need to "lose", we can just
| talk about the technologies instead.
|
| Next.js gives you a great toolbag to choose from for each
| challenge, it's definitely going to stay around and keep
| growing like crazy.
| k__ wrote:
| I thought so too.
|
| JAMStack is Next.js with SSG+CSR.
| eyelidlessness wrote:
| I would also prefer something like Next.js with partial
| hydration. But what I want in that is probably a much bigger
| ask: I want the partial hydration to be performed automatically
| with static analysis. Something like Svelte (real DOM codegen,
| no need to ship a library to the browser) would be especially
| nice, but I don't want to give up JSX. In the end, this is
| probably well outside the scope of a framework coupled directly
| with React, and I suspect that if I want it badly enough it's
| something I'll need to build myself.
| gherkinnn wrote:
| 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.
| ng12 wrote:
| If you can do server side great: do it. The difficulty is
| accurately predicting how much JavaScript you'll end up writing.
| If your client-side JavaScript is comparable in complexity to
| your SSR you'll eventually end up with the worst of both worlds.
| jimbob45 wrote:
| An actual app? I'd love for container-sandboxed native apps to
| make their "comeback".
| zmmmmm wrote:
| 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 threshold of latency. In my
| experience, it's nearly impossible to get non-SPAs across that
| threshold for large sections of their functionality, while for
| SPAs it becomes more or less the default. So people can make all
| the technical arguments they want, but to me the human factor of
| that subjective feeling trumps it all.
| cblconfederate wrote:
| 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
| candiddevmike wrote:
| 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.
| vmception wrote:
| while breaking my back button
|
| nothing to do with the SPA of course
| candiddevmike wrote:
| Which part breaks your back button?
| vmception wrote:
| on ios safari when I click that link, and then swipe back
| or press back, instead of showing me this hackernews thread
| it shows me that site again
| ceejayoz wrote:
| 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.)
| candiddevmike wrote:
| 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.
| ceejayoz wrote:
| 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?)
| sebmellen wrote:
| 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.
| dnautics wrote:
| > they also wholeheartedly embrace the thing everyone tries to
| avoid: mutable state on the server.
|
| For most apps in Phoenix LiveView, it's probably best to think of
| this as a "relatively smart caching layer". Keeping state on the
| client invokes distributed state concens anyways, and in the case
| of the Phoenix, at least the VM is well-equipped with the
| relevant primitives to make distributed state easy, especially.
| Basically the only cost you have to pay is if latency is a big
| deal, you are making a trip back and forth to the server, which
| could be 100s of milliseconds or more in bad situations... Or
| even really bad situations, like driving under a tunnel, or being
| in some stretches of subway.
| merb wrote:
| well there is also React.NET which actually can use razor pages
| to include react components. pretty neat. also there is blazor
| which works with websockets and pushes html to clients.
| ckorhonen wrote:
| I used Turbolinks for the first time on a new Rails app about 2
| years ago and was floored by the impact - it felt like a SPA in
| terms of no page loads and overall speed.
|
| I'm convinced that this is the solution for the majority of use-
| cases, combined with selective usage of either React components
| or something like Stimulus where you need more sophisticated UI
| components.
| ForHackernews wrote:
| Is there an equivalent of Turbolinks for something like Django?
| Or even for MVC PHP apps?
| deefour wrote:
| Turbolinks isn't specific to rails.
| treis wrote:
| 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.
| dfabulich wrote:
| IMO, TurboLinks + service workers are the way to go.
|
| Not many people know this, but a service worker (previously
| called "local server") allows you to run a little web server in
| the user's browser that intercepts requests to your own web site.
| (There's no open IP port.)
|
| The service-worker web server can proxy requests to the remote
| server, and even build/store entire pages on the client side,
| enabling offline support. Service workers also have access to a
| local database, IndexedDB, running in the user's browser.
|
| You can build a _very_ fast web experience this way. You can
| easily cache individual pieces of a web page and glue them all
| together.
|
| For example, you can easily implement server-side includes
| https://en.wikipedia.org/wiki/Server_Side_Includes or edge-side
| includes https://en.wikipedia.org/wiki/Edge_Side_Includes but
| running on a server that's running _on the client._
| firefoxd wrote:
| 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.
| kej wrote:
| 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...
| EGreg wrote:
| I am going to advocate the other way:
|
| https://qbix.com/blog/2020/01/02/the-case-for-building-clien...
| [deleted]
| randompwd wrote:
| The fan on my thin laptop are nearly always on when browsing the
| web. Something that wasnt the case even 3 years ago.
|
| Too much JS being executed on every page.
| kqvamxurcagg wrote:
| Having mostly used Angular and React with APIs, I recently wrote
| a small app with server-side templating and a very small amount
| of jquery. It was an absolute joy. Especially with webpack it
| feels like the front-end has become needlessly complex and I'm
| not sure it has improved quality for users.
| k__ wrote:
| Isn't Next.js (and in turn React, on which Next is built) the
| answer to that question?
|
| It can do client side rendering, server side rendering, and
| static site genration.
| xiaomai wrote:
| I think Phoenix Live View is maybe the most compelling story
| around this
| (https://github.com/phoenixframework/phoenix_live_view). I'm
| moving a side-project from React/SPA to Phoenix live view and
| it's kind of amazing to get the dev ergonomics of a server-
| rendered page with the UX benefits of a SPA.
|
| This course is a pretty great intro:
| https://pragmaticstudio.com/phoenix-liveview
| basch wrote:
| as a user, this is the kind of experience I want on the web.
| any spa like page should always degrade back to web standards.
| and it should be lightening fast. and not spin my cpu fan or
| warm my desk.
| brightball wrote:
| Agree completely. My only concern is that so many imitations
| are attempting to pop up in other languages and you just can't
| do it as effectively.
|
| There are so many tradeoffs present that happen to result in
| the necessary set of functionality to do this efficiently that
| aren't easily present outside of the BEAM.
___________________________________________________________________
(page generated 2020-10-28 23:00 UTC)