
Dear Developer, the Web Isn't About You - NoGravitas
https://sonniesedge.co.uk/talks/dear-developer
======
gnicholas
The part about accessibility resonates strongly. I've definitely worked with
visual designers who worked as if their primary audience was comprised
primarily of other visual design professionals.

News flash: they're not. They're regular people with a variety of aesthetic
preferences, some of which you would abhor. And for some of them, the
accessibility features that you find clunky or inelegant are critical for
their ability to read and understand your website.

~~~
originalsimba
This is a problem not limited to the development and design circles. It's a
human problem. Disabled people are relatively rare, and so humans have a
tendency to forget they exist.

To some extent developers are a product of their customers' demands. If
customers are emphasizing dirt prices ($200 websites what the hell is going
on?) and launch deadlines of "a couple of hours", they aren't thinking about
accessibility, along with a half dozen other things.

It's really become evident to me since web development became a focus of my
career, that people remain blissfully unaware of those less fortunate than
them. Which we should shame out of them in my respected opinion.

At the very least, all visual elements should include an alt tag.

Making your content "readable" is a good idea anyway.

One last thing, and sorry such a long comment, it occurs to me maybe a lot of
websites aren't "accessible" because things like Alt tags would expose the
manipulative subliminal tactics of the design.

~~~
ryandrake
Accessibility to disabled people is the right goal, but at this point, I'm
often happily surprised to see software that is even accessible to fully abled
people! So much software out there (on the web and otherwise) look and behave
as if their purpose was to fill a spot on a slide deck, fill out the
"frameworks" section of a developer's resume, or look sleek in an artist's
portfolio, rather than be used by actual human users.

~~~
leggomylibro
That's one way of looking at it. Another is that with hobby projects, people
often do the first 80% of the work, see that the concept works, and then move
on before finishing the other 80%. There really aren't THAT many hours in a
day.

------
saagarjha
While I agree with the overall argument, there are a couple of points the
author made on HTML that I don't think are quite true:

> It is this flirty declarative nature makes HTML so incredibly robust. Just
> look at this video. It shows me pulling chunks out of the Amazon homepage as
> I browse it, while the page continues to run.

> Let’s just stop and think about that, because we take it for granted. I’m
> pulling chunks of code out of a running computer application, AND IT IS
> STILL WORKING.

> Jut how… INCREDIBLE is that? Can you imagine pulling random chunks of code
> out of the memory of your iPhone or Windows laptop, and still expecting it
> to work? Of course not! But with HTML, it’s a given.

HTML isn't "run" in the way traditional compiled languages are. It's modular
by design, so of course you can tear out parts and have it still work. And the
way you're tearing out things is exactly on these module boundaries; if you
really wanted to pull stuff out you'd do it at a random location so you get
tags being cut off.

~~~
tomc1985
HTML is just a datastructure, we just happen to use it more heavily than most.

I think she makes a lot of very valid points, Web 3.0 is abandoning its
foundational robustness for ... whatever the hell js dev is nowadays.

~~~
saagarjha
> HTML is just a datastructure

Sure, that's a nice way to put it. If you remove data from it using its normal
contract, of course it's bound to behavior reasonably well. If you go and take
a linked list and start zeroing out random bits of a node's next pointer, of
course it isn't going to work, and the same is true with HTML.

~~~
stephengillie
If you delete a div from the DOM, nested divs are deleted as well. This is the
core to a new site engine I've built[0]. It takes a JSON representation of a
single-page application, and dynamically constructs pages within the browser.
The resulting page is very fast and lightweight, especially on mobile, as
there are almost no server calls involved. The Node engine is less than 200
LOC and the client is less than 600 - both are smaller than the JSON file for
the main site. I'm building a hosting service for this new type of site,
hoping to launch before end of summer[1].

[0]
[https://gilpublic.s3.amazonaws.com/Gilgamech.js](https://gilpublic.s3.amazonaws.com/Gilgamech.js)

[1] [https://www.SPArational.com](https://www.SPArational.com)

~~~
jakobegger
Did you read that part about the upside down pyramid? I‘m not sure this
article is the best place to pitch your project...

~~~
stephengillie
Part of the goal of this project is to abstract the data of a site's
construction further from its presentation. Sites, and parts of sites, are
very portable and transparent. You can move a div around a page simply by
changing the parent element specified in the 'elementParent' field of the HTML
element you're describing. And you can copy divs, pages, even whole sites,
more easily than server-hosted HTML sites. Being in a more formal data
structure lends sites to more automation, working with data objects alongside
string parsing.

The browser engine is meant to be as minimal as possible, and could be easily
replaced by a native browser function that ingests JSON to display pages. CSS
still works normally, and the engine has a variable system to add flexibility
to CSS - you can specify several CSS styles as a variable, then just use the
variable in the class field of the HTML element you're describing - the
browser engine will replace the variable with the several styles on page
build.

These are written in JavaScript because it's the only language that runs in
major browsers. Were other languages available in Chrome, Firefox, etc, this
might be better in another language.

Websites should be easier to build, faster to load, more robust and stable,
while being smaller in memory. But going back to 1997 technology isn't the
answer.

------
rossdavidh
I really, strongly agree with almost every point in this article (maybe even
100%). There is only one problem, and that is that it is aimed at developers.

Sure, there are some developers who don't get this, but in every case where
I've seen this debated, it is only developers who are in favor of
accessibility, core HTML that works without JS, etc. There is often a debate
or division among developers, but there is a non-zero number of developers
advocating this.

There have been, in numerous different organizations (educational, startup,
big corporate) where I have worked, zero management support for any of this.
Also, zero client support. These ideas typically die, because nobody but a
(sometimes lone) developer is advocating for them, and they can't win the
argument.

Again, I 100% agree with the sentiment, and I'd love it if the web changed to
work like this (again). But the obstacle is not developers, primarily, or at
least they are the group (in my experience) most open to this argument. It is
absolutely everybody else in the conversation (client, sales, management,
design) who doesn't want to spend time or thought on it. I don't know how to
solve that.

If someone has experience succeeding at that, I'd love to read that post.

------
akincisor
Unrelated to the content, this is the best way to archive a presentation with
notes that I've found. Much faster to read than to see an hour long video and
not as cryptic as a bunch of mostly content-free slides.

~~~
blakesterz
Any idea what she used to do this?

~~~
Deimorz
Appropriately, I'm going to guess it was with HTML and CSS.

------
vesrah
The requirements for the kind of things described here often come from above
us in the form of creative comps, feature requirements, timeline constraints
with respect to required functionality, etc. This is something that should
probably have been touched on in this article. I do completely agree with the
sentiment, so I guess this is just me projecting frustration :)

~~~
smoe
I'm not sure if the requirement from above is true most of the time.

A lot of developers nowadays default to using a SPA as the starting point for
everything without even considering if they actually need the whole bouquet of
fronted build pipeline, innumerable dependencies, reactive something and a
dozen layers of abstractions to hardly do more than loading and turning JSON
into html while showing a spinning thing.

Sure, there are plenty of features of frontend frameworks that come in handy.
But how often do devs truly analyze what the best tool for the job is vs.
chasing after that shiny newthing.js which just came out.

~~~
CM30
I don't think it's just about novelty here (though as said, chasing the new
shiny thing seems to play a large role none the less), but also because:

1\. Developers want their CV/resume to look good for the next job, and the
best way to do that is to have a bunch of fancy technologies and frameworks on
it. Going for what's simple and works best is great, but unfortunately not
something recruiters (especially at large tech companies) care much about.

2\. They're used to that one language or framework, and hence think every
single problem under the sun should be solved with it. It's the old 'when all
you have is a hammer' issue, and endemic in every company from the small
agency to the large tech corporation.

------
ElatedOwl
>Diversity was understood; we loved and embraced different users and devices.

The hilarious irony here is that supporting all devices is a contributing
factor to the "problem". Yes, I want to support older versions of IE, mobile
devices or whatever browser you're using. Frameworks like jQuery (or babel...)
exist because of this.

~~~
pythonaut_16
Not to mention the early iPhone days generally meant making a separate mobile
or iPhone version of the site rather than embracing diversity.

It's only been in the past few years that sites have started to work
relatively well between mobile and desktop formats without a separate mobile
site.

------
jopuwep12489
So glad to see this sentiment here, while every other HN post is about
Javascript framework of the month.

This is how you make stuff on the web.

------
strictnein
> "Personally, this one blows my mind - it it still somehow not a core
> requirement of being a front end developer. It should be a core skill, the
> default on any frontend developers resume."

Not sure if I agree with this. Ideally, this would be the case, but the
tooling and dominant platforms just aren't as mature as they would need to be
to consider it a required core skill. Doing Accessibility work feels like
doing CSS work back in the late 90s. The dominant target platform, JAWS, is
just a horribly coded product. It kinda, sorta, handles ARIA attributes and it
kinda, sorta, does the same thing each time a page is loaded, but then also
doesn't.

And it's a very expensive tool. The "pro" version, which is the only version
approved for dev work is $1100 (outside of the extended 90 trial for $179, I
guess). Now consider that not only do your devs need copies, but so do your
testers. And if they want to stay up to date, you're really looking more like
$1100 + $550 a year. And, yes, there's other options, but since a lot of
accessibility work is really more for lawsuit avoidance than anything else,
not going with the industry standard isn't a wise choice.

And, after all of that, unless you work someplace with enough funds to
properly test out your product with, you know, actual users with visual
impairment, what qualifies as good accessibility is difficult to suss out. You
can run automated tools, but they're just code linting tools, more or less,
and really speak nothing to the user experience. How do you really test out
the UI you've developed? If you close your eyes or cover the screen you still
know exactly what it looks like.

~~~
heartbreak
> And it's a very expensive tool. The "pro" version, which is the only version
> approved for dev work is $1100

Which brings us to one of the author's other points: Not everyone is rich.
There are many solo web developers who simply don't have the resources
available to make their website accessible. Do we (in the U.S.) need an ADA
for websites? We essentially applied it to government websites, but my
personal blog doesn't have to be compliant.

Regulation of that nature would have an immediate impact on solo and other
small web developers, just like GDPR. Perhaps it's necessary, though, so that
we aren't excluding wide swaths of people from having equal opportunities on
the web.

Edit: Note that certain interpretations (including court opinions) of ADA
apply the public accommodation concept to business websites. I'm not aware of
such an interpretation for personal websites as ADA would probably not apply.

~~~
logfromblammo
> _There are many solo web developers who simply don 't have the resources
> available to make their website accessible._

All HTML and JS documentation is available gratis, and every operating system
is distributed with a text editor.

    
    
      <html>
        <head>
          <title>Accessible Web Page</title>
        </head>
        <body>
          <p>This is an accessible web page.</p>
        </body>
      </html>
    

Perhaps you meant to specify _rapid, tool-assisted_ development of a _feature-
rich_ website?

Making an accessible website is simple as dirt. It will just look dated to
people who don't need to rely on the accessibility features of their browser
or OS. It may even "look" dated to people who use screen-readers.

~~~
gnode
The plain HTML example is a bit of a straw-man. It's beyond "dated", being a
faux pas for all but the most ascetic of users.

My interpretation of "resources" here would be time / money. Making sure a
site is accessible by everyone takes effort which is difficult to justify,
particularly if you're already stretched to capacity.

~~~
logfromblammo
That's a way of saying that accessibility is a _low priority_. Everyone has a
choice between finally making the site usable for a minority of potential
users, or putting in a new feature. If you always choose the option that makes
the most money, some people always get left out.

The ADA was drafted to force physical businesses to make reasonable access a
higher priority. Accessibility has the same time/money costs as any other
feature. The same goes for internationalization and localization. Or for
robust user data protection and security. The longer you wait to consider
doing it, the more it's going to cost you.

------
tw1010
The history of the internet is like a plane sweeping a metropolis starting in
the sky. Each epoch intersects a number of buildings, and the level-set it
creates can be seen as a representation of the demographic that used it in
that instance. At first the plane only touched the very highest buildings.
These people are all mostly comfortable and well off. What has fundamentally
changed in the past few years, however, is a phase shift as the plane has
reached further and further down towards the ground. Look around at street
level in a city and what do you see? Buildings dedicated to social security,
hospitals, less-well-off individuals, people on disability, and more diversity
than the ecologically narrow space above.

It reminds me of a quote by Obama: "Government will never run the way Silicon
Valley runs because, by definition, democracy is messy. This is a big, diverse
country with a lot of interests and a lot of disparate points of view. And
part of government’s job, by the way, is dealing with problems that nobody
else wants to deal with."

~~~
lainga
Wouldn't the plane explode when it hit the highest buildings?

~~~
wolfgang42
I think this is a geometric plane, not an airplane. It doesn't explode because
it has zero thickness and so can't interact with the atoms of the building
materials.

------
smoe
Related to the "Cutting the Mustard" of BBC part in the talk where they serve
a core set of html/css and then depending on browser capabilities load
additional js/css.

What are people recommending for progressive enhancement these days? For sites
that don't need a whole lot of js, but enough that just slapping on a bunch of
jquery lines would get too messy.

E.g. when you want to support sorting tables or saving forms without reloading
the whole page. In other works, using js merely to make the experience
smoother. Besides the points mentioned in the talk, setting up and maintaining
a build pipeline for a fronted framework and maybe even server side rendering
with it is just a vast overkill and unnecessary increase of complexity for the
given problem.

I used to use backbone.js for those kind of sites, because its view layer
worked pretty well on already existing html and letting you fallback to it,
while giving you more structure and modularity than plain js/jquery.

~~~
girvo
I typically just write some DOM based JS for those situations. Web APIs do a
lot more than we think these days. Write some data structures to drive them,
maybe call Object.freeze if you want, perhaps use Immutable.js because it’s
setter/getter functions are kind of nice, but really, I’ve not found a
pressing need for many libraries for these “in between” sites myself.

------
chapill
Well, the main problem is HTML sucks. It can't do things literally everyone
wants to do at one point or another.

One example, scrolling table with fixed table head. Why is that not something
I can specify declaratively? Why is that next to impossible, even with the aid
of JavaScript.

Where are tabs? Where are image carousels? Why is it that styling forms
elements is still essentially impossible? Where are <select> elements with
icons? Where are calendar date pickers that allow me to select multiple dates
and ranges?

Why was three columns with header and footer declared the "Holy Grail" of CSS
for a decade? And does anyone remember building rounded corners with <b> tags?

Basic basic basic structures that literally every developer is asked to build
don't exist. Every developer everywhere has wasted ridiculous amounts of time
making something barely functional which should have been stupidly simple.

~~~
perilunar
>One example, scrolling table with fixed table head. Why is that not something
I can specify declaratively?

You can:

    
    
        tbody {display:block; height:50vh; overflow:scroll;}

------
sdhgaiojfsa
The bits about dial up ring a bit hollow when this page clocks in at >700kB
and more than a hundred requests.

~~~
talmand
Well, being part of the problem doesn't prevent one from complaining about the
problem.

But I see interesting stats in my network panel:

HTML - 33.25K

CSS - 65.89K (the bulk of which is Twitter, which looks to be the same
stylesheet loaded multiple times; 3.2K without Twitter)

JS - 53.62K (it appears all of it is Twitter)

Images - 658.75K

Media - 206.12K

Stop using Twitter's code and build for users turning off images/media gets
you a half-decent loading website.

~~~
ryanbrunner
On top of that, the page is 100% usable and readable with just the HTML, and
the images will load more or less in order as you're reading, unlike a JS-
driven site which will have that 700KB (or more) as a hard prerequisite to see
anything.

------
ebiester
It comes back to this: What are you doing with your page?

If you are building a content delivery vehicle, this all makes sense.

If you are building an interactive application, the html paradigm is terrible
and we took it as far as we could. We _really_ need to get away from HTML but
that's going to require leadership.

I recently went back and wrote an application with JavaFX. It's quite a bit
easier than dealing with the fiddly bits of HTML, CSS, and JS.

Web applications are terrible because we build on terrible abstractions for
the purpose of applications, JS being the least worst of them. That's why we
end up as an inverted pyramid.

------
xab9
Let me tell you what's more important than the user:

design, bells and whistles, brand identity, tracking, ad-hoc A/B testing,
banners, newsletter interstitials, page rank, comments on brand's facebook
page, number of followers, claps, likes, thumbsups, reblogs, autoplaying
videos, filler stock photos.

~~~
justherefortart
Money. Money is the driver.

------
hokus
What most people don't know but is instantly obvious: Disabled people may
spend their entire day reading web pages 365 days of the year. An estimate of
half a million per year seems entirely reasonable if you cant do anything
else. An average of 1 per minute seems entirely doable?

If we think of websites not related to work. How many of those would the
average person view per day? 5-20 ?

------
jaclaz
Very good IMHO that someone is "fighting from the inside", ar least verbally.

I guess her previous post [2017] testing "mainstream" sites without Javascript
is worth a mention:

[https://sonniesedge.co.uk/posts/a-day-without-
javascript](https://sonniesedge.co.uk/posts/a-day-without-javascript)

------
themihai
The author seems to complain about old good HTML but fails to to mention the
native apps. The future of the web(web 3.0/x.0) seems to be more about apps,
mostly native apps than websites.

~~~
amiga-workbench
I'm not sure I agree, most of the time I just want to read some text. I don't
want an """experience"""

~~~
themihai
I believe most use the "experience" method. At least for the top sites such
facebook, twitter, instagram, google, youtube etc. I even receive links from
Apple news so I guess the "news" are moving to some kind of native experience
too. Not to mention music services(i.e. spotify)

------
maxharris
Dear Web Fanatics: Most Users Want Apps, Not Documents

------
originalsimba
The irony here is the subjective nature of the article itself conflicts with
the headline. Still it's a somewhat fun read but if you're into this stuff
then you probably know the material already.

------
ad-hominem
Discussing HTML:

> Just look at this video. It shows me pulling chunks out of the Amazon
> homepage as I browse it, while the page continues to run. Jut [sic] how…
> INCREDIBLE is that? Can you imagine pulling random chunks of code out of the
> memory of your iPhone or Windows laptop, and still expecting it to work? Of
> course not! But with HTML, it’s a given.

Yeah, because HTML isn't a programming language, and it's not related to
whether or not the browser can render some site. It has nothing to do with the
code in the browser's sanity or the server serving content. The more accurate
analogy would be "Could you imagine pulling random chunks out of a string that
was passed to a string manipulation function, and the function still
completing?!" And the answer is yes, I can imagine that. Especially
considering it is a mundane fact of life for most web developers. It's almost
like the author doesn't fully comprehend the difference between a markup
language and a programming language.

~~~
bandrami
Or, more likely, you don't comprehend the point she is making about the
browser as a programming target. Go try SmallTalk for a while and you'll see
what she's getting at.

