I converted my talk, “Dear Developer, the Web Isn’t About You”, into a page that you can read at you leisure. Check it out if you want to learn more about universal design, performance, diversity, and empathy.
I converted my talk, “Dear Developer, the Web Isn’t About You”, into a page that you can read at you leisure. Check it out if you want to learn more about universal design, performance, diversity, and empathy.
[Comment from banned user removed]
Interesting, the title made me come into this ready to see the latest clone of a post that’s been written over and over and over and over again. And that’s exactly what it is.
It doesn’t matter how well these posts are written, how much they get shared, or how many people agree. I still see Javascript developers working on integrating the latest bleeding edge artisanal libraries rather than building usable websites. We the users will get a moment of sympathy from web devs, and by next week we will be forgotten again, doomed to stumble in slow motion through an endless hell of glitches and bugs.
This culture absolutely blows my mind.
Last summer I thought I’d take a stab at learning React to expand my horizons, after soliciting recommendations from my web dev friends. What a rollercoaster. Once I grokked the virtual DOM subtree rendering it didn’t seem too bad. It basically acts like a log-structured merge tree, except for the DOM instead of on-disk indexes. Ok neat. But after building a few components I started getting weird errors. Googling around I found a React blogpost about error handling.
Yeah. It’s not a post explaining how I could have handled component errors, it’s a post explaining that error handling was coming soon, but not yet available.
Wat?
Wat?
React got all the way to version 16 before it could even handle component errors. In theory that means that React can handle other errors, just not component errors, which might be sort of okay, except everything in React is a component.
These problems have been around for years. They’re well documented and well understood. But the average web developer does not care. At this point I have zero faith. Negative faith really, since I’m pretty sure it’s just going to get worse. The title is absolutely spot on.
I felt the same, and I’m also worried what it says about me that I opened this article and immediately thought “this is way too long, I’m not reading this”. It was only your comment here that sent me back to look again (so thank you for that).
There are some little gems in this article - the bit about how we should be thinking of “edge cases” as “stress cases” due to the effect they likely had on a user really resonated with me. I know I have done that: I have dismissed a bug report from a user as an “edge case” and completely failed to put myself in her shoes, and imagine that maybe due to my bug she couldn’t deliver a report on time and got yelled at by her boss, or jeopardized a client relationship and got heat from them. She might have taken that stress home with her. It could have ruined her day, or even her week.
I’ve also been on the user side of “goddamn airport wifi the website’s not working, oh no!” too, and never connected that back to what I do for a living as a software engineer.
I’m going to have to try harder.
Everything she’s saying is true. This is why I loathe React and other approaches to web development that make JavaScript the primary dependency rather than using JS for progressive enhancement.
Thankfully this page is completely readable without JavaScript. Yay!
Not only that, she really puts her money where her mouth is in terms of accessibility! I’d gone halfway through the text with the default zoom, because I really enjoyed the Tufte-style layout. But my eyes don’t really like small text for long reads. When I did finally switch (reluctantly) to reader view, I was very impressed with how well everything was still represented on the page. My old eyes thanked me, too!
Presentation and content both top-notch. The ‘healthy tech pyramid’ macguffin is used to great effect!
I think there’s blame to go around. For example, part of it is web designers trying to treat the web like a print medium and forcing devs to reproduce designs with pixel-perfect fidelity. If you care that much about pixels, you simply haven’t understood what a web page is.
Once I saw a designer who gave advises such as “internal margin always 5px”, “everything clickable this colour”, “no space between these kind of elements”, along with illustrations and mockups to give an idea.
One can quite put these into a CSS stylesheet and attach it to any kind of HTML content and then it works!
Would be excellent if we come up with these guidelines and they become standard.
I really thought the article was going to go for the opposite line of argumentation, since it is usually developers who want to simplify (I guess “Web Developers” are different in this respect?), and they’re not the ones who have to be told to do so.
Yeah, though I praised the article it does omit the minor detail that web developers are hardly working alone. It’s not as though we are solely responsible for the design and functionality of these large websites. Deadlines, budgets, and project managers are real.
This is speculation because I haven’t tried both methods, but wouldn’t the development approach she suggests be way cheaper and quicker than making a single page JavaScript application where you’re reinventing basic browser navigation and form functionality from scratch? Now the problem of managers wanting to do the newest coolest thing and forcing the team to make a single page app is another conversation (though the article certainly provides arguments that you could make to a manager in such a situation).
I don’t think most developers using the new technologies like React are re-inventing the wheel - they’re using packages where the wheel re-invention has been already done by someone else. I think that’s a lot of what draws people to React - there are well-tested animation libraries, routing libraries, state management libraries etc all there ready to use, and because React is component-based they typically play fairly well with each other, in my experience.
That’s React, though, I can’t speak to Angular, Vue, Ember etc… and I wouldn’t really advocate the React ecosystem (ie w/ Redux or MobX, react-router etc…) for basic informational or limited-interactivity websites [0], because it does take some up-front effort to understand and integrate those libraries, and sometimes they’re just a React-ified layer on top of some browser-native functionality that you could probably just use directly, and which might be accessible to more people.
In general I think it’s significantly more work to build a website that’s fully functional on devices without Javascript, while also delivering an excellent modern experience for the majority with JS, and that’s fully accessible in both cases. I think that’s probably why we don’t do it.
Edit: To directly address your question - delivering a complex application entirely based on server-side rendering for everyone is probably a non-starter, as has been for a while. The responsiveness is just not there, and the app architecture becomes potentially much more complex, because you can’t make a request from the website for just the piece of data you need. You also need to put your state management on the server, which means modeling it outside of its domain. For complex applications this is just a lot of work, and is probably the reason we don’t tend to do it this way any more.
This is where I find people do conflate things a little bit, too. React was developed by Facebook, to solve Facebook’s problems - surely one of the worlds most complex web applications (which is nonetheless accessible to virtually everyone). There are a lot of people working on web applications of lesser, but still significant, complexity, who really benefit from the React ecosystem. But if you’re build (say) the BBC News page which almost no state, and limited interactivity, you really don’t need it. But that’s not who it was made for, either, so I think it’s unfair to criticise React itself and call it a bad piece of technology, which a lot of people seem to enjoy doing.
[0] I might advocate Gatsby though, as a way to give the developer the React development experience and the user a very fast, very compliant experience.
Was it really necessary to make the political dig “
orangefuckface@whitehouse.gov” in this post? It makes the whole talk seem a tad more unprofessional than it needed to be.Eh, at this point insulting Führer Cheeto has widely become socially acceptable, even in professional settings. In San Francisco it’s blatantly a free pass to say something outrageously inappropriate.
Which means they’re basically acting more like him given how he does Twitter and meetings. At least they’re trolling a fellow troll this time. That’s progress I guess. ;)
EDIT to add: Yet, if anyone does it the other way, many of them will cry that it’s offensive with conference ejection or job termination being mandatory. I say they need to knock it off or take what they dish out.
I agree. It isn’t exactly taking the high road.
She tells you up front that it’s basically a rant. If it was me writing it I would have used
pussygrabber@whitehouse.gov, because I’m a guy and could probably get away with it.Does Springer really need to worry about low-end browsers? I would have thought everyone who can afford to get their content from the source would be well-resourced.
Many will get content from their Universities that might be covered by grants, loans, or money already dropped on tuition. From there, they’ll have to use what they personally have to access the content if they’re not on campus. That could be some crappy connections.