Hacker News Reader

Comment by LeanderK | Hacker News Reader

i don't understand this holy crusade against bloat. Yes, many if not most of websites i visit are bloated, but i think reasonable steps are the right answer (like an automatic, idiot-proof system that serves 4k pictures to 4k-displays and hd pictures to smartphones). Shovelling nanoseconds by manually inlining everything is not scalable. Sometimes i think about starting to blog, but this should be a small hobby and as painless as possible. Ideally i would like an automated system that handles:

  - a custom font (i like fonts)
  - being fast on wifi
  - being fast on LTE
  - being reasonable fast on slower networks (maybe don't load the font etc.)

Edit: trying to be not too provocative :)

View on HN

>i don't understand this holy crusade against bloat. Yes, many if not most of websites i visit are bloated, but i think reasonable steps are the right answer (like an automatic, idiot-proof system that serves 4k pictures to 4k-displays and hd pictures to smartphones).

What's reasonable about serving MBs of BS to people who don't care for them just to follow the latest design trends, or the latest frameworks, or whatever?

The thing is, if I'm reading your blog, I don't care about your custom font. I don't even know if I care about what your blog says yet when I click on it, so I certainly don't care about how it looks.

If I could take only the text from your web page, I would probably be all for it. Maybe after reading it I might care to see the rest of your site.

A text blog honestly has no business being drastically larger than, you know, the text I came to read. Which is why I like RSS readers.

i think it seemed more provocative than it was meant to be ;) But i don't agree :)

I like things that look nice, not fancy, over the top animated. But a good picture paired with a nice font, maybe combined with a tasteful color scheme and i have much more fun reading. It doesn't that much. Idk, maybe we're just wired different, but for me reading RSS in every break would be too repetitive visually ;)

That's a bit presumptuous. Not everyone is on fast internet. Even supposedly "fast" internet benefits, as I've been very surprised about connection latency issues in the US.

Also it's more secure to have a static site.

Also it's simpler to manage in the long term.

win win win

it wasn't meant to be presumptuous. I have an older smartphone that's limited to 3g (and way to often Edge). What i wanted to say: instead of manually selecting and limiting yourself we should invest in simple, transparent tools that help you get reasonable fast.

I would choose a static site, preferably github pages because of its simplicity and easy update-process. We use elaborate compilers every day to optimize our code, so why is there no "global" optimiser for static pages that exclude a few common libraries that one assumes are already cached (if you really need js)? Maybe it's because i don't know that much about "real" web development besides some dashboard-frontend for a way more complicated backend. But this was more composing bootstraps than developing. I usually am more interested in the backend. But to me these seem to be client-problems. Some quick inlined js for selecting the correct image and whether to load the font should not waste much time. Or is this possible via CSS? In my mind this should not be an impossible task.

I have always wondered why some website display nothing until loading of font finished.

Depends on your goals.

If you're a company like Facebook or Google, you're looking to eke growth out of every corner of the Earth, including those with really slow Internet.

So after you've conquered the 1st and 2nd world countries, you start optimizing for additional tiers. (And optionally launch balloons that shower Internet upon untapped markets)

However, if you're not one of those two behemoths, then your target audience is probably located within ~3,500 miles of you/your servers (which would translate roughly into a RTT latency figure of ~100 milliseconds, and add 40ms for those folks on low-grade ADSL or cellular connections).

Your barebones site is competing with other fully-featured sites that are taking advantage of the high bandwidth delay product that's available to them.

Unless, competing for eyeballs is not one of your goals.

But regardless, optimizing for reach beyond that mileage range by slicing bits here and there, rather than bolting on a CDN, is probably a premature optimization.

To throw out a new presumption, I'd say that if you measured user's rage, they're more angry with packet loss than with consistent latency.

One is predictable and can be planned for ("open 5 tabs, go do some chores, come back in 15 minutes when they're loaded").

The other is absolutely infuriating ("open 1 tab, get teased by some amount of partially loaded objects, spend the next 5 minutes refreshing due to socket timeouts, cross fingers that not too many refreshes evicts items out of the local cache, give up")

read this:

The web sucks if you have a slow connection (danluu.com) https://news.ycombinator.com/item?id=13601451

i edited my original comment because it didn't come out right. I already read the article before, but for me the solution would be an dynamic system that only serves whats possible. For simple static sites this should be not too complicated.

Having to use webpages like we are in the 90s again doesn't seem like a good solution, or at least i don't like it (of course the opposite is also not exactly successful. AMP is being forced upon everybody for a reason).

> Having to use webpages like we are in the 90s again doesn't seem like a good solution

You underestimate the tools you have now. Mobiles are mostly on Android 4.4+, which gives us fairly advanced CSS support for example. There is a plethora of oldschool JS which can be easily replaced by simple CSS rules, a trivial example: resizing images to viewport - just use vw and vh as units, done.

I remember the word DHTML too well to know how easy it is to misuse JS. Always have a working, HTML (and maybe CSS) only solution first, especially, if you content is text. Only after this add the JS, and make whatever you want with it, make it fancy, part-reloading, whatever, but first make sure you can load your content, because that is the main reason for the site. (Again, not talking about webapps. Loading gmail is an idiotic idea on a GSM connection, just use IMAP and an offline client, if that worked during the 80s and 90s, it'll be fine.)

Apply GPRS cap in Chrome and see what's it like in rural ENGLAND. Not India, not China, the very middle (maybe not the actual, geographical middle, but you get my point) of the UK, with terrible signal reception. ( F12 -> network -> 'No throlling' dropdown ).

https://mbasic.facebook.com is a thing for good reasons. (and, by the way, a good way to browse FB without giving them the ability to trace everything via JS).

So no, not like the 90s: do it for modern browser, but the energy, bandwidth and cpu efficient way and don't block text with JS.

No one can afford not to be accessible from billions of devices from millions of people from outside of "The West".

The presentation "World Wide Web, not Wealthy Western Web" describes the effects of the bloated web around the world: https://vimeo.com/194968584

I have created a skeleton project I use for new sites made of Pure CSS with a grunt workflow.

I run jinja2 templates through Grunt and it:

* Optimizes all images - this saves megabytes upon megabytes

* minfies css, html and javascript

* the static files are served via nginx.

Pure is responsive and comes in at just 3.8kb minified and gzipped.

The result is pretty close the fastest blog in the world, and it's super simple to get started with. You can put a CDN in front of it for even better performance if you like.

>Shovelling nanoseconds by manually inlining everything is not scalable.

Neither is Internet speed (even near to) infinitely scalable (even forgetting cost), despite the dreams or hype of some.

Not to mention people on slower lines, as others have said.

Multiply those multi-MB (for pico-content) sites by gazillions of people accessing (some of) them, and the slowdown of the Net becomes serious real fast - no matter what the gung-ho types might claim or say.

Reply on news.ycombinator.com