Hacker News Reader

Comment by pdenton | Hacker News Reader

Nothing saves as much as just writing the HTML, CSS, and JS by hand. No build step or anything but an editor. No need to minify anything, keeping it nice and simple.

Responsive images are kind of funny in the sense that my webpages are nearly twice the size on mobile vs my laptop. The screen may be smaller, but the CSS pixel ratio is 1 on my laptop vs 3 on an iPhone.

View on HN

I think a lot of the suggestions the parent comment suggests are orders of magnitude better savings than writing things by hand...

Perhaps writing things by hand has a questionable nostalgic allure of "keeping one honest" but beyond that I don't think it's super practical.

While true in theory, I believe that keeping things handmade means that the payload couldn't realistically become big enough for the parent's suggested optimizations to actually matter.

An unoptimized payload isn't that big of a deal if it's still smaller than the best optimized one.

Perhaps not all of the advice applies, but when it comes to images and fonts, I don't think any amount of keeping things handmade is going to outstrip the advice regarding static caching and loading fewer fonts.

The best advice for images is to delete them. There's a widespread belief that meaningless pictures at the top of a post are critical. Here's the first link that comes up on Medium: https://equinox-launch.medium.com/trade-hard-win-big-dopewar... The value added of that image at the top is negative. This is, sadly, the rule rather than the exception.

Edit: This is an even better example: https://medium.com/general_knowledge/top-10-crypto-gaming-pr... How anyone can look at that image and say "that'd be perfect for the top of my next post" is beyond me.

At least the Medium gif-every-paragraph plague seems to have ended. Not sure why anyone thought it was necessary.

Heavy images & fonts on an otherwise plain HTML page will still be acceptable as they would be loading in parallel - in most cases the text will come first anyway.

I'd rather have a half-loaded page with images/fonts missing than a JS-based page which won't give me anything until the full JS payload is downloaded & executed.

Writing HTML by hand is pretty dubious advice (slightly impractical but doable, so not necessarily something to rule out on those grounds, but the factor that dominates in deciding whether or not to do it comes down negligible benefit). But writing CSS and JS by hand is both way more practical than people think, and the gains are real.

If you're not a fan of hand rolled HTML, then what do you think of JSX?

If HTML allowed you to trivially import reuseable components like you can with JSX it’d be killer. That’s the one thing that stops me writing my site by hand.

I’m looking at Astro for my site’s re-write as it seems to find a happy medium here.

>If HTML allowed you to trivially import reuseable components like you can with JSX

Sounds like WebComponents.

>I'm looking at Astro...

Never heard of it and just gave it a quick glance. Hadn't heard of the "islands architecture" it implements either, although it is similar to some familiar concepts.

In fact, it reminds me of the way we built sites years ago (pre-AJAX even), when static HTML was just delivered by the server and there was little-to-no JS involved, save for some effects.

And, that's the funny thing: in spite of all the myriad paths and paradigms, we seem to be coming full circle. It's funny in 2021 to see a "new" project advocating for a "new" approach that is essentially "SSR static HTML with minimal client JS FTW!"

> Sounds like WebComponents.

Interesting. I’ll check it out.

Update: checked it out. Shame that `Getting Started` > `Web Components` = 404.

https://www.webcomponents.org/introduction works for me.

WebComponents have been discussed for a while. They were just a dream not too long ago, and I'm not sure what their usability is right now. So, word of warning that I'm not advocating for or against their use at this point. Just mentioning that the description you gave previously reminded me of WebComponents.

i don't. Write by hand and apply the above! But there won't be seconds to shave no more in the first place.

If your project is that small that you can manage and implement on your own without teams having to work together and if you don't care about older browser. In that case you maybe have a point.

If you work on bigger projects you will run into many problems really soon. Like some Safari strangeness when it comes to CSS. Someone using some old browser which you as a developer would never use but your user base still uses it and it makes 12 % of the revenue.

reminds me I used to check websites under elinks just to see how structure/content would feel without css. You can identify fat quick this way.

This really only works for relatively small sites that don't change much and aren't developed by multiple people. After that you'll at least want some static site generation (which by itself doesn't slow down the experience), bundling of multiple JS sources together (allows you to handwrite JS over multiple files without taking the perf hit of serving multiple files), and likely a CSS preprocessor (e.g. SCSS).

I write my CSS by hand. I just don't like setting up preprocessors unless I have colleagues working on the same code.

No, it does not help. CSS is trivially small, especially after it's compressed. Same for HTML and JS. JS will balloon in size if you start using Webpack, but your own code will stay fairly small.

A single image will outweigh your text files, so the effort isn't really worth it.

> writing the HTML, CSS, and JS by hand.

plus careful image scale, quality and progressive display. Often images appear to be print quality. You need to know about the difference of web and print, however.

Agreed. Most sites don't even need JS, and for those that do, they'd be far better off with a desktop application.

Then you have to get people to install said application

I would hate giving any random piece of software full access to my computer instead of using a sandboxed version in a browser. The perf tradeoff is worth it for stuff like games and photo/video editors, but every random webapp? No way.

You don't need a web browser to sandbox a program.

A large 3x phone in portrait orientation is still only 1-1.5K physical pixels wide.

Wrong. Of course if you use a minifier you save bytes, it’s by definition. A decent built tool can still start from static files but also optimize them as much as possible. If there’s little CSS it might even just inline it.

After gzip, minified vs. hand written code size is negligible. You are gzipping your HTML, CSS, and JS, right?

gzip? What year is it? 2014? You better brotli your stuff!

A properly minified JS might be smaller after compression, even if the difference is not huge, but it may also be faster to parse.

Reply on news.ycombinator.com