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

Immutable Web Apps

immutablewebapps.org

Post reply on HN
Print view View original

61–66 of 66 posts

Re: Immutable Web Apps

#61

Post by nmca »

knubie wrote: post #38
diggan wrote: post #23

The proposed solution in "index.html contains fully-qualified references to the static assets" seems backwards. Changing resources from `./main.js` to ` https://assets.myapp.com/apps/1.0.2/main.js` makes the opposite of an "immutable application" in that loading the script will effectively be a side-effect and depending on other factors than just the index.html link with it's child directories. Overall it seems like…

It's immutable in the sense that ` `" rel="nofollow">https://assets.myapp.com/apps/1.0.2/main.js">` will always load the same resource whenever the page is loaded (especially if it's cached indefinitely). Where as ` ` could potentially load different versions of `main.js` depending on the release version.

And particularly, if you always host the old versions then you can rollback by updating index.html - rollbacks are otherwise hard when you start thinking about caches.

Re: Immutable Web Apps

#62

Post by pmarreck »

Immutability (and the related idea of forming things in a declarative instead of procedural fashion) is a good idea generally and prevents vast swaths of possible bugs from ever occurring.

SPA's are a bad idea because 1) it greatly complicates good unit testing and requires gross things like headless browser drivers in your integration test suite, 2) it does not degrade gracefully to HTML (such as on assisted devices) 3) javascript is, at best these days, a sunny wasteland of dependency hell.

Re: Immutable Web Apps

#63

Post by marcosdumay »

kodablah wrote: post #54
Twisol wrote: post #49

Earlier quoted context omitted.

> Can you clarify, if I add a JS line to my file, I should version that JS file as a never-ever-changing static asset to be cached? It only has to be cached as long as there exist deployments that need to reference it. But as long as there exist references to it, the content at the referenced address should not change. So yes, you should version that file -- or that deployment as a whole, if you'd rather not get that…

I understand the general note about caches not lasting forever, no longer referenced files, etc. This response skipped over the most important question "And if I make a change daily (or more frequently w/ CD), have 365 of those versions (i.e. maybe versioned as date or hash)?". Simply asked, is every generated JS file a static asset? Must the (indefinite) cache headers be present for every static asset be returned? S…

> And if I make a change daily (or more frequently w/ CD), have 365 of those versions (i.e. maybe versioned as date or hash)?

It's a good practice for any web application. You place huge caching times for your assets, and make their URLs unique.

At the backend, you either have a compilation step that adds the unique marker (a hash is more common) to your links or you have the backend add it at runtime.

Re: Immutable Web Apps

#64

Post by jamesgeck0 »

pmarreck wrote: post #62

Immutability (and the related idea of forming things in a declarative instead of procedural fashion) is a good idea generally and prevents vast swaths of possible bugs from ever occurring. SPA's are a bad idea because 1) it greatly complicates good unit testing and requires gross things like headless browser drivers in your integration test suite, 2) it does not degrade gracefully to HTML (such as on assisted devices…

1) Writing unit tests for a SPA doesn't have to be much more complicated than unit testing a server-side application. Integration testing is a bit hairy, but that's generally the case in many technology stacks.

2) SPAs don't have to be pure HTML to be compatible with assistive technology.

Re: Immutable Web Apps

#65

Post by erichurkman »

Twisol wrote: post #49
kodablah wrote: post #43

Earlier quoted context omitted.

Can you clarify, if I add a JS line to my file, I should version that JS file as a never-ever-changing static asset to be cached? It is a build artifact. And if I make a change daily (or more frequently w/ CD), have 365 of those versions (i.e. maybe versioned as date or hash)? Or should I start embedding that frequently changing JS in the pages that need it, thereby duplicating content, just to avoid breaking the rul…

> Can you clarify, if I add a JS line to my file, I should version that JS file as a never-ever-changing static asset to be cached? It only has to be cached as long as there exist deployments that need to reference it. But as long as there exist references to it, the content at the referenced address should not change. So yes, you should version that file -- or that deployment as a whole, if you'd rather not get that…

Unique file names also solve poorly behaved caches. I spent too long at a previous job trying to figure out why a particular user kept hitting the same error even after it was fixed: it turned out to be his computer's clock being off significantly enough that assets that should have expired from his cache were not expiring.

Re: Immutable Web Apps

#66

Post by jugglebird »

__oh_es wrote: post #33
jasonhansel wrote: post #24

Isn't this incompatible with server side rendering? Rendering the page's contents initially on the server is good for performance, SEO, accessibility, etc.

Nope - works perfectly. With React/Redux you can inject the initial state into the rendered page. Subsequent calls are then just api. See https://redux.js.org/recipes/serverrendering#inject-initial-... for ideas.

There are elements of the article that argue against that though. It argues that the index.html will be small (and thus not an issue to not cache), which will not be the case if you're server-rendering pages.
Post reply on HN