JoeAltmaier 2021-01-26 13:48 UTC link

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.

antihero 2021-01-27 17:27 UTC link

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.

ogre_codes 2021-01-27 17:56 UTC link

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/

apabepa 2021-01-27 18:13 UTC link

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!

pbronez 2021-01-27 18:15 UTC link

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.

stakkur 2021-01-27 18:18 UTC link

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.

MaxBarraclough 2021-01-27 18:41 UTC link

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

bachmeier 2021-01-27 18:47 UTC link

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.

nabla9 2021-01-27 18:50 UTC link

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.

salutonmundo 2021-01-27 18:55 UTC link

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.

xkr 2021-01-27 18:56 UTC link

Reminded me of https://motherfuckingwebsite.com/

forgotmypw17 2021-01-27 19:00 UTC link

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.

lovelyviking 2021-01-27 19:05 UTC link

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.

dekhn 2021-01-27 19:09 UTC link

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 2021-01-27 19:23 UTC link

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

vascocosta 2021-01-27 20:48 UTC link

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.

tabtab 2021-01-27 20:51 UTC link

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.

jbj 2021-01-27 22:02 UTC link

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.

euske 2021-01-28 03:06 UTC link

> 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

lmm 2021-01-28 12:10 UTC link

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.

mattl 2021-01-27 17:25 UTC link

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

zelphirkalt 2021-01-27 17:49 UTC link

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.

smadge 2021-01-27 17:52 UTC link

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 2021-01-27 17:58 UTC link

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.

simias 2021-01-27 18:04 UTC link

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.

throwaway1239Mx 2021-01-27 18:09 UTC link

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)

elliekelly 2021-01-27 18:13 UTC link

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

recursive 2021-01-27 18:18 UTC link

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

red_hare 2021-01-27 18:31 UTC link

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.

MaxBarraclough 2021-01-27 18:44 UTC link

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

kstrauser 2021-01-27 18:51 UTC link

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.

sct202 2021-01-27 18:51 UTC link

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.

ratww 2021-01-27 18:58 UTC link

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.

theandrewbailey 2021-01-27 19:03 UTC link

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

forgotmypw17 2021-01-27 19:04 UTC link

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.

forgotmypw17 2021-01-27 19:05 UTC link

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

grishka 2021-01-27 19:11 UTC link

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.

grishka 2021-01-27 19:16 UTC link

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.

kstrauser 2021-01-27 19:16 UTC link

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.

reificator 2021-01-27 19:24 UTC link

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.

dgb23 2021-01-27 19:26 UTC link

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

chrismorgan 2021-01-27 19:27 UTC link

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.

chrismorgan 2021-01-27 19:39 UTC link

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

codazoda 2021-01-27 19:50 UTC link

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

tpxl 2021-01-27 19:53 UTC link

lastofthemojito 2021-01-27 19:56 UTC link

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.

ziftface 2021-01-27 20:04 UTC link

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.

ratww 2021-01-27 20:05 UTC link

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.

tpxl 2021-01-27 20:12 UTC link

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

anderspitman 2021-01-27 20:18 UTC link

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.

Editorial Channel

What the content says

Structural Channel

What the site does