Live data from Hacker News

The unreasonable effectiveness of simple HTML

shkspr.mobi

201–210 of 387 posts

Re: The unreasonable effectiveness of simple HTML

#201

Earlier quoted context omitted.

> worse in almost all ways How so? I dislike the text color choice, but other than that it seems perfectly fine to me.

Admittedly most is just personal preference but the line width thing is the cardinal sin. Forcing huge blocks of whitespace on either side of the text for nebulous "readability" reasons is just wasteful. Too many web sites ape this pattern too. Look at John Gruber's website [1] on a nice wide 27" monitor for an extreme example. The content takes up less than 1/5 of the width of the screen. 1: https://daringfireball.n…

I used to think this, but after really trying to assess the difference in some examples I made myself, I was converted.

Have you seriously tried yourself to read two identical blocks of text, one at full screen width (I tested 100% zoom Wikipedia on a 1440p, 27" screen at standard DPI) and one at a width of about 55 characters on the same screen? Have a go.

I find it easier to locate the next line after finishing one, which gives me a quicker reading speed.

Re: The unreasonable effectiveness of simple HTML

#202
post #185

I loved this article so much. For real. I hope web designers will follow the advice, and focus all their efforts on html+css. It's more complicated, I know. But it's better.

Its not simply better. Going HTML only means killing features and conveniences that users want for a benefit they mostly won't see. Its perfectly possible to make web apps run very fast.

Re: The unreasonable effectiveness of simple HTML

#203
post #4

Different solutions for different problems. You have a different design requirement when you are designing something for use by the most vulnerable and those without access to reasonable technology. This absolutely needs to be factored in when choosing how to build something, however, this is a tiny subset of users, and this is for essential life-is-in-the-balance types of service. The vast majority of users will hav…

In the US, we collectively decided (via elected representatives) that this is important to us, and we passed the ADA to enforce it. Visually impaired people have as much right to use stuff as you and I do, and the law says so. From a purely economic point of view: if your competitor's website supports the visually impaired, and yours does not, then even though that's a relatively small market segment you're probably…

Do you have an example (outside of a niche, like a site catering specifically to some disability) of the economic argument working? Because the obvious economic counter argument is that while you work on accessibility your competitors work on features for the 90+% rest of the population.

In my opinion it's why it's especially important to have regulations here, free market won't save us because in most cases the ROI just isn't there. However this is wrong to abandon those people, thus we need incentives to force people to do the right thing.

Re: The unreasonable effectiveness of simple HTML

#204
post #19

I am not a front-end developer but looking at it from a distance I really don't get modern web design. Sure some sites might need fancy javascript single page features, like if your webpage is an interactive map or realtime game, but most sites are just text and some pictures. Whats with all the javascript? Your site looks just like the next one anyway! It feels like an "Emperor's New Clothes" situation or maybe more…

The two biggest rants on HN are 1) Why doesn't this site work without JavaScript? It's inaccessible. and 2) Why doesn't this app work offline? It invades my privacy. Maybe I'm wrong, but as far as I can tell, you can't have both. Sorry folks. You are right, JS is not needed if the site truly is static content. But if you try to make an interactive app that could be implemented client-side (AKA javascript) and attach…

I don’t understand your second point. Which web app works offline?? (Unless they are deliberately made for that purpose. Hell, even most electron apps refuse to work without a connection) They regularly make new requests, there is literally no difference between SSR and CSR in this regard - it seems a bit that you are arguing with a straw men. Like, what does a webshop do which is written in react/whatever and you go to the next “page”, it hadn’t loaded yet?

Also, noone would even think that it is unreasonable for a WEBapp to phone home. What people have trouble with is tracking, that is orthogonal to the current topic and should be condemned.

Re: The unreasonable effectiveness of simple HTML

#205
post #171

Earlier quoted context omitted.

Admittedly most is just personal preference but the line width thing is the cardinal sin. Forcing huge blocks of whitespace on either side of the text for nebulous "readability" reasons is just wasteful. Too many web sites ape this pattern too. Look at John Gruber's website [1] on a nice wide 27" monitor for an extreme example. The content takes up less than 1/5 of the width of the screen. 1: https://daringfireball.n…

While it is wasteful, I think the readability gain is far from nebulous. If you look at newspapers, they break pages up into columns. If books exceed a certain width, they get broken down into columns. Journals often break their articles into columns. Now, a fair follow-up to this is that why don't we make text on the web into columns, so instead of big sidebars of white space you fit multiple columns of text on the…

I took several graphic design classes in college, and the rule burned into my brain is "between 8 and 13 words per line" for maximum readability. This was a guideline for print, but I do think it matters on the web as well, and it's very easy to exceed!

Re: The unreasonable effectiveness of simple HTML

#206
> The unreasonable effectiveness of simple HTML

If website owner gone wild he would just disable simple HTML frontend and would bloat you to download hundreds of JS-sripts.

Still curious, why Nitter CAN provide usable & modern looking simple HTML frontend for Twitter[0], but Twitter itself can't (guess, probably won't) do that.

[0] https://nitter.net/app4soft/status/1335199292701761538

Re: The unreasonable effectiveness of simple HTML

#207
post #176

Earlier quoted context omitted.

Admittedly most is just personal preference but the line width thing is the cardinal sin. Forcing huge blocks of whitespace on either side of the text for nebulous "readability" reasons is just wasteful. Too many web sites ape this pattern too. Look at John Gruber's website [1] on a nice wide 27" monitor for an extreme example. The content takes up less than 1/5 of the width of the screen. 1: https://daringfireball.n…

I find it much worse that so many sites nowadays expect users to have their browsers maximised. Noticed how most books aren't wider than an A5, and how any publications wider than this use relatively narrow columns? Because reasonably narrow text is easier to read.

My question is why so many users keep their browsers maximized! I bought a wider monitor so I could comfortably have multiple windows open at once.

And by "wider" I mean from 1024x768 to 1080p, and by "bought" I mean "bought a decade ago".

Re: The unreasonable effectiveness of simple HTML

#208
post #119

As someone who did a lot of desktop application development prior to the web just totally gutting native app development, this is my take: The problem is that people want to make dynamic applications that have a rich UX and deep system integration while being highly portable. Unfortunately, it turns out that "portable" is basically a Great Filter for applications. If you can't run it, you can't use it and the rich UX…

My memories of non-web toolkits are not as fond as yours. You mention Swing, but I remember lots of my non-programmer friends dreading having to use applications made with Java, since they were considered sluggish and resource-intensive. They also had a certain look and feel to them that made them stick like a sore thumb compared to other apps, and a lot of people knew by looking when an app was made with Java. Java…

Back then, looking native was the most important thing. Today it seems electron apps can get away with looking anything but native - so perhaps it’s time to resurrect some other desktop frameworks (I just recently started working with JavaFX and I really like it so far. Unfortunate that it is so niche)

Re: The unreasonable effectiveness of simple HTML

#209
post #83

Earlier quoted context omitted.

What has happened in that scenario is that the designer has failed in their job. Unfortunately it’s up to engineers to catch this, which they often don’t

Designers don't really know or understand the limits of how you can style a select box. Nor should they need to. A good team will work together around the limits. Also, FWIW some of the problem is with the browser makers (still!!). CSS still has a lot of browser specific quirks when working with some components.

“ Nor should they need to.”

It’s funny - I’d expect an interior designer to know something about the limitations of the materials they work with.

Why don’t we expect this of digital designers?

Re: The unreasonable effectiveness of simple HTML

#210

Earlier quoted context omitted.

From what I can tell the short answer is that you're right, there's really no good technical reason for all that weight. Which is to say, it's just bloat. Much has been written on this. Here's an article from 2018. (I realise the irony in that it's hosted on Medium.) https://medium.com/@addyosmani/the-cost-of-javascript-in-201...

The JS performance difference between high and low-end devices is stunning (9s vs 32s load times, based on the Medium article). Web devs, who are often used to using the latest and greatest devices, will have no idea how terrible their code performs on slower devices. And I fear that modern CPUs with excellent JS performance will only exacerbate this issue

> will have no idea how terrible their code performs on slower devices

You can (and should) monitor page load performance... using JS

Post reply on HN