Live data from Hacker News

Immutable Web Apps

immutablewebapps.org

1–10 of 66 posts

Re: Immutable Web Apps

#2
This is essentially an opinionated take on how to deploy JAMStack style applications. TLDR is to use index.html as deployment config / manifest ONLY, and load all other assets from static unchanging resources. This kind of discipline is a little like what you might use for an optimal IPFS (content-addressed) deployment, so it's cool to see best practices converge.

I clicked through and read the article because I though it would be about Clojure-style immutable data structures, like ImmutableJS uses. Or maybe how to use databases like Datomic or patterns like CQRS and event sourcing.

Re: Immutable Web Apps

#3
post #2

This is essentially an opinionated take on how to deploy JAMStack style applications. TLDR is to use index.html as deployment config / manifest ONLY, and load all other assets from static unchanging resources. This kind of discipline is a little like what you might use for an optimal IPFS (content-addressed) deployment, so it's cool to see best practices converge. I clicked through and read the article because I thou…

Stop trying to make JAMStack happen /Mean Girls

Re: Immutable Web Apps

#4
post #2

This is essentially an opinionated take on how to deploy JAMStack style applications. TLDR is to use index.html as deployment config / manifest ONLY, and load all other assets from static unchanging resources. This kind of discipline is a little like what you might use for an optimal IPFS (content-addressed) deployment, so it's cool to see best practices converge. I clicked through and read the article because I thou…

Interesting, I've never heard term JAMStack before. I knew this was a common concept to have pre-built templates with JS client and API backend, but now I know it has a name!

Re: Immutable Web Apps

#6
post #2

This is essentially an opinionated take on how to deploy JAMStack style applications. TLDR is to use index.html as deployment config / manifest ONLY, and load all other assets from static unchanging resources. This kind of discipline is a little like what you might use for an optimal IPFS (content-addressed) deployment, so it's cool to see best practices converge. I clicked through and read the article because I thou…

I'm surprised there's no mention of Subresource Integrity. That works well with content addressable stores, provides extra verification inside of the browser.

Re: Immutable Web Apps

#7
> All of the leading application frameworks (Angular CLI, Create React App, Ember CLI, Vue CLI 3) recommend defining environment values at compile time. This practice requires that the static assets are generated for each environment and regenerated for any change to an environment.

As a backend developer that relies heavily on environment variables for configuration, I was surprised that runtime configuration is not something these frameworks recommend.

In the few occasions that I have to do some front end (Angular) stuff, I had to write my own service just so that I can have runtime configuration.

Why don't these frameworks support this out of the box? Are there any issues I may be missing?

Re: Immutable Web Apps

#8
post #7

> All of the leading application frameworks (Angular CLI, Create React App, Ember CLI, Vue CLI 3) recommend defining environment values at compile time. This practice requires that the static assets are generated for each environment and regenerated for any change to an environment. As a backend developer that relies heavily on environment variables for configuration, I was surprised that runtime configuration is not…

You can't have runtime configuration on the frontend because the frontend is running on the client (browser). The best you can get is build-time configuration that embeds in the SPA.

Re: Immutable Web Apps

#9
post #7

> All of the leading application frameworks (Angular CLI, Create React App, Ember CLI, Vue CLI 3) recommend defining environment values at compile time. This practice requires that the static assets are generated for each environment and regenerated for any change to an environment. As a backend developer that relies heavily on environment variables for configuration, I was surprised that runtime configuration is not…

You can't have runtime configuration on the frontend because the frontend is running on the client (browser). The best you can get is build-time configuration that embeds in the SPA.

Here's an example where it can be done in Angular: https://www.jvandemo.com/how-to-use-environment-variables-to....

Not exactly the same as shell environment variables, of course. And you may disagree about exposing the `enableDebug` flag as a runtime config there.

Still it is doable, in a sort of roundabout way, using the browser as the environment.

Re: Immutable Web Apps

#10
post #9

Earlier quoted context omitted.

You can't have runtime configuration on the frontend because the frontend is running on the client (browser). The best you can get is build-time configuration that embeds in the SPA.

Here's an example where it can be done in Angular: https://www.jvandemo.com/how-to-use-environment-variables-to... . Not exactly the same as shell environment variables, of course. And you may disagree about exposing the `enableDebug` flag as a runtime config there. Still it is doable, in a sort of roundabout way, using the browser as the environment.

Ah, indeed. If you count "open dev shell, manually edit globally exposed variables so that it will affect only my browser" then yes, you can have that as runtime configuration.
Post reply on HN