in my eyes this is all madness. deploying sites via github to some docker shit. how about good old ftp and a cheap shared webhost? like its been done for 30 years.
That doesn't have enough buzzwords.
Shrinking my static site
31–40 of 107 posts
Re: Shrinking my static site
#32Aside: one should not use package.json to install dependencies. Use either package-lock.json (and command "npm ci") or yarn.lock (and... I forget). Keep the lock file as part of repo too, or each build could be different.
Re: Shrinking my static site
#33I'd suggest changing this:
COPY package.json .
RUN npm install
COPY package.json package-lock.json .
RUN npm ci
Re: Shrinking my static site
#343 minutes to build a static blog (with a grand total of five posts) that doesn’t look any different from decade-old blogs. Pulling hundreds of MB from the Internet in the process. Wow.
Re: Shrinking my static site
#35Aside: one should not use package.json to install dependencies. Use either package-lock.json (and command "npm ci") or yarn.lock (and... I forget). Keep the lock file as part of repo too, or each build could be different.
> or each build could be different.
Or not working.
Re: Shrinking my static site
#36in my eyes this is all madness. deploying sites via github to some docker shit. how about good old ftp and a cheap shared webhost? like its been done for 30 years.
To be honest, GitHub sites have been amazing for me. I just have a simple static website with personal information. HTML and CSS with minimal JS. Purchasing a shared webhost still means extra cost on top of domain registration. With GitHub, I just followed their instructions with my domain, and everything just worked. I'm also not paying anything per month or year besides domain registration which is really nice when you have to start budgeting tightly.
I don't know about docker and all of that, though.
Re: Shrinking my static site
#37in my eyes this is all madness. deploying sites via github to some docker shit. how about good old ftp and a cheap shared webhost? like its been done for 30 years.
Yeah but...but... that would just get the job done. Nothing to write about, nothing to whine about, no weird dependencies being pulled, nothing to hand-wave, nothing to yell and humblebrag about. No theatre.
You are right, this IS madness.
Re: Shrinking my static site
#38How about binary patching your container? - pretty sure I've seen this done somewhere but can't find the link to it.
Re: Shrinking my static site
#39This post says a lot more about the javascript ecosystem than Docker. Multi-stage image builds are nothing new or extraordinary, and in fact it's Docker 101. However, being forced to install 500MB worth of tooling and dependencies just to deploy a measly 30MB static website on nginx is something unbelievable.
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).
A closer comparison - an average node folder weighs a lot more than an average Python virtualenv.
Re: Shrinking my static site
#40I 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…
That's exactly how I was doing it years ago: Hugo and script to upload to S3. Engineers like to overengineer stuff... get away from that habit folks.