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

31–40 of 66 posts

Re: Immutable Web Apps

#31

Post by Twisol »

kodablah wrote: post #30

I wish there was some "why" > Static assets must be hosted at locations that are unique and independent of the web application environment(s) Why? Meaning a different domain or is path enough? What are "static assets" compared to every other file served by a web server? I assume meaning will never ever change, so images are not "static assets"? What if I name them by what they are and commit to changing the name when…

> Static assets must be hosted at locations that are unique and independent of the web application environment(s)

> Why?

Broadly, for the same reason that separating content, structure, and style is considered a good idea. (We can debate separately about whether HTML/CSS/JS applied this principle appropriately.)

From another angle, this is just another way of saying that static assets should not depend directly on the environment, and that only `index.html` should differ, since it's the effective manifest of your application. It's okay for different environments to go to a different URL for `index.html`.

> I assume meaning will never ever change, so images are not "static assets"?

An individual image is a static asset. If you want to use a different image, you should change the URL. This is where the "immutable" part comes in.

> So, static assets are only immutable when they don't have anything environment specific. Oh, and static assets always don't have anything environment specific.

Not every static asset is a build artifact, but every build artifact should be a static asset. This is not true in general, but it is what the whole idea of an "immutable application" is trying to achieve. The environmental bindings are pushed out to the top level, where they belong.

I agree it could have been worded better; the phrase "static asset" is a bit overloaded here.

Re: Immutable Web Apps

#32

Post by Twisol »

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.

Since this page is talking about SPAs, the only "entry point" it considers is `index.html`. I don't see anything against pre-rendering parts of `index.html` on the server-side -- just that the configuration embedded in `index.html` of _which_ static assets to use and _what_ the environment defines must be managed.

In multi-page applications (MPAs?), among the other things that would probably have to be accounted for, you could treat all of your pages as "entry points" in the same way as `index.html`.

Re: Immutable Web Apps

#33

Post by __oh_es »

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.

Re: Immutable Web Apps

#34

Post by knubie »

kodablah wrote: post #30

I wish there was some "why" > Static assets must be hosted at locations that are unique and independent of the web application environment(s) Why? Meaning a different domain or is path enough? What are "static assets" compared to every other file served by a web server? I assume meaning will never ever change, so images are not "static assets"? What if I name them by what they are and commit to changing the name when…

> So, static assets are only immutable when they don't have anything environment specific. Oh, and static assets always don't have anything environment specific.

If I understand correctly, the immutability of a particular asset is what makes it a "static" asset.

Re: Immutable Web Apps

#35

Post by GeorgeO84 »

jarfil wrote: post #11

Shouldn't this be called "Immutable Resources" rather than immutable web apps? Sure with JS the resources make up the app, but that index.html is still mutable, so no much different from an "index.php?section=whatever". Setting such long expiry times on the cache also sounds like a great way to pollute browser caches with obsolete resources.

Yes the name is too encompassing. Almost click-baity for what it is.

Re: Immutable Web Apps

#36

Post by ams6110 »

Illniyar wrote: post #20
jarfil wrote: post #11

Shouldn't this be called "Immutable Resources" rather than immutable web apps? Sure with JS the resources make up the app, but that index.html is still mutable, so no much different from an "index.php?section=whatever". Setting such long expiry times on the cache also sounds like a great way to pollute browser caches with obsolete resources.

"Setting such long expiry times on the cache also sounds like a great way to pollute browser caches with obsolete resources. " Setting "forever" caching is standard practice for web development for many years. The browser doesn't really cache these forever - it is merely a hint to the browser that the resource won't change and you don't have to check it again. In fact, the more resources you can put with such caching…

You really can't control how long something stays in a browser cache. The user can clear it at any time. Mine are cleared every time I close the browser.

Re: Immutable Web Apps

#37

Post by marius_k »

I would separate app config into ./config.json and then load it before rendering instead of putting everything in ./index.html.

SPA bundler would generate all files as usual. index.html would be versioned. Configs would not be versioned (except for config examples).

Re: Immutable Web Apps

#38

Post by knubie »

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.

Re: Immutable Web Apps

#40

Post by knewter »

apexalpha wrote: post #26

This has been a very interesting read. I've been wanting to build a single page personal website as a means of learning. I'm not a star in webdev so I have a lot of hours ahead of me. I might actually deploy it like this, why not? If anyone has any good book or other resources to get started in building a website like this for people who already have back-end and programming experience but lack html, css, js etc.. pl…

I'd recommend checking out Elm: https://elm-lang.org

it's ridiculously good and if you don't have js experience that shouldn't get in your way. it's easily my favorite frontend language.

Post reply on HN