5 ms·

I don't find this anything better than just using Next.js or any similar framework. Custom solutions for bundling end up being custom reinvented square wheels i

I don't find this anything better than just using Next.js or any similar framework. Custom solutions for bundling end up being custom reinvented square wheels in my experience.

deleted 4y ago
[deleted]
asciiresort 4y ago
The point here is vendoring and dependency management. Makefile and sed are decades old, stable, available on every Linux distro including the Alpine docker image clocking in at 30mb total. The entire image containing an Linux distro with all the needed CLI tools is 30mb. └─ ▶ podman build -t base . && podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/base latest b593261330c1 1 minutes ago 30.5 MB The only dependency here is the Go based minifier, and Go programs are self-contained executables. Alpine contains an entire package manager. Compare with adding Node and one CLI for minification. └─ ▶ echo 'RUN apk add npm' >> Containerfile && echo 'RUN npm i -g terser' >> Containerfile && podman build -t node . && podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/node latest a28f38037137 6 seconds ago 93.5 MB localhost/base latest b593261330c1 5 minutes ago 30.5 MB Assuming dependency management was equal level of maintenance with Node, the spirit of Node ecosystem tends accept being whimsical with breaking changes. Terser or whatever Node-based processing library will introduce breaking changes to their config in relatively small timescales ( months, years, instead of decades ). That's not inherently a technical fault of the ecosystem as it is a cultural one. The popularity of JavaScript is its own undoing. Opting for tools in other web-friendly languages selects for a different type of developer. That's just for minification. Want to inline CSS? That sed command is 66 characters long. That's about the same as Parcel's zero-config config boilerplate that is NoOp: https://parceljs.org/features/plugins/ https://parceljs.org/features/plugins/. Surely a WebPack config is more than 66 bytes. I proceeded to add Parcel to compare how much it increases the image size, unfortunately it failed because there is a Python dependency: └─ ▶ echo 'RUN npm i parcel' >> Containerfile && podman build -t parcel . [2/2] STEP 18/18: RUN npm i parcel npm WARN deprecated stable@0.1.8: Modern JS already guarantees Array#sort() is a stable sort, so this library is deprecated. See the compatibility table on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#browser_compatibility npm ERR! code 1 npm ERR! path /usr/share/nginx/html/node_modules/@parcel/watcher npm ERR! command failed npm ERR! command sh -c node-gyp-build npm ERR! gyp info it worked if it ends with ok npm ERR! gyp info using node-gyp@9.0.0 npm ERR! gyp info using node@18.2.0 | linux | arm64 npm ERR! gyp ERR! find Python Fine, I added Python, Make, and other transitive dependencies to see how deep this rabbit hole goes: └─ ▶ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/python latest 05582c8b2425 2 minutes ago 156 MB Will Parcel installation work now? Nope, here's the new error trace: https://gitlab.com/-/snippets/2364041 https://gitlab.com/-/snippets/2364041. It appears this is a dependency issue with Parcel, Maybe?, with this similar 6 week old thread: https://github.com/parcel-bundler/parcel/issues/8152 https://github.com/parcel-bundler/parcel/issues/8152, which reiterates the painpoint about Node. Let's take a step back and forget the Parcel example for a second. How about NextJS? From that 30mb Alpine base image: ```Containerfile RUN apk add npm && npm i next react react-dom └─ ▶ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/nextjs latest d177ee032ff0 9 seconds ago 266 MB Kudos to NextJS for installing properly at least, but that single command added 266-30mb = 236MB to the image, and this is where the bloat creeps in. Thinking 200MB is a nothingburger is how we end up with gigabytes large images.
- likortera 4y ago
  Yes, because optimising for docker image size sounds like the right thing to optimize for.
  - asciiresort 4y ago
    Again, you're missing the point about supply chain risk. The Docker Image size is a good proxy indicator of this.
    - Shorel 4y ago
      He's just straw manning the argument. And this is ignoring the time lost watching WebKit process the same thousands of one-liner dependencies over and over. Instead of the almost instantaneous tools written in go.
Shorel 4y ago
He can replace minify and sed with Hugo and now everything is well maintained instead of custom. He even uses make instead of any of the reinvented square wheels used in JS!
- asciiresort 4y ago
  I thought you were being sarcastic and snarky at first, but Hugo is exactly what I was looking in the event I need to scale up.

I don't find this anything better than just using Next.js or any similar framework. Custom solutions for bundling end up being custom reinvented square wheels in my experience.

deleted 4y ago

[deleted]

asciiresort 4y ago

The point here is vendoring and dependency management. Makefile and sed are decades old, stable, available on every Linux distro including the Alpine docker image clocking in at 30mb total. The entire image containing an Linux distro with all the needed CLI tools is 30mb. └─ ▶ podman build -t base . && podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/base latest b593261330c1 1 minutes ago 30.5 MB The only dependency here is the Go based minifier, and Go programs are self-contained executables. Alpine contains an entire package manager. Compare with adding Node and one CLI for minification. └─ ▶ echo 'RUN apk add npm' >> Containerfile && echo 'RUN npm i -g terser' >> Containerfile && podman build -t node . && podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/node latest a28f38037137 6 seconds ago 93.5 MB localhost/base latest b593261330c1 5 minutes ago 30.5 MB Assuming dependency management was equal level of maintenance with Node, the spirit of Node ecosystem tends accept being whimsical with breaking changes. Terser or whatever Node-based processing library will introduce breaking changes to their config in relatively small timescales ( months, years, instead of decades ). That's not inherently a technical fault of the ecosystem as it is a cultural one. The popularity of JavaScript is its own undoing. Opting for tools in other web-friendly languages selects for a different type of developer. That's just for minification. Want to inline CSS? That sed command is 66 characters long. That's about the same as Parcel's zero-config config boilerplate that is NoOp: https://parceljs.org/features/plugins/ https://parceljs.org/features/plugins/. Surely a WebPack config is more than 66 bytes. I proceeded to add Parcel to compare how much it increases the image size, unfortunately it failed because there is a Python dependency: └─ ▶ echo 'RUN npm i parcel' >> Containerfile && podman build -t parcel . [2/2] STEP 18/18: RUN npm i parcel npm WARN deprecated stable@0.1.8: Modern JS already guarantees Array#sort() is a stable sort, so this library is deprecated. See the compatibility table on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#browser_compatibility npm ERR! code 1 npm ERR! path /usr/share/nginx/html/node_modules/@parcel/watcher npm ERR! command failed npm ERR! command sh -c node-gyp-build npm ERR! gyp info it worked if it ends with ok npm ERR! gyp info using node-gyp@9.0.0 npm ERR! gyp info using node@18.2.0 | linux | arm64 npm ERR! gyp ERR! find Python Fine, I added Python, Make, and other transitive dependencies to see how deep this rabbit hole goes: └─ ▶ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/python latest 05582c8b2425 2 minutes ago 156 MB Will Parcel installation work now? Nope, here's the new error trace: https://gitlab.com/-/snippets/2364041 https://gitlab.com/-/snippets/2364041. It appears this is a dependency issue with Parcel, Maybe?, with this similar 6 week old thread: https://github.com/parcel-bundler/parcel/issues/8152 https://github.com/parcel-bundler/parcel/issues/8152, which reiterates the painpoint about Node. Let's take a step back and forget the Parcel example for a second. How about NextJS? From that 30mb Alpine base image: ```Containerfile RUN apk add npm && npm i next react react-dom └─ ▶ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/nextjs latest d177ee032ff0 9 seconds ago 266 MB Kudos to NextJS for installing properly at least, but that single command added 266-30mb = 236MB to the image, and this is where the bloat creeps in. Thinking 200MB is a nothingburger is how we end up with gigabytes large images.

likortera 4y ago
Yes, because optimising for docker image size sounds like the right thing to optimize for.
- asciiresort 4y ago
  Again, you're missing the point about supply chain risk. The Docker Image size is a good proxy indicator of this.
  - Shorel 4y ago
    He's just straw manning the argument. And this is ignoring the time lost watching WebKit process the same thousands of one-liner dependencies over and over. Instead of the almost instantaneous tools written in go.

Shorel 4y ago

He can replace minify and sed with Hugo and now everything is well maintained instead of custom. He even uses make instead of any of the reinvented square wheels used in JS!

asciiresort 4y ago
I thought you were being sarcastic and snarky at first, but Hugo is exactly what I was looking in the event I need to scale up.