The unreasonable effectiveness of simple HTML

https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiveness-of-simple-html/

by edent • 5 years ago

1064 378 5 years ago

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.

mattl2• 5 years ago

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

JoeAltmaier4• 5 years ago

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.

tshaddox• 5 years ago

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.

forgotmypw179• 5 years ago

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.

simias3• 5 years ago

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.

iforgotpassword• 5 years ago

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?

theandrewbailey• 5 years ago

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.

fouric• 5 years ago

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

dvdkon4• 5 years ago

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.

antihero3• 5 years ago

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.

zelphirkalt• 5 years ago

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.

mschaef• 5 years ago

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.

antihero3• 5 years ago

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.

smadge• 5 years ago

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.

another-dave• 5 years ago

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.

flemhans• 5 years ago

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

iso1631• 5 years ago

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.

kaba04• 5 years ago

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

throwaway1239Mx• 5 years ago

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)

glitchc• 5 years ago

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.

kwdc2• 5 years ago

A massive fine might help.

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

kstrauser5• 5 years ago

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.

Leherenn2• 5 years ago

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.

antihero3• 5 years ago

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

ogre_codes16• 5 years ago

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/

arcturus17• 5 years ago

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?

rstupek• 5 years ago

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

udia• 5 years ago

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.

ogre_codes16• 5 years ago

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/

elliekelly• 5 years ago

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?

recursive4• 5 years ago

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

ogre_codes16• 5 years ago

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.

kodt• 5 years ago

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

aidos• 5 years ago

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

inopinatus2• 5 years ago

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

recursive4• 5 years ago

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.

ogre_codes16• 5 years ago

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!

jcranmer3• 5 years ago

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

pbronez2• 5 years ago

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.

ratww8• 5 years ago

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

tingletech• 5 years ago

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

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

cptskippy3• 5 years ago

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.

ahuth• 5 years ago

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

hanniabu• 5 years ago

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.

reificator2• 5 years ago

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.

ogre_codes16• 5 years ago

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.

madeofpalk2• 5 years ago

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

codazoda2• 5 years ago

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.

wizzwizz42• 5 years ago

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

ogre_codes16• 5 years ago

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

lastofthemojito2• 5 years ago

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.

dmhmr• 5 years ago

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

ogre_codes16• 5 years ago

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.

bonestamp2• 5 years ago

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!

acdha3• 5 years ago

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/

scooble• 5 years ago

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

eins1234• 5 years ago

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.

thewakalix• 5 years ago

This is commonly termed the "curb cut effect".

analog312• 5 years ago

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.

ehnto• 5 years ago

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.

hsitz• 5 years ago

. . .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"?

m4632• 5 years ago

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.

benbristow• 5 years ago

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.

GrumpyNl• 5 years ago

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

darekkay• 5 years ago

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

vxNsr• 5 years ago

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.

908B64B197• 5 years ago

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.

pier25• 5 years ago

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

https://open-ui.org/

gcblkjaidfj2• 5 years ago

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.

deergomoo• 5 years ago

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.

analog312• 5 years ago

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.

DCoder2• 5 years ago

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.

trissylegs2• 5 years ago

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.

DCoder2• 5 years ago

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.

rkangel• 5 years ago

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.

apabepa3• 5 years ago

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!

alecst• 5 years ago

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?

apabepa3• 5 years ago

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

dgb232• 5 years ago

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.

MaxBarraclough3• 5 years ago

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

spideymans• 5 years ago

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

sct202• 5 years ago

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.

timw4mail• 5 years ago

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

ratww8• 5 years ago

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.

michaelpb4• 5 years ago

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.

SulfurHexaFluri7• 5 years ago

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.

antonhag• 5 years ago

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.

apabepa3• 5 years ago

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.

gonzo41• 5 years ago

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.

smaudet3• 5 years ago

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

grishka4• 5 years ago

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.

nicbou• 5 years ago

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

ziftface6• 5 years ago

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.

apitman2• 5 years ago

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

ratww8• 5 years ago

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.

michaelpb4• 5 years ago

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.

com2kid2• 5 years ago

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.

b0rsuk2• 5 years ago

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.

midrus• 5 years ago

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.

userbinator3• 5 years ago

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.

carapace• 5 years ago

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

srcreigh• 5 years ago

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/

kaba04• 5 years ago

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.

TeMPOraL3• 5 years ago

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.

throw_m239339• 5 years ago

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.

csomar• 5 years ago

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!

moring3• 5 years ago

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?

smaudet3• 5 years ago

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

datagram• 5 years ago

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>)

pbronez2• 5 years ago

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.

red_hare• 5 years ago

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.

foopod• 5 years ago

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.

allenu• 5 years ago

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.

aembleton• 5 years ago

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

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

stakkur• 5 years ago

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.

thehappypm• 5 years ago

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.

grishka4• 5 years ago

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

john37386• 5 years ago

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.

MaxBarraclough3• 5 years ago

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.

bachmeier2• 5 years ago

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.

forgotmypw179• 5 years ago

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

anderspitman3• 5 years ago

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.

petepete3• 5 years ago

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

GoblinSlayer11• 5 years ago

You can read simple html as plain text just fine.

nabla9• 5 years ago

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.

exporectomy2• 5 years ago

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!

salutonmundo• 5 years ago

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.

forgotmypw179• 5 years ago

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.

tpxl6• 5 years ago

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

cutler2• 5 years ago

Not to mention single points of failure like Letsencrypt.

kstrauser5• 5 years ago

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.

SulfurHexaFluri7• 5 years ago

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

exporectomy2• 5 years ago

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.

sundarurfriend• 5 years ago

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.

chrismorgan8• 5 years ago

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.

wizzwizz42• 5 years ago

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

superkuh• 5 years ago

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.

ndiddy• 5 years ago

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]

outsomnia• 5 years ago

HSTS

GoblinSlayer11• 5 years ago

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.

xkr• 5 years ago

Reminded me of https://motherfuckingwebsite.com/

tpxl6• 5 years ago

http://bettermotherfuckingwebsite.com/

ryandrake4• 5 years ago

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!

forgotmypw179• 5 years ago

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.

chrismorgan8• 5 years ago

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

forgotmypw179• 5 years ago

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.

lovelyviking• 5 years ago

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.

grishka4• 5 years ago

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.

hbn• 5 years ago

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.

dgb232• 5 years ago

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.

chrismorgan8• 5 years ago

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

samoa42• 5 years ago

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)

mtrower6• 5 years ago

longstanding use != intended use

dekhn• 5 years ago

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.

cashewchoo• 5 years ago

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

ratww8• 5 years ago

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.

kaba04• 5 years ago

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)

tpxl6• 5 years ago

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.

stickfigure• 5 years ago

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.

anderspitman3• 5 years ago

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

turtlebits• 5 years ago

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

TeMPOraL3• 5 years ago

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.

chovybizzass• 5 years ago

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

vascocosta• 5 years ago

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.

greggturkington4• 5 years ago

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.

seumars• 5 years ago

HN gets only 1 bag of popcorn

yen223• 5 years ago

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

userbinator3• 5 years ago

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.

tabtab• 5 years ago

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.

cutler2• 5 years ago

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.

greggturkington4• 5 years ago

So, progressive enhancement?

kome• 5 years ago

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.

SulfurHexaFluri7• 5 years ago

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.

hn_scripter• 5 years ago

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

jbj2• 5 years ago

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.

GoblinSlayer11• 5 years ago

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.

jbj2• 5 years ago

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.

app4soft• 5 years ago

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

euske• 5 years ago

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?

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

stjohnswarts• 5 years ago

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.

chenster• 5 years ago

Funny, no one mentioned Craigslist.

rob742• 5 years ago

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!

JonNordland• 5 years ago

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.

rob742• 5 years ago

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

lmm2• 5 years ago

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.

GoblinSlayer11• 5 years ago

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

The unreasonable effectiveness of simple HTML

Related Stories