[HN Gopher] The unreasonable effectiveness of simple HTML
___________________________________________________________________
The unreasonable effectiveness of simple HTML
Author : edent
Score : 530 points
Date : 2021-01-26 13:02 UTC (1 days ago)
(HTM) web link (shkspr.mobi)
(TXT) w3m dump (shkspr.mobi)
| forgotmypw17 wrote:
| 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.
| chrismorgan wrote:
| Pity that you must expose everyone's passwords in plain text to
| achieve this (those older browsers won't support TLS).
| forgotmypw17 wrote:
| Not every website requires passwords or any other secrets to
| be transmitted. I use a combination of fingerprinting and WoT
| to allow (but not require) anyone to maintain an identity
| without having to register or sign in.
| tommica wrote:
| What is WoT? Does your system send a single-use code to the
| email, or some other method? I cant imagine a way to login
| to the account without some secret key, and that creates a
| dependency that might make the app unusable in another way
| on older devices.
| MaxBarraclough wrote:
| > 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.
| [deleted]
| JoeAltmaier wrote:
| 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.
| simias wrote:
| I concur. I wrote a web interface for a crappy 20yo DSP last
| year, the thing doesn't even have an MMU and only 32MB of RAM.
| I basically put all the code in the browser, on the device
| there's only a very simple C HTTP server that serves the static
| files and blobs of data. In the end the UI looks fairly modern
| and responsive even though the backend is potato hardware.
|
| I wouldn't say that client-side JS is underrated though. If
| anything I'd argue that the modern web heavily abuses it. Try
| browsing twitter or youtube with Javascript disabled for
| instance. The site simply won't work.
| iforgotpassword wrote:
| 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?
| simias wrote:
| 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...
| userbinator wrote:
| What's most ironic is that HTML5 added a <video> element
| specifically to make videos as easy and convenient to
| manipulate as images.
| chrismorgan wrote:
| 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.)
| simias wrote:
| > 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.
| scaladev wrote:
| 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.
| theandrewbailey wrote:
| > Embedded javascript to make them responsive.
|
| We must have different definitions of 'responsive'. You don't
| need javascript to make a website look different due to
| different screen sizes.
| fouric wrote:
| What if you do, though?
|
| Flexbox is a CSS 3 feature. Support appears to have been
| implemented in FF and Chrome around 2012-2014 and still
| doesn't fully work in IE[1].
|
| The fact that a site uses CSS and HTML instead of Javascript
| does not imply that it's easier for older browsers to
| display.
|
| Javascript 1.0 was released in 1996.
|
| [1] https://caniuse.com/flexbox
| leephillips wrote:
| 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".
| dvdkon wrote:
| 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.
| JoeAltmaier wrote:
| Right. Populating pulldowns, updating dynamic lists
| (available APs after a scan) etc.
| mattl wrote:
| And what if the device can't or won't run JavaScript?
| JoeAltmaier wrote:
| 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.
| DHPersonal wrote:
| The PSP does, but it's pretty limited.
| kwdc wrote:
| Javascript is available for microcontrollers within various
| ram footprints.
|
| Here's one mentioned recently on HN
| https://jerryscript.net/
|
| There's even benchmarks for them.
| https://bellard.org/quickjs/bench.html
| JoeAltmaier wrote:
| Cool!
| Twirrim wrote:
| "And what if the device doesn't run javascript"
|
| You've still got javascript requirements there on the
| browsing device, eating up more CPU/Memory/Battery than a
| straight HTML page would.
| wayneftw wrote:
| "Embedded javascript _to make them responsive_ "
|
| That sounds optional and a bit of JS for making things
| responsive certainly doesn't automatically create a
| CPU/Memory/Battery drain.
| tshaddox wrote:
| 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.
| mattl wrote:
| 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.
| godshatter wrote:
| 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.
| forgotmypw17 wrote:
| 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.
| forgotmypw17 wrote:
| 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.
| jbj wrote:
| 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.
| greggturkington wrote:
| So, progressive enhancement?
| lovelyviking wrote:
| 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.
| grishka wrote:
| 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.
| Ashanmaril wrote:
| >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.
| dgb23 wrote:
| > 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 wrote:
| 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.)
| [deleted]
| cashewchoo wrote:
| 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).
| ratww wrote:
| 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.
| kaba0 wrote:
| 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)
| ratww wrote:
| I think the issue with Swing was that is was in a bit of an
| uncanny valley. If all controls were custom it wouldn't
| look strange.
|
| Visual Basic was very... well, "basic", so it looked
| normal. Some tools like CCleaner and a lot of Antiviruses
| had fully custom looks, but didn't look out of place,
| because they were too different.
|
| JavaFX looks fine, though.
| tpxl wrote:
| > 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.
| thehappypm wrote:
| Ads need JavaScript, in general.
|
| Rich logging/event tracking needs JavaScript, in general.
|
| Native Apps tend not to be HTML-powered, they're powered by APIs
| that can also power Web sites that use JavaScript, again, in
| general.
|
| A lot of these corporate-ey features rely on JS.
| grishka wrote:
| So, yeah, if you disable JS, you'd only improve your experience
| on many non-interactive websites.
| john37386 wrote:
| Excellent story. It's true that sometimes we should go back to
| the origin of the web, when it was mostly grey. I miss that web.
| I feel that it was an art to make it that ugly, but for me it was
| beautiful to the eyes.
| bachmeier wrote:
| 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.
| anderspitman wrote:
| 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.
| forgotmypw17 wrote:
| Amen. Markdown does unexpected things so often, and then I
| struggle with how to escape it.
| apabepa wrote:
| 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!
| ratww wrote:
| 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.
| SulfurHexaFluri wrote:
| >The issue is that a lot of developers will want to use React
| for everything else on the page, because they think it's
| "icky" to use other kinds of tech in other parts of the
| website.
|
| It is though. I work on an app thats 80% react and 20% rails
| SSR and when working on anything, seeing that an area that
| needs change is written with SSR makes the job 10x harder as
| you have to come up with alternative methods to get it
| working or just rewrite it in react. When everything is react
| everything is quite easy and you can pass around data and
| update things without a refresh easily.
| antonhag wrote:
| 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.
| michaelpb wrote:
| 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.
| SulfurHexaFluri wrote:
| 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.
| ratww wrote:
| 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.
| userbinator wrote:
| 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.
| alecst wrote:
| I agree with you. It definitely does not serve the user. I have
| two thoughts, as a nobody.
|
| 1. Ads/trackers/etc. need javascript 2. It's a way of flexing
| and saying "we have resources to put into this webpage which
| makes us a serious business."
|
| Any other thoughts?
| apabepa wrote:
| 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..
| dgb23 wrote:
| Things that are running based on JS on "regular" sites from
| the top of my head:
|
| - Toggling widgets such as menus, modals and other things you
| only want to show when the user requests it. This includes
| updating accessibility related HTML attributes.
|
| - filtering, sorting etc. of larger data sets in the client.
|
| - live updates of fresh, time related data
|
| - search that doesn't force a complete reload, via AJAX or
| cached on the client.
|
| - smoother page / content transitions via AJAX
|
| - _everything_ related to forms / user input: you want to
| instantly react
|
| - managing and preserving state / context per user
|
| - visualizations / graphs that are explorable / interactive
|
| - polyfills for older browsers that don't support
| optimizations such as lazy loading.
|
| - interactive widgets such as chat boxes (not a fan but
| still)
|
| - testing and analytics
|
| A website isn't made of paper.
| MaxBarraclough wrote:
| From what I can tell the short answer is that you're right,
| there's really no good technical reason for all that weight.
| Which is to say, it's just bloat.
|
| Much has been written on this. Here's an article from 2018. (I
| realise the irony in that it's hosted on Medium.)
| https://medium.com/@addyosmani/the-cost-of-javascript-in-201...
| spideymans wrote:
| 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
| MaxBarraclough wrote:
| 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.
| SulfurHexaFluri wrote:
| 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.
| cellar_door wrote:
| > will have no idea how terrible their code performs on
| slower devices
|
| You can (and should) monitor page load performance... using
| JS
| srcreigh wrote:
| The two biggest rants on HN are 1) Why doesn't this site work
| without JavaScript? It's inaccessible. and 2) Why doesn't this
| app work offline? It invades my privacy.
|
| Maybe I'm wrong, but as far as I can tell, you can't have both.
| Sorry folks.
|
| You are right, JS is not needed if the site truly is static
| content. But if you try to make an interactive app that could
| be implemented client-side (AKA javascript) and attach a server
| to it, everybody will complain that the application doesn't
| respect the user's privacy, since it could be offline-only but
| it's not.
|
| Don't get me wrong, I think "interactive" can meaningfully
| include a simple site with links if you are looking at it from
| a privacy angle. Just look at how StackOverflow recently was
| able to track all the pages their hacker viewed. [1] SO is
| pretty much static content. So do you want StackOverflow to
| work without JavaScript? Are you happy that in-so-doing it
| needs to phone home whenever you look something up? You can't
| have one without the other.
|
| There is also the argument from scalability. You'll get less
| QPS on your servers if you implement a 3-step form with
| validation in the frontend, and send off all the data in one
| go. It's also faster/better UX and is more resilient under bad
| network conditions.
|
| Edge computing is maybe an alternative there, but that doesn't
| address inherent privacy concerns of phoning home to a server.
|
| Last there is the reality of a spectrum of interactivity of
| websites. If you are doing a blog, sure, don't do it in JS. At
| that point you make a decision to make it difficult to add any
| interactive features to you site which require JS. If you are
| building an evolving app with interactive features, there
| aren't many options for easily mixing static HTML with
| interactive JS. You could see how far you get with static HTML
| but then what if you need interactivity (JS/JQuery)? What if
| you need complex interactivity (React)? Are you willing to pay
| the costs of a heterogeneous app architecture of HTML mixed
| with interactive JS?
|
| Think of Facebook. It is kinda like a blog, but what about
| infinite scroll? Etc.
|
| Anyway that last point, I think, is why people are excited
| about 37signals' Hotwire[2]. It's more of a HTML-but-
| interactive architecture as opposed to the fully-interactive
| JS/React vs static HTML forms.
|
| [1]: https://stackoverflow.blog/2021/01/25/a-deeper-dive-into-
| our... [2]: https://hotwire.dev/
| kaba0 wrote:
| 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.
| carapace wrote:
| Yes, the Emperor is bare-ass naked, now hush before you get
| someone fired.
| ziftface wrote:
| 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 wrote:
| I disagree.
|
| Rails was _already_ faster for CRUD apps back in the
| mid-2000s. Batteries included, maybe a gem or two for an
| admin panel or for auth. Not that it matters, but _rails new_
| is probably faster than 60 seconds too. Django is pretty good
| too.
|
| ASP.NET Webforms was made for CRUD, and it even provided a
| WYSIWG designer back in the early 2000s. And it was just a
| matter of launching Visual Studio and creating a new project.
| Again, doesn't matter, but it was/is way less than 60
| seconds, and a lot less fiddling. Webforms got an MVC version
| a few years later if you prefer that. And they haven't
| stopped: Blazor is new-ish and very productive, and runs both
| in the backend and in the frontend (using WASM).
|
| Both Rails and Microsoft tech also give you a backend, which
| you're not putting into your equation. Sure you can have a
| Backend in JS but the experience it's nowhere near as
| ergonomic or as fast as using Rails or ASP.NET.
|
| Sure, if you're comparing with building an app in Xcode or
| Android Studio then JS tooling is faster to use. But if you
| compare to what people were using to build _CRUD_ for the
| last 20 years then JS is not really special. For interactive
| frontend apps? Then it 's a different discussion. But for
| CRUD, modern JS is not that special.
| ziftface wrote:
| 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.
| SulfurHexaFluri wrote:
| 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.
| michaelpb wrote:
| 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.
| anderspitman wrote:
| The cost of developing in JS isn't necessarily lower, just
| amortized. Or in many cases, externalized to your users.
| ziftface wrote:
| > externalized to your users
|
| You mean if you have customers with less powerful devices
| like the OP? I don't really see internal services or B2B
| products having that problem.
| anderspitman wrote:
| You original point
|
| > the Javascript ecosystem is unmatched when it comes to
| very quickly creating frontend applications
|
| Didn't hinge on whether you were creating internal tools
| or not. You simply used internal tools as an example of
| what you personally do with JS.
| ziftface wrote:
| 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.
| sct202 wrote:
| 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.
| grishka wrote:
| As an Android developer who's now making a hobby project that
| has a web UI, I don't understand it either. I'm doing it the
| old-fashioned way and it's so fast that my browser doesn't have
| the time to display a loading animation when I refresh the
| page.
| nicbou wrote:
| In the end, I just end up using Firefox' reader mode, because
| what I really want is the main article. Everything else is
| noise.
| timw4mail wrote:
| I have done a lot of front-end work, and full stack work. I do
| not understand either.
| chovybizzass wrote:
| had an interview yesterday where the guy was trying to justify
| using jsx over html. i hung up on him
| ogre_codes wrote:
| 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/
| lastofthemojito wrote:
| 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.
| acdha wrote:
| > One of the great things about accessibility is that it
| often doesn't just benefit people with disabilities.
|
| I really love how Microsoft's design team has pushed this
| with their "Inclusive Design" concept[1] and highlighting how
| any sort of disability can be situational (holding a baby),
| temporary (broken arm), or permanent (missing arm) but we
| often only think of those in the last context despite there
| being orders of magnitude more people in the first two
| categories. Parenting is really good for showing this out
| since you get the need to be quiet, be able to do something
| using only one hand (or none), navigate sidewalks with a
| stroller, trying to do anything while sleep deprived, etc.
|
| There's a great chart on page 42 ("Persona Spectrum") of this
| PDF which I try to get every team I work on to go through
| which really gets people to think about what this means:
|
| https://download.microsoft.com/download/b/0/d/b0d4bf87-09ce-.
| ..
|
| 1. https://www.microsoft.com/design/inclusive/
| pvorb wrote:
| I fully agree with all of your points.
|
| I just wanted to point out the irony that the manual and
| other documentation for this "inclusive design" toolkit
| come as PDFs - the worst choice you can make if you strive
| for accessibility.
| labawi wrote:
| 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.
| lucasmullens wrote:
| I would assume PDFs don't typically work well with screen
| readers, which is what a large part of web accessibility
| is designed for.
| dmhmr wrote:
| I might be misinterpreting your last sentence regarding M1
| MacBook Pros. Are you saying they are underpowered for
| surfing the internet?
| lastofthemojito wrote:
| 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).
| jaywalk wrote:
| What he's saying is that this stuff has benefits even for
| people using modern, powerful machines like the M1 MacBook
| Pro.
| [deleted]
| bonestamp2 wrote:
| > 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!
| ogre_codes wrote:
| Yes, absolutely.
|
| I use closed caption when possible because often I don't
| quite hear things right and can't make out words. I could
| turn up the TV, but this means I can enjoy it at the same
| volume as everyone.
| scooble wrote:
| 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).
| AtlasBarfed wrote:
| The culture of distraction distracts everyone from
| realizing they'll die.
|
| Disability is just the fine print.
|
| I remember walking around in a city after a parent died,
| and the world seemed like an illusion.
| arcturus17 wrote:
| > 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?
| [deleted]
| rstupek wrote:
| There is not a codified standard however that doesn't stop
| websites from being sued
| ogre_codes wrote:
| If you comply with the WCAG 2.1, you have a pretty good
| legal defense. While it isn't "Law", it is the most widely
| known published standard and likely to be added to the law
| soon.
|
| https://www.w3.org/TR/WCAG21/
| udia wrote:
| I have had a lot of success with this course (Web
| Accessibility, by Google):
| https://www.udacity.com/course/web-accessibility--ud891
|
| > In this course you'll get hands-on experience making web
| applications accessible. You'll understand when and why users
| need accessibility. Then you'll dive into the "how": making a
| page work properly with screen readers, and managing input
| focus (e.g. the highlight you see when tabbing through a
| form.) You'll understand what "semantics" and "semantic
| markup" mean for web pages and add ARIA markup to enable
| navigating the interface with a range of assistive devices.
| Finally, you'll learn styling techniques that help users with
| partial vision navigate your pages easily and reliably.
| ogre_codes wrote:
| > Is there an equivalent legally codified and enforceable
| standard for the web?
|
| More or less yes. The link I posted has a few good resources,
| but generally speaking sites need to work with a screen
| reader and they need to be accessible via the keyboard (which
| by extension enables other accessibility devices).
|
| This site has some more guidelines.
| https://www.essentialaccessibility.com/blog/ada-guidelines
|
| Generally speaking, if you start with existing components
| that do the thing you want done, you have a huge leg up. If
| you try to reinvent the wheel, you are likely in for a lot of
| trouble. The more complex the control, the harder it is to
| roll your own. Calendar controls and Selects are particularly
| tough to get right.
|
| UPDATE: Also, the wc3 has some good guidelines which should
| cover your ass.
|
| https://www.w3.org/TR/WCAG21/
| reificator wrote:
| 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.
| madeofpalk wrote:
| 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
| reificator wrote:
| > _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
| typehttps://www.npmjs.com/package/eslint-plugin-jsx-a11y_
|
| I'm not sure how you got that out of
|
| > _I have seen an increase in unknowingly doing so by
| importing a calendar widget or similar without reviewing
| it._
|
| I'm referring to: <div class="div-button"
| onclick="clickHandler()" />
|
| VS: <SomeGreatNpmWidget
| onClick={clickHandler} />
|
| The point of using components is so that you don't have to
| look under the covers to understand them at a high level,
| but that also means if you don't look you don't see how
| they're breaking accessibility.
| Aeolun wrote:
| Depends on how far you are linting it? If you lint your
| node_packages folder you may still catch these.
| ogre_codes wrote:
| > Using a div as a button is not "bog-standard" HTML or a
| "standard component". Use a button and be done with it.
|
| Fully agree. In fact that is exactly point I was trying to
| make.
| elliekelly wrote:
| > 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?
| aidos wrote:
| 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).
| tyingq wrote:
| <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.
| recursive wrote:
| My guess is that some learn react et al without ever really
| learning HTML first.
| pferde wrote:
| 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."
| recursive wrote:
| And then there's jsx, which is different from html in
| some important ways, and generally a little closer to
| xml.
| ogre_codes wrote:
| 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.
| K0nserv wrote:
| 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
| ogre_codes wrote:
| 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.
| ryandrake wrote:
| > 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!"
| K0nserv wrote:
| I'm sure the designers who work on GDS[0] and its design
| system do. You are probably right that most don't, they
| should in my opinion. Of course you are also right that
| good teams will work together on this. I think the best
| designers have an understanding of HTML/CSS or the native
| toolkits if they work on Android/iOS. They know when the
| _user experience_ will be signficantly improved by a
| custom component and work with their team to make it
| accessible and good in those case. They also know when
| not to reinvent a select to make it look slightly better.
|
| This subthread is about why divs are used for buttons and
| why developers reimplement existing HTML components
| poorly. Good designers help their teams avoid this, good
| engineers work with their designers to avoid it.
|
| 0:
| https://www.gov.uk/government/organisations/government-
| digit...
| zepto wrote:
| " Nor should they need to."
|
| It's funny - I'd expect an interior designer to know
| something about the limitations of the materials they
| work with.
|
| Why don't we expect this of digital designers?
| kortilla wrote:
| 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.
| berkes wrote:
| 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".
| K0nserv wrote:
| That might be the way many companies work, doesn't mean
| it's correct. Design is more than how things look, in
| fact how things look is secondary.
| kodt wrote:
| Perhaps because buttons have some default styles attached and
| people just decided to use a div.
| grishka wrote:
| That's what a CSS reset is for.
| pbronez wrote:
| 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.
| ratww wrote:
| There's a Firefox/Chrome extension called Axe that's pretty
| good. We use at my company it to make our products accessible
| and it helped us tremendously.
|
| [1] https://addons.mozilla.org/en-US/firefox/addon/axe-
| devtools/
|
| [2] https://chrome.google.com/webstore/detail/axe-web-
| accessibil...
| bramd wrote:
| 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.
| tingletech wrote:
| our web team wanted this in the CI/CD https://allyjs.io
|
| edit: actually it's spelled https://pa11y.org
| cptskippy wrote:
| Yes, there are a lot of tools. None are great and are mostly
| for compliance.
|
| Products like Siteimprove are targeted at Enterprise (e.g.
| demos with sales weasels, unpublished pricing, etc). They
| mostly suck but check an auditing and compliance box.
| ahuth wrote:
| Shameless plug: at work we created axe-storybook-testing [1],
| which can be used to run accessibility tests against
| Storybook stories [2] on CI.
|
| 1. https://github.com/chanzuckerberg/axe-storybook-testing 2.
| https://storybook.js.org/docs/react/get-started/whats-a-
| stor...
| Aeolun wrote:
| Oh, this sounds interesting. I'll have a look.
| benbristow wrote:
| > 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.
| vxNsr wrote:
| 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.
| GrumpyNl wrote:
| its about simple html and older devices, so just plain button
| will do the job.
| darekkay wrote:
| I wish this would be the case. The button will not be
| focusable, so we need to add tabindex="0". A disabled div
| with role="button" is not handled as disabled, so we need to
| take care of that. Keyboard space/enter will not be triggered
| on "click" event, unlike real buttons, hence excluding
| keyboard users. You can check my playground [1] - I'm using
| it to demo why one should prefer native over custom
| components.
|
| [1] https://darekkay.github.io/presentations/accessible-
| web/reso...
| recursive wrote:
| > Making your site accessible isn't just a good practice, in
| the US, it is the law. Courts have rules that the ADA applies
| to web sites along with any other type of business.
|
| This seems to imply that web sites are businesses. If my hobby
| sites are subject to this, I'm going to be in trouble.
| ogre_codes wrote:
| One of the big linked sites was Beyonce's web site.
|
| How big an issue this is depends largely on how big your
| hobby site is.
|
| Update: I think this might even be wrong, its likely personal
| sites are fine. It's still good practice though!
| bachmeier wrote:
| Unless there's a law I haven't heard of (definitely a
| possibility) it would be necessary to classify it as a
| commerce site for the law to apply.
| jcranmer wrote:
| Taking a quick look at the site, Beyonce has a store page
| on it, which would be sufficient to classify it.
| ogre_codes wrote:
| With regards to the ADA, commerce means more than just
| "Selling stuff" so I'd be careful making assumptions
| about that.
| [deleted]
| bluefirebrand wrote:
| Selling stuff is probably sufficient but not necessary to
| qualify as commerce.
| [deleted]
| recursive wrote:
| The size of any of my sites is well below 1 milli-Beyonce.
| jcranmer wrote:
| If you're not selling anything, then you're not engaged in
| commerce and you wouldn't qualify as a "public accommodation"
| and the law doesn't kick in for you.
|
| (Complete list of public accommodation is 24 USC SS12181(7)--
| https://www.law.cornell.edu/uscode/text/42/12181).
| unicornporn wrote:
| ...and you'd be OK in the EU too.
|
| https://ec.europa.eu/digital-single-market/en/web-
| accessibil...
| ogre_codes wrote:
| Right at the top of that page:
|
| > The term "commerce" means travel, trade, traffic,
| commerce, transportation, or communication
|
| It is pretty funny that their definition of commerce
| includes commerce, but seems like communication is on the
| list as well.
| cptskippy wrote:
| Non-profits don't necessarily sell anything but they've
| been sued by the ADA for violating the laws on
| accessibility.
| wikibob wrote:
| ADA is the American disabilities act, it can't sue
| anyone.
| cptskippy wrote:
| Sorry, I meant American Association of People with
| Disabilities (AAPD). We got sued under the ADA by the
| AAPD.
| jcranmer wrote:
| "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.
| andi999 wrote:
| Today I learned Ikea is non-profit....
| hanniabu wrote:
| 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.
| codazoda wrote:
| > 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.
| ogre_codes wrote:
| 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).
| wizzwizz4 wrote:
| Conceptually, those are links, not buttons. Buttons are for
| forms and JavaScript and such.
| codazoda wrote:
| 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).
| anderspitman wrote:
| Nah I think I'll just keep rendering text in my 20M SLOC virtual
| machine thank you.
| stickfigure wrote:
| This is a good article, but I have to differ with this bit:
|
| _> If your laptop and phone both got stolen - how easily could
| you conduct online life through the worst browser you have? If
| you have to file an insurance claim online - will you get sent a
| simple HTML form to fill in, or a DOCX which won't render?_
|
| Assuming my laptop & phone got stolen, I'd have a hell of a time
| getting through 2FA to my email and password manager. I can get
| other non-crappy devices. And I'd never log in through an
| untrusted device anyway.
| nabla9 wrote:
| 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 EUR1000 per year in impulse buys
| because of these sites.
| app4soft wrote:
| > _The unreasonable effectiveness of simple HTML_
|
| If website owner gone wild he would just disable simple HTML
| frontend and would bloat you to download hundreds of JS-sripts.
|
| Still curious, why _Nitter_ CAN provide usable & modern looking
| simple HTML frontend for Twitter[0], but Twitter itself can't
| (guess, probably won't) do that.
|
| [0] https://nitter.net/app4soft/status/1335199292701761538
| dekhn wrote:
| 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.
| vascocosta wrote:
| 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.
| greggturkington wrote:
| Yeah. <img> tags for presentation (with no `alt` attr).
|
| Form <input>s without <label>s.
|
| No skip link, no landmark regions.
|
| <table>s with <div>s inside for non-tabular content.
|
| <font> tags. FONT TAGS.
|
| "A breath of fresh hair" is a typo that accidentally makes a
| good comparison.
| seumars wrote:
| HN gets only 1 bag of popcorn
| pbronez wrote:
| 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.
| allenu wrote:
| 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.
| red_hare wrote:
| My favorite example of this was when I worked on a B2B product
| with a daily email report. We noticed the most common usage of
| this email report came from native iOS email clients first
| thing in the morning.
|
| As a test, my team all went home and practiced being the user.
| We had a test email sent to our email addresses we would open
| first thing in the morning and attempt to make sense of it
| while laying in bed.
|
| The result was a lot less cruft, bigger text, and key takeaways
| above the fold.
| foopod wrote:
| 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.
| satyrnein wrote:
| Very poignant example!
|
| In terms of dispassionate product analysis, nice job using
| emails to reengage users at risk of churning out.
| turtlebits wrote:
| Part of the problem is that once you expand past a single read-
| only document, things like navigation, routing, user input/forms-
| get complicated. Devs want friendly URLs, static sites for easy
| deploys (ie no backend for form processing).
| tabtab wrote:
| 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.
| stakkur wrote:
| 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.
| kome wrote:
| I loved this article so much. For real. I hope web designers will
| follow the advice, and focus all their efforts on html+css.
|
| It's more complicated, I know. But it's better.
| SulfurHexaFluri wrote:
| Its not simply better. Going HTML only means killing features
| and conveniences that users want for a benefit they mostly
| won't see. Its perfectly possible to make web apps run very
| fast.
| salutonmundo wrote:
| 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.
| kstrauser wrote:
| 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.
| SulfurHexaFluri wrote:
| With DNS over HTTPS and encrypted SNI, soon the only
| information you will get is "They accessed a website on
| amazon/cloudflair"
| forgotmypw17 wrote:
| 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.
| tpxl wrote:
| ISPs regularly MITM http websites to inject ads (in the US
| even).
| chrismorgan wrote:
| 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.
| ndiddy wrote:
| > almost no one will get the HTTPS version unless you
| deliberately push them over to it, which you will only be
| able to do after page load by some JavaScript-based user-
| agent or feature-based sniffing, so now the page loads and
| then reloads immediately, every time the user visits your
| site by URL
|
| This is false. All you have to do is configure your webserver
| to only redirect port 80 requests to port 443 if the request
| includes the "Upgrade-Insecure-Requests" header. Obviously
| since headers are sent unencrypted this means attackers could
| easily bypass it, but it's still suitable for personal
| webpages with no user data. For example, here's how you do it
| in Apache:
|
| RewriteEngine on
|
| RewriteCond %{HTTP:Upgrade-Insecure-Requests} =1
|
| RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI}
| [END,NE,R=permanent]
| superkuh wrote:
| The implicit premise here is that your website _requires_
| HTTPS only and that a theoretical downgrade attack is enough
| to justify not having http at all.
|
| Most websites don't even need HTTPS and the complications and
| sacrifice of autonomy required isn't worth it. Remember,
| there are no cert authorities that are human people. They are
| all corporations or institutions. Having to get an
| incorporated entity's permission to communicate will have
| dangerous consequences eventually. HTTPS everywhere is done
| with the best of intentions but it will be the centralizing
| push that provides juicy targets for government and corporate
| censorship.
| SulfurHexaFluri wrote:
| I'd flip that and say you should only support http if your
| website absolutely requires it. Unless you absolutely can
| not avoid supporting old devices you should just redirect
| http to https.
|
| The privacy of all users is more important than supporting
| the outdated browser on an ereader.
| wizzwizz4 wrote:
| You can: have an "insecure." version of your site, like
| people used to have a "secure." version.
| xkr wrote:
| Reminded me of https://motherfuckingwebsite.com/
| tpxl wrote:
| http://bettermotherfuckingwebsite.com/
| ryandrake wrote:
| The irony is that bettermotherfuckingwebsite is worse in
| almost all ways. I wonder if that was what the author was
| going for. I don't know what's truly satire anymore!
| [deleted]
| jedimastert wrote:
| > worse in almost all ways
|
| How so? I dislike the text color choice, but other than
| that it seems perfectly fine to me.
| ryandrake wrote:
| Admittedly most is just personal preference but the line
| width thing is the cardinal sin. Forcing huge blocks of
| whitespace on either side of the text for nebulous
| "readability" reasons is just wasteful. Too many web
| sites ape this pattern too. Look at John Gruber's website
| [1] on a nice wide 27" monitor for an extreme example.
| The content takes up less than 1/5 of the width of the
| screen.
|
| 1: https://daringfireball.net
| 12ian34 wrote:
| I used to think this, but after really trying to assess
| the difference in some examples I made myself, I was
| converted.
|
| Have you seriously tried yourself to read two identical
| blocks of text, one at full screen width (I tested 100%
| zoom Wikipedia on a 1440p, 27" screen at standard DPI)
| and one at a width of about 55 characters on the same
| screen? Have a go.
|
| I find it easier to locate the next line after finishing
| one, which gives me a quicker reading speed.
| rhines wrote:
| While it is wasteful, I think the readability gain is far
| from nebulous. If you look at newspapers, they break
| pages up into columns. If books exceed a certain width,
| they get broken down into columns. Journals often break
| their articles into columns.
|
| Now, a fair follow-up to this is that why don't we make
| text on the web into columns, so instead of big sidebars
| of white space you fit multiple columns of text on the
| screen? I'd say this is probably because the web uses
| scrolling instead of pagination. If there's more text
| than can fit on the page, it's faster and easier to just
| scroll down than it is to load a new page. But if you
| have a layout with columns, you'd have to scroll down to
| read, then scroll back to the top each time you finish a
| column, which is a hassle. So just having one long column
| requires the least user effort.
|
| All said, of course some people might have different
| preferences. I'm sure some people find it easier looking
| from side to side with full screen text than scrolling
| down, or easier to click a next page button than
| scrolling down. But I think the trend for fixed width
| single columns on the web is one that's meeting many if
| not most peoples' preferences.
| Wowfunhappy wrote:
| I took several graphic design classes in college, and the
| rule burned into my brain is "8 - 13 words per line for
| maximum readability". This was a guideline for print, but
| I do think it matters on the web as well, and it's _very_
| easy to exceed!
| callmeal wrote:
| There's two ways of reading - scrolling your eyes from
| side to side, then down, or just scrolling down with your
| eyes (no side-to-side).
|
| Smaller widths make it easier for the "read the whole
| line in one glance" readers and is I think the main
| reason for this confusion.
|
| Sometimes I like just glancing down a page and getting
| the gist of the screen. Other times I prefer to let my
| eyes do extra work and read denser text.
| dvdkon wrote:
| I find it much worse that so many sites nowadays expect
| users to have their browsers maximised. Noticed how most
| books aren't wider than an A5, and how any publications
| wider than this use relatively narrow columns? Because
| reasonably narrow text _is_ easier to read.
| Wowfunhappy wrote:
| My question is _why_ so many users keep their browsers
| maximized! I bought a wider monitor so I could
| comfortably have multiple windows open at once.
|
| And by "wider" I mean 1080p instead of 1024x768, and by
| "bought" I mean a decade ago.
|
| (If you do want a screen optimized for having single
| browser windows open at once, I'd recommend a portrait
| display.)
| wffurr wrote:
| If only it was simple to configure my user agent to act
| as my agent and format things readably. I prefer moderate
| line widths. Even at half-screen on my 29" widescreen
| monitor, unformatted text is too wide.
| ryandrake wrote:
| Yes, this would be the best. Web site provides the
| content and the browser (user agent) decides how best to
| render it, potentially different than how the web
| developer would want it.
| GoblinSlayer wrote:
| >font-size:18px
|
| This shit is never fine.
| antihero wrote:
| Different solutions for different problems. You have a different
| design requirement when you are designing something for use by
| the most vulnerable and those without access to reasonable
| technology. This absolutely needs to be factored in when choosing
| how to build something, however, this is a tiny subset of users,
| and this is for essential life-is-in-the-balance types of
| service.
|
| The vast majority of users will have even a rudimentary
| smartphone (some years ago I visited the Calais jungle to donate
| food and supplies, and whilst people were struggling to eat, they
| knew that a smartphone was a cheap, key thing to obtain and hold
| onto because they make accessing help and communicating with
| their support network possible) and or laptop that can handle
| some lightweight JavaScript and benefit from an enhanced
| experience.
| zelphirkalt wrote:
| I think this is an exclusionary mindset. Just because it is a
| tiny subset of users, it is OK to exclude them?
|
| How about when it is quite easy in many cases to support them,
| by using standard conform simple HTML?
|
| Example: How many login forms have I seen, which will not show
| their input fields, if I do not allow their shitty scripts to
| run? In fact, just today I have seen it, on a VPN login, on a
| thing, that is supposed to give you security, I need to allow
| scripts, to have a login. Otherwise there is only a background
| picture. Thank you very much, so helpful! And then when I
| allowed their scripts, guess what. A text became visible, which
| told me, that in general scripts need to run in order to use
| the page. How much fail is that? They don't know the noscript
| tag or something?
|
| That's only today's anecdote. I see this kind of fail every
| day, except for the days, when I miraculously manage to avoid
| all badly designed websites. It is getting worse and worse,
| because web developers seem to find it normal to, by default,
| reach for JS, instead of thinking about how they can solve the
| same thing using just HTML and CSS for a second or two.
|
| I think it is still worth pursuing simplicity in web
| development. For the earlier example: Rendering a login using
| JavaScript is not simplicity. It is unnecessary, silly, and
| exclusionary without need.
|
| So my message is: If your service can be done using plain
| simple standard conform HTML(5), then use it. It will also
| almost always have less bugs and be simpler code to maintain.
| Information display does not require dynamic pages per se.
| Usually it does not and many many websites are about
| information display, not impossible to solve via REST dynamic
| pages. Nowadays properly designed static websites are faster
| than badly designed JS heavy websites, which render on the
| client-side. The bloat has become this bad already.
| mschaef wrote:
| > Example: How many login forms have I seen, which will not
| show their input fields, if I do not allow their shitty
| scripts to run? ... They don't know the noscript tag or
| something?
|
| This is often less about the developers not knowing a
| technique and more about the constraints they're working
| under. Maybe there's a third party auth library they're using
| that requires JS. Maybe either they or or their management
| have other priorities than removing JS from the login screen.
| It's not that hard to believe that scriptless login would
| fall fairly low on a team's priority list behind features
| more likely to drive revenue, etc.
| stan_rogers wrote:
| That doesn't explain the lack of a noscript message, which
| is the difference between "we really need you to turn on
| javascript" and "as you can plainly see, our page is
| broken".
| throwaway1239Mx wrote:
| Making things more accessible rarely has a downside for folks
| who don't need it in my experience, and often has an upside. My
| favorite example is doorknobs - think of a round doorknob vs
| one with a lever. People with broken/missing fingers/hands or
| fine motor impairments will have a much easier time opening a
| door with a simple lever vs gripping and turning a round
| doorknob, _and so will a person with two fully intact hands who
| is also carrying groceries_. (edit: corrected italics)
| glitchc wrote:
| I hear you: Businesses have no incentive to cater to niche
| segments of the population as they are not revenue drivers.
| What you call "enhanced experience," I translate to "adverts"
| (what else?).
|
| How can government compel businesses to provide better
| experiences? Why, standards and regulations of course.
| kwdc wrote:
| A massive fine might help.
|
| Social pressure in the form of "corporation xyz only supports
| ie6 for their bank website" is another way.
| smadge wrote:
| 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.
| kstrauser wrote:
| 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.
| Leherenn wrote:
| Do you have an example (outside of a niche, like a site
| catering specifically to some disability) of the economic
| argument working? Because the obvious economic counter
| argument is that while you work on accessibility your
| competitors work on features for the 90+% rest of the
| population.
|
| In my opinion it's why it's especially important to have
| regulations here, free market won't save us because in most
| cases the ROI just isn't there. However this is wrong to
| abandon those people, thus we need incentives to force people
| to do the right thing.
| kstrauser wrote:
| Heh, not directly, but...
|
| Once upon a time, a younger engineer worked for a company
| that dealt with the DOD. The DOD wanted to upgrade their
| website, and as often happens, the lowest bidder was a
| giant company who could blacken the sky with lawyers. They
| worked and worked, and their deadline slipped. Finally,
| they made something that _kind of_ worked, sort of, as long
| as the wind wasn 't blowing too hard.
|
| The younger engineer noticed that the new DOD website
| served webpages via carrier pigeon, but with more latency.
| As in, page loads often took _minutes_. He proposed to the
| lord of his domain: "your majesty, what if I crafted a
| robot to visit all of their pages and enscribe their lore
| into our own tomes, such that when your customers want the
| information, we can give it to them in milliseconds, and
| not minutes. Oh, and I can make the robot labor only at
| night lest the DOD get persnickety." The lord gave his
| blessing, and the younger engineer went away and made The
| Thing.
|
| The Thing worked wonders, and there was much rejoicing
| among the many kingdoms. But lo, the DOD was not happy, for
| it made their contractors look as though a pack of
| jackasses. And so they sent a sternly worded missive:
| "cease at once, knave, or we shall cut you off from the
| river of nectar for all of time!" And the younger
| engineer's lord's voice quavered, for he knew that his own
| kingdom would starve if this were to happen.
|
| But the younger engineer was cleverer. He noticed that the
| DOD's website could not be perceived by those who could not
| see, but his own website was beautiful to behold by both
| the sighted and those not. He proposed a plan to his lord,
| and his lord giggled for the plan was good and clever.
|
| The lord sent a missive of his own, both to the Maker Of
| The Website and the DOD, saying:
|
| "Alas, your own website cannot be perceived by those
| without sight, as are some of our customers. Our website
| can be. If you go away and stop sending threatening
| letters, our customers have agreed to behold the riches of
| thine data through our site as a proxy, and not file a
| lawsuit with an injunction that shall turn your website off
| tomorrow until you spend a few tens of millions of dollars
| fixing it."
|
| And the Maker Of The Website shut the hell up about it, and
| the DOD formally approved the plan, and all were happy.
|
| Except for the Maker Of The Website, of course, but lo,
| they were as though a pack of jackasses.
|
| The younger engineer was celebrated, then moved away to
| distant lands with better pay.
|
| The end.
| another-dave wrote:
| 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.
| iso1631 wrote:
| > so many things are designed and tested by people on T1
| broadband in a downtown office
|
| I wish. A T1 is 1.5mbit. CNN's front page is 6MB - 30 seconds
| at full T1 bandwidth.
| smlckz wrote:
| Maybe try https://lite.cnn.io.
| flemhans wrote:
| Sidetrack: Is T1 still ~1.5 Mbps or is it referring to
| something more modern nowadays?
| kstrauser wrote:
| It's still 1.544Mbps. That use to mean you were at a
| university or something, but now seems to mean you can't
| get DSL in your area.
___________________________________________________________________
(page generated 2021-01-27 23:00 UTC)