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

Shrinking my static site

hampton.pw

Post reply on HN
Print view View original

71–80 of 107 posts

Re: Shrinking my static site

#71

Post by 1337shadow »

herohamp wrote: post #68
1337shadow wrote: post #55

Earlier quoted context omitted.

On a second thought, I also don't understand why do npm in two different images, why not just copy the webpack bundles from the builder image into the nginx image ? For me the cause of the big image size was in COPY --from=npmpackages /app /app From your third Dockerfile, it seems replacing the above with the following would have done the trick without adding an extra stage COPY --from=npmpackages /app/_site/ /usr/sh…

I do npm in two different images so that the node_modules can be cached between builds. this massively speeds up my build. The npmpackages layer only installs the npm modules

I see, this speeds up when you change a dependency, because at least then your whole node_modules is not thrown away is that right ?

Re: Shrinking my static site

#72

Post by onion2k »

ashishb wrote: post #21
masklinn wrote: post #4

Earlier quoted context omitted.

> 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.

There are real problems with NPM, like the proliferation of packages that include things they shouldn't (babel included a picture of Guy Feiri for a while...) but the simplistic "there's a lot of files" argument is nonsense. If you need a lot of files then you need a lot of files.

Re: Shrinking my static site

#73

Post by epmaybe »

1337shadow wrote: post #52
epmaybe wrote: post #36

Earlier quoted context omitted.

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…

With GitLab Pages it's even easier, just fork one of the examples in gitlab.com/pages, push a content update in a commit and it's online a minute later thanks to GitLab-CI and GitLab Pages.

This workflow seems almost exactly the same as GitHub Pages, I'm not sure it's worth my time to switch platforms and go through the hassle when everything works now.

Re: Shrinking my static site

#74

Post by onion2k »

jrururufuf666 wrote: post #30

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.

I've only been doing it for 25 years rather than the full 30 but in my noob opinion I'll take Docker and Github over it every time. The number of times a site failed to update because an FTP file failed to transfer completely, or that the permissions were wrong, or that the FTP client changed a file's CRLFs, or that a directory on the server wasn't writable by the FTP user, or... well, let's just admit that FTP sucked and things are far more reliable now.

Re: Shrinking my static site

#75

Post by ebiester »

Symbiote wrote: post #64
oplav wrote: post #41

Earlier quoted context omitted.

At work, we build a couple SPA React application for internal tools. All of these SPAs talk to other internal APIs via REST, so you can think of these as static websites. In production, we do exactly what you suggest: serve through a CDN. However, for our dev environments and PR builds, programmatically setting up CDN to handle these use cases is not easily integrated with our CI/CD workflow. Our CI/CD environment is…

Possibly this is far too old fashioned, but all our internal static sites (and a good few external static sites) I deploy to a single Apache server.

It's not old fashioned. However, it does mean you have two methods of deployment. In larger ecosystems, a suboptimal release system for some components is less harmful than multiple release systems that have to interact.

I wouldn't suggest moving to docker for this use case, but if everything else was in docker, I'd want this in docker as well, even if that docker container was just running apache.

(Practically, though, if I was starting from scratch, I'd be using NginX.)

Re: Shrinking my static site

#77

Post by CJefferson »

kissgyorgy wrote: post #76

YOU DON'T NEED DOCKER FOR A STATIC SITE. That's why it's called "static". There should be no moving parts in it.

I have had several problems with static sites being broken by library updates. I now have a vagrant disc image which will let me always build my site.

Re: Shrinking my static site

#78

Post by saagarjha »

fock wrote: post #28
ig0r0 wrote: 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)

Why do you need a container in the first place?

Re: Shrinking my static site

#79

Post by nicoburns »

Symbiote wrote: post #64
oplav wrote: post #41

Earlier quoted context omitted.

At work, we build a couple SPA React application for internal tools. All of these SPAs talk to other internal APIs via REST, so you can think of these as static websites. In production, we do exactly what you suggest: serve through a CDN. However, for our dev environments and PR builds, programmatically setting up CDN to handle these use cases is not easily integrated with our CI/CD workflow. Our CI/CD environment is…

Possibly this is far too old fashioned, but all our internal static sites (and a good few external static sites) I deploy to a single Apache server.

I highly recommend nginx over apache. It's both more performant AND much easier to configure. Other than inertia for an existing deployment I don't think there's any reason to use Apache in 2020.
Post reply on HN