7 ms·

> my blog ...is the usual use case for the "why not just use HTML?!" argument. Still, even at the enterprise level, considering SSR's popularity, the "pendulum

> my blog ...is the usual use case for the "why not just use HTML?!" argument. Still, even at the enterprise level, considering SSR's popularity, the "pendulum" has been in favor of static HTML for a while.

Closi 4y ago
You mean static HTML loaded onto serverless cloud storage with cloudfront, using Hugo to compile markup into HTML with a CI/CD pipeline created to push the content up to your S3 bucket, then with a headless CMS visual editor which sits on some SaaS platform, with any server-side interactions written in Lambdas?
- vmception 4y ago
  Sounds tedious, I propose we make scripts for all these steps and bundle it alongside the frontend framework that renders static html
- ant6n 4y ago
  Exactly, plain html!
- tshaddox 4y ago
  > static HTML loaded onto serverless cloud storage with cloudfront That's just a verbose way of saying "a file hosting service." > using Hugo to compile markup into HTML with a CI/CD pipeline created to push the content up to your S3 bucket What's wrong with that though? You could describe any computer technology in arbitrarily high level of depth to mock how complicated it is. Text editors sound very complicated too if you describe their internal data structures, the window server the GUI runs on, the operating system's context switching system, etc.
  - jameshart 4y ago
    For some reason using a bash script to munge a few files together then a cron job running to rsync them to an Apache server running on a VPS is considered morally and technically superior to using a JavaScript tool to build a site then having a GitHub Action push the files up to an S3 bucket with a cloudfront distribution in front of it. There’s no obvious reason for this, other than a belief that if something can be done with 50 year old technology, it should be.
    - jjnoakes 4y ago
      I don't think one is morally superior to the other, but there are trade-offs. With bash, cron, rsync, and a vps, one is using stable, long-lived tools that usually come with Linux, are vetted and patched automatically, and are familiar in the sense that those same tools can be used for all sorts of tasks, not just frontend development. There is also the argument that the only remote piece controlled by the service provider is a vps which still gives you lots of control and flexibility with minimal lock-in. I prefer somewhere in the middle of the two extremes, but I see more appeal to the "old" approach than you allude to.
      - jameshart 4y ago
        Funny that tools distributed via a linux package manager are considered 'vetted and patched automatically', but a broadly used JS build tool distributed via npm is likely seen as an unstable dependency, or worse a supply-chain attack vector. Sure, there are maturity differences but it's nowhere near so vast a difference as some claim. These are just preferences. It's not a culture war issue.
        sickill 4y ago
        If you don’t understand the difference between software shipped by a distro and software shipped by developer (npmjs.com) then all is left is preferences or culture war issues. However there’s fundamental difference: in a model of distribution by a distro the developer only produces a software but they don’t release it themselves. They provide source code and that’s it. Maintainers of packages for each distro vet new releases, test, and sometimes patch them so they work best within context of a given distro. So there’s extra effort spent on making sure the software is stable. In a model where a developer publishes their new release to some package repository directly (npmjs.com is just one of them, same applies to pypi.org, rubygems.org, etc) that extra “QA” by others than the developer doesn’t happen.
    - FpUser 4y ago
      >"using a JavaScript tool to build a site then having a GitHub Action push the files up to an S3 bucket with a cloudfront distribution in front of it." Why would I want to introduce so many a dependencies when I can have zero? Yes in this case old tech is superior. Sure if (and that is a big if) your blog is super popular you might want to "cloudflare" but that's about it.

Closi 4y ago

You mean static HTML loaded onto serverless cloud storage with cloudfront, using Hugo to compile markup into HTML with a CI/CD pipeline created to push the content up to your S3 bucket, then with a headless CMS visual editor which sits on some SaaS platform, with any server-side interactions written in Lambdas?

vmception 4y ago
Sounds tedious, I propose we make scripts for all these steps and bundle it alongside the frontend framework that renders static html
ant6n 4y ago
Exactly, plain html!
tshaddox 4y ago
> static HTML loaded onto serverless cloud storage with cloudfront That's just a verbose way of saying "a file hosting service." > using Hugo to compile markup into HTML with a CI/CD pipeline created to push the content up to your S3 bucket What's wrong with that though? You could describe any computer technology in arbitrarily high level of depth to mock how complicated it is. Text editors sound very complicated too if you describe their internal data structures, the window server the GUI runs on, the operating system's context switching system, etc.
- jameshart 4y ago
  For some reason using a bash script to munge a few files together then a cron job running to rsync them to an Apache server running on a VPS is considered morally and technically superior to using a JavaScript tool to build a site then having a GitHub Action push the files up to an S3 bucket with a cloudfront distribution in front of it. There’s no obvious reason for this, other than a belief that if something can be done with 50 year old technology, it should be.
  - jjnoakes 4y ago
    I don't think one is morally superior to the other, but there are trade-offs. With bash, cron, rsync, and a vps, one is using stable, long-lived tools that usually come with Linux, are vetted and patched automatically, and are familiar in the sense that those same tools can be used for all sorts of tasks, not just frontend development. There is also the argument that the only remote piece controlled by the service provider is a vps which still gives you lots of control and flexibility with minimal lock-in. I prefer somewhere in the middle of the two extremes, but I see more appeal to the "old" approach than you allude to.
    - jameshart 4y ago
      Funny that tools distributed via a linux package manager are considered 'vetted and patched automatically', but a broadly used JS build tool distributed via npm is likely seen as an unstable dependency, or worse a supply-chain attack vector. Sure, there are maturity differences but it's nowhere near so vast a difference as some claim. These are just preferences. It's not a culture war issue.
      - sickill 4y ago
        If you don’t understand the difference between software shipped by a distro and software shipped by developer (npmjs.com) then all is left is preferences or culture war issues. However there’s fundamental difference: in a model of distribution by a distro the developer only produces a software but they don’t release it themselves. They provide source code and that’s it. Maintainers of packages for each distro vet new releases, test, and sometimes patch them so they work best within context of a given distro. So there’s extra effort spent on making sure the software is stable. In a model where a developer publishes their new release to some package repository directly (npmjs.com is just one of them, same applies to pypi.org, rubygems.org, etc) that extra “QA” by others than the developer doesn’t happen.
  - FpUser 4y ago
    >"using a JavaScript tool to build a site then having a GitHub Action push the files up to an S3 bucket with a cloudfront distribution in front of it." Why would I want to introduce so many a dependencies when I can have zero? Yes in this case old tech is superior. Sure if (and that is a big if) your blog is super popular you might want to "cloudflare" but that's about it.