This is a fantastic article, it does miss one very key point about bog-standard HTML which is worth mentioning though.
The standard widgets are all accessible, people with screen readers, limited mobility, poor vision, etc, all rely on pages being written so the devices they use to read the web can function properly. People who choose to eschew these standard components very frequently end up with a site which is unusable for disabled people.
Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them.
Making your site accessible isn't just a good practice, in the US, it is the law. Courts have ruled that the ADA applies to web sites along with any other type of business. A small sample of sites where people thought they could smash together super-fancy sites without concern for basic needs of users: https://www.atilus.com/top-10-ada-lawsuits/
One of the great things about accessibility is that it often doesn't just benefit people with disabilities.
My wife and I have watched a lot of TV in the past year with the volume down and captioning on, while we enjoy some down time while our baby is sleeping.
A ramped entrance to a building allows wheelchair-bound folks access, but it also helps able-bodied people using delivery dollies.
Making simple, lightweight web pages makes them accessible to those with older browsers and devices, but it also saves power consumption, time, and frustration for folks on M1 MacBook Pros.
> One of the great things about accessibility is that it often doesn't just benefit people with disabilities.
I really love how Microsoft's design team has pushed this with their “Inclusive Design” concept[1] and highlighting how any sort of disability can be situational (holding a baby), temporary (broken arm), or permanent (missing arm) but we often only think of those in the last context despite there being orders of magnitude more people in the first two categories. Parenting is really good for showing this out since you get the need to be quiet, be able to do something using only one hand (or none), navigate sidewalks with a stroller, trying to do anything while sleep deprived, etc.
There's a great chart on page 42 (“Persona Spectrum”) of this PDF which I try to get every team I work on to go through which really gets people to think about what this means:
1. With due respect to various useful elements of design in Microsoft's work - this booklet reads like "We design for black people! We design for LGBT people! We design for disabled people! Look at us, we're so morally and politically superior!"
2. Microsoft makes software which costs a lot of money (for most people in the world); often a lot of money. One of the main problems people with disabilities have is low income and lots of expenses.
3. Microsoft makes software which hogs resources and thus runs poorly, or not at all, on older or simpler, low-power devices. This also not very accessible. So it might have a perfect UI experience - on the computer people don't have. Admittedly, though, this is not as bad of a problem in the past few years.
4. I wonder how actually accessible MS apps and Windows actually are. Considering how they've botched a lot of their designs in recent years even for normies (Metro; Ribbons).
It's disturbing that you find trying to be inclusive offensive because you perceive them as political opponents. I mean, who cares what people's political leanings are if they are making things better for people who haven't been well-served historically?
Similarly, while Microsoft software isn't free nothing in computing is and it seems like an odd angle to criticize an effort to help make their products better based on decisions made by other people in different parts of a huge company, or to criticize them for things in the past which they've since corrected.
Haha, that lazy troll takes me right back to Slashdot before the turn of the century. On the off chance that you actually believe what you're doing is useful, here's why this form of advocacy has singularly failed to attract converts (speaking as someone who's been using and contributing to open source software since the early 1990s): open source software is only free if your time and expertise are free.
That free software has to run on non-free hardware (even if the oft-heralded RISC-V revolution happens, someone has to manufacture the device) and most people do not have the skills or time to assemble the hardware or maintain an OS. That means that we're all making tradeoffs of what things we buy and what we do ourselves, and for the vast majority of computer users, even open source developers, that involves outsourcing that work to a handful of companies (or, maybe, a hardware company and Debian). Most computer users consider that a good deal: they spend time on things they like and pay a rather small amount of money relative to the utility they get from a transformative device like a general purpose computer. This means that for most people the decisions which matter the most are made by Microsoft, Apple, or Google — and that anyone who cares should applaud them improving accessibility because it will affect daily life for billions of people.
This is especially true for accessibility, where people develop deep habits around things like screen readers and quality matters a great deal. I happen to work with a number of visually impaired users and have not heard good things about the Linux screen readers compared to their Windows or iOS counterparts, and that means that in the context of this thread it's really not useful to snark about the moral superiority of free software.
> open source software is only free if your time and expertise are free
but since you seem to actually be trying to discuss this in a thoughtful way, please note that we're not given a choice between free software that takes time and expertise to use and maintain vs closed software that takes no time or expertise to maintain. To mimic your original phrase, Windows 10 Pro is only $199 if your time and expertise is free. Going further, in my experience it's often been the case that the free software takes less time and less expertise to use and maintain.
Also, it's worth mentioning that you are conflating two different things, open source software and free software, a distinction that often doesn't matter but is central when the point at hand is the ethics of free-as-in-freedom software vs non-free software, a distinction the term open source was deliberately created to elide. You are also conflating free-as-in-freedom with free-as-in-beer by opposing the "software is only freedom-free" with "your time and expertise are free-as-in-beer free".
Finally it's not clear to me why you went on to address the pragmatics of non-free hardware or the fact that human effort is necessary to build computers, maintain distros, write kernels etc. Is there a claim that it's unethical to try to run free software on the hardware that you have, or that free(dom) software must always be provide without cost on hardware that is both free(dom) and without cost? If not, then computer users can still spend a small amount of money, relative to utility, to buy a computer that runs free(dom) software.
I'm not disputing your claims that accessibility software on Windows or iOS is better than that on Linux, because I don't know the space. It's an unrelated argument, afaict. To illustrate this, simply imagine that some government or corporation had decided to make high-quality accessibility software available under a free license. (I am reminded of Intel's work supporting Dr. Hawking.) You wouldn't conclude from this that all your previous thoughts about free and open source software vs closed/commerical software were wrong, I assume.
I just wanted to point out the irony that the manual and other documentation for this "inclusive design" toolkit come as PDFs – the worst choice you can make if you strive for accessibility.
PDF/A is a small family of sub-formats to PDFs which amount to the accessible subset of PDF + some requirements.
PDF/A and PDF/UA are mandated by a variety of governments for PDF distribution. They're very suitable to archival and are accessible (screenreaders can work with them, their text can be cleanly copied, etc).
That might be true, but these ones are not. I can't efficiently read them on my smartphone and have to scroll around a lot. They also show two pages on one, probably to be better printable for some marketing material, but I would never want to print a PDF that's mostly black, because that would overwhelm my printer. I'm also not near a printer right now. This is clearly inaccessible to me.
HTML, on the other side, can be easily made readable on any device. Even if the author didn't care, through readable mode in my browser.
PDFs are often the BEST way to read something. I prefer PDF text books over any other format, because (not very good) computer algorithms laying out text is inferior to proper professional layout.
PDF/A isn't necessarily accessible. First, PDF is very hard to impossible to scale for people who need big writing, due to reflowing being unavailable or not working properly. Text in PDF/A can still be a big image, e.g. in a scan for archival purposes, if you are "lucky" there is an OCR overlay, but then your screenreader reads OCR'd text which is hit-or-miss. And text ordering is supposed to be "reading order" in PDF/A, but many tools, especially DTP tools make a mess of it and jumble up the (screenreader-visible) order of text in textboxes, columns and sometimes even paragraphs.
IME PDF/A is better than nothing, but far worse than plain HTML for accessibility..
Scanned images are totally PDF/A-compliant. The standard is just about reproducible archiving, nothing else. Bitmaps are perfectly reproducible and pass every compliance check. That PDF/A is more accessible than any old PDF is just a side-effect.
This is their strength: You know a PDF will not shift its presentation due to device changes. PDFs from when the PDF was created still work right today. And they still look the same.
I may be missing something obvious, but why is pdf such a bad choice?
As long as it has actual text and is reasonably typeset (selecting text in this pdf seems to work properly), I don't see what's wrong. I'd take it any day over webpages with random floating content that you have to click through and use a modern browser with javascript without blockers/filters for the content to even render, in small text on 20% of the page, with low contrast and somehow broken zoom.
Where it breaks down is some badly designed OCR systems which place the letters independently rather than in lines/blocks. But that's starting from a document which was not accessible in the first place, so not a huge issue.
As PDF is essentially saying, “put this thing here”, you’d think it wouldn’t. But it does. You can embed the source text for screen readers. It’s also how copying text from PDFs works.
The whole topic of this thread is reading web pages on a PSP. There's a whole universe of devices that perfectly render good old server-side HTML with CSS styling, but can't display a PDF for reasons. Or if they can, it will be annoying because it won't fit on the screen and be readable at the same time. That's its unique selling point as well as its biggest drawback.
I have to admit that many modern SPAs also won't rendet on many devices, though.
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).
Ever used your phone in the blazing sun, or rain? Had a partly shattered screen or tried to do something on the stone-age library computer? Searched for something with really slow or shaky connection? Tried to explain where to click via phone?
Suddenly all those accessibility features and "fail gracefully" come in really handy.
> 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!
I use closed caption when possible because often I don't quite hear things right and can't make out words. I could turn up the TV, but this means I can enjoy it at the same volume as everyone.
I also use captions (even when the TV isn't muted). If someone else in the room is speaking so something on the TV is missed, it will be shown on the captions. Sometimes there might be some word or name I don't know and will want to look it up, and the caption will have the spelling (if the caption writer has spelled it correctly, which sometimes they don't, unfortunately). It could also be used for transcripts and caption scrollback, if those features were implemented, although unfortunately it isn't.
Another great example of this is effective keyboard navigation is both an accessibility feature and something you can sell as a feature for power users who like to get things done as quickly and effortlessly as possible.
I use a tool called Vimium so I don't need my mouse to navigate websites, and it really quickly highlights websites that have accessibility problems. Even before this though, my preference was websites that use standard elements, as so frequently people can't write robust code and boutique buttons, drop downs or other widgets break.
Indeed, I'm a double bassist, and accessible buildings are a huge blessing, especially when loading out at 2 AM after playing for 4 hours straight. Not to mention, they've probably saved me thousands of dollars in repairs.
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.
The M1 MacBook Pro is at the other end of the spectrum from the outdated/underpowered device that requires a lightweight web page. But the user of such a fast machine still benefits from lightweight web pages (faster loading times, less CPU usage, etc).
> Making your site accessible isn't just a good practice, in the US, it is the law. Courts have rules that the ADA applies to web sites along with any other type of business.
This seems to imply that web sites are businesses. If my hobby sites are subject to this, I'm going to be in trouble.
If you're not selling anything, then you're not engaged in commerce and you wouldn't qualify as a "public accommodation" and the law doesn't kick in for you.
"Sell anything" is probably a bit too restrictive, but summarizing case law on what counts as "affecting commerce" is difficult. In general, you need something that looks like a service or good being provided (even if no money is actually paid for it). Something like Youtube would absolutely fall under the ADA--it's clearly analogous to a movie theater.
Let’s just be honest - anyone can sue anybody, but you’re probably not going to have problems under the ADA unless you become visible for some reason (success, expressing the wrong thoughts loudly, service necessity for a community, etc).
> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them.
What was the catalyst behind this trend? I just don’t understand the reason behind it. Hasn’t <button> been around forever? Was there some limitation on the button tag that made the div tag more desirable?
You’ll find it’s because until “recently” (depending on how long you’ve been in this game, cough some of us since before css was even a thing) buttons weren’t stylable like they are now.
There’s no good reason to just not use buttons these days, but for a long time that wasn’t the case (cross platform).
<div> is also substantially older than both <button> and <input type="button">. The only button like thing before HTML4 was <input TYPE=SUBMIT>.
And, as you mention, the default styling was typically "make it look like the button in the underlying OS".
So there was a lot of inertia from existing code, examples, and docs that predated buttons. And a (misinformed) avoidence of it when it did appear because of styling.
Since it's introduction, jQuery was born and died. Backbone was created and became obsolete. React took over the internet. Webpack, babel, and node were invented.
With all that change, I think it's safe to say web technologies are adopted or not based on inertia.
Maybe came across more crossly than I intended... I have a blog I started in the 90s so I hear you.
FWIW, my issue with using divs is not that they should never be used as buttons. It's that few people who use them that way go to the effort of doing it correctly. It's absolutely possible to do it right and have a functioning/ accessible js button.
Either go the full way and do it right—with accessibility—or just style the standard components. In most cases the latter is the easiest way to go if you care about getting it right.
I suspect a lot has to do with the fact that it's easier to slap together a quick list/ menu thing than it is to make a select box look the way a designer wants it to. Similarly with calendar components, radio buttons, etc.
What has happened in that scenario is that the designer has failed in their job. Unfortunately it’s up to engineers to catch this, which they often don’t
Designers don't really know or understand the limits of how you can style a select box. Nor should they need to. A good team will work together around the limits.
Also, FWIW some of the problem is with the browser makers (still!!). CSS still has a lot of browser specific quirks when working with some components.
> Designers don't really know or understand the limits of how you can style a select box. Nor should they need to.
Designers absolutely need to be aware of and work within their platform's constraints, like a painter needs to understand and work with the physical characteristics of their canvas. It's this kind of mentality that results in visual specs that read "Make the window look exactly, to the pixel, like this Photoshop image!"
I'm sure the designers who work on GDS[0] and its design system do. You are probably right that most don't, they should in my opinion. Of course you are also right that good teams will work together on this. I think the best designers have an understanding of HTML/CSS or the native toolkits if they work on Android/iOS. They know when the user experience will be signficantly improved by a custom component and work with their team to make it accessible and good in those case. They also know when not to reinvent a select to make it look slightly better.
This subthread is about why divs are used for buttons and why developers reimplement existing HTML components poorly. Good designers help their teams avoid this, good engineers work with their designers to avoid it.
If the site looks correct visually, the designer has actually completed their job. You’ll find that very few businesses care how a page is implemented and happily pay for shit html if it looks right.
This painfully reminds me of ages ago, pre-ie6 even, when we would get html-tables, spacergifs and whatnots, blurped out by ancient Dreamweaver, Paint Shop Pro slices and such.
It looked good. But hardly worked.
Apparently the web hasn't really changed in that part: we're still churning out HTML that hardly works, but "looks good".
I was listening to a podcast and they were talking about using semantic HTML instead of piles of divs. One of the things they mentioned was that a survey of public web sites showed that the presence of ARIA in html was usually a sign that a site would have poor usability. Mostly because it's a sign that the site has abandoned standard HTML and went their own way and tried to patch things up by smearing aria properties everywhere.
That seems like a misinterpretation of ARIA guidelines. I'm pretty sure the guidelines are meant as "if you are going to use a div as a button, do this", not "do this instead of using a button".
That's entirely possible. I've seen a React tutorial that shows a simple example HTML snippet, and comments on it with "We’ll get to the funny XML-like tags soon."
HTML buttons have special behaviour in CSS (not even styles, but differences in the rules how they work) that cannot be reset using a CSS reset. I actually tried to make a button fit into the reset of the UI until I gave up and used a div.
"button are special element and their content is always vertically aligned by default. Even all the propertise are the same, if you don't center the text in the link, you won't get the same visual"
> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them.
I created a minimalist CSS framework called Neat CSS (https://neat.joeldare.com). I use anchors instead of buttons and explain why in the quote below. I'd love feedback on the accessibility of that alternative.
It's best to use semantic web tags whenever possible. Buttons are a unique case where you're typically linking somewhere, but the button tag doesn't currently support the href attribute. So, buttons are anchor tags with a class of button.
FWIW, I'm not an expert on this so take what I say with a grain of salt.
An anchor tag that links to another page but looks like a button is probably fine. So long as you can access them via the keyboard (tabbing to it) and they have a distinct appearance when focused so if you are tabbing through you can see whats active (this is different from the hover attribute).
Fair. I would typically us a form tag with an input tag inside it for forms. Sounds like the button tag can be styled a little more because it allows i, em, br, img, and similar tags inside it, while an input does not. They are interchangable in the case of a form (based on your style need).
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.
FWIW, using React or whatever makes it more obvious that you're making these mistakes because your event handlers are attached right on the "HTML" element. It makes it easy to spot because you see
<div className="button" onClick={handler}>
and it immedaitely sticks out as a mistake. Because its easier to statically understand these mistakes, theres even tooling to automate detecting some of them as you type https://www.npmjs.com/package/eslint-plugin-jsx-a11y
> FWIW, using React or whatever makes it more obvious that you're making these mistakes because your event handlers are attached right on the "HTML" element. It makes it easy to spot because you see
> <div className="button" onClick={handler}>
> and it immedaitely sticks out as a mistake. Because its easier to statically understand these mistakes, theres even tooling to automate detecting some of them as you type https://www.npmjs.com/package/eslint-plugin-jsx-a11y
I'm not sure how you got that out of
> I have seen an increase in unknowingly doing so by importing a calendar widget or similar without reviewing it.
The point of using components is so that you don't have to look under the covers to understand them at a high level, but that also means if you don't look you don't see how they're breaking accessibility.
> Using React or whatever does not prevent you from doing this, and in fact makes it less obvious to anyone doing a cursory review
Sure. From that level it might not be apparent, but within that component the mistake would be immediately obvious, on a cursory glance. Again, I don’t think React or whatever makes this less obvious.
But really, this just isn’t a problem I’ve seen in practice. Because of good tooling, and the ease of doing things the right way, I think the majority do it well. Those that don’t were going to fuck it up regardless of the framework or paradigm.
> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them.
You can add role="button" and a modern browser will treat it just like a normal button and all the accessibility that comes with it.
I wish this would be the case. The button will not be focusable, so we need to add tabindex="0". A disabled div with role="button" is not handled as disabled, so we need to take care of that. Keyboard space/enter will not be triggered on "click" event, unlike real buttons, hence excluding keyboard users. You can check my playground [1] - I'm using it to demo why one should prefer native over custom components.
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.
This is the issue. People (especially on HN) complain about people building un-semantic, inaccessible websites that don't work with JS disabled—and I agree this sucks—but HTML is so limited your only choice is to build the niceties yourself or skip them altogether. Sure, in some circumstances you can progressively enhance (sortable table for example), but many cases having a HTML fallback that still does what you need it to is a ton of extra work.
HTML covers text, painfully basic tables, semantic rectangles (<nav>, <aside>, etc.), form inputs, and embedded media. Basically, anything you could build with a word processor. Outside of that, you're on your own.
JavaScript and CSS are continually improving and are so much more capable than they were even five years ago, but it feels like HTML is just stagnating. Why can't we have new elements every year, with behaviour? Stuff that works just fine out of the box, but can be easily tweaked with CSS or a little sprinkling of JS. The amount of developer time and bandwidth we could save not having to re-invent the wheel for every little thing.
You have a great point. Browser UI elements are stuck in time and all the attention now is directed to things that Google can make money from (e.g. DRM, sandbox for rich apps/extensions, webrtc for their video call products, etc)
but your cited site is not a good advocacy of that.
Not even the most exalted UI framework fix the most obvious problems with those either. e.g. tables still won't hold the header and first column(s) while scrolling.
Most of the these elements does not help consuming information, like carousels. And any true UX designer abhor them all for the fallacy they are.
It's all red :( No support anywhere but Firefox. In fact, I will now use this URL as my main argument in support of firefox!
even the grand-parent, javascript infused solutions, only two out of 20 support this extremely basic and obvious use case.
Web UI standards are a joke. Everyone involved only cares about rich ads and accordions/carrousels which are lame ways to shove lots of content in a badly designed space.
Are there any automated ways to assess a web product against the Web Content Accessibility Guidelines (WCAG)? This should really be part of the CI/CD process.
There's a Firefox/Chrome extension called Axe that's pretty good. We use at my company it to make our products accessible and it helped us tremendously.
The engine behind that add-on, Axe core, can be called from JS and there are some open source tools around to integrate it in your CI. I would say Axe is kind of the gold standard at this time when it comes to automated accessibility testing. Not because it catches the highest number of issues, but if it flags something you can be pretty sure it's a real issue and not a false positive.
Yes, there are a lot of tools. None are great and are mostly for compliance.
Products like Siteimprove are targeted at Enterprise (e.g. demos with sales weasels, unpublished pricing, etc). They mostly suck but check an auditing and compliance box.
Would be nice to have an html builder that follows all these best practices. That would also make it nice and easy to apply different crowdsourced themes.
> Making your site accessible isn't just a good practice, in the US, it is the law
> Courts have rules that the ADA applies to web sites along with any other type of business
For a business like a coffee shop I'd imagine that accessibility is codified in law through things like building regulations (ie, you must have n disabled parking spots per square foot, a disabled toilet, etc)
Is there an equivalent legally codified and enforceable standard for the web?
> Is there an equivalent legally codified and enforceable standard for the web?
More or less yes. The link I posted has a few good resources, but generally speaking sites need to work with a screen reader and they need to be accessible via the keyboard (which by extension enables other accessibility devices).
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.
> 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.
If you comply with the WCAG 2.1, you have a pretty good legal defense. While it isn't "Law", it is the most widely known published standard and likely to be added to the law soon.
> 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.
Generally, it should be noted that an <a> tag is only appropriate if it makes sense to right-click this element and get options to "open in new tab" or "add to bookmarks". All the stupid "buttons" implemented as <a href="#"> + e.preventDefault() need to die.
Yea I use <a> if it's a navigation button for react-router. But it still shows up like a URL because we're using the Browser history (it just updates the URL and renders the new page, each route has a URL and resource id's are in the url).
As opening the URL directly should work (if authenticated) it makes sense to use <a> tags.
I remember learning about HTML for the first time, maybe in Byte Magazine. It was before I actually had a computer with a browser. But the article talked about a benefit of HTML, which was that the tags could be interpreted by custom browsers for accessibility, including for the blind or sight-impaired. It seemed like a pretty cool idea to me.
Later on, when people started treating web design as a general purpose graphical and GUI framework, many of the accessibility benefits probably vanished.
Yeah, nowadays most of the sites are suffering from div-ititis that has no semantics, massive blackholes of JavaScript that have to be loaded and processed before you can even see plain text, and CSS class names that are randomly hashed with each deployment in the name of modularity.
General accessibility be damned.
<noscript> fallback messages be damned. (Except when snitching on your page views to Google Analytics, that's too important to be neglected! I wonder if GA has any default marker to let their customers distinguish these views from normal ones, or if that's still left to each customer to implement manually.)
UI customizations in the form of browser extensions and styles be damned.
Designing for people with disabilities usually increases the overall UX for everyone. I see it a bit like resistance training for fitness - you train in a 'more difficult than normal' scenario, and then when you return to normal it feels much easier.
I am not a front-end developer but looking at it from a distance I really don't get modern web design. Sure some sites might need fancy javascript single page features, like if your webpage is an interactive map or realtime game, but most sites are just text and some pictures. Whats with all the javascript? Your site looks just like the next one anyway! It feels like an "Emperor's New Clothes" situation or maybe more likely I just don't understand the allure as an clueless user.. I am almost tempted to make a webpage to see what the big fuss is about!
As someone involved in hiring, this is what Bootcamps and Universities are teaching, and what companies are looking for: backend spits JSON, frontend consumes it using React.
Rendering HTML on the server is not really "the default" anymore as it was 10 year ago: it's more of an optimization for when your React site is slow, and it's a black box to most people. Even static websites are "strange tech" to new graduates outside the HN bubble.
Also, developers hate mixing tech. You mentioned an "interactive map" in your example. This can be made with React or something like that, right? The issue is that a lot of developers will want to use React for everything else on the page, because they think it's "icky" to use other kinds of tech in other parts of the website. They sorta have a point (the "microfrontends" discussion was a thing a couple years ago), but on the other hand they're not considering the tradeoffs.
Also, the frontend is officially the centre of the application on medium sized companies (50+ devs). It's way easier to add new code to the frontend and spin another microservice than to coordinate between multiple teams of backend engineers.
I'm not saying this is good or bad, btw. It's just how it is.
EDIT: One thing that really bothers me that people fresh in the industry don't really believe that websites were faster 10 or 20 years ago, so I don't really see any light at the end of the tunnel. Sure we can do new things on the web, but what was already possible before has been made slower by our collective refusal to "use the right tool for the job". Even the frontend tooling today is very heavy and slow, and I'm in a 2020 MBP. I don't think we progressed much. React is an amazing idea (and the implementation is great), but the community has become too dogmatic.
A few years ago when teaching at a previous coding bootcamp that started with FE JavaScript, I remember my surprise when well-performing students got through 3 months or so of it and were confused and very impressed when I showed them how an <a> tag worked, since they had only been aware of (jQuery) JavaScript powered pages. When you are stuck just doing JS powered SPAs, an <a> tag seems like advanced technology!
I ended up at a new school creating a new curriculum. This approach is where we "recapitulate the evolution of the web", so we start with SSGs & server-side programming (Python/Django), then only at the end cover SPAs and React.JS -- since, as you mentioned, that's still the main skillset that companies are new devs for.
Almost every JS app I have seen uses a tags though. Even if they are just links to # pages. With most router libraries you can even use real paths and it works all on the front end. Sounds like you found one anecdotal case that didn't know this.
Maybe I wasn't clear -- What I meant to say is that the curriculum barely covered <a> tags, but instead started just with JS DOM manipulation, which meant students were using document.location on click events since they weren't taught anything else. This isn't a criticism of JS best practices, instead it's a criticism of how it's taught, specifically in this curriculum that's sold as a white-label curriculum and used by MANY bootcamps across the US. It might even be the most popular coding bootcamp curriculum in the country. It's possible they've improved it since I was teaching it, but definitely it was not the case a few years ago!
Exactly. And sometimes they're not even taught it! But since they also weren't taught the foundations, they also won't know how to "ask" questions. So they end up searching for "how do go to another page using Javascript", which will obviously yield results with window.location.
It definitely happens. I've seen some internship/junior interview tests where candidates use javascript's window.open or window.location to link to some fixed destination rather than just using an anchor tag.
>The issue is that a lot of developers will want to use React for everything else on the page, because they think it's "icky" to use other kinds of tech in other parts of the website.
It is though. I work on an app thats 80% react and 20% rails SSR and when working on anything, seeing that an area that needs change is written with SSR makes the job 10x harder as you have to come up with alternative methods to get it working or just rewrite it in react. When everything is react everything is quite easy and you can pass around data and update things without a refresh easily.
> seeing that an area that needs change is written with SSR makes the job 10x harder as you have to come up with alternative methods to get it working or just rewrite it in react
Without details it's hard to know what you mean. Do you have an example?
It feels more like the SSR part was not the right tool for the job in this case (or maybe it was from the speed point of view and not development). Your point seems to be that react is better than SSR and not that mixing technologies is bad.
Thanks for the response, very informative, I feel it explains a lot of what I was confused about.
So maybe a simplified view for me is: massive adoption of JS + frameworks, cookie cutter development, no point learning anything else when you have the golden hammer.
I actually thought you still did learn HTML and stuff before the digging into the frameworks.
But maybe it is analogous to learning assembler before python, i.e out of fashion and not needed to get the job done.
In this context what seems like the simpler and more suitable solution to me (static HTML+some minimal JS) might not be on the map for most modern web developers. What they do is overkill but it is what they know and it gets the job done.
One thing I love about Svelte/Sapper is that it can be used for both the server-side rendering and the interactive map. And it doesn't feel like an afterthought - idiomatic usage leads to server-side rendered html with progressive enhancement of JS.
Oof. Yeah, I am now very glad I got out of that game, does not sound like a nice place.
SPAs were for a specific, narrow, set of use cases where it really didn't make a lot of sense to even have a backend...
Companies don't really have the incentive to build good software, though. Fads and cargo cult 'lets use this popular BS' tend to catch on more when the name of the game isn't software, rather its about pandering to a job market. Outside of sudden and painful corrections that market seems to promote bad engineering, probably because it costs more over time to maintain and thus creates more demand in a 'negative' positive feedback loop...
Trying to legislate it back in by pointing out that most sites are hot piles over garbage that are unusable by anyone with any sort of impediment (physical, technological) seems like a nice idea, I don't see much growth in that area anyways so perhaps it is time for strict law enforcement...
The fact is, the Javascript ecosystem is unmatched when it comes to very quickly creating frontend applications. Maybe another set of tools would have been better, but that doesn't really matter. This set of tools is what everyone uses, and a lot of effort and creativity goes into making js frontend development as smooth and fast as possible.
I often need to very quickly make internal services at my job and while I like working in other languages (and i do for longer term projects), those always take longer to set up and get working. In js with next you're up and running in less than 60 seconds and if you're doing crud stuff, most of the work is frankly done for you.
Rails was already faster for CRUD apps back in the mid-2000s. Batteries included, maybe a gem or two for an admin panel or for auth. Not that it matters, but rails new is probably faster than 60 seconds too. Django is pretty good too.
ASP.NET Webforms was made for CRUD, and it even provided a WYSIWG designer back in the early 2000s. And it was just a matter of launching Visual Studio and creating a new project. Again, doesn't matter, but it was/is way less than 60 seconds, and a lot less fiddling. Webforms got an MVC version a few years later if you prefer that. And they haven't stopped: Blazor is new-ish and very productive, and runs both in the backend and in the frontend (using WASM).
Both Rails and Microsoft tech also give you a backend, which you're not putting into your equation. Sure you can have a Backend in JS but the experience it's nowhere near as ergonomic or as fast as using Rails or ASP.NET.
Sure, if you're comparing with building an app in Xcode or Android Studio then JS tooling is faster to use. But if you compare to what people were using to build CRUD for the last 20 years then JS is not really special. For interactive frontend apps? Then it's a different discussion. But for CRUD, modern JS is not that special.
I can't really speak to all the technologies you mentioned, but some of the other apps I maintain are in python using django. It is also "batteries included", and does give you more tools out of the box for backend work. It's actually really nice to work with and maintain in my opinion.
I would say though, that for very quickly creating new applications that get the job done, js has been the fastest for me. And while django and similar give you more database stuff to work with, honestly that feels like a solved problem, and it's often easier to not have to do any backend work at all, and instead use something like hasura. And next does include backend code too for functions that you need to write for the backend.
Obviously, this isn't ideal for a lot of problems. I think if you can get away with it, you can be really productive. I've made crud apps for work with this stack in very little time.
It's unbeliable how many things Django gets right out-the-box. I am talking about things like i18n and i13n which are usually are afterthought for most of these frontend frameworks but Django already includes a amazing system for it.
You cannot compare those though. Rails is entirely different from plain Ruby. If you want to compare you need to take something like NestJS, which approaches Django in immediate useability.
Rails is an excellent choice for the backend but on the frontend its much less productive than react. Most rails apps these days would use rails as an api backend and react on the frontend.
> and if you're doing crud stuff, most of the work is frankly done for you.
React sucks for large complex forms unless you pair it with another technology or two.
Want to write a crud app fast? C# and Winforms.
Couple years back, I once did a prototype of a web app in C# and Winforms connected to Firebase. Less than a day, done.
Month later, had it working in React. Granted the React website looked nice, but the difference in efficiency is huge.
Data binding 20 fields on C# is a matter of minutes. Data binding 20 fields in React, and with Redux, ugh. I really should have just learned Redux Forms.
And for any given forms library in React, you then get to practice learning how to beat it into shape and style it how you want.
I, no kidding, think writing CRUD apps was easier with VB6 and Microsoft Access.
That's really interesting, I should look into that pattern, maybe it can be applied elsewhere (I have to maintain a vb6 application at work, and I'm not terribly interested in doing that anymore).
Yeah working with redux sucks in general imo, I try to avoid it when I can. If I can get away with it, I try to avoid the problem entirely by using hasura as a backend. But sometimes that's not viable.
> That's really interesting, I should look into that pattern, maybe it can be applied elsewhere (I have to maintain a vb6 application at work, and I'm not terribly interested in doing that anymore).
I hadn't used C# for years, I was shocked that the winforms designer duct taped to a community contributed Firebase library, was able to get a prototype out in hours.
I had been using JS for 2 years at that point. I estimate at 10x-15x productivity boost in C# over JS.
The C# tooling is just that good.
Now if I'd been trying to learn XAML or something at the same time, eh, probably wouldn't have gone as well.
Of course the downside here is that a Winforms app is hard to distribute, and usable only on Windows desktops.
The react web app was, well, beautiful, and usable everywhere.
But I could have written the C# app once for every platform I care about and still been better off.
Ugh, I am sad that Winforms is only ever going to be Win32 based.
I'm interested in knowing how you get to do "crud stuff" so fast with Next.js
- How do you do validations?
- How do you handle database migrations?
- How do you handle background jobs?
- How do you handle authentication?
- How do you handle authorization?
- How do you handle file uploads (to filesystem or S3)?
- What ORM or database toolkit do you use for queries?
- How do you send emails?
- How do you do websockets/real time?
All of these of course have answers, but each one of these comes with a lot of "decision fatigue", discussions, maintenance work and I highly doubt the cost of reaching the same level of robustness of a full stack framework is any smaller.
Real life production "CRUD stuff" is not just some http handler doing sql inserts into sqlite. There's a lot more involved. That's what Rails/Django/Symfony give you a solution for. I agree Next.js could have a faster startup for a landing page. But as soon as you need the most minimal backend, you are way, way, way further to get something robust working if not using one of the full stack frameworks.
This is just a personal preference. I would say the same about Python / Django: You get extensible login/signup/password-reset/etc authentication & user-permissions management, and even an admin interface with user groups, right out of the box. I can put together a web app in "60 seconds" that would take weeks to assemble using the JavaScript ecosystem. Having taught classes on both, I'd also say it's also easier for beginners. Again, might be my own bias or other factors, but it seemed to me that the Python/Django student's final projects have on average "out-shown" the JavaScript SPA student's final projects in terms of features that they had time to complete.
This isn't to hate on JS, this is just to acknowledge that other languages and frameworks have substantial advantages in many use-cases.
Django's user system is .. limited. You need a bunch of third party libraries to add very commonly used things such as auth APIs, oauth, 2fa, etc.
I've worked with Django for over a decade and i dislike it more and more. It hasn't evolved to match the environment around it and how to best use it. Typing is missing. Something like FastAPI is very promising but Django's admin is still superb for prototyping and its orm is a lot more instinctive so i put off switching away ...
Agreed, it definitely is limited. Also the admin panel is limited too, and although it's very extendable, the admin extension API is kind of clunky and inconsistent at times. Yeah FastAPI looks great! I've used Sanic in the past and FastAPI seems cool for some of the same reasons. I'm also following closely Django Hotwire - https://hotwire.dev/
I only brought up Django in a narrow context to challenge an assumption made by the post I was replying to, that seemed to imply that JavaScript ecosystem is indisputably the fastest for rapid prototyping. Hence my providing of a counter-example. I think this is especially true for new coders, as having certain things out of the way is super vital to keep motivated when building MVPs -- I've seen many students give up on ideas simply because implementing authentication with a Node.js-based stack was too challenging, when they would have been happily coding away had we been teaching a batteries-included framework (django / rails / etc).
Funny you should mention that, I'm watching that too, and I can't wait until that's to the point where it's just as easy and seamless to get something up and running in django or a similar framework, while also having all the advantages of a frontend application and a backend one. Hotwire does look very intriguing to me.
I think overall we need a new wave of backend frameworks with what we've learned in the past decade. I'm hoping it's in python or clojure, but my guess is it's going to be in javascript (see react server components for one potential contender).
I've been in the NextJS world lately and it's honestly gotten really good. Nowhere near perfect yet but they are clearly on the right track and it's already more than usable.
Last time I hanged around #django, they said admin pages are for prototyping and technical admins only. Admin is not meant to be extensible. For true power without issues, you should roll your own CRUD views. Django has features which make it easier, such as viewsets.
I see your point, and I agree it's definitely not a good solution to some problems. But I think it can be very productive if your constraints allow you to use it.
That would be fine if the attitude were 'best tool for the job'...
Often there is the people element to tech though - that isn't the attitude, normally optics is your tech wiz kid is doing something cool with (metaphor) peanut butter sandwiches, lets build our next office complex with peanut butter sandwiches. Architecture? What's that. Move fast, break things, eat lots of sandwiches.
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.
Some people are used to using javascript packages (so importing a whole framework when they are only using a small portion of the functionality) to help with UI like collapsing/expanding menus depending on the screen width. You can do a lot of those things with pure CSS now, but that's a more recent thing and a lot of popular tutorials are still JS + CSS.
From what I can tell the short answer is that you're right, there's really no good technical reason for all that weight. Which is to say, it's just bloat.
The JS performance difference between high and low-end devices is stunning (9s vs 32s load times, based on the Medium article). Web devs, who are often used to using the latest and greatest devices, will have no idea how terrible their code performs on slower devices. And I fear that modern CPUs with excellent JS performance will only exacerbate this issue
I had always been using 2-3 year old android phones for the last 7 years and I was unable to comprehend how anyone uses the web on mobile because everything was so incredibly slow in the browser while native apps were fine. Then I got the latest iphone and my mind was blown at how I could scroll a website at 60fps. I guess if you have the fastest phone on the market, everything seems fine.
It's strange as poor performance is known to be off-putting to users, which presumably translates into less traffic and thereby less profit for the site.
As an Android developer who's now making a hobby project that has a web UI, I don't understand it either. I'm doing it the old-fashioned way and it's so fast that my browser doesn't have the time to display a loading animation when I refresh the page.
It's a bit more complicated than that. Modern web development done correctly can help: Pages are generated in the server, no JavaScript required. If you start with a PWA mentality, then your application/site is progressive and you should cover everyone; or almost.
However:
1- Progressive is expensive. You'll need more time as you need to sort what features can work; and work your way up to the full experience. The full experience, however, is what you are getting paid for (or showing). Unless the client or the company cares about these categories, you don't want to expend budget on that.
2- Web development is becoming complicated. You can get started quickly with Nextjs/Gatsby thanks to "DX"(Developer Experience). The reality is that you don't understand much of what's going on behind the surface and if you bootcamp-ed your way in 3 months, you probably have no idea what's going on. But it works!
I agree with you. It definitely does not serve the user. I have two thoughts, as a nobody.
1. Ads/trackers/etc. need javascript
2. It's a way of flexing and saying "we have resources to put into this webpage which makes us a serious business."
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)
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..
The irony is that it took AMP, a proprietary solution, for all these websites that mainly deal with text and image, to start cracking down on all that stuff.
Remember "mobile first"? Well the majority of web developers clearly do not have a Mobile first strategy, when you look at how heavy their webpages are.
Even the javascript could be lighter, but since everybody is using node.js and NPM behind the scene with a lot of complex modules, well code bundles become crazy big.
I'm not either, but I've written quite a few webpages over the years, and even the occasional use of JS, but only when it's not possible to do without.
I suspect much of the superfluous JS comes from a " if you have only a hammer, everything looks like a nail" mentality.
What's with all the server round-trips? If you have a UI that takes user input and just reacts to it, without any data needed from the server -- why should it go on a full round-trip just to get a new UI element that it could create locally just as well?
Look at other things on your computer: a text editor, or a calculator. Would you expect every interaction to send a request to some remote server just for the sake of it?
Shitty server code isn't an excuse for shitty frontend code though.
Moreover you are confounding apps with the web. A calculator should probably never use the network...
Pretty much every web browser can and has to open and send network packets - as long as they are small and there is not a lot of state, you are fine. You can support almost any device from 20, 30 years ago.
'Modern' JS dogpiles huge swathes of mostly unused, uncompiled code, resulting in huge network transfer costs, extreme overusage of CPU and RAM, and encourages a lot of e-waste because it mainly only works well with the latest devices...
It's arguable that this is such a bad engineering design, just to save some network packets, I wouldn't be surprised if the carbon footprint of a JS developer was at least similar to that of burning coal...
Developer productivity: Making complex pages and reusing components across pages is much easier with a library like React than with more vanilla approaches. For a lot of companies with large numbers of engineers, making sure that engineers can be productive without intimate knowledge of HTML/CSS ends up taking priority over things like performance and accessibility.
Branding/customization: The built-in HTML controls are difficult/impossible to style or customize. A lot of UI designers will design some fancy looking select dropdown, not appreciating the fact that they're forcing developers to reinvent the wheel in order to implement their design. Alternatively, there are cases where the UX for built-in controls is lacking enough that you're somewhat forced to implement a replacement (e.g. <select multiple>)
The two biggest rants on HN are 1) Why doesn't this site work without JavaScript? It's inaccessible. and 2) Why doesn't this app work offline? It invades my privacy.
Maybe I'm wrong, but as far as I can tell, you can't have both. Sorry folks.
You are right, JS is not needed if the site truly is static content. But if you try to make an interactive app that could be implemented client-side (AKA javascript) and attach a server to it, everybody will complain that the application doesn't respect the user's privacy, since it could be offline-only but it's not.
Don't get me wrong, I think "interactive" can meaningfully include a simple site with links if you are looking at it from a privacy angle. Just look at how StackOverflow recently was able to track all the pages their hacker viewed. [1] SO is pretty much static content. So do you want StackOverflow to work without JavaScript? Are you happy that in-so-doing it needs to phone home whenever you look something up? You can't have one without the other.
There is also the argument from scalability. You'll get less QPS on your servers if you implement a 3-step form with validation in the frontend, and send off all the data in one go. It's also faster/better UX and is more resilient under bad network conditions.
Edge computing is maybe an alternative there, but that doesn't address inherent privacy concerns of phoning home to a server.
Last there is the reality of a spectrum of interactivity of websites. If you are doing a blog, sure, don't do it in JS. At that point you make a decision to make it difficult to add any interactive features to you site which require JS. If you are building an evolving app with interactive features, there aren't many options for easily mixing static HTML with interactive JS. You could see how far you get with static HTML but then what if you need interactivity (JS/JQuery)? What if you need complex interactivity (React)? Are you willing to pay the costs of a heterogeneous app architecture of HTML mixed with interactive JS?
Think of Facebook. It is kinda like a blog, but what about infinite scroll? Etc.
Anyway that last point, I think, is why people are excited about 37signals' Hotwire[2]. It's more of a HTML-but-interactive architecture as opposed to the fully-interactive JS/React vs static HTML forms.
> You are right, JS is not needed if the site truly is static content. But if you try to make an interactive app that could be implemented client-side (AKA javascript) and attach a server to it, everybody will complain that the application doesn't respect the user's privacy, since it could be offline-only but it's not.
That's the gist of it. Don't use JS if not absolutely needed (or at the very least, don't make the site break without JS enabled). If needed, consider whether there is a valid technical reason why this should be a server-dependent web app in the first place - and if there is, consider supporting off-line mode where possible anyway.
It's a perfectly valid position to hold. It's a user-respecting and waste-minimizing view.
I don’t understand your second point. Which web app works offline?? (Unless they are deliberately made for that purpose. Hell, even most electron apps refuse to work without a connection) They regularly make new requests, there is literally no difference between SSR and CSR in this regard - it seems a bit that you are arguing with a straw men. Like, what does a webshop do which is written in react/whatever and you go to the next “page”, it hadn’t loaded yet?
Also, noone would even think that it is unreasonable for a WEBapp to phone home. What people have trouble with is tracking, that is orthogonal to the current topic and should be condemned.
Made me think of a time I didnt do adequate research before buying an expensive flight ticket: I was in Changi Airport and had a cheap return ticket to Malaysia, when I got back I was going to travel in the east coast of Australia for a few weeks as the end of my study abroad in Asia.
It dawned to me that I never actually checked the Visa rules for Australia, but just pressumed that they would be like any othet commonweath country I had previously visited. Turned out I was lucky and didnt need a paper visa, but could do with an e-visa.
As my HTC Desire Android phone had died in the humiddity, I only had the cheapest nokia I could find, X-1 ... Armed with a 2011 public internet kiosk of internet explorer, I tabulated through the australian immigration forms and found the correct form, filled it out while my browsing session of the kiosk expired, after a few tries, I knew exactly the way around the static site, and was what some would call "speedrunning" through their website. After sumbitting I just had to hope for the best. If that site had been required any more than it did, I am not sure I would have been able to submit my application through that public internet browser.
Another example: a train schedule site that requires the latest approved browser. If you want to travel, first make sure you're not in the middle of nowhere.
Talking about the sun ...
We got a variant of those credit card sized NFC cards to check in to public transit, the issuer decided that they should have an expiry date. From what I remember reading in local tech news, the logic was that people bend/break them over time, making them have a measurable lifespan.
My card actually expired in the middle of the countryside, and phone support just told me to get a replacement in the nearest convenience store.
I could have been prepared for this if I had checked the expiry date and put it in my calendar, but how many people do this?
btw, apologies for typos in my post above, it went quick, and was typed on touch screen.
> Go sit in an uncomfortable chair, in an uncomfortable location, and stare at an uncomfortably small screen with an uncomfortably outdated web browser. How easy is it to use the websites you’ve created?
It's so easy to get disconnected from the real-world applications of our technology. Build user empathy.
My favorite example of this was when I worked on a B2B product with a daily email report. We noticed the most common usage of this email report came from native iOS email clients first thing in the morning.
As a test, my team all went home and practiced being the user. We had a test email sent to our email addresses we would open first thing in the morning and attempt to make sense of it while laying in bed.
The result was a lot less cruft, bigger text, and key takeaways above the fold.
I love examples like this, I hope you don't mind me tagging on my own.
Our team was doing in home interviews for a TV product. One of the customers subscribed to an expensive sports service and yet barely ever watched it.
When we probed it was because her two sons had left home in the last year and she knew they would come home when a game was on if she had the service. She said that she wish she knew when big/popular games would be coming up so she could invite them around and see them more often.
We trialed a fortnightly email newsletter for people that were subscribed but not very active. And saw a decent uptake in viewing almost immediately.
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.
As someone who did a lot of desktop application development prior to the web just totally gutting native app development, this is my take:
The problem is that people want to make dynamic applications that have a rich UX and deep system integration while being highly portable.
Unfortunately, it turns out that "portable" is basically a Great Filter for applications. If you can't run it, you can't use it and the rich UX and deep system integrations don't matter.
So developers cast about looking for alternatives to Qt and GTK and friends. Flash and Java (and Silverlight....) all had browser plugins and offered vaguely convenient APIs for building applications with rich UXs. Unfortunately those plugins had inherent technical issues and died (or were killed, as it were).
So what platform remained that had super easy distribution and portability? A XML document format that supported directives for styling xml and some rudimentary scripting language that could dynamically change that xml and styling.
So that's what ended up getting built upon. And now, since abstraction can do anything, we finally have things resembling what we had 30 years ago in desktop applications but built on top of a standardized runtime with a JIT and a sandbox and a nascent assembly language. So that's finally what people use.
I really had nothing but disdain for web applications built with javascript/jquery soup for the longest time. They worked, sure, and printed money and all that, but I was bitter that such poor technology was what won, instead of some evolution of the existing desktop app paradigm.
Now with React et al it's finally getting bearable again. But I still find myself wishing I could just say forget all this web junk, I could write this as a Swing or JavaFX program in 10% of the time.
(It's just unfortunate that nobody would be able to use it because nobody downloads programs off random websites anymore except Putty and nobody has an (independently-installed) Java runtime anymore. Which brings us right back to the initial problem).
My memories of non-web toolkits are not as fond as yours.
You mention Swing, but I remember lots of my non-programmer friends dreading having to use applications made with Java, since they were considered sluggish and resource-intensive. They also had a certain look and feel to them that made them stick like a sore thumb compared to other apps, and a lot of people knew by looking when an app was made with Java.
Java was actually pretty fast even back in the early 2000s, but thanks to Swing et al (and to the JDK requirement), Java desktop apps had a reputation was much worse than Electron or JS-heavy websites have today. Especially among non-programmers.
Strangely, OTOH, Visual Basic had a terrible reputation among programmers, but most Windows users had no idea about it since it used native widgets.
Back then, looking native was the most important thing. Today it seems electron apps can get away with looking anything but native - so perhaps it’s time to resurrect some other desktop frameworks (I just recently started working with JavaFX and I really like it so far. Unfortunate that it is so niche)
I think the issue with Swing was that is was in a bit of an uncanny valley. If all controls were custom it wouldn't look strange.
Visual Basic was very... well, "basic", so it looked normal. Some tools like CCleaner and a lot of Antiviruses had fully custom looks, but didn't look out of place, because they were too different.
I suspect there is a growing web developer conspiracy to fight overconsumption and climate change.
I see slow websites with carousels of large images with big texts. They link to value statements, mission statements, experiences, goals, community bullshit. If you want to know products, prices, or even what the site is all about, you must squint your eyes and really concentrate, maybe scroll down to the bottom of the page. I save €1000 per year in impulse buys because of these sites.
Somehow we've regressed to 2000s levels of aggravating websites. When I want to buy a thing from a retail chain, I go to their site ready to search and have to click through multiple pop-ups first. No I don't want to subscribe to whatever bullshit, no I don't want to allow access to location data, no I don't care about stupid cookies, no I'm not wasting time talking to a chatbot that interleaves computer generated and human generated text with unpredictable delays. Just get out of my face and let me buy the thing I'm here for. I could understand all that for, say, a news site where they need to suck you in to subscribe for them to make money, but not a retailer where you're obviously there because you already want to buy something!
> I asked about the PSP – a hand-me-down from an older brother – and the web browser. Her reply was “It’s shit. But it worked.”
This is particularly high praise for simple HTML as the shit part is likely the PSP's UI, which is of course out of the control of the website, whereas the it worked part is due to the PSP's browser and the website both working adequately.
Those are not ‘crappy browsers’. If we call it “Browser” it should be browser, isn’t it? It should brows pages. It was never intended to be overweighted virtal machine and not a good one by the way.
Past 8 years or so Youtube has nothing really more to offer then it was offering back then. The only new things it offers for me is overweighted dumb slow shit that fails to perform what it was perfectly doing 8 years ago, and all those slowness added for no particular reason that I could appreciate.
All of this ‘comfort’ is getting on the way or doesn’t work at all. Perfectly capable IPad Pro now is struggling to load even Youtube.
Almost every site I visit is bloated with idiotic unnecessary things that do not not even work properly.
And once you see some new idiocy appearing on some big site, the first thing you think is :‘oh no’ because you can be pretty sure that every “designer” would copy this bullshit and it will appear on every site very soon for no reason.
If that is not a dumb design by definition then what is? I would not call it even design. Those are layers and layers of garbage piled on top of each other and at this point when I see simple HTML I just wish to thank the author for lack of so called “design”.
It’s not crappy browsers - It’s crappy sites overloaded with useless features.
I didn’t see One big site lately that did become better ... not one! I wish to see one, show me one please. I wish to be mistaken there but I think it simply doesn’t exist.
Oh, YouTube. I'll never understand how they made it such that when you open your subscriptions page it first loads the list of videos, and then, 5 seconds later, shows their durations. Or how the player UI is unresponsive for several seconds after you open a video. That took some special talent apparently.
>you open your subscriptions page it first loads the list of videos, and then, 5 seconds later, shows their durations
Every time this happens I have this horrible feeling that they just removed showing video durations entirely. Which wouldn't even surprise me, I could imagine them doing some stupid A/B testing to discover they got more people clicking around when durations were removed.
But regardless, it's insane that one of the biggest sources of internet traffic on the planet is software that can render a bunch of images (thumbnails) but it takes several seconds to display a few characters of text on them. I don't know if they're grabbing durations as a separate API call, or if that's just how slow their JavaScript is. Either way, it's pathetic.
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.)
Client-side javascript is underrated. We put simple websites in embedded devices with shockingly low memory/flash. They're for configuring the device. The pages are pretty serviceable with html controls, color schemes, logo etc. Embedded javascript to make them responsive. A couple of kilobytes total html.
I concur. I wrote a web interface for a crappy 20yo DSP last year, the thing doesn't even have an MMU and only 32MB of RAM. I basically put all the code in the browser, on the device there's only a very simple C HTTP server that serves the static files and blobs of data. In the end the UI looks fairly modern and responsive even though the backend is potato hardware.
I wouldn't say that client-side JS is underrated though. If anything I'd argue that the modern web heavily abuses it. Try browsing twitter or youtube with Javascript disabled for instance. The site simply won't work.
For YouTube I kind of still see a point, if only to not make scraping videos dead simple by not just having the plain URL of the video file in the html (yes there are still tools out there).
But twitter is so ducking ridiculous in that regard. At its core it is a web site to share 280 character long strings, but as of recently you cannot do this anymore without JavaScript! They shut down the legacy page at the end of 2020 that was blazing fast and a pleasure to use. And what irritates me the most about their modern Js based mobile page is that it frequently happens that I tap a twitter link on HN which takes forever to load, then it shows two blue spinners one at the top and one in the center and then after another eternity it says "this content isn't available". Then I hit reload, the whole thing repeats and this time the 280 characters display just fine. How? Just how do you end up with this?
I would argue that the fact that video content is often so frustrating to scrape is symptomatic of the massive cultural shift the web has seen over the past decade or two.
In the "old" web you could basically right-click -> save anything you want (ignoring plugin blobs for the sake of making my point more compelling). Meanwhile I tried manually scrapping a video from reddit the other day, I succeeded but it was quite the puzzle. First you have to find the right element in the DOM, then find the source which is a playlist for the various qualities available, then there was a 2nd indirection I think, then finally I got the URL of my video file.
My browser obviously knows about all of this but it won't expose it easily. No "Save video as" menu. For some reason I don't expect that Chrome will implement it any time soon...
Firefox exposes this stuff just fine: its context menu on videos has “View Video”, “Copy Video Location” and “Save Video As…”. (I thought that Chrome did too, but maybe my memory is faulty or maybe they removed it at some point.)
But sites can easily prevent all of this stuff from happening by putting something transparent on top of the video, so that you’re not actually right clicking on the video, but on another element.
And here’s the thing—there’s a sound technical reason why they all do that, and it’s not just legal nonsense. Those operations only make sense if you’re playing one video file, but as you remark, there are all the various qualities available, and all of these platforms are designed to be able to switch seamlessly between sources, so that the browser never does get told “play this single video file, it’s the whole thing”, but rather “here, play this (1080p) chunk”, then “here, now this (144p) chunk”, then “and now this 360p”—with the JavaScript monitoring everything and trying to make it flow as smoothly as possible at each step.
So… no, your browser actually doesn’t know about all of this, and that’s the reason that YouTube and the likes have stopped it from exposing it even in browsers that are otherwise willing to.
(You could still easily say that there’s a culture shift in this: in the distant past, the web valued simplicity and openness at the cost of performance and effectiveness; but as the internet went more and more mainstream, more and more developers broke ranks and insisted on unbreaking things for their users and improving performance and effectiveness, even at the cost of openness and simplicity.)
> Firefox exposes this stuff just fine: its context menu on videos has “View Video”, “Copy Video Location” and “Save Video As…”. (I thought that Chrome did too, but maybe my memory is faulty or maybe they removed it at some point.)
You're right, I never noticed that. Although I just tried on youtube and the option are there... but greyed out. Not sure why.
As for the various formats, if the web wasn't a javascript shitfest that would be exposed to the browser and it would decide what format it wants to use. That would help with all these websites with a crappy streaming implementation. That would also make downloading very easy, you could just select which format and bitrate you want.
Greyed out because there is no video location for you to view or save. It’s playing a stream, put together from many pieces, so that it performs and functions better.
Switching between sources mid-play is a lot harder than most realise, because random seek is expensive in videos. So instead you tend to treat it as a large number of files of a few seconds each that get glued together as you play it, and you can switch between them as you go.
The web platform could be extended to cover multiple-bitrate streaming and let the browser take control, but that’s a pretty complex affair, and I suspect that it still wouldn’t be enough to make these operations work—the browser would need a way of putting it back together again into one file.
I would imagine it's the result of inventing some busywork the keep the frontend team occupied after the product is "done" and the only thing it really requires is low amounts of maintenance.
That, and pushing more useds to the mobile application.
I didn't make myself clear. The embedded device is the web server in this setup. The browsing device (phone, tablet etc) runs javascript. You're right, no way a tiny embedded device runs javascript.
What if a device doesn't have a web browser? Or a display? Or a network connection? At some point you have to make some basic assumptions about the platform you're targeting.
There are many web browsers that don't support JavaScript, and JavaScript is something that can be quite easily turned off in many browsers that support it. Harder than it used to be, if anything.
Then there are those like myself that run NoScript or something similar where the author of the website has to entice me into allowing them to run javascript code on my computer. If I can find the correct one to enable out of the dozen or so that most websites seem to use.
At some point it,s time to give up. But before I do, I will bend over backwards twice to try to accomodate the user. Maybe it,s because of all those times some arrogant asshole website told me my browser isn,t goos enough.
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.
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.
You don’t need CSS to make a website look different due to different screen sizes.
In other words, plain HTML is responsive by default. You can improve things with CSS. But if your site is unusable on small screens, you’ve broken something with your “design”.
Flexbox is by no means necessary to make a responsive web page. Media queries have been supported by mobile browsers for over a decade as has the viewport meta tag. Between the two it should be straightforward to make most page designs responsive.
Old browsers (old IE especially) that don't handle those features aren't a problem because they'll just fall through to the screen style. Trying to use JavaScript to help old browsers is a worse solution as you're more likely to run into JavaScript incompatibility problems than CSS.
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/