←back to thread

The myth that you can’t build interactive web apps except as single page app

(htmx.org)
260 points gherkinnn | 3 comments | 17 Nov 24 13:44 UTC | HN request time: 0.421s | source
Show context
mh-cx ◴[17 Nov 24 15:05 UTC] No.42164537[source]▶
I wonder why the article doesn't mention utilizing the browser cache for your static CSS and JS assets instead of introducing a service worker as first measure.

Few years ago I built a shopping site MPA this way and the page transitions were almost not noticable.

replies(7): >>42164573 #>>42164584 #>>42164743 #>>42168597 #>>42169927 #>>42170948 #>>42173755 #
palsecam ◴[17 Nov 24 15:42 UTC] No.42164743[source]▶
Especially since the `stale-while-revalidate` and `immutable` Cache-Control directives are well supported nowadays.

Stale-while-revalidate: see https://web.dev/articles/stale-while-revalidate & https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca...

Immutable: https://datatracker.ietf.org/doc/html/rfc8246 & https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca...

And if using a CDN, `s-maxage` (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca...) is quite useful. Set it to a long time, and purge the CDN cache on deploy.

replies(1): >>42166681 #
exceptione ◴[17 Nov 24 20:02 UTC] No.42166681[source]▶

  Immutable
is what you need. Crazy enough, Chrome has not implemented it. Bug open since 2016: https://issues.chromium.org/issues/41253661

------------------

EDIT: appears that Chrome suddenly had decided in 2017 to not validate at all on reload anymore, after Facebook had complained to Chrome devs about Chrome being more a drag on their servers compared to other browsers.

replies(1): >>42166914 #
palsecam ◴[17 Nov 24 20:27 UTC] No.42166914[source]▶
To be fair, it’s because Chrome handling of a soft reload is different from Firefox or Safari, and does not lead to revalidating (let alone refetching) assets files. See https://blog.chromium.org/2017/01/reload-reloaded-faster-and...

Quoting https://engineering.fb.com/2017/01/26/web/this-browser-tweak...:

> We began to discuss changing the behavior of the reload button with the Chrome team. […] we proposed a compromise where resources with a long max-age would never get revalidated, but that for resources with a shorter max-age the old behavior would apply. The Chrome team thought about this and decided to apply the change for all cached resources, not just the long-lived ones.

> Firefox was quick in implementing the cache-control: immutable change and rolled it out just around when Chrome was fully launching their final fixes to reload.

> Chrome and Firefox’s measures have effectively eliminated revalidation requests to us from modern version of those browsers.

replies(1): >>42166966 #
exceptione ◴[17 Nov 24 20:32 UTC] No.42166966[source]▶
I just wrote my edit before I saw yours. Must have been a cache problem :)
replies(1): >>42167004 #
palsecam ◴[17 Nov 24 20:37 UTC] No.42167004[source]▶
“There are only two hard things in Computer Science: cache invalidation and naming things.” — Phil Karlton (cf. https://www.Karlton.org/2017/12/naming-things-hard/ or https://MartinFowler.com/bliki/TwoHardThings.html)

;-)

replies(1): >>42167475 #
traverseda ◴[17 Nov 24 21:29 UTC] No.42167475[source]▶
And off by one errors
replies(2): >>42168340 #>>42168349 #
1. ohthatsnotright ◴[17 Nov 24 23:38 UTC] No.42168340[source]▶
And dates and times And currency
replies(2): >>42169262 #>>42172208 #
2. yndoendo ◴[18 Nov 24 02:40 UTC] No.42169262[source]▶
Manage date and time in UTC/Zulu. Append the time zone if that meta is needed and store both the client and server for backend. That way you don't have to deal with time travel and can handle time shifts.

I would say that concurrency is a caching issue once proper locking has been set.

3. zbentley ◴[18 Nov 24 13:42 UTC] No.42172208[source]▶
And ce conditions rainduced by concurrency.