4 ms·

My stack will outlive yours

19 points by headalgorithm 6y ago

smt88 6y ago
It's easy to say we should write plain HTML and post it as-is when talking about a non-commercial blog that only one person contributes to and self-markets. It's not particularly interesting or new advice. Outside of that extremely narrow use case, it's not as clear cut. A lot of us have non-technical users who need to be able to publish pages, interactive content, A/B tests, and videos.
- nom 6y ago
  ... and thousands of pages and even more legacy redirects to manage, several new landing pages for campaigns and SEO every week written by non-technical people, localized content in 15 languages integrated with a translation backend, integrated e-commerce features, serving different image formats and resolutions for mobile, new integrations with third-party tools every month, etc Yeah, no one is going to manage that with GIT + HTML + CSS.
deleted 6y ago
[deleted]
eyelidlessness 6y ago
> My stack requires no maintenance That’s all fine and good, if it’s true and you anticipate it staying true. And plain HTML and CSS can go a long way for a static site. But when you want to change something site-wide, and you’ve accumulated a lot of content, it can be a ton of work to do manually and incredibly error prone to automate. This is where we reach for tooling. Even if it’s just a simple template engine to generate HTML/CSS. After all, the author is right: that stack will outlive all others. But all the others (for web) are fundamentally built on it. Now, it also depends a lot on the complexity of what you want to build into HTML/CSS. For instance, I’m working on a site with art derived from some fairly involved maths. All of the art is rendered statically. I could manually calculate the various inputs and outputs, but what a pain. And my intention is to evolve the art over time (again still rendering statically, but existing images will be updated), which would mean going back and manually recalculating each one. Exponential pain. The thing that bugs me about this tech-minimalism web trend that’s pervasive here isn’t just that it’s a weird sort of Luddism, but that it’s fundamentally uncreative. There’s great work being done on tech stacks that allow us to write programs to solve repetitive and complex problems but still ship efficient code to the client. Not just the current breed of static site generators, but also more involved tools that strip out code at build time allowing eg components which are static by default but progressively enhanced with some interactivity. Examples: - Microsite (I’m currently investigating this for my project) - Preact with partial client hydration (there are a ton of proofs of concept out there) - Solid (which is also investigating partial hydration) - Marko (does partial hydration automatically with static analysis) - Similar efforts for Svelte and Vue - React server components All of these may be dead ends in the long run, but the progression toward powerful build tools that produce efficient sites is a good thing, and the web will benefit from it without trying to force an extreme tech minimalism that will never capture a large part of the web dev culture because it’s inefficient for a lot of what people want to build.
- cecja 6y ago
  sed -Ei 's/foo|bar/foobar/g' ?
- eyelidlessness 6y ago
  I wish I could reply to the dead response, but I’ll address it here: > sed -Ei 's/foo|bar/foobar/g' ? Regex manipulation of arbitrarily structured data like HTML (and CSS!) is such a bad idea it became a meme[1]. Even where you fully control the data, there are so many potential footguns it’s not worth considering. Surely there are tools more fit for the job, but at the point you’re using tooling like that you’ve just replaced “stack” with “random commands that are implicitly part of my workflow”. [1]: https://stackoverflow.com/a/1732454 https://stackoverflow.com/a/1732454
  - johnchristopher 6y ago
    Oh, I know what to do ! Let's add an XSL that would just applies those changes without modifying the original HTML ! We can even version those XSL to reflect change history ! eg. update.01.xsl, update.02.xsl, etc.

19 points by headalgorithm 6y ago

It's easy to say we should write plain HTML and post it as-is when talking about a non-commercial blog that only one person contributes to and self-markets. It's not particularly interesting or new advice. Outside of that extremely narrow use case, it's not as clear cut. A lot of us have non-technical users who need to be able to publish pages, interactive content, A/B tests, and videos.

nom 6y ago
... and thousands of pages and even more legacy redirects to manage, several new landing pages for campaigns and SEO every week written by non-technical people, localized content in 15 languages integrated with a translation backend, integrated e-commerce features, serving different image formats and resolutions for mobile, new integrations with third-party tools every month, etc Yeah, no one is going to manage that with GIT + HTML + CSS.

deleted 6y ago

[deleted]

eyelidlessness 6y ago

> My stack requires no maintenance That’s all fine and good, if it’s true and you anticipate it staying true. And plain HTML and CSS can go a long way for a static site. But when you want to change something site-wide, and you’ve accumulated a lot of content, it can be a ton of work to do manually and incredibly error prone to automate. This is where we reach for tooling. Even if it’s just a simple template engine to generate HTML/CSS. After all, the author is right: that stack will outlive all others. But all the others (for web) are fundamentally built on it. Now, it also depends a lot on the complexity of what you want to build into HTML/CSS. For instance, I’m working on a site with art derived from some fairly involved maths. All of the art is rendered statically. I could manually calculate the various inputs and outputs, but what a pain. And my intention is to evolve the art over time (again still rendering statically, but existing images will be updated), which would mean going back and manually recalculating each one. Exponential pain. The thing that bugs me about this tech-minimalism web trend that’s pervasive here isn’t just that it’s a weird sort of Luddism, but that it’s fundamentally uncreative. There’s great work being done on tech stacks that allow us to write programs to solve repetitive and complex problems but still ship efficient code to the client. Not just the current breed of static site generators, but also more involved tools that strip out code at build time allowing eg components which are static by default but progressively enhanced with some interactivity. Examples: - Microsite (I’m currently investigating this for my project) - Preact with partial client hydration (there are a ton of proofs of concept out there) - Solid (which is also investigating partial hydration) - Marko (does partial hydration automatically with static analysis) - Similar efforts for Svelte and Vue - React server components All of these may be dead ends in the long run, but the progression toward powerful build tools that produce efficient sites is a good thing, and the web will benefit from it without trying to force an extreme tech minimalism that will never capture a large part of the web dev culture because it’s inefficient for a lot of what people want to build.

cecja 6y ago
sed -Ei 's/foo|bar/foobar/g' ?
eyelidlessness 6y ago
I wish I could reply to the dead response, but I’ll address it here: > sed -Ei 's/foo|bar/foobar/g' ? Regex manipulation of arbitrarily structured data like HTML (and CSS!) is such a bad idea it became a meme[1]. Even where you fully control the data, there are so many potential footguns it’s not worth considering. Surely there are tools more fit for the job, but at the point you’re using tooling like that you’ve just replaced “stack” with “random commands that are implicitly part of my workflow”. [1]: https://stackoverflow.com/a/1732454 https://stackoverflow.com/a/1732454
- johnchristopher 6y ago
  Oh, I know what to do ! Let's add an XSL that would just applies those changes without modifying the original HTML ! We can even version those XSL to reflect change history ! eg. update.01.xsl, update.02.xsl, etc.