Hacker News new | past | comments | ask | show | jobs | submit login
Dear Developer, the Web Isn't About You (sonniesedge.co.uk)
191 points by NoGravitas on Apr 6, 2018 | hide | past | web | favorite | 85 comments

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.

My best education on this was working with a guy who was absolutely militant about accessibility. He was the lead HTML/CSS guy for a contract firm that I worked with and insisted that all projects be tested in a standard browser AND screen readers.

The sales people didn't like it until he showed them how to pitch it properly to clients. Screen readers are a better reflection of how a search engine will read a site and so it was pushed as an SEO enhancement. Anecdotally, this was accurate from our research as well.

There's probably a couple thousand sites on the web now that are accessibility focused simply because of that one guy.

My advice to consumer-facing websites is that it's a means to avoid losing a potentially expensive lawsuit.

I think that's the point as well.

By designing for accessibility, you prioritize for both people with handicaps as well as machines. Think of machines as really really fast visual handicap readers.

And avoiding lawsuits is just a big plus as well.

I think to be sued, you would have to have had requests from handicap users to make accomodations, and then refuse.

And you would also have to have at least 15 full time employees to even be included in ADA requirements.

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.

> Disabled people are relatively rare, and so humans have a tendency to forget they exist.

This is how many people think about accessibility, especially starting out (myself included). An alternative framing is to realize that some people have permanent disabilities, some have temporary disabilities, and some have situational disabilities.

For example, about 15 percent of people have dyslexia. They have a more-or-less permanent challenge with reading. In the second category are people with temporary reading challenges. Someone with a concussion, stroke, or other traumatic brain injury often have similar reading challenges, that sometimes (but not always) can get better over time. And in the last category, we have people who have situational challenges, such as "I'm on in the subway and the car is moving in 3 axes and I'm trying to read on my smartphone". This is a situational challenge, but a challenge nonetheless.

If we focus only on the first category of people, the group who might be assisted by a reading-related accessibility feature seem relatively small. But when you realize that there are also temporary and situational challenges that can be ameliorated by the exact same feature, then it becomes clear that the number of people who can be helped is actually much greater than originally appeared.

Ditto for "wheelchair ramps" that are used by people with strollers or crutches for broken legs.

Disabled people are relatively rare

Rare? "Disabled" people are so common, politicians bend over backward to cater to them at the expense of others. An entire organization is devoted to service them: the AARP, where "RP" stands for "retired people". Because many over 50 are going to have a hard time reading your tiny-print, low-contrast, gray-on-light-gray website.

"Accessibility" != ("make exceptions for disabled people" WHERE "disabled people" == "protected class"). "Accessibility" means a lot of things. Maybe it's color-deficient sight ("color blind"). Maybe I lost hearing in one ear because of a tragic toilet lid accident. Maybe I'm just over 40 and wear reading glasses. Just because a user might not have a handicapped placard hanging from their rear view mirror doesn't mean they don't find your "innovative" design annoying.

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

This is a completely misguided notion. There are many types of disabilities out there, some can be apparent to the outside observer (physical disabilities) but there are many which are not apparent (mental and sensory disabilities).

1 in 12 men and 1 in 200 women throughout the world are affected by colorblindness.

Epilepsy affects 2.5-3 million individual in the United States.

Hearing loss and vision loss will affect most individuals during the course of their entire lives.

These disabilities and others are all considerations relevant to web and software development, with so many affected populations throughout the world disabilities are much more common than you or I might perceive.

But it's really not a question of perception among developers. Accessibility guidelines are relevant to some industries more than others, enforcement is sparse. If it became necessary to support all users and take into account their accessibility needs then we would see a change in the marketplace. The short answer is that developers and product managers who do not take accessibility into account with their products are lazy.

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.

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.

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.

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.

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

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

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

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

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.

A good linked list implementation will also allow you to delete nodes through its normal contract

Yes, that's what I'm getting at. If you delete a linked list's nodes through the normal way of doing it, nothing goes wrong. If you do bad things to it bad things will happen.

Modern JS frameworks haven't abandoned accessibility. Developers (by choice or by ignorance) are simply not using accessibility features, which is not much different than before JS frameworks. If you're looking for the actual cause and not a cheap scapegoat, it's lack of training and/or MVP culture. Businesses are pushing more and more for getting a prototype out the door and less and less for a quality product.

Is there a guide to this which is easily accessible to developers? Are there some quick pointers to make a basic HTML site more friendly to differently-accessing users?

Test it in a text-mode browser such as lynx, or w3m. If it's usable/readable there, it will probably be fine in a acreen reader, braille, whatever.

HTML isn't even chunks of code, it's a Markup Language. It is declarative in the same way that a TeX file is.

I think you're burying some assumptions about what is and isn't "code" in there. Prolog is declarative; so is Lustre. For that matter any sufficiently mature Lisp project is going to have developed an internal declarative DSL that the actual programming gets done in.

HTML isn't Turing complete. It doesn't transform data, either through functions or routines, so it's not code in the sense that most people mean when referring to "code."

HTML with CSS is Turing complete, just in a ludicrously impractical way.

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.

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.

Maciej Ceglowski puts his talks up in a similar format (most recent example: http://idlewords.com/talks/ancient_web.htm). It definitely makes them easy to read, refer back to, etc.

Ironically, this presentation is unusable on my phone in landscape orientation. The responsive landscape layout is a narrow column with just 2-3 words per line and tons of whitespace.

I totally agree, this is a way better format than the slideshare service through linkedin.

there really is something like slideshare through linkedin? rofl

You've never seen static powerpoint slides uploaded to the linkedin slideshare site? Besides pdf files this is what I run into sometimes with physics and computational science presentations


Any idea what she used to do this?

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

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

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.

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.

I think a lot of people agree with the sentiment. Most of the points here are ones that have been hashed and rehashed countless times in various blog posts and whatnot. People just tend to write code first, and only worry about optimization if it becomes an explicit issue.

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

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.

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.

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

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

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

      <title>Accessible Web Page</title>
      <p>This is an accessible web page.</p>
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.

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.

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.

You don't need unstyled HTML to look accessible. But you need to keep accessibility in mind from the very beginning with your project.

Of course, I've worked in web design, so I know the workflow doesn't really allow you to do anything right from the beginning. Things get hacked up, and accessibility is sacrificed.

There is an ADA for websites. It's called the ADA. https://www.emedialaw.com/does-my-website-need-to-be-ada-com...

I think laws and enforcement are the wrong way to look at it.

A small business doesn't have to spend money developing tooling and a framework to, e.g., make asynchronous database calls and update page data without a refresh. The community developed that because the community cares about it. The community has shown significantly less caring about persons with disabilities being able to use websites. If the developer community had developed the accessibility version of AJAX we would use it just like we use AJAX.

US web sites don't have to worry about "accessibility" any more. The Trump Administration moved enforcement in that area to the "inactive" category last year.[1]

[1] https://www.adatitleiii.com/2017/07/doj-places-website-rulem...

Anything one president changes can be changed back by the next president. I would follow the guidelines regardless.

Hardly, most of the risk to organizations is from citizens lawsuits, not federal regulatory enforcement. There are more lawsuits than ever and as judgements and settlements have been almost entirely on the side of making sites more accessible, the risk of continuing to provide an inaccessible site increases.

> but the tooling and dominant platforms just aren't as mature as they would need to be to consider it a required core skill

Then incent a generation of 19 year olds to fix that, rather than build yet another JavaScript library dependency resolution tool. I think she is spot on: the tooling and libraries are weak because the developer community just doesn't care.

Of course the community doesn't care. You can spend your time learning to make a better visually designed project or spend your time learning to make an accessible project. You can't do both (to the same degree and in the same amount of time) and one is way more likely to make a difference in your likelihood to get a job.

I agree that the community should care but am not at all surprised that hardly anybody does. There's no incentive to do so.

I'm not saying it's solely on businesses to make people care. They don't have the incentives, either. This is where regulations might've helped.

> There's no incentive to do so

Well, the incentives to do so aren't obvious.

Having worked on a bunch of (a) web applications with no dynamic client behavior to speak of (b) SPAs that are essentially a dynamic client talking to a service layer speaking JSON and/or XML (c) things in between... I think I've noticed a pattern, and it's that web applications where people take the time to think about how things would work with no dynamic client behavior, going through a process that more or less represents domain logic as HTTP operations on resources that can be represented as HTML (among other representations), these applications end up being more legible over time than projects with client engineering/experience as most of the focus.

Not all applications fit this model, so there are limits to the approach. And accessibility is a somewhat different domain.

But the concerns overlap, so one tl;dr might be this:

Site accessibility is one canary in the web application mines. If it's dead, you might be accumulating technical debt.

As a developer you can design with more empathy, here are a few tips that are not expensive and I and other people with disabilities or even healthy persons would appreciate: -allow the usage of the application without the mouse(if it is a painting app then maybe skip this), so don't break the navigation with Tab key, allow selecting buttons and activating them with the keyboard, if you have a search input allow me to press Enter to start and not to hit a search button with the mouse, try to allow the users customizing the key bindings(depends if your app needs key bindings) -don't use horrible colors for fonts, like light gray on white background, even if it feels readable on your screen other screens differ so better use some more contrast -if you make a mobile or desktop application use the user defined colors and font sizes, test your app with the larger font sizes and see how it looks.

There are very few problems that you could create that would effect JAWS users but not users of free screen readers like NVDA or VoiceOver (VoiceOver being free if you've bought an Apple device). Being free, those screen readers are quite popular.


And mobile use of screen readers has massively grown just as mobile web traffic has grown.


There's a lot you can do without firing up a screen reader. Try to use your site without touching the mouse. Don't waste your time or someone else's if you can't complete tasks without the mouse even with your vision. Visual indication of focus is something you need anyway and not necessarily discovered by screen reader testing (though using a screen reader and screen zooming together is common).

> "Doing Accessibility work feels like doing CSS work back in the late 90s." Agreed. One of my first positions was doing accessibility on a government agency's app because no one else wanted to. It was a horrible, bloated legacy app with an antiquated UI framework that did not support most Accessibility features natively, so it was a lot of JQuery DOM manipulation (per my supervisor's suggestion) to rewrite CSS. I still have nightmares.

I'm not sure it's fair to call JAWS the "dominant" platform. It's one of two dominant platforms. A lot of people use multiple screen readers.

JAWS 66.0%

NVDA 64.9%

VoiceOver 39.6%

Source: https://webaim.org/projects/screenreadersurvey7/#used

You can use NVDA, it is a free, OS and it does the job!

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

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

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.

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.

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.

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.

>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;}

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

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.

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.

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.

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.

Money. Money is the driver.

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 ?

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:


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.

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

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)

Dear Web Fanatics: Most Users Want Apps, Not Documents

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.

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.

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact