My stack will outlive yours "name": "My stack will outlive yours", My stack will outlive yours
So what?
Don't Repeat Yourself? I'm OK repeating myself if that can avoid me taking a dependency on fragile tooling
My stack is HTML+CSS
61–70 of 194 posts
Re: My stack is HTML+CSS
#62This is an inaccurate over-simplification. If you just use HTML and CSS, you can also have really bad Lighthouse scores. For example, vanilla ` ` will ship the same image to every device, regardless of viewport size. Vanilla ` ` doesn't enforce setting `width` and `height`, which makes your layouts shift. Slow-loading images and layout shifts are the very things that will downgrade the "100" score he's currently prou…
Just meant to be humorous, does your brain not provide any illumination, while at it, do you have time and energy left to address other then software in itself, for adding to the cycle of aggregate rentier-ism?
Re: My stack is HTML+CSS
#63I swear this same exact post gets re-dressed and upvoted weekly. Is there anything worth discussing here? The entire thesis of the post is "my blog is maintenance free". Ok, and? Is blog maintenance really a noteworthy topic? How many times can blogs rephrase "use the right tool for the job"?
"My personal website with 4 pages doesn't need a CMS!"
This comment presents a caricatured perspective of those it opposes by using a made-up quote (it doesn't seem to have actually been said by anyone anywhere), and it doesn't really do anything for the discussion that wasn't already covered by the parent comment it's attached to.
Please, folks, don't encourage people to post low-effort noise by upvoting comments like this.
Re: My stack is HTML+CSS
#64Earlier quoted context omitted.
> Vanilla ` ` will ship the same image to every device, regardless of viewport size. You can have responsive images with vanilla [0]. You can even lazy load images with just `loading="lazy"` attribute[1]. I'm pretty sure I can optimize more things. I'm mostly agree with this blog post. Plain HTML+CSS is really good for simple webpages, like landing page or portfolio that requires less update. But for a blog with pagi…
The point is that "just HTML+CSS" is not the recipe for performance. You get into the same nuance as any other technology: how you use HTML+CSS is the recipe for performance. In fact, his image in this blog post doesn't have `width` and `height` set, so had it been higher up on the page and part of the "Largest Contentful Paint", not sure we'd have a 100 here. This is where frameworks can be really helpful, and I wou…
At the same time though, in my experience, performance optimizations follow paretto's law: try to get 80% of the way with 20% effort. There are pitfalls both with and without frameworks (e.g. it's equally easy to accidentally plop a hi-res image into a Next.js app), but generally speaking, limiting the tech stack means there's less potential stack-specific pitfalls.
If "I'm gonna restrict myself to HTML and CSS only" gets them 80% of the way to their performance goals then IMHO, that's a perfectly valid approach.
As far as images go, the reality is that most mainstream sites with image/video content are heavy sites with multi-second page load times, despite literal millions of dollars being spent on engineer salaries. In that context, does it really matter if a random blog decides to just use pngcrush and a dumb img tag for the occasional eye candy imagery, instead of whatever is the state of art multi-resolution technology?
Re: My stack is HTML+CSS
#65My output is HTML and CSS, but my stack is React with Next.JS. I just tell Next to not emit JS at build time. This is the best of both worlds. You get an excellent dev experience with TypeScript, fast refresh, the world of React components (granted many don't work when reduced to being static HTML), and I can also opt back into React on a page by page basis if I have the need. With Next's static site generation and e…
Beautiful site! Do you write your articles in markdown or something like that and render them into pages at build time? Is your source available by chance? I've been wanting to do this exact thing but while the Next.js docs are great, what would really help is to just see an example site that does exactly what I want to do. All the good examples are either too trivial to be useful or to complex to be useful.
Re: My stack is HTML+CSS
#66Sure, it's super easy when your page doesn't have even a header and/or a footer. Try having a top-menu in your design, or some banners/ads, and then you need to change ALL the pages to change a single url. This is how we used to do things long time ago, and it sucked BIG TIME, and that's why people invented server-side includes and cgi and mod_php and all of that... it saves time, and your time costs much more than hardware...
Re: My stack is HTML+CSS
#67This is an inaccurate over-simplification. If you just use HTML and CSS, you can also have really bad Lighthouse scores. For example, vanilla ` ` will ship the same image to every device, regardless of viewport size. Vanilla ` ` doesn't enforce setting `width` and `height`, which makes your layouts shift. Slow-loading images and layout shifts are the very things that will downgrade the "100" score he's currently prou…
Back in the day you sized your image for the web, there was no need for dimensions in img tags
> For example, vanilla `` will ship the same image to every device,
As it should be, for simplicity's sake.
Designers trying to assert pixel-perfect control of layout is part of why the web sucks so much today.
Let the browser handle layout, that is one of the things it is designed to do!
Re: My stack is HTML+CSS
#68Plain HTML+CSS is really good nowadays. You can for example lazy load images with `loading="lazy"` attribute. You don't need JS anymore just to lazy load images. You can use plain CSS for simple interaction like opening and closing menu, toggling pricing plan, etc. If you're curious with what you can build with plain HTML+CSS, check out my side project[0]. It's a collection of free landing page templates in plain HTM…
Not needing to write markup at the time of content generation even better than writing HTML, though. Use any of a million static site generators and get the benefit of writing what you want to write in the most efficient format for that, without needing to program the typesetting markup while you're writing. HTML is in no way the best tool for write content. But it is the best tool to serve content in a browser.
The browser is the bitch. Out of control, bloated, willingly so, in interaction with layers of scripting on both sides. The server and client are bait. There should be a serious effort to tackle the world of academics and their use of analog tools for digital publishing. Nothing is better mined and searched(for any entity not meta-rapers that "employ" slave coders as battery-chickens) as text. There should be a tendency to reductionist auto-censuring or have coders but one ambition? Being scooped up by corporations for scraps so they can piggy back on their wild efforts for cents on the dollar?
Re: My stack is HTML+CSS
#69> "When I publish a new page, I need to link to it manually from the index page. I’m OK with that. It’s done in one line. It also allows me to have more control over when I want the page to be “published”."
I've sometimes wondered whether pg's essays are done with just HTML and CSS — it kinda looks that way, [0] but I'm not expert enough to be able to tell.
Re: My stack is HTML+CSS
#70The main issues are the ergonomics of authoring and maintaining consistency around a site. A minimal static site generator would keep internal links and boilerplate consistent. Connecting that with markdown, Org mode, or reStructured Text would help with the ergonomics. But then you lose the goal of having no necesary tools. Anyhow, if there's one general purpose tool that predates the web and will probably be around…
> A minimal static site generator would keep internal links and boilerplate consistent.
Maybe not. There's an argument to be made that says you should treat a blog as a series of pages, each modeling something corresponding to what you might call a "publication event" in the real world, e.g. printing a magazine or passing around a physical memo. The consistency angle is probably overvalued (not worth its cost). When a newspaper or magazine changes its masthead, old issues don't get updated. You might say that this reflects a limitation of the physical medium and that you would if you could (as is the case with digital editions), but what does it get you, really? Your links to external sources are already going to lead to wildly different forms of presentation outside your control.
If an internal link leads to a page published in 2014, and it still matches the way it looked in 2014, is that a problem? (And if so, e.g. due to changes in fashion/trends that have led to it being intolerable, it's worth asking, "what makes it so?", "was it ever really tolerable, even in 2014?", and "is the material I'm publishing right now guilty of the same thing—its presentation only squeaking over the threshold of acceptability because of something else that's currently en vogue but soon won't be?")