The unreasonable effectiveness of simple HTML | Hacker News Reader

The unreasonable effectiveness of simple HTML

shkspr.mobi

1,064 pointsedent378 comments

This is a fantastic article, it does miss one very key point about bog-standard HTML which is worth mentioning though.

The standard widgets are all accessible, people with screen readers, limited mobility, poor vision, etc, all rely on pages being written so the devices they use to read the web can function properly. People who choose to eschew these standard components very frequently end up with a site which is unusable for disabled people.

Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them.

Making your site accessible isn't just a good practice, in the US, it is the law. Courts have ruled that the ADA applies to web sites along with any other type of business. A small sample of sites where people thought they could smash together super-fancy sites without concern for basic needs of users: https://www.atilus.com/top-10-ada-lawsuits/

One of the great things about accessibility is that it often doesn't just benefit people with disabilities.

My wife and I have watched a lot of TV in the past year with the volume down and captioning on, while we enjoy some down time while our baby is sleeping.

A ramped entrance to a building allows wheelchair-bound folks access, but it also helps able-bodied people using delivery dollies.

Making simple, lightweight web pages makes them accessible to those with older browsers and devices, but it also saves power consumption, time, and frustration for folks on M1 MacBook Pros.

> One of the great things about accessibility is that it often doesn't just benefit people with disabilities.

I really love how Microsoft's design team has pushed this with their “Inclusive Design” concept[1] and highlighting how any sort of disability can be situational (holding a baby), temporary (broken arm), or permanent (missing arm) but we often only think of those in the last context despite there being orders of magnitude more people in the first two categories. Parenting is really good for showing this out since you get the need to be quiet, be able to do something using only one hand (or none), navigate sidewalks with a stroller, trying to do anything while sleep deprived, etc.

There's a great chart on page 42 (“Persona Spectrum”) of this PDF which I try to get every team I work on to go through which really gets people to think about what this means:

https://download.microsoft.com/download/b/0/d/b0d4bf87-09ce-...

1. https://www.microsoft.com/design/inclusive/

1. With due respect to various useful elements of design in Microsoft's work - this booklet reads like "We design for black people! We design for LGBT people! We design for disabled people! Look at us, we're so morally and politically superior!"

2. Microsoft makes software which costs a lot of money (for most people in the world); often a lot of money. One of the main problems people with disabilities have is low income and lots of expenses.

3. Microsoft makes software which hogs resources and thus runs poorly, or not at all, on older or simpler, low-power devices. This also not very accessible. So it might have a perfect UI experience - on the computer people don't have. Admittedly, though, this is not as bad of a problem in the past few years.

4. I wonder how actually accessible MS apps and Windows actually are. Considering how they've botched a lot of their designs in recent years even for normies (Metro; Ribbons).

It's disturbing that you find trying to be inclusive offensive because you perceive them as political opponents. I mean, who cares what people's political leanings are if they are making things better for people who haven't been well-served historically?

Similarly, while Microsoft software isn't free nothing in computing is and it seems like an odd angle to criticize an effort to help make their products better based on decisions made by other people in different parts of a huge company, or to criticize them for things in the past which they've since corrected.

I fully agree with all of your points.

I just wanted to point out the irony that the manual and other documentation for this "inclusive design" toolkit come as PDFs – the worst choice you can make if you strive for accessibility.

PDFs can be accessible, and many of them are! Everyone who works with PDF needs to know about PDF/A:

https://en.wikipedia.org/wiki/PDF/A

PDF/A is a small family of sub-formats to PDFs which amount to the accessible subset of PDF + some requirements.

PDF/A and PDF/UA are mandated by a variety of governments for PDF distribution. They're very suitable to archival and are accessible (screenreaders can work with them, their text can be cleanly copied, etc).

I may be missing something obvious, but why is pdf such a bad choice?

As long as it has actual text and is reasonably typeset (selecting text in this pdf seems to work properly), I don't see what's wrong. I'd take it any day over webpages with random floating content that you have to click through and use a modern browser with javascript without blockers/filters for the content to even render, in small text on 20% of the page, with low contrast and somehow broken zoom.

What sort of file types are preferable? I'm not very familiar with accessible tech.

To add to this, a perspective I've heard working in the disability sphere is 'everybody is disabled eventually' - be that through injury, illness, or even just old age.

This really challenges the view that thinking about disabled users is catering to the needs of a small group of the population. Whereas in fact it is bringing benefits to the majority of the population (at some point in their lives).

The culture of distraction distracts everyone from realizing they'll die.

Disability is just the fine print.

I remember walking around in a city after a parent died, and the world seemed like an illusion.

It's weird, sometimes I do something and I realize that if things had been slightly different it might have killed me.

Then I wonder if in a parallel universe I'm already dead.

Then I realize that if there are parallel universes there are probable countless times where I'm already dead.

Does not even have to be that grim/profound.

Ever used your phone in the blazing sun, or rain? Had a partly shattered screen or tried to do something on the stone-age library computer? Searched for something with really slow or shaky connection? Tried to explain where to click via phone?

Suddenly all those accessibility features and "fail gracefully" come in really handy.

It's often put as "temporarily abled" or "able-bodied".

    "We're all just temporarily abled."

is quite famous quote, as far as I traced attributed to Cindy Li.

> watched a lot of TV in the past year with the volume down and captioning onf

I like how Apple TV now lets you pair two bluetooth headsets. My wife and I can watch shows without waking the baby. Combine that with the visual sound indicator on the baby monitor, and headphones with transparency mode, we can see when the baby is making noise and hear other environmental noises too. It's a nice combination of accessibility features that make a clever setup for hearing the TV. I can't wait until Apple TV supports spatial audio... then we'll have "surround sound" in our headphones too!

Yes, absolutely.

I use closed caption when possible because often I don't quite hear things right and can't make out words. I could turn up the TV, but this means I can enjoy it at the same volume as everyone.

I also use captions (even when the TV isn't muted). If someone else in the room is speaking so something on the TV is missed, it will be shown on the captions. Sometimes there might be some word or name I don't know and will want to look it up, and the caption will have the spelling (if the caption writer has spelled it correctly, which sometimes they don't, unfortunately). It could also be used for transcripts and caption scrollback, if those features were implemented, although unfortunately it isn't.

Another great example of this is effective keyboard navigation is both an accessibility feature and something you can sell as a feature for power users who like to get things done as quickly and effortlessly as possible.

Like the apple face tracking mouse pointer, where you raise your eyebrows to click.

https://youtu.be/wAVij3tTAxE

I use a tool called Vimium so I don't need my mouse to navigate websites, and it really quickly highlights websites that have accessibility problems. Even before this though, my preference was websites that use standard elements, as so frequently people can't write robust code and boutique buttons, drop downs or other widgets break.

Indeed, I'm a double bassist, and accessible buildings are a huge blessing, especially when loading out at 2 AM after playing for 4 hours straight. Not to mention, they've probably saved me thousands of dollars in repairs.

This is commonly termed the "curb cut effect".

The troublesome grey area is the part where people do it for control.

There is also sort of "exclusive design" that is practiced. You know - where you can't get comfortable on a park bench because you might sleep on it, or a ramp or stairs are built to exclude skateboards.

Same thing happens with websites, to "control" adblockers or "reader mode" and other nonsense.

I might be misinterpreting your last sentence regarding M1 MacBook Pros. Are you saying they are underpowered for surfing the internet?

The M1 MacBook Pro is at the other end of the spectrum from the outdated/underpowered device that requires a lightweight web page. But the user of such a fast machine still benefits from lightweight web pages (faster loading times, less CPU usage, etc).

What he's saying is that this stuff has benefits even for people using modern, powerful machines like the M1 MacBook Pro.

> . . .also saves power consumption, time, and frustration for folks on M1 MacBook Pros.

Did you mean to say ". . . for folks /not/ on M1 Macbook Pros"?

> Making your site accessible isn't just a good practice, in the US, it is the law. Courts have rules that the ADA applies to web sites along with any other type of business.

This seems to imply that web sites are businesses. If my hobby sites are subject to this, I'm going to be in trouble.

If you're not selling anything, then you're not engaged in commerce and you wouldn't qualify as a "public accommodation" and the law doesn't kick in for you.

(Complete list of public accommodation is 24 USC §12181(7)--https://www.law.cornell.edu/uscode/text/42/12181).

Right at the top of that page:

> The term “commerce” means travel, trade, traffic, commerce, transportation, or communication

It is pretty funny that their definition of commerce includes commerce, but seems like communication is on the list as well.

Seems to be a common thing. One of my favourites from The Canadian Customs Tariff Schedule, Ch. 71 § 4.B:

> The expression "platinum" means platinum, iridium, osmium, palladium, rhodium and ruthenium

...and you'd be OK in the EU too.

https://ec.europa.eu/digital-single-market/en/web-accessibil...

Non-profits don't necessarily sell anything but they've been sued by the ADA for violating the laws on accessibility.

"Sell anything" is probably a bit too restrictive, but summarizing case law on what counts as "affecting commerce" is difficult. In general, you need something that looks like a service or good being provided (even if no money is actually paid for it). Something like Youtube would absolutely fall under the ADA--it's clearly analogous to a movie theater.

Let’s just be honest - anyone can sue anybody, but you’re probably not going to have problems under the ADA unless you become visible for some reason (success, expressing the wrong thoughts loudly, service necessity for a community, etc).

ADA is the American disabilities act, it can’t sue anyone.

Today I learned Ikea is non-profit....

One of the big linked sites was Beyonce's web site.

How big an issue this is depends largely on how big your hobby site is.

Update: I think this might even be wrong, its likely personal sites are fine. It's still good practice though!

The size of any of my sites is well below 1 milli-Beyonce.

Unless there's a law I haven't heard of (definitely a possibility) it would be necessary to classify it as a commerce site for the law to apply.

Taking a quick look at the site, Beyoncé has a store page on it, which would be sufficient to classify it.

> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them.

What was the catalyst behind this trend? I just don’t understand the reason behind it. Hasn’t <button> been around forever? Was there some limitation on the button tag that made the div tag more desirable?

You’ll find it’s because until “recently” (depending on how long you’ve been in this game, cough some of us since before css was even a thing) buttons weren’t stylable like they are now.

There’s no good reason to just not use buttons these days, but for a long time that wasn’t the case (cross platform).

<div> is also substantially older than both <button> and <input type="button">. The only button like thing before HTML4 was <input TYPE=SUBMIT>.

And, as you mention, the default styling was typically "make it look like the button in the underlying OS".

So there was a lot of inertia from existing code, examples, and docs that predated buttons. And a (misinformed) avoidence of it when it did appear because of styling.

The button html element is old enough to vote.

Since it's introduction, jQuery was born and died. Backbone was created and became obsolete. React took over the internet. Webpack, babel, and node were invented.

With all that change, I think it's safe to say web technologies are adopted or not based on inertia.

I think you are being over-generous.

I suspect a lot has to do with the fact that it's easier to slap together a quick list/ menu thing than it is to make a select box look the way a designer wants it to. Similarly with calendar components, radio buttons, etc.

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.

> Designers don't really know or understand the limits of how you can style a select box. Nor should they need to.

Designers absolutely need to be aware of and work within their platform's constraints, like a painter needs to understand and work with the physical characteristics of their canvas. It's this kind of mentality that results in visual specs that read "Make the window look exactly, to the pixel, like this Photoshop image!"

I'm sure the designers who work on GDS[0] and its design system do. You are probably right that most don't, they should in my opinion. Of course you are also right that good teams will work together on this. I think the best designers have an understanding of HTML/CSS or the native toolkits if they work on Android/iOS. They know when the user experience will be signficantly improved by a custom component and work with their team to make it accessible and good in those case. They also know when not to reinvent a select to make it look slightly better.

This subthread is about why divs are used for buttons and why developers reimplement existing HTML components poorly. Good designers help their teams avoid this, good engineers work with their designers to avoid it.

0: https://www.gov.uk/government/organisations/government-digit...

“ 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?

If the site looks correct visually, the designer has actually completed their job. You’ll find that very few businesses care how a page is implemented and happily pay for shit html if it looks right.

That might be the way many companies work, doesn’t mean it’s correct. Design is more than how things look, in fact how things look is secondary.

This painfully reminds me of ages ago, pre-ie6 even, when we would get html-tables, spacergifs and whatnots, blurped out by ancient Dreamweaver, Paint Shop Pro slices and such.

It looked good. But hardly worked.

Apparently the web hasn't really changed in that part: we're still churning out HTML that hardly works, but "looks good".

Ironically, it's because of the ARIA Authoring Practices guidelines[1], which include exactly this sort of nonsense[2].

[1] https://www.w3.org/TR/wai-aria-practices/

[2] https://www.w3.org/TR/wai-aria-practices/#examples

I was listening to a podcast and they were talking about using semantic HTML instead of piles of divs. One of the things they mentioned was that a survey of public web sites showed that the presence of ARIA in html was usually a sign that a site would have poor usability. Mostly because it's a sign that the site has abandoned standard HTML and went their own way and tried to patch things up by smearing aria properties everywhere.

That seems like a misinterpretation of ARIA guidelines. I'm pretty sure the guidelines are meant as "if you are going to use a div as a button, do this", not "do this instead of using a button".

Quite so.

My guess is that some learn react et al without ever really learning HTML first.

That's entirely possible. I've seen a React tutorial that shows a simple example HTML snippet, and comments on it with "We’ll get to the funny XML-like tags soon."

And then there's jsx, which is different from html in some important ways, and generally a little closer to xml.

Perhaps because buttons have some default styles attached and people just decided to use a div.

That's what a CSS reset is for.

HTML buttons have special behaviour in CSS (not even styles, but differences in the rules how they work) that cannot be reset using a CSS reset. I actually tried to make a button fit into the reset of the UI until I gave up and used a div.

Like what? I can't think of any "special behaviour" that I would not want to have in a button and that cannot be changed by CSS.

> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them.

I created a minimalist CSS framework called Neat CSS (https://neat.joeldare.com). I use anchors instead of buttons and explain why in the quote below. I'd love feedback on the accessibility of that alternative.

It's best to use semantic web tags whenever possible. Buttons are a unique case where you're typically linking somewhere, but the button tag doesn't currently support the href attribute. So, buttons are anchor tags with a class of button.

FWIW, I'm not an expert on this so take what I say with a grain of salt.

An anchor tag that links to another page but looks like a button is probably fine. So long as you can access them via the keyboard (tabbing to it) and they have a distinct appearance when focused so if you are tabbing through you can see whats active (this is different from the hover attribute).

Conceptually, those are links, not buttons. Buttons are for forms and JavaScript and such.

Fair. I would typically us a form tag with an input tag inside it for forms. Sounds like the button tag can be styled a little more because it allows i, em, br, img, and similar tags inside it, while an input does not. They are interchangable in the case of a form (based on your style need).

There are more ways to interact with a link than a button.

You can drag it to your tab bar, bookmarks or desktop, middle click to open in a new tab, copy the target URL etc.

With a button you can push it.

While I agree with your message of "make things accessible" I think you're pointing the finger the wrong way.

> This is a fantastic article, it does miss one very key point about bog-standard HTML which is worth mentioning though.

> The standard widgets are all accessible, people with screen readers, limited mobility, poor vision, etc, all rely on pages being written so the devices they use to read the web can function properly. People who choose to eschew these standard components very frequently end up with a site which is unusable for disabled people.

> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them.

Using a div as a button is not "bog-standard" HTML or a "standard component". Use a button and be done with it.

Using React or whatever does not prevent you from doing this, and in fact makes it less obvious to anyone doing a cursory review. I've not seen any difference overall in the amount of people knowingly using divs as buttons with plain HTML vs whatever framework, but I have seen an increase in unknowingly doing so by importing a calendar widget or similar without reviewing it.

> Using a div as a button is not "bog-standard" HTML or a "standard component". Use a button and be done with it.

Fully agree. In fact that is exactly point I was trying to make.

FWIW, using React or whatever makes it more obvious that you're making these mistakes because your event handlers are attached right on the "HTML" element. It makes it easy to spot because you see

    <div className="button" onClick={handler}>

and it immedaitely sticks out as a mistake. Because its easier to statically understand these mistakes, theres even tooling to automate detecting some of them as you type https://www.npmjs.com/package/eslint-plugin-jsx-a11y

> FWIW, using React or whatever makes it more obvious that you're making these mistakes because your event handlers are attached right on the "HTML" element. It makes it easy to spot because you see

> <div className="button" onClick={handler}>

> and it immedaitely sticks out as a mistake. Because its easier to statically understand these mistakes, theres even tooling to automate detecting some of them as you type https://www.npmjs.com/package/eslint-plugin-jsx-a11y

I'm not sure how you got that out of

> I have seen an increase in unknowingly doing so by importing a calendar widget or similar without reviewing it.

I'm referring to:

    <div class="div-button" onclick="clickHandler()" />

VS:

    <SomeGreatNpmWidget onClick={clickHandler} />

The point of using components is so that you don't have to look under the covers to understand them at a high level, but that also means if you don't look you don't see how they're breaking accessibility.

Got it from the first part

> Using React or whatever does not prevent you from doing this, and in fact makes it less obvious to anyone doing a cursory review

Sure. From that level it might not be apparent, but within that component the mistake would be immediately obvious, on a cursory glance. Again, I don’t think React or whatever makes this less obvious.

But really, this just isn’t a problem I’ve seen in practice. Because of good tooling, and the ease of doing things the right way, I think the majority do it well. Those that don’t were going to fuck it up regardless of the framework or paradigm.

Depends on how far you are linting it? If you lint your node_packages folder you may still catch these.

> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them.

You can add role="button" and a modern browser will treat it just like a normal button and all the accessibility that comes with it.

I wish this would be the case. The button will not be focusable, so we need to add tabindex="0". A disabled div with role="button" is not handled as disabled, so we need to take care of that. Keyboard space/enter will not be triggered on "click" event, unlike real buttons, hence excluding keyboard users. You can check my playground [1] - I'm using it to demo why one should prefer native over custom components.

[1] https://darekkay.github.io/presentations/accessible-web/reso...

That's kind of missing the point though, most bad browsers the author mentions don't do modern web very well. They're likely using an older renderer and are missing many features.

its about simple html and older devices, so just plain button will do the job.

It would be great if browsers implemented other common elements such as sortable data tables, carousels, etc.

https://open-ui.org/

This is the issue. People (especially on HN) complain about people building un-semantic, inaccessible websites that don't work with JS disabled—and I agree this sucks—but HTML is so limited your only choice is to build the niceties yourself or skip them altogether. Sure, in some circumstances you can progressively enhance (sortable table for example), but many cases having a HTML fallback that still does what you need it to is a ton of extra work.

HTML covers text, painfully basic tables, semantic rectangles (<nav>, <aside>, etc.), form inputs, and embedded media. Basically, anything you could build with a word processor. Outside of that, you're on your own.

JavaScript and CSS are continually improving and are so much more capable than they were even five years ago, but it feels like HTML is just stagnating. Why can't we have new elements every year, with behaviour? Stuff that works just fine out of the box, but can be easily tweaked with CSS or a little sprinkling of JS. The amount of developer time and bandwidth we could save not having to re-invent the wheel for every little thing.

You have a great point. Browser UI elements are stuck in time and all the attention now is directed to things that Google can make money from (e.g. DRM, sandbox for rich apps/extensions, webrtc for their video call products, etc)

but your cited site is not a good advocacy of that. Not even the most exalted UI framework fix the most obvious problems with those either. e.g. tables still won't hold the header and first column(s) while scrolling.

Most of the these elements does not help consuming information, like carousels. And any true UX designer abhor them all for the fallacy they are.

> e.g. tables still won't hold the header and first column(s) while scrolling.

https://caniuse.com/css-sticky

position:sticky works on tables.

It's all red :( No support anywhere but Firefox. In fact, I will now use this URL as my main argument in support of firefox!

even the grand-parent, javascript infused solutions, only two out of 20 support this extremely basic and obvious use case.

Web UI standards are a joke. Everyone involved only cares about rich ads and accordions/carrousels which are lame ways to shove lots of content in a badly designed space.

Are there any automated ways to assess a web product against the Web Content Accessibility Guidelines (WCAG)? This should really be part of the CI/CD process.

There's a Firefox/Chrome extension called Axe that's pretty good. We use at my company it to make our products accessible and it helped us tremendously.

[1] https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/

[2] https://chrome.google.com/webstore/detail/axe-web-accessibil...

The engine behind that add-on, Axe core, can be called from JS and there are some open source tools around to integrate it in your CI. I would say Axe is kind of the gold standard at this time when it comes to automated accessibility testing. Not because it catches the highest number of issues, but if it flags something you can be pretty sure it's a real issue and not a false positive.

Shameless plug: at work we created axe-storybook-testing [1], which can be used to run accessibility tests against Storybook stories [2] on CI.

1. https://github.com/chanzuckerberg/axe-storybook-testing 2. https://storybook.js.org/docs/react/get-started/whats-a-stor...

Oh, this sounds interesting. I’ll have a look.

our web team wanted this in the CI/CD https://allyjs.io

edit: actually it's spelled https://pa11y.org

Yes, there are a lot of tools. None are great and are mostly for compliance.

Products like Siteimprove are targeted at Enterprise (e.g. demos with sales weasels, unpublished pricing, etc). They mostly suck but check an auditing and compliance box.

Would be nice to have an html builder that follows all these best practices. That would also make it nice and easy to apply different crowdsourced themes.

That was the original idea behind HTML.

It might not get rendered the same everywhere depending on the device receiving it.

If the goal was to send pixel perfect pages, the web would have settled on postscript + hyperlinks.

> Making your site accessible isn't just a good practice, in the US, it is the law

> Courts have rules that the ADA applies to web sites along with any other type of business

For a business like a coffee shop I'd imagine that accessibility is codified in law through things like building regulations (ie, you must have n disabled parking spots per square foot, a disabled toilet, etc)

Is there an equivalent legally codified and enforceable standard for the web?

> Is there an equivalent legally codified and enforceable standard for the web?

More or less yes. The link I posted has a few good resources, but generally speaking sites need to work with a screen reader and they need to be accessible via the keyboard (which by extension enables other accessibility devices).

This site has some more guidelines. https://www.essentialaccessibility.com/blog/ada-guidelines

Generally speaking, if you start with existing components that do the thing you want done, you have a huge leg up. If you try to reinvent the wheel, you are likely in for a lot of trouble. The more complex the control, the harder it is to roll your own. Calendar controls and Selects are particularly tough to get right.

UPDATE: Also, the wc3 has some good guidelines which should cover your ass.

https://www.w3.org/TR/WCAG21/

I have had a lot of success with this course (Web Accessibility, by Google): https://www.udacity.com/course/web-accessibility--ud891

> In this course you’ll get hands-on experience making web applications accessible. You’ll understand when and why users need accessibility. Then you’ll dive into the "how": making a page work properly with screen readers, and managing input focus (e.g. the highlight you see when tabbing through a form.) You’ll understand what "semantics" and "semantic markup" mean for web pages and add ARIA markup to enable navigating the interface with a range of assistive devices. Finally, you’ll learn styling techniques that help users with partial vision navigate your pages easily and reliably.

There is not a codified standard however that doesn't stop websites from being sued

If you comply with the WCAG 2.1, you have a pretty good legal defense. While it isn't "Law", it is the most widely known published standard and likely to be added to the law soon.

https://www.w3.org/TR/WCAG21/

> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them.

Gahhh. I use either an <a> or a <button> and put style on it. Has all the same visual appeal of the equivalent div. But it already is a button.

> use either an <a> or a <button>

Generally, it should be noted that an <a> tag is only appropriate if it makes sense to right-click this element and get options to "open in new tab" or "add to bookmarks". All the stupid "buttons" implemented as <a href="#"> + e.preventDefault() need to die.

Yea I use <a> if it's a navigation button for react-router. But it still shows up like a URL because we're using the Browser history (it just updates the URL and renders the new page, each route has a URL and resource id's are in the url). As opening the URL directly should work (if authenticated) it makes sense to use <a> tags.

I remember learning about HTML for the first time, maybe in Byte Magazine. It was before I actually had a computer with a browser. But the article talked about a benefit of HTML, which was that the tags could be interpreted by custom browsers for accessibility, including for the blind or sight-impaired. It seemed like a pretty cool idea to me.

Later on, when people started treating web design as a general purpose graphical and GUI framework, many of the accessibility benefits probably vanished.

Yeah, nowadays most of the sites are suffering from div-ititis that has no semantics, massive blackholes of JavaScript that have to be loaded and processed before you can even see plain text, and CSS class names that are randomly hashed with each deployment in the name of modularity.

General accessibility be damned.

UI customizations in the form of browser extensions and styles be damned.

Ad blocking be damned.

Designing for people with disabilities usually increases the overall UX for everyone. I see it a bit like resistance training for fitness - you train in a 'more difficult than normal' scenario, and then when you return to normal it feels much easier.

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 likely I just don't understand the allure as an clueless user.. I am almost tempted to make a webpage to see what the big fuss is about!

As someone involved in hiring, this is what Bootcamps and Universities are teaching, and what companies are looking for: backend spits JSON, frontend consumes it using React.

Rendering HTML on the server is not really "the default" anymore as it was 10 year ago: it's more of an optimization for when your React site is slow, and it's a black box to most people. Even static websites are "strange tech" to new graduates outside the HN bubble.

Also, developers hate mixing tech. You mentioned an "interactive map" in your example. This can be made with React or something like that, right? The issue is that a lot of developers will want to use React for everything else on the page, because they think it's "icky" to use other kinds of tech in other parts of the website. They sorta have a point (the "microfrontends" discussion was a thing a couple years ago), but on the other hand they're not considering the tradeoffs.

Also, the frontend is officially the centre of the application on medium sized companies (50+ devs). It's way easier to add new code to the frontend and spin another microservice than to coordinate between multiple teams of backend engineers.

I'm not saying this is good or bad, btw. It's just how it is.

EDIT: One thing that really bothers me that people fresh in the industry don't really believe that websites were faster 10 or 20 years ago, so I don't really see any light at the end of the tunnel. Sure we can do new things on the web, but what was already possible before has been made slower by our collective refusal to "use the right tool for the job". Even the frontend tooling today is very heavy and slow, and I'm in a 2020 MBP. I don't think we progressed much. React is an amazing idea (and the implementation is great), but the community has become too dogmatic.

A few years ago when teaching at a previous coding bootcamp that started with FE JavaScript, I remember my surprise when well-performing students got through 3 months or so of it and were confused and very impressed when I showed them how an <a> tag worked, since they had only been aware of (jQuery) JavaScript powered pages. When you are stuck just doing JS powered SPAs, an <a> tag seems like advanced technology!

I ended up at a new school creating a new curriculum. This approach is where we "recapitulate the evolution of the web", so we start with SSGs & server-side programming (Python/Django), then only at the end cover SPAs and React.JS -- since, as you mentioned, that's still the main skillset that companies are new devs for.

Almost every JS app I have seen uses a tags though. Even if they are just links to # pages. With most router libraries you can even use real paths and it works all on the front end. Sounds like you found one anecdotal case that didn't know this.

Maybe I wasn't clear -- What I meant to say is that the curriculum barely covered <a> tags, but instead started just with JS DOM manipulation, which meant students were using document.location on click events since they weren't taught anything else. This isn't a criticism of JS best practices, instead it's a criticism of how it's taught, specifically in this curriculum that's sold as a white-label curriculum and used by MANY bootcamps across the US. It might even be the most popular coding bootcamp curriculum in the country. It's possible they've improved it since I was teaching it, but definitely it was not the case a few years ago!

It definitely happens. I've seen some internship/junior interview tests where candidates use javascript's window.open or window.location to link to some fixed destination rather than just using an anchor tag.

>The issue is that a lot of developers will want to use React for everything else on the page, because they think it's "icky" to use other kinds of tech in other parts of the website.

It is though. I work on an app thats 80% react and 20% rails SSR and when working on anything, seeing that an area that needs change is written with SSR makes the job 10x harder as you have to come up with alternative methods to get it working or just rewrite it in react. When everything is react everything is quite easy and you can pass around data and update things without a refresh easily.

> seeing that an area that needs change is written with SSR makes the job 10x harder as you have to come up with alternative methods to get it working or just rewrite it in react

Without details it's hard to know what you mean. Do you have an example?

It feels more like the SSR part was not the right tool for the job in this case (or maybe it was from the speed point of view and not development). Your point seems to be that react is better than SSR and not that mixing technologies is bad.

Thanks for the response, very informative, I feel it explains a lot of what I was confused about.

So maybe a simplified view for me is: massive adoption of JS + frameworks, cookie cutter development, no point learning anything else when you have the golden hammer.

I actually thought you still did learn HTML and stuff before the digging into the frameworks. But maybe it is analogous to learning assembler before python, i.e out of fashion and not needed to get the job done.

In this context what seems like the simpler and more suitable solution to me (static HTML+some minimal JS) might not be on the map for most modern web developers. What they do is overkill but it is what they know and it gets the job done.

One thing I love about Svelte/Sapper is that it can be used for both the server-side rendering and the interactive map. And it doesn't feel like an afterthought - idiomatic usage leads to server-side rendered html with progressive enhancement of JS.

Big lols on this, ~They think it's "icky" to use other kinds of tech in other parts of the website.

Does anyone remember Google Web Toolkit when Java came to the front end.

History repeats. Again and again.

Patterns may repeat. But everytime it is different.

Oof. Yeah, I am now very glad I got out of that game, does not sound like a nice place.

SPAs were for a specific, narrow, set of use cases where it really didn't make a lot of sense to even have a backend...

Companies don't really have the incentive to build good software, though. Fads and cargo cult 'lets use this popular BS' tend to catch on more when the name of the game isn't software, rather its about pandering to a job market. Outside of sudden and painful corrections that market seems to promote bad engineering, probably because it costs more over time to maintain and thus creates more demand in a 'negative' positive feedback loop...

Trying to legislate it back in by pointing out that most sites are hot piles over garbage that are unusable by anyone with any sort of impediment (physical, technological) seems like a nice idea, I don't see much growth in that area anyways so perhaps it is time for strict law enforcement...

The fact is, the Javascript ecosystem is unmatched when it comes to very quickly creating frontend applications. Maybe another set of tools would have been better, but that doesn't really matter. This set of tools is what everyone uses, and a lot of effort and creativity goes into making js frontend development as smooth and fast as possible.

I often need to very quickly make internal services at my job and while I like working in other languages (and i do for longer term projects), those always take longer to set up and get working. In js with next you're up and running in less than 60 seconds and if you're doing crud stuff, most of the work is frankly done for you.

I disagree.

Rails was already faster for CRUD apps back in the mid-2000s. Batteries included, maybe a gem or two for an admin panel or for auth. Not that it matters, but rails new is probably faster than 60 seconds too. Django is pretty good too.

ASP.NET Webforms was made for CRUD, and it even provided a WYSIWG designer back in the early 2000s. And it was just a matter of launching Visual Studio and creating a new project. Again, doesn't matter, but it was/is way less than 60 seconds, and a lot less fiddling. Webforms got an MVC version a few years later if you prefer that. And they haven't stopped: Blazor is new-ish and very productive, and runs both in the backend and in the frontend (using WASM).

Both Rails and Microsoft tech also give you a backend, which you're not putting into your equation. Sure you can have a Backend in JS but the experience it's nowhere near as ergonomic or as fast as using Rails or ASP.NET.

Sure, if you're comparing with building an app in Xcode or Android Studio then JS tooling is faster to use. But if you compare to what people were using to build CRUD for the last 20 years then JS is not really special. For interactive frontend apps? Then it's a different discussion. But for CRUD, modern JS is not that special.

I can't really speak to all the technologies you mentioned, but some of the other apps I maintain are in python using django. It is also "batteries included", and does give you more tools out of the box for backend work. It's actually really nice to work with and maintain in my opinion.

I would say though, that for very quickly creating new applications that get the job done, js has been the fastest for me. And while django and similar give you more database stuff to work with, honestly that feels like a solved problem, and it's often easier to not have to do any backend work at all, and instead use something like hasura. And next does include backend code too for functions that you need to write for the backend.

Obviously, this isn't ideal for a lot of problems. I think if you can get away with it, you can be really productive. I've made crud apps for work with this stack in very little time.

It's unbeliable how many things Django gets right out-the-box. I am talking about things like i18n and i13n which are usually are afterthought for most of these frontend frameworks but Django already includes a amazing system for it.

You cannot compare those though. Rails is entirely different from plain Ruby. If you want to compare you need to take something like NestJS, which approaches Django in immediate useability.

Rails is an excellent choice for the backend but on the frontend its much less productive than react. Most rails apps these days would use rails as an api backend and react on the frontend.

It really depends what for. For CRUD apps or static content, Rails still has an edge. For something else, like rich apps? Sure, JS beats it.

> and if you're doing crud stuff, most of the work is frankly done for you.

React sucks for large complex forms unless you pair it with another technology or two.

Want to write a crud app fast? C# and Winforms.

Couple years back, I once did a prototype of a web app in C# and Winforms connected to Firebase. Less than a day, done.

Month later, had it working in React. Granted the React website looked nice, but the difference in efficiency is huge.

Data binding 20 fields on C# is a matter of minutes. Data binding 20 fields in React, and with Redux, ugh. I really should have just learned Redux Forms.

And for any given forms library in React, you then get to practice learning how to beat it into shape and style it how you want.

I, no kidding, think writing CRUD apps was easier with VB6 and Microsoft Access.

That's really interesting, I should look into that pattern, maybe it can be applied elsewhere (I have to maintain a vb6 application at work, and I'm not terribly interested in doing that anymore).

Yeah working with redux sucks in general imo, I try to avoid it when I can. If I can get away with it, I try to avoid the problem entirely by using hasura as a backend. But sometimes that's not viable.

> That's really interesting, I should look into that pattern, maybe it can be applied elsewhere (I have to maintain a vb6 application at work, and I'm not terribly interested in doing that anymore).

I hadn't used C# for years, I was shocked that the winforms designer duct taped to a community contributed Firebase library, was able to get a prototype out in hours.

I had been using JS for 2 years at that point. I estimate at 10x-15x productivity boost in C# over JS.

The C# tooling is just that good.

Now if I'd been trying to learn XAML or something at the same time, eh, probably wouldn't have gone as well.

Of course the downside here is that a Winforms app is hard to distribute, and usable only on Windows desktops.

The react web app was, well, beautiful, and usable everywhere.

But I could have written the C# app once for every platform I care about and still been better off.

Ugh, I am sad that Winforms is only ever going to be Win32 based.

I'm interested in knowing how you get to do "crud stuff" so fast with Next.js

- How do you do validations?

- How do you handle database migrations?

- How do you handle background jobs?

- How do you handle authentication?

- How do you handle authorization?

- How do you handle file uploads (to filesystem or S3)?

- What ORM or database toolkit do you use for queries?

- How do you send emails?

- How do you do websockets/real time?

All of these of course have answers, but each one of these comes with a lot of "decision fatigue", discussions, maintenance work and I highly doubt the cost of reaching the same level of robustness of a full stack framework is any smaller.

Real life production "CRUD stuff" is not just some http handler doing sql inserts into sqlite. There's a lot more involved. That's what Rails/Django/Symfony give you a solution for. I agree Next.js could have a faster startup for a landing page. But as soon as you need the most minimal backend, you are way, way, way further to get something robust working if not using one of the full stack frameworks.

This is just a personal preference. I would say the same about Python / Django: You get extensible login/signup/password-reset/etc authentication & user-permissions management, and even an admin interface with user groups, right out of the box. I can put together a web app in "60 seconds" that would take weeks to assemble using the JavaScript ecosystem. Having taught classes on both, I'd also say it's also easier for beginners. Again, might be my own bias or other factors, but it seemed to me that the Python/Django student's final projects have on average "out-shown" the JavaScript SPA student's final projects in terms of features that they had time to complete.

This isn't to hate on JS, this is just to acknowledge that other languages and frameworks have substantial advantages in many use-cases.

Django's user system is .. limited. You need a bunch of third party libraries to add very commonly used things such as auth APIs, oauth, 2fa, etc.

I've worked with Django for over a decade and i dislike it more and more. It hasn't evolved to match the environment around it and how to best use it. Typing is missing. Something like FastAPI is very promising but Django's admin is still superb for prototyping and its orm is a lot more instinctive so i put off switching away ...

Agreed, it definitely is limited. Also the admin panel is limited too, and although it's very extendable, the admin extension API is kind of clunky and inconsistent at times. Yeah FastAPI looks great! I've used Sanic in the past and FastAPI seems cool for some of the same reasons. I'm also following closely Django Hotwire - https://hotwire.dev/

I only brought up Django in a narrow context to challenge an assumption made by the post I was replying to, that seemed to imply that JavaScript ecosystem is indisputably the fastest for rapid prototyping. Hence my providing of a counter-example. I think this is especially true for new coders, as having certain things out of the way is super vital to keep motivated when building MVPs -- I've seen many students give up on ideas simply because implementing authentication with a Node.js-based stack was too challenging, when they would have been happily coding away had we been teaching a batteries-included framework (django / rails / etc).

The cost of developing in JS isn't necessarily lower, just amortized. Or in many cases, externalized to your users.

> externalized to your users

You mean if you have customers with less powerful devices like the OP? I don't really see internal services or B2B products having that problem.

You original point

> the Javascript ecosystem is unmatched when it comes to very quickly creating frontend applications

Didn't hinge on whether you were creating internal tools or not. You simply used internal tools as an example of what you personally do with JS.

Javascript is as privileged as programming languages get. It's welded into all web browsers except perhaps Lynx. To get traction, an alternative language would need to be simultaneously included in several browsers. Good luck with that.

Only webassembly can save us

Some people are used to using javascript packages (so importing a whole framework when they are only using a small portion of the functionality) to help with UI like collapsing/expanding menus depending on the screen width. You can do a lot of those things with pure CSS now, but that's a more recent thing and a lot of popular tutorials are still JS + CSS.

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

I had always been using 2-3 year old android phones for the last 7 years and I was unable to comprehend how anyone uses the web on mobile because everything was so incredibly slow in the browser while native apps were fine. Then I got the latest iphone and my mind was blown at how I could scroll a website at 60fps. I guess if you have the fastest phone on the market, everything seems fine.

It's strange as poor performance is known to be off-putting to users, which presumably translates into less traffic and thereby less profit for the site.

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

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

As an Android developer who's now making a hobby project that has a web UI, I don't understand it either. I'm doing it the old-fashioned way and it's so fast that my browser doesn't have the time to display a loading animation when I refresh the page.

It's a bit more complicated than that. Modern web development done correctly can help: Pages are generated in the server, no JavaScript required. If you start with a PWA mentality, then your application/site is progressive and you should cover everyone; or almost.

However:

1- Progressive is expensive. You'll need more time as you need to sort what features can work; and work your way up to the full experience. The full experience, however, is what you are getting paid for (or showing). Unless the client or the company cares about these categories, you don't want to expend budget on that.

2- Web development is becoming complicated. You can get started quickly with Nextjs/Gatsby thanks to "DX"(Developer Experience). The reality is that you don't understand much of what's going on behind the surface and if you bootcamp-ed your way in 3 months, you probably have no idea what's going on. But it works!

I agree with you. It definitely does not serve the user. I have two thoughts, as a nobody.

1. Ads/trackers/etc. need javascript 2. It's a way of flexing and saying "we have resources to put into this webpage which makes us a serious business."

Any other thoughts?

Things that are running based on JS on "regular" sites from the top of my head:

- Toggling widgets such as menus, modals and other things you only want to show when the user requests it. This includes updating accessibility related HTML attributes.

- filtering, sorting etc. of larger data sets in the client.

- live updates of fresh, time related data

- search that doesn't force a complete reload, via AJAX or cached on the client.

- smoother page / content transitions via AJAX

- everything related to forms / user input: you want to instantly react

- managing and preserving state / context per user

- visualizations / graphs that are explorable / interactive

- polyfills for older browsers that don't support optimizations such as lazy loading.

- interactive widgets such as chat boxes (not a fan but still)

- testing and analytics

A website isn't made of paper.

Yes the ads/trackers/etc is most likely a reason that a webpage cannot be completely without javascript.

Two other possible reasons from the top of my head:

If a web developer is hired to make a site they can probably charge more if it is a fancy javascript site. In some cases it might be in their self interest to up-sell this to a client that does not know better.

If a web developer makes a site for themselves I am sure many want to take the opportunity to get some experience in the latest web-tech while they are at it. Just as I will use an obscure programming language for my next side project..

> Whats with all the javascript?

On blogs and news media site? mostly ad tech .

The irony is that it took AMP, a proprietary solution, for all these websites that mainly deal with text and image, to start cracking down on all that stuff.

Remember "mobile first"? Well the majority of web developers clearly do not have a Mobile first strategy, when you look at how heavy their webpages are.

Even the javascript could be lighter, but since everybody is using node.js and NPM behind the scene with a lot of complex modules, well code bundles become crazy big.

I'm not either, but I've written quite a few webpages over the years, and even the occasional use of JS, but only when it's not possible to do without.

I suspect much of the superfluous JS comes from a " if you have only a hammer, everything looks like a nail" mentality.

Yes, the Emperor is bare-ass naked, now hush before you get someone fired.

In the end, I just end up using Firefox' reader mode, because what I really want is the main article. Everything else is noise.

> Whats with all the javascript

What's with all the server round-trips? If you have a UI that takes user input and just reacts to it, without any data needed from the server -- why should it go on a full round-trip just to get a new UI element that it could create locally just as well?

Look at other things on your computer: a text editor, or a calculator. Would you expect every interaction to send a request to some remote server just for the sake of it?

Shitty server code isn't an excuse for shitty frontend code though.

Moreover you are confounding apps with the web. A calculator should probably never use the network...

Pretty much every web browser can and has to open and send network packets - as long as they are small and there is not a lot of state, you are fine. You can support almost any device from 20, 30 years ago.

'Modern' JS dogpiles huge swathes of mostly unused, uncompiled code, resulting in huge network transfer costs, extreme overusage of CPU and RAM, and encourages a lot of e-waste because it mainly only works well with the latest devices...

It's arguable that this is such a bad engineering design, just to save some network packets, I wouldn't be surprised if the carbon footprint of a JS developer was at least similar to that of burning coal...

I have done a lot of front-end work, and full stack work. I do not understand either.

I think the bloat comes from a few places:

Developer productivity: Making complex pages and reusing components across pages is much easier with a library like React than with more vanilla approaches. For a lot of companies with large numbers of engineers, making sure that engineers can be productive without intimate knowledge of HTML/CSS ends up taking priority over things like performance and accessibility.

Branding/customization: The built-in HTML controls are difficult/impossible to style or customize. A lot of UI designers will design some fancy looking select dropdown, not appreciating the fact that they're forcing developers to reinvent the wheel in order to implement their design. Alternatively, there are cases where the UX for built-in controls is lacking enough that you're somewhat forced to implement a replacement (e.g. <select multiple>)

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 a server to it, everybody will complain that the application doesn't respect the user's privacy, since it could be offline-only but it's not.

Don't get me wrong, I think "interactive" can meaningfully include a simple site with links if you are looking at it from a privacy angle. Just look at how StackOverflow recently was able to track all the pages their hacker viewed. [1] SO is pretty much static content. So do you want StackOverflow to work without JavaScript? Are you happy that in-so-doing it needs to phone home whenever you look something up? You can't have one without the other.

There is also the argument from scalability. You'll get less QPS on your servers if you implement a 3-step form with validation in the frontend, and send off all the data in one go. It's also faster/better UX and is more resilient under bad network conditions.

Edge computing is maybe an alternative there, but that doesn't address inherent privacy concerns of phoning home to a server.

Last there is the reality of a spectrum of interactivity of websites. If you are doing a blog, sure, don't do it in JS. At that point you make a decision to make it difficult to add any interactive features to you site which require JS. If you are building an evolving app with interactive features, there aren't many options for easily mixing static HTML with interactive JS. You could see how far you get with static HTML but then what if you need interactivity (JS/JQuery)? What if you need complex interactivity (React)? Are you willing to pay the costs of a heterogeneous app architecture of HTML mixed with interactive JS?

Think of Facebook. It is kinda like a blog, but what about infinite scroll? Etc.

Anyway that last point, I think, is why people are excited about 37signals' Hotwire[2]. It's more of a HTML-but-interactive architecture as opposed to the fully-interactive JS/React vs static HTML forms.

[1]: https://stackoverflow.blog/2021/01/25/a-deeper-dive-into-our... [2]: https://hotwire.dev/

You answered your own question:

> 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 a server to it, everybody will complain that the application doesn't respect the user's privacy, since it could be offline-only but it's not.

That's the gist of it. Don't use JS if not absolutely needed (or at the very least, don't make the site break without JS enabled). If needed, consider whether there is a valid technical reason why this should be a server-dependent web app in the first place - and if there is, consider supporting off-line mode where possible anyway.

It's a perfectly valid position to hold. It's a user-respecting and waste-minimizing view.

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.

Made me think of a time I didnt do adequate research before buying an expensive flight ticket: I was in Changi Airport and had a cheap return ticket to Malaysia, when I got back I was going to travel in the east coast of Australia for a few weeks as the end of my study abroad in Asia. It dawned to me that I never actually checked the Visa rules for Australia, but just pressumed that they would be like any othet commonweath country I had previously visited. Turned out I was lucky and didnt need a paper visa, but could do with an e-visa. As my HTC Desire Android phone had died in the humiddity, I only had the cheapest nokia I could find, X-1 ... Armed with a 2011 public internet kiosk of internet explorer, I tabulated through the australian immigration forms and found the correct form, filled it out while my browsing session of the kiosk expired, after a few tries, I knew exactly the way around the static site, and was what some would call "speedrunning" through their website. After sumbitting I just had to hope for the best. If that site had been required any more than it did, I am not sure I would have been able to submit my application through that public internet browser.

Another example: a train schedule site that requires the latest approved browser. If you want to travel, first make sure you're not in the middle of nowhere.

Talking about the sun ... We got a variant of those credit card sized NFC cards to check in to public transit, the issuer decided that they should have an expiry date. From what I remember reading in local tech news, the logic was that people bend/break them over time, making them have a measurable lifespan.

My card actually expired in the middle of the countryside, and phone support just told me to get a replacement in the nearest convenience store.

I could have been prepared for this if I had checked the expiry date and put it in my calendar, but how many people do this?

btw, apologies for typos in my post above, it went quick, and was typed on touch screen.

Love this:

> Go sit in an uncomfortable chair, in an uncomfortable location, and stare at an uncomfortably small screen with an uncomfortably outdated web browser. How easy is it to use the websites you’ve created?

It's so easy to get disconnected from the real-world applications of our technology. Build user empathy.

My favorite example of this was when I worked on a B2B product with a daily email report. We noticed the most common usage of this email report came from native iOS email clients first thing in the morning.

As a test, my team all went home and practiced being the user. We had a test email sent to our email addresses we would open first thing in the morning and attempt to make sense of it while laying in bed.

The result was a lot less cruft, bigger text, and key takeaways above the fold.

I love examples like this, I hope you don't mind me tagging on my own.

Our team was doing in home interviews for a TV product. One of the customers subscribed to an expensive sports service and yet barely ever watched it.

When we probed it was because her two sons had left home in the last year and she knew they would come home when a game was on if she had the service. She said that she wish she knew when big/popular games would be coming up so she could invite them around and see them more often.

We trialed a fortnightly email newsletter for people that were subscribed but not very active. And saw a decent uptake in viewing almost immediately.

Very poignant example!

In terms of dispassionate product analysis, nice job using emails to reengage users at risk of churning out.

Years ago I noticed that when I was hungry and tired, I would notice just how much bad design got in the way of completing a task. Things that I would work around easily when I was well-rested and sated all of a sudden became incredibly frustrating. Unclear instructions, or buttons that were hard to find, or error messages that were inscrutable suddenly became very obvious.

I posited that it would be an interesting user test to have someone who was in an irritable mood try to use your product. I've never actually done this, and I still think it would generate interesting feedback.

That sounds similar to https://theuserisdrunk.com/

The guy behind the site will get drunk and then test out your website.

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 and deep system integrations don't matter.

So developers cast about looking for alternatives to Qt and GTK and friends. Flash and Java (and Silverlight....) all had browser plugins and offered vaguely convenient APIs for building applications with rich UXs. Unfortunately those plugins had inherent technical issues and died (or were killed, as it were).

So what platform remained that had super easy distribution and portability? A XML document format that supported directives for styling xml and some rudimentary scripting language that could dynamically change that xml and styling.

So that's what ended up getting built upon. And now, since abstraction can do anything, we finally have things resembling what we had 30 years ago in desktop applications but built on top of a standardized runtime with a JIT and a sandbox and a nascent assembly language. So that's finally what people use.

I really had nothing but disdain for web applications built with javascript/jquery soup for the longest time. They worked, sure, and printed money and all that, but I was bitter that such poor technology was what won, instead of some evolution of the existing desktop app paradigm.

Now with React et al it's finally getting bearable again. But I still find myself wishing I could just say forget all this web junk, I could write this as a Swing or JavaFX program in 10% of the time.

(It's just unfortunate that nobody would be able to use it because nobody downloads programs off random websites anymore except Putty and nobody has an (independently-installed) Java runtime anymore. Which brings us right back to the initial problem).

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 was actually pretty fast even back in the early 2000s, but thanks to Swing et al (and to the JDK requirement), Java desktop apps had a reputation was much worse than Electron or JS-heavy websites have today. Especially among non-programmers.

Strangely, OTOH, Visual Basic had a terrible reputation among programmers, but most Windows users had no idea about it since it used native widgets.

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)

My problem with the default Swing theme, and any theme in Java at the time, was that they were so ridiculously ugly compared to the system default.

It wasn’t exactly easy to make your own theme either. Something that HTML allows without almost without thinking.

Yeah, I agree. But Swing has some cool themes nowadays. (And JavaFX is pretty easy to theme, but I have not yet tried it extensively)

I think the issue with Swing was that is was in a bit of an uncanny valley. If all controls were custom it wouldn't look strange.

Visual Basic was very... well, "basic", so it looked normal. Some tools like CCleaner and a lot of Antiviruses had fully custom looks, but didn't look out of place, because they were too different.

JavaFX looks fine, though.

> It's just unfortunate that nobody would be able to use it because nobody downloads programs off random websites anymore

But they do, just in javascript format! I still am bitter such a poor technology won.

I suspect there is a growing web developer conspiracy to fight overconsumption and climate change.

I see slow websites with carousels of large images with big texts. They link to value statements, mission statements, experiences, goals, community bullshit. If you want to know products, prices, or even what the site is all about, you must squint your eyes and really concentrate, maybe scroll down to the bottom of the page. I save €1000 per year in impulse buys because of these sites.

Somehow we've regressed to 2000s levels of aggravating websites. When I want to buy a thing from a retail chain, I go to their site ready to search and have to click through multiple pop-ups first. No I don't want to subscribe to whatever bullshit, no I don't want to allow access to location data, no I don't care about stupid cookies, no I'm not wasting time talking to a chatbot that interleaves computer generated and human generated text with unpredictable delays. Just get out of my face and let me buy the thing I'm here for. I could understand all that for, say, a news site where they need to suck you in to subscribe for them to make money, but not a retailer where you're obviously there because you already want to buy something!

> I asked about the PSP – a hand-me-down from an older brother – and the web browser. Her reply was “It’s shit. But it worked.”

This is particularly high praise for simple HTML as the shit part is likely the PSP's UI, which is of course out of the control of the website, whereas the it worked part is due to the PSP's browser and the website both working adequately.

Good on GOV.UK for doing it properly.

Those are not ‘crappy browsers’. If we call it “Browser” it should be browser, isn’t it? It should brows pages. It was never intended to be overweighted virtal machine and not a good one by the way.

Past 8 years or so Youtube has nothing really more to offer then it was offering back then. The only new things it offers for me is overweighted dumb slow shit that fails to perform what it was perfectly doing 8 years ago, and all those slowness added for no particular reason that I could appreciate.

All of this ‘comfort’ is getting on the way or doesn’t work at all. Perfectly capable IPad Pro now is struggling to load even Youtube.

Almost every site I visit is bloated with idiotic unnecessary things that do not not even work properly.

And once you see some new idiocy appearing on some big site, the first thing you think is :‘oh no’ because you can be pretty sure that every “designer” would copy this bullshit and it will appear on every site very soon for no reason. If that is not a dumb design by definition then what is? I would not call it even design. Those are layers and layers of garbage piled on top of each other and at this point when I see simple HTML I just wish to thank the author for lack of so called “design”.

It’s not crappy browsers - It’s crappy sites overloaded with useless features. I didn’t see One big site lately that did become better ... not one! I wish to see one, show me one please. I wish to be mistaken there but I think it simply doesn’t exist.

Oh, YouTube. I'll never understand how they made it such that when you open your subscriptions page it first loads the list of videos, and then, 5 seconds later, shows their durations. Or how the player UI is unresponsive for several seconds after you open a video. That took some special talent apparently.

>you open your subscriptions page it first loads the list of videos, and then, 5 seconds later, shows their durations

Every time this happens I have this horrible feeling that they just removed showing video durations entirely. Which wouldn't even surprise me, I could imagine them doing some stupid A/B testing to discover they got more people clicking around when durations were removed.

But regardless, it's insane that one of the biggest sources of internet traffic on the planet is software that can render a bunch of images (thumbnails) but it takes several seconds to display a few characters of text on them. I don't know if they're grabbing durations as a separate API call, or if that's just how slow their JavaScript is. Either way, it's pathetic.

> It was never intended to be overweighted virtal machine and not a good one by the way.

Citation needed. It's been two and a half decades since people started using the web as more than just a delivery mechanism for text and images.

As an example of this, forms were in the HTML 2 spec of 1995, and you’ll recognise every last part of it as still working exactly the same way: https://www.w3.org/MarkUp/html-spec/html-spec_8.html. (<input type=image> has fallen into disuse and <input type=reset> is rare and generally discouraged, but all the rest is still universally used.)

longstanding use != intended use

> It's been two and a half decades since people started using the web as more than just a delivery mechanism for text and images.

I still do (mostly)

Client-side javascript is underrated. We put simple websites in embedded devices with shockingly low memory/flash. They're for configuring the device. The pages are pretty serviceable with html controls, color schemes, logo etc. Embedded javascript to make them responsive. A couple of kilobytes total html.

I concur. I wrote a web interface for a crappy 20yo DSP last year, the thing doesn't even have an MMU and only 32MB of RAM. I basically put all the code in the browser, on the device there's only a very simple C HTTP server that serves the static files and blobs of data. In the end the UI looks fairly modern and responsive even though the backend is potato hardware.

I wouldn't say that client-side JS is underrated though. If anything I'd argue that the modern web heavily abuses it. Try browsing twitter or youtube with Javascript disabled for instance. The site simply won't work.

For YouTube I kind of still see a point, if only to not make scraping videos dead simple by not just having the plain URL of the video file in the html (yes there are still tools out there).

But twitter is so ducking ridiculous in that regard. At its core it is a web site to share 280 character long strings, but as of recently you cannot do this anymore without JavaScript! They shut down the legacy page at the end of 2020 that was blazing fast and a pleasure to use. And what irritates me the most about their modern Js based mobile page is that it frequently happens that I tap a twitter link on HN which takes forever to load, then it shows two blue spinners one at the top and one in the center and then after another eternity it says "this content isn't available". Then I hit reload, the whole thing repeats and this time the 280 characters display just fine. How? Just how do you end up with this?

I would argue that the fact that video content is often so frustrating to scrape is symptomatic of the massive cultural shift the web has seen over the past decade or two.

In the "old" web you could basically right-click -> save anything you want (ignoring plugin blobs for the sake of making my point more compelling). Meanwhile I tried manually scrapping a video from reddit the other day, I succeeded but it was quite the puzzle. First you have to find the right element in the DOM, then find the source which is a playlist for the various qualities available, then there was a 2nd indirection I think, then finally I got the URL of my video file.

My browser obviously knows about all of this but it won't expose it easily. No "Save video as" menu. For some reason I don't expect that Chrome will implement it any time soon...

I would imagine it's the result of inventing some busywork the keep the frontend team occupied after the product is "done" and the only thing it really requires is low amounts of maintenance.

That, and pushing more useds to the mobile application.

And what if the device can't or won't run JavaScript?

I didn't make myself clear. The embedded device is the web server in this setup. The browsing device (phone, tablet etc) runs javascript. You're right, no way a tiny embedded device runs javascript.

What if a device doesn't have a web browser? Or a display? Or a network connection? At some point you have to make some basic assumptions about the platform you're targeting.

My several years iPad with iOS 9, an otherwise capable device, locks up regularly on many js sites. JS is a global toggle which takes 30 seconds to switch.

> Embedded javascript to make them responsive.

We must have different definitions of 'responsive'. You don't need javascript to make a website look different due to different screen sizes.

They might have meant actual responsiveness, as in the absence of lag. On low-end embedded devices, rendering a template with something like PHP could easily take high units or even tens of seconds, whereas JS on a much more capable client device can respond to the user's input immediately.

Right. Populating pulldowns, updating dynamic lists (available APs after a scan) etc.

What if you do, though?

Flexbox is a CSS 3 feature. Support appears to have been implemented in FF and Chrome around 2012-2014 and still doesn't fully work in IE[1].

The fact that a site uses CSS and HTML instead of Javascript does not imply that it's easier for older browsers to display.

Javascript 1.0 was released in 1996.

[1] https://caniuse.com/flexbox

You don’t need CSS to make a website look different due to different screen sizes.

In other words, plain HTML is responsive by default. You can improve things with CSS. But if your site is unusable on small screens, you’ve broken something with your “design”.

Flexbox is by no means necessary to make a responsive web page. Media queries have been supported by mobile browsers for over a decade as has the viewport meta tag. Between the two it should be straightforward to make most page designs responsive.

Old browsers (old IE especially) that don't handle those features aren't a problem because they'll just fall through to the screen style. Trying to use JavaScript to help old browsers is a worse solution as you're more likely to run into JavaScript incompatibility problems than CSS.

Fortunately there's a practical way to do properly responsive layouts that will work in any browser even from before 1996: HTML tables.

Not really the point of the article, but I've been moving to plain HTML for a while now for certain types of personal documents. It's a great feeling to open a file in the browser and know it's going to work. Make a change and all you have to do is refresh the page. Markdown, org-mode, etc. have good intentions, and they work for super simple documents, but in the end the flexibility of html and its closing tags pays off.

FWIW, I started going this direction and ended up taking one step back and settling on Markdown. The reason was I realized an HTML renderer is still a pretty heavy dependency to consume my content.

The upshot is you can now browse my blog with curl or netcat:

  curl https://apitman.com/txt/feed

  nc apitman.com 2052 <<< /txt/feed

I may switch to another format in the future. It doesn't matter much as long as it's readable as plain text.

I tend to write in Slim, it does an excellent job of removing most of the tag noise from HTML while giving you more flexibility than Markdown.

https://slim-lang.com

Slim doesn't look particularly interesting for majority-plaintext applications.

It doesn't let you add nodes inline, so things like emphasis or links become much more verbose.

Yeah, that's the main weakness. Being able to drop down to markdown from within Slim alleviates the problem to a degree.

You can read simple html as plain text just fine.

Maybe for some definitions of "you"

https://motherfuckingwebsite.com/ html is unreadable?

As long as the HTML file is not minified, they're quite readable. <p>It's just plain text with some markup</p>.

Amen. Markdown does unexpected things so often, and then I struggle with how to escape it.

Warren Buffett said one of his greatest assets is the ability to "no" without fear of social pressure and retribution.

Too many bosses and customers want fancy eye-candy without knowing and/or caring about the carrying cost of this bloat. Staff feels obliged to make them happy. All primates love "shiny red things", even humans, even if it's not rational.

K.I.S.S. is dead in IT. Fads and toys won.

Toys won in more ways than one. Most content consumers now use apps more than websites so all this won't matter in a decade or two when the open internet will be some anachronism which lives outside the prevailing handful of walled gardens.

My undergraduate thesis has been hosted by my undergrad institution, UCSC, https://compbio.soe.ucsc.edu/papers/thesis_rafael/thesis.htm... for 26 years.

It was rendered using Latex2HTML. The "next page" images don't work since they were links to a website that doesn't serve those assets any more, but the thesis is still completely readable.

I'm embarrassed to say that “It’s shit. But it worked" is a fair assessment of many web projects I've worked on over the years.

Reminded me of https://motherfuckingwebsite.com/

http://bettermotherfuckingwebsite.com/

The irony is that bettermotherfuckingwebsite is worse in almost all ways. I wonder if that was what the author was going for. I don't know what's truly satire anymore!

> worse in almost all ways

How so? I dislike the text color choice, but other than that it seems perfectly fine to me.

The "better" site looks mostly better to me, but there are two things I don't like about, and what I like even less is the authors assertions that his ideas about those are absolutely and obviously and undeniably better.

My pet peeve is line length. Too long lines are not comfortable because it's difficult to find the start of the next line, that's true. But too short lines force you to find the start of the next line every couple of words, and that's annoying too. There's a middle ground somewhere, and I think it's not the same for everyone. The 650px used on the "better" size is certainly too short for me. I can't count the number of sites where I open the style editor in dev console and go hunting for max-width or whatever to set it to a more comfortable width. So just respect the width of the browser window, which anyone can choose to their own liking. Some margin left and right is OK, perhaps even preferable.

The other thing is font size. Browsers have settings for font size, and in modern browser you can change the size with ctrl+ and ctrl-. Why override that choice?

I like overview: being able to not just see the sentence I'm reading, but a whole lot of context. Short lines, large fonts and large line-heights all work against that.

What I do like, I think, is #444 for the text instead of pure black. Looks less aggressive that way. And some amount of margin left and right. Something like the original page plus "body { margin: 40px 100px; color: #444; }".

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.net

That alone is bad enough!

>font-size:18px

This shit is never fine.

The simple HTML of Hacker News is one of the reasons I love it so much. What a breath of fresh hair compared to modern Reddit.

Yeah. <img> tags for presentation (with no `alt` attr).

Form <input>s without <label>s.

No skip link, no landmark regions.

<table>s with <div>s inside for non-tabular content.

<font> tags. FONT TAGS.

"A breath of fresh hair" is a typo that accidentally makes a good comparison.

Nonetheless, the fact that it works in browsers as old as IE6 (haven't tried anything before that) is living proof of the fact that dogmatic "best practices" cargo-culting is, practically speaking, of zero or even negative value.

That idea is progressive enhancement, is a best practice, and has been around for two decades

Hacker news has divs for the upvote/downvote buttons too, which apparently is a cardinal sin

For accessibility and on general principle, you should use a <button> for a button.

HN gets only 1 bag of popcorn

The worst web browser I have access to is the "experimental" one on a Kindle 4. Most web pages that one might want to visit will not load in this web browser—because it does not support modern versions of TLS.

For the reasons mentioned in this article—it's probably a good idea to keep plain HTTP access available on your websites.

The trouble is that you can’t support HTTP without completely undermining HTTPS.

If you support HTTP at all, you’re damaging the experience for the almost everyone that could have used HTTPS: almost no one will get the HTTPS version unless you deliberately push them over to it, which you will only be able to do after page load by some JavaScript-based user-agent or feature-based sniffing, so now the page loads and then reloads immediately, every time the user visits your site by URL, and you’re causing trouble with search engines, and it’s a regular maintenance burden because no one treads this path so you’ll have to figure out the cut-off points yourself as certificates change, and on top of that it’ll always be subject to a downgrade attack, so now you can’t ever depend on HTTPS.

Remember also that various new features are gated on using a secure context (which roughly means “HTTPS”), like HTTP/2 and HTTP/3. And as for entering passwords or the likes, you’d be opening quite a can of worms if you allow that over cleartext HTTP.

So… yeah, it sounds nice in theory, but I think that it’s just not practical or advisable to retain plain HTTP support. Even supporting TLS < 1.2 or older cipher suites is steadily becoming inadvisable, only to be used on a few sorts of websites. The unfortunate fact of the matter is that you can’t support ancient devices without harming things materially for everything else.

> almost no one will get the HTTPS version unless you deliberately push them over to it, which you will only be able to do after page load by some JavaScript-based user-agent or feature-based sniffing, so now the page loads and then reloads immediately, every time the user visits your site by URL

This is false. All you have to do is configure your webserver to only redirect port 80 requests to port 443 if the request includes the "Upgrade-Insecure-Requests" header. Obviously since headers are sent unencrypted this means attackers could easily bypass it, but it's still suitable for personal webpages with no user data. For example, here's how you do it in Apache:

RewriteEngine on

RewriteCond %{HTTP:Upgrade-Insecure-Requests} =1

RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

Ah yes, I had completely forgotten about upgrade-insecure-requests. This mitigates a lot of what I was complaining of, though, as you say, it’s still subject to downgrade attacks at some points. Thanks for the correction.

The implicit premise here is that your website requires HTTPS only and that a theoretical downgrade attack is enough to justify not having http at all.

Most websites don't even need HTTPS and the complications and sacrifice of autonomy required isn't worth it. Remember, there are no cert authorities that are human people. They are all corporations or institutions. Having to get an incorporated entity's permission to communicate will have dangerous consequences eventually. HTTPS everywhere is done with the best of intentions but it will be the centralizing push that provides juicy targets for government and corporate censorship.

I'd flip that and say you should only support http if your website absolutely requires it. Unless you absolutely can not avoid supporting old devices you should just redirect http to https.

The privacy of all users is more important than supporting the outdated browser on an ereader.

You can't prevent a downgrade attack on server side, the attacker can simply roll full HTTP on top of your server. And browsers already disallow or warn against submitting passwords over HTTP, is there a problem to fix there? Browsers disabled old versions of TLS, you don't harm anyone by supporting them (except for bit rot of that old code). There are also sites with zealous TLS settings, they support only sha384 cypher suites and nothing else at all.

There are multiple layers of protection against HTTPS-to-HTTP downgrade attacks.

① An HSTS policy will protect people that have visited your site within max-age seconds, typically “within the last year”.

② An HSTS policy with preload will protect everyone.

③ HTTPS-only cookies will prevent them being sent over plain HTTP.

⑤ You could depend on various newer functionality that is only available in secure contexts <https://developer.mozilla.org/en-US/docs/Web/Security/Secure...>. For example, the Web Authentication API. (This also raises a good point about using the Web Authentication API for security: authentication is tied to the origin, so http://example.com, https://example.com and https://example.com.evil.example are all different origins and no one will be able to log in over the wrong origin.)

⑥ Any JavaScript code can check the origin and rebel if it’s not what you expect—in fact, I’d say that it’s very common to do this quite incidentally. This protects against a drive-by downgrade attack, increasing the effort required by the attacker who must now reverse-engineer a bit of your code.

You can: have an “insecure.” version of your site, like people used to have a “secure.” version.

You can’t:

① If it’s on the same domain, it would necessitate weakening the HSTS policy, removing includeSubDomains and preload.

② If it’s on a separate domain, you’re actively training people to do dangerous things and get phished.

③ Pretty much the only way this will ever be used is if you push people to it and ensure that search engines choose it rather than the secure version. (Implicit in this is a significant SEO hassle.) Thus you’re back exactly where you started.

HSTS

Eh, 98.24% of all users worldwide can use TLS 1.2: https://caniuse.com/?search=tls%201.2

I'm not willing to make security exceptions to support devices from 2011. "HTTPS by default" lifts all boats: people who would MITM your users can't tell if they're reading your nice blog or a critique of their local government, and that's a good thing.

> Eh, 98.24% of all users worldwide can use TLS 1.2: https://caniuse.com/?search=tls%201.2

That's 98.24% of users captured by CanIUse's sources (which seems to be StatCounter). Like most things on the Internet, that's a bubble - the bubble of users who visit statcounter-infested websites, and are able to run their scripts. And the point of the original post is to think outside the bubble. Not in all cases - if you're a B2B service, or selling T-shirts with slogans on them, CanIUse is likely a good enough source to base your choices on. But if you're a government website, or providing critical Covid-19 data for example, it's irresponsible to ignore these long-tail of users who fall outside expected and easily visible patterns. There's a spectrum between these two kinds of websites, and it's worth thinking about where you fall on that and how many you're comfortable with denying access to your website.

It's a tradeoff between security and accessibility, and we should at least be thoughtful about the implications of our decisions.

That's a tough one, because the examples you gave are exactly the ones that I don't want a shady ISP or other interested party to my snooping. I'm not unsympathetic, and genuinely feel bad for the people stuck with truly ancient systems. But at some point, you have to do the analysis of whether it's better to 1) give secure communication to everyone who can have it, or 2) retain insecure communications to support an ever-shrinking pool of people who can't/won't upgrade. I think we're at the point where #1 is more important.

And honestly, I think a lot of people in the second group are there because they bought smartphone in 2007 and won't upgrade because "if it ain't broke, don't fix it". Well, now it's broken. Fix it.

> That's a tough one, because the examples you gave are exactly the ones that I don't want a shady ISP or other interested party to my snooping.

This sounds like a personal consideration - one you're entitled to, but perhaps shouldn't force on others. Maybe consider Tor?

> ever-shrinking pool of people who can't/won't upgrade.

Are you sure about this? The kind of security you're advocating for here is a moving target. As the pool shrinks on the tail end, surely the head advances...

> Well, now it's broken. Fix it.

Erm, no. The device isn't broken, you are willfully breaking it. I can appreciate your stance, but glib comments like this aren't going to convince anyone in that camp.

They can tell what page you're looking at from the host name and request response lengths, though, right? Especially if those are the only two pages on your site.

With DNS over HTTPS and encrypted SNI, soon the only information you will get is "They accessed a website on amazon/cloudflair"

This is not a guarantee. If you have your own public IP it is quite possible to do a reverse ip lookup and get the domain.

This, a thousand times. No one is going to mitm someone browsing my text blog. On the other hand, https creates many barriers to access, including recent version requirement, time sync, and extra cpu and bandwidth.

ISPs regularly MITM http websites to inject ads (in the US even).

It happens. I think I'd rather my site be served with ads, than not at all.

It would be great if we could always automatically choose the right option, but browsers don't do that.

Ads aren't that much of a problem, but serving cryptominers/phishing websites/viruses is a real issue.

Not to mention single points of failure like Letsencrypt.

I,ve been working on a hyper-compatible web forum system. With some tweaking, I,ve been able to achieve compatibility with Netscape 2.x, IE 3.x, Mosaic 1.x, Opera 3.x, and everything since then, not to mention Lynx, Links, w3m, etc. I still have some advanced JS stuff, but it,s behind feature checks. 25+ years of various client compatibility, for people with older devices and retro fans. Amazing tech we should not throw away.

Pity that you must expose everyone’s passwords in plain text to achieve this (those older browsers won’t support TLS).

Not every website requires passwords or any other secrets to be transmitted. I use a combination of fingerprinting and WoT to allow (but not require) anyone to maintain an identity without having to register or sign in.

What is WoT? Does your system send a single-use code to the email, or some other method? I cant imagine a way to login to the account without some secret key, and that creates a dependency that might make the app unusable in another way on older devices.

I use a combination of cookies, fingerprinting, and web-of-trust verification (by volunteer moderators). The WoT works by building a DAG of "vouch" tags for each user. For more capable browser, client-side signing using a private key is available.

There is always an accessibility-security gradient, and there are trade-offs you have to make on every side. The needs of each user are different, and many would prefer to trade a lot of security for a lot of accessibility.

For example, if someone un-housed is only using borrowed devices, older tech, library computers, public wifi, many would happily trade some security for being able to let their loved ones know they're OK.

They're not worried about espionage or privacy, they just want to be able to send an "I'm OK" message to their family every day or two.

For this type of scenario, and many others like it, a simple http-accessible website behind a simple password is by far the best solution I've found to date.

This is such a quotable paragraph. It also reminds me of this:

"Do what you can, with what you have, where you are." - Theodore Roosevelt

Making things work on crappy browsers is definitely important. But that doesn't always mean "simple HTML", and it definitely doesn't mean avoiding react or jQuery or whatever HN framework hipsters are complaining about this week - if anything, those popular, "bloated" frameworks are more likely to have been tested on these obscure browsers and have whatever workarounds you didn't think of. It might not even mean following "web standards"; frankly I've found writing HTML3 with no CSS, table layouts, and maybe even the occasional <EMBED> works a lot better on these old browsers than flexbox, semantic tags, or whatever the overengineers are trying to push these days.

The bottom line is right; rather than posturing, test your site - actually test it - on one of these browsers.

html3 is still a web standard all right: https://www.w3.org/TR/REC-html32

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 have even a rudimentary smartphone (some years ago I visited the Calais jungle to donate food and supplies, and whilst people were struggling to eat, they knew that a smartphone was a cheap, key thing to obtain and hold onto because they make accessing help and communicating with their support network possible) and or laptop that can handle some lightweight JavaScript and benefit from an enhanced experience.

I don't think the problem is that niche though. Even outside of accessibility concerns, there are plenty of times I've tried to use websites on smartphones within intermittent internet access — e.g. on the London underground checking in to a flight on the way to the airport or ordering a pizza when coming home late from work.

In both scenarios, I'm trying to complete my task as quickly as possible while I still have a good connection. A simple HTML page (with JS layered on top for fancier stuff) would be plenty to get the job done. Instead you get hindered by sites that aren't optimised in any way for slow devices or slow internet.

Heard that Facebook before had "2G Tuesdays" where the product teams throttled their internal net speeds to 2G while browsing the site to see what it was like — that should be the standard for dev teams. The trouble is so many things are designed and tested by people on T1 broadband in a downtown office, but that's not the set-up of a majority of their users.

> so many things are designed and tested by people on T1 broadband in a downtown office

I wish. A T1 is 1.5mbit. CNN's front page is 6MB - 30 seconds at full T1 bandwidth.

Sidetrack: Is T1 still ~1.5 Mbps or is it referring to something more modern nowadays?

Perhaps they forgot to disable 2G on their servers /s

I think this is an exclusionary mindset. Just because it is a tiny subset of users, it is OK to exclude them?

How about when it is quite easy in many cases to support them, by using standard conform simple HTML?

Example: How many login forms have I seen, which will not show their input fields, if I do not allow their shitty scripts to run? In fact, just today I have seen it, on a VPN login, on a thing, that is supposed to give you security, I need to allow scripts, to have a login. Otherwise there is only a background picture. Thank you very much, so helpful! And then when I allowed their scripts, guess what. A text became visible, which told me, that in general scripts need to run in order to use the page. How much fail is that? They don't know the noscript tag or something?

That's only today's anecdote. I see this kind of fail every day, except for the days, when I miraculously manage to avoid all badly designed websites. It is getting worse and worse, because web developers seem to find it normal to, by default, reach for JS, instead of thinking about how they can solve the same thing using just HTML and CSS for a second or two.

I think it is still worth pursuing simplicity in web development. For the earlier example: Rendering a login using JavaScript is not simplicity. It is unnecessary, silly, and exclusionary without need.

So my message is: If your service can be done using plain simple standard conform HTML(5), then use it. It will also almost always have less bugs and be simpler code to maintain. Information display does not require dynamic pages per se. Usually it does not and many many websites are about information display, not impossible to solve via REST dynamic pages. Nowadays properly designed static websites are faster than badly designed JS heavy websites, which render on the client-side. The bloat has become this bad already.

I think reaching for JS is often a reflex because we want to avoid delving into building backends that aren't a simple REST API. If you stick to HTML and CSS you need to start building pages and managing state server-side, which a lot of people don't really want to do.

Even cheap, old smartphones support JS. You can have fast, efficient JS.

> Example: How many login forms have I seen, which will not show their input fields, if I do not allow their shitty scripts to run? ... They don't know the noscript tag or something?

This is often less about the developers not knowing a technique and more about the constraints they're working under. Maybe there's a third party auth library they're using that requires JS. Maybe either they or or their management have other priorities than removing JS from the login screen. It's not that hard to believe that scriptless login would fall fairly low on a team's priority list behind features more likely to drive revenue, etc.

Making things more accessible rarely has a downside for folks who don't need it in my experience, and often has an upside. My favorite example is doorknobs - think of a round doorknob vs one with a lever. People with broken/missing fingers/hands or fine motor impairments will have a much easier time opening a door with a simple lever vs gripping and turning a round doorknob, and so will a person with two fully intact hands who is also carrying groceries. (edit: corrected italics)

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 giving away 100% of it. And blind people have friends and family too, and they'll also send all of those people to your competitor.

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.

Don't modern screen-readers work based on rendered content? So if your JS is outputting ARIA tagged DOM, it will be fine.

HTML typically just works, even for users on powerful hardware accessing non-essential services. You don't have to worry about some modal warping out of the screen, or having your scrollbar hijacked.

I hear you: Businesses have no incentive to cater to niche segments of the population as they are not revenue drivers. What you call "enhanced experience," I translate to "adverts" (what else?).

How can government compel businesses to provide better experiences? Why, standards and regulations of course.

A massive fine might help.

Social pressure in the form of "corporation xyz only supports ie6 for their bank website" is another way.

This is a good article, but I have to differ with this bit:

> If your laptop and phone both got stolen – how easily could you conduct online life through the worst browser you have? If you have to file an insurance claim online – will you get sent a simple HTML form to fill in, or a DOCX which won’t render?

Assuming my laptop & phone got stolen, I'd have a hell of a time getting through 2FA to my email and password manager. I can get other non-crappy devices. And I'd never log in through an untrusted device anyway.

> 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

Part of the problem is that once you expand past a single read-only document, things like navigation, routing, user input/forms- get complicated. Devs want friendly URLs, static sites for easy deploys (ie no backend for form processing).

That's true, but vast majority of websites are just a collection of interlinked single read-only documents. There are various reasons why they get overloaded with JavaScript, and none of them are beneficial to the reader.

Excellent story. It's true that sometimes we should go back to the origin of the web, when it was mostly grey. I miss that web. I feel that it was an art to make it that ugly, but for me it was beautiful to the eyes.

Hmmm, starting out with a description of what the plebes do in the housing benefit offices. Then mentioning in passing that his "old car" is a BMW i3 (can I have that old car? Oh, he was only test driving it...). This juxtaposition doesn't really endear the author to me. Ok, maybe I'm not getting the British sense of humour... he does have a point however!

I might be misunderstanding you, but it seems that you feel the author tried to sneak in a brag, by telling us he owns a i3. Not to be disparaging i3, but it's not here bragging car. It goes for 11,5k USD in Norway.

Maybe having an i3 today is not something worth bragging about for the HN clientele, but saying your "old car" is an i3 after the previous paragraph might not go down well with someone who would be glad if they could afford a (used) i3. Just my impression...

Nah I think I'll just keep rendering text in my 20M SLOC virtual machine thank you.

Ads need JavaScript, in general.

Rich logging/event tracking needs JavaScript, in general.

Native Apps tend not to be HTML-powered, they're powered by APIs that can also power Web sites that use JavaScript, again, in general.

A lot of these corporate-ey features rely on JS.

So, yeah, if you disable JS, you'd only improve your experience on many non-interactive websites.

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.

With careful architecture, it is perfectly possibly to run performant web apps with a lot of JavaScript, or Wasm even.

This article has a lot of good points. I went to my county's covid page to sign up for the vaccine wait list. It could have been one page of about 10 questions and radio button (and other basic controls) and a submit button. But nope, it had 500k of god knows what javascript being downloaded for transitions and fancy buttons and 5 pages of really nice looking questions. All I wanted to do was register for a wait list! Imagine older people (who I'm all have surely filled out simple online forms) with older computers going through this stuff. Or someone who is blind. It's ridiculous.

Funny, no one mentioned Craigslist.

So, progressive enhancement?

had an interview yesterday where the guy was trying to justify using jsx over html. i hung up on him

Reply on news.ycombinator.com