[HN Gopher] Defaulting on Single Page Applications
___________________________________________________________________
Defaulting on Single Page Applications
Author : 0xblinq
Score : 46 points
Date : 2023-03-27 20:47 UTC (2 hours ago)
(HTM) web link (www.zachleat.com)
(TXT) w3m dump (www.zachleat.com)
| pqdbr wrote:
| This article was the first time I learned about
| https://developer.chrome.com/docs/web-platform/view-transiti....
|
| It looks really great, and I think Rails Hotwired / Turbo could
| really benefit from this API.
|
| Of course, someone beat me to it:
| https://dev.to/nejremeslnici/how-to-use-view-transitions-in-...
| kerblang wrote:
| Nobody ever talks about the monolithic all-in-one framework
| upgrade? You really haven't come to terms with SPA until you've
| done the all-in-one framework upgrade, man. It's like running
| thru a hailstorm of razor blades
| benatkin wrote:
| > You can't JavaScript your way out of an excess-JavaScript
| problem. These large JavaScript bundles are costly to site
| performance.
|
| I was gonna say:
|
| "This is what some Hugo fans might say, but 11ty and Astro
| suggest otherwise."
|
| Then I saw the author of the post is the author of 11ty.
|
| Still, the middle ground is being pursued by Svelte and Fresh. I
| prefer something less frameworky though.
| nfRfqX5n wrote:
| > Inclusive and robust by default, Energy-efficiency, Privacy-
| focused I imagine trying to use these reasons with executives and
| getting laughed out of the room
| slaymaker1907 wrote:
| I think the view transitions API will be good, but it's currently
| only available for Chromium browsers so it is not really a
| competitor to SPAs for the time being. I'm also kind of opposed
| to really broad generalizations like this since what is most
| effective currently kind of depends on what you're building. A
| calculator built as an MPA would be kind of ridiculous.
| Ralfp wrote:
| I've liked the transitions demo from Chrome guys, but it has
| barely any support yet.
| endisneigh wrote:
| The SPA vs server side rendered page debate is so exhausted at
| this point. The tech is such that they're nearly equivalent if
| you have a good team that understands the appropriate technology.
|
| You can have an SPA with a proper router that respects page
| history, loads html fragments from a server, remembers positions
| on reload, etc.
|
| You can also have a server side rendered page sprinkled with
| JavaScript and use web sockets to create dom element level
| transitions and interactivity
|
| The "MPA" described in the article has always been possible in a
| "SPA." It's more about the UX of your app than anything else
| the_gipsy wrote:
| > You can have an SPA with a proper router that respects page
| history, loads html fragments from a server, remembers
| positions on reload, etc.
|
| In theory.
| ec109685 wrote:
| Your second paragraph essentially is creating a little mini
| browser, and you have to make sure to get every detail right or
| you're back to the uncanny valley of SPA web _pages_.
| Performance can even be worse with SPA "page" navigation if
| multiple round trips are needed for the data on the next page.
|
| SPA's should be used web _apps_ (think slack or Asana), and
| stick to sever rendered for web pages.
| EGreg wrote:
| Is this an SPA?
|
| https://intercoin.app
| slaymaker1907 wrote:
| I think you've highlighted a big problem with SPAs in that
| they can encourage multiple API calls per user action. IMO,
| you should probably have a single endpoint per thing a user
| might do that might combine several conceptual APIs. i.e., if
| you have an API to add something to a list, have that API
| also return the current list.
| simonw wrote:
| How do you make sure your SPAs work well with screen readers?
| endisneigh wrote:
| More or less the same as a regular page - use aria labels,
| update names and titles of elements, make sure the focus is
| set correctly, etc.
| taeric wrote:
| And try to be frugal on the tags you make.
|
| Component design is the enemy here. Just take a peak at the
| nav elements in many designs and see how embedded the divs
| go.
| sebazzz wrote:
| Are you referring to styled-components and the like? What
| is exactly the problem with that?*
|
| * except media queries, those seem hard
| zdragnar wrote:
| Many prebuilt component libraries design for maintenance
| and all possible uses over being frugal. The actual
| markup can get really ugly with i.e. MUI.
|
| When you put in the effort to build the components
| yourself, you aren't trying to be everything for
| everyone, so you get to skip a lot of the cruft.
| taeric wrote:
| Exactly this. Is a large reason to not try to build the
| most general components, either. Build what you need,
| where you can.
|
| That all said, I also have to ack that the libraries are
| going to be hard to beat for speed of delivery. :(
| taeric wrote:
| The idea of components is fine. I should have been clear,
| there. The problem typically comes from the authoring
| tools. To have the hooks necessary to put the decoration
| that we want, in html, they typically add a ton of div
| elements. When, realistically, you could almost certainly
| get what you want with very minimal markup.
|
| And being fair, I'm sure this has gotten a bit better in
| recent years. But the Rube Goldberg efforts people would
| put in to get the "flow" of the browser to automatically
| place things in locations that were easily calculated is
| frustrating.
| chatmasta wrote:
| Screen readers don't read the hierarchy of elements back
| to you. They find the text that renders inside the
| elements and read it out loud to you. And for navigating
| between elements, the level of nesting is much less
| relevant than having the correct aria-role assigned to
| each element that contains an interactive component.
| fks wrote:
| An incredible example of what's suddenly possible with the View
| Transition API:
| https://twitter.com/charca/status/1637832314364497920 (Built with
| Astro)
| thrill wrote:
| Quit using these ginormous frameworks and libraries. Vanilla
| Javascript is all you need.
| graypegg wrote:
| The organizational and maintainability benefits you get from
| using something like react far out weigh the actually quite
| minor file size bump. That is the least of your worries.
|
| source: myself; someone who moved to working on a project
| entirely written in vanilla JS... which has just become its own
| bespoke framework.
| WillPostForFood wrote:
| I agree, but note that we are talking about a benefit that
| accrues to the developer, not the user.
| slaymaker1907 wrote:
| It also benefits users in that you can implement more
| features and fix more bugs in less time. Performance is a
| feature and what that means is that while you can't just
| completely ignore it, it's not always the highest priority.
| simonw wrote:
| I think it's worth calling out accessibility directly, in
| particular screen reader compatibility.
|
| I have yet to find a great guide to making SPAs work well with
| screen readers that goes beyond "read the ARIA spec" - but the
| ARIA spec isn't actually that useful for understanding the nuts
| and bolts of how you should build things so that e.g. screen
| readers know when the SPA has navigated to a new page, or loaded
| fresh content in a smaller page region.
|
| My understanding is that MPAs are, by default, massively more
| accessible than SPAs. But my experience is that SPA authors
| rarely seem to indicate that they care.
___________________________________________________________________
(page generated 2023-03-27 23:00 UTC)