Live data from Hacker News

Shrinking my static site

hampton.pw

21–30 of 107 posts

Re: Shrinking my static site

#21
post #4

Earlier quoted context omitted.

How is that any different from build tooling for any other language? On my system, gcc with a bunch of commonly used dependencies requires just about the same space (and it's a full Linux system, not a trimmed down container).

> How is that any different from build tooling for any other language? On the one hand yes, on the other hand it's a large amount of crap just to build a static site. `npm install @11ty/eleventy` pulls 600 packages and yields a 100MB node_modules folder. Even Sphinx (whose scope goes way beyond static site generation) "only" pulls in about 75MB worth of stuff (a third of that being Babel) over two dozen dependencies…

The problem with JS ecosystem is less about size and more about the number of files.

Re: Shrinking my static site

#23
tl;dr author discovers multi-stage build to throw away useless nodejs dependencies.

Same also applies to even Java. Maven downloads tons of stuff these days. You may only be using single static string from a dependency.

Re: Shrinking my static site

#24
Back in 2015 when cloud offerings were still marginally new, a lot of big providers were gettting into the game with Docker offerings (ie, IBM Bluemix) where the charge was based entirely on RAM*Hours.

Naturally this lead to me gaming the system and making my docker images as in RAM usage small as possible. In the end I even abandoned SSH as too heavy and switched to shadowsocks (2MB resident) for networking the docker instances together.

Re: Shrinking my static site

#25
> This docker image resulted in a 419MB final image and took about 3 minutes to build. There are some obvious issues with this. For instance every-time I change any file it must go through and reinstall all of my node_modules.

He doesn't tell whether there have been any build time improvements after the changes to the Dockerfile. Will the builder docker images get cached and thus reduce the build and deployment time?

Re: Shrinking my static site

#26
post #25

> This docker image resulted in a 419MB final image and took about 3 minutes to build. There are some obvious issues with this. For instance every-time I change any file it must go through and reinstall all of my node_modules. He doesn't tell whether there have been any build time improvements after the changes to the Dockerfile. Will the builder docker images get cached and thus reduce the build and deployment time?

Well, the article mentions an obvious improvement. The node_moduoes won't be rebuilt after any changes to the code, only changes specific to the packages.json.

Basically the main step is the COPY . . step (previously COPY . /app) which will invalidate the cache every change to the code.

Also that on the builder, the steps beyond npm run are not needed, but well they won't improve much on the performance or space of the overall process.

Re: Shrinking my static site

#27
post #19

Static site and docker shouldn’t be seen together.

So if I have a kubernetes env hosting all my stuff, with standardized CI /deployment flows, and one site is static, hosting it from a container like everything else would be a cardinal sin? Thats a strangely black-and-white way to put it...

Re: Shrinking my static site

#28
post #7

I use Hugo as my static site generator, single binary, no dependencies, generating hundreds of pages in milliseconds ... so reading this feels so wrong, I want to call it JavaScript masochism. Taking a simple concept like a static site and adding a ton of complex tooling around it because it is the trend now? Why would you even need a docker image to run a static website? The best thing about a static website us you…

best thing: you could easily pack your static Hugo binary in a container with nothing else. But somehow nobody does this without talking about microkernels (and probably internal google-apps)
Post reply on HN