Actually (cue Adam Conover!)… some people do. They represent about a tenth of a percent (0.1%) of the people who don’t get your JavaScript file, though, and they’ve chosen to browse
the web that way, so let’s ignore them for a second.
I see this argument—that one one disables JS in 2019—as an argument for not bothering to care or worry about progressive enhancement. But it’s wrong!
There are plenty of other reasons why people don’t get your JavaScript.
Your CDN fails
An ad blocker or filewall got a little overly aggressive
A JS error (either in your code or something third-party) stops all of the JS from rendering
The file times out because it’s too big or too slow to parse
Today, I want to focus on that last one.
…
So very much this. Web bloat is becoming a huge issue (incidentally, I was pleased to see that DanQ.me’s homepage Web Bloat Score is in the
region of a nice, clean 0.1, but I’m confident that there’s still plenty I could do to improve it); it’s easy to see how developers on their powerful desktops and laptops and with their
WiFi-connected high-end smartphones might overlook people on older, less-powerful devices and slower, lower-bandwidth connections.
I’m not saying that Javascript is bad: it’s not! I’m saying that where functionality exists in simpler, more-lightweight technologies (like good old-fashioned links and regular
<input> elements, both of which are routinely reimplemented in the front-end), then those technologies should be used in the first instance. If you
want to build on top of that with Javascript, that’s great! But starting from the ground floor when building for the web is the surest way to support the widest
diversity of potential users (and it makes it easier to achieve your accessibility goals, too!)
I would say treat the web like that big red button of the original Flip camera. Just push it, write something and then publish it. It may not be perfect, but nothing ever is anyway.
I write all sorts of crap on my blog — some of it really niche like snippets for Vim. Yet it’s out there just in case someone finds it useful at some point — not least me when I
forget how I’ve done something.
…
I write all kinds of crap on my blog, too, and for mostly the same reasons: my blog is for me, first and foremost. Hopefully others, from time to time, find it
interesting or useful, but I can’t in good faith argue that I keep the shit I wrote in the 90s or early 2000s here for the benefit of the Internet as a whole! It’s for me first.
Good analogy with the Flip camera (follow the link through to Brendan’s post for the full explanation).
Kurzgesagt tells it like it is. The thing I love the most about this video is the clickbaity title that’s clearly geared to try to get the attention of antivaxxers and the “truth
teaser” opening which plays a little like many antivaxxer videos and other media… and then the fact that it goes and drops a science bomb on all the fools who tout their superstitious
bollocks. Awesome.
What’s cool is that a browser won’t actually load that background image until this selector is used – that is, when this button is pressed. So now we have a way to trigger a request
to a server of our choice on a button press. That sounds like data sending!
Now, of course, this only works once per button (since a browser won’t try to load that image twice), but it’s a start.
Receiving Data
Since we can’t use JS, it’s really hard to change a page after it’s already been loaded. But it is possible.
Back before websockets were widely supported, we had to use clever hacks if we wanted to push data from a server to a client in an ongoing basis. One such hack was just to make the
page never finish loading. It turns out that you can tell the browser to start rendering a page before it’s finished loading (using the Transfer-Encoding: chunked http
header). And when you do that, you don’t actually have to stop loading the page. You can just keep adding stuff to the bottom of the html forever, at whatever rate you
want.
So, for example, you could start sending a normal html page, then just stop sending html (while still telling the client you’re sending) until you’re ready to deliver another
message.
Now, all this lets us do is periodically append html to the page. What can we do with that? How about, when you load the index page, this happens:
We load up the first pile of html we want to show. A welcome message, etc.
We stop loading html for a while until we want to send some sort of update.
Now we load up a <style> element that display: none‘s all the previous html
Then we load up whatever new html we want to show
Finally we wait until the next update we want to send and GOTO 3.
Single-use buttons?
Ok, so we have that problem earlier where each button is only single-use. It tries to send a get request once, then never will again.
Thankfully, our method of receiving data fixes that for us. Here’s what happens:
We show an “a” button whose background image is like “img/a”.
When you press it, the server receives the image request for “a”
The server then pushes an update to the client to hide the current button and replace it with one whose background images is “image/aa”.
If the buttons you pressed were “h”, “e”, and “l”, then the “a” button’s background image url would be “img/hela”. And since we’re replacing all buttons every time you press one,
the single-use button problem goes away!
Misc other details
We actually encode a bit more info into the button urls (like each client’s id)
Because the data-sending and data-receiving happens on different threads, we need inter-thread communication. That sounds like work, so we’ll just use Redis pubsub for that.
FAQ
What inspired this? Chernobyl, Hindenburg, The Tacoma Narrows Bridge…
No but really Because I was mostly making this up as I went. There’s a lot of exploratory coding here that I only minimally cleaned up. If I rebuilt it I’d store
the UI state for a client in redis and just push it out in its entirety when needed via a single generic screen-updating mechanism.
What could go wrong with this technique? Broken by browser bg-image handling changes; long-request timeouts; running out of threads; fast-clicking bugs; generic
concurrency headaches; poor handling by proxies; it’s crazy inaccessible; etc etc
Should I use this in real life? Dear god yes.
I have an idea for how this could be made better/worse/hackierTweet at me (@kkuchta). I’m always down to
see a terrible idea taken further!
Practical Details
If you want to install and use this locally you should:
Re-evaluate your life choices
If you simply must continue, check out INSTALL.md
If you want to contribute, see number 1 above. After that, just fork this repo, make a change, and then open a PR against this repo.
This epic video (which contains spoilers for Game of Thrones through the third episode of season eight The Long Night). If you’re somehow not up-to-date, you can
always watch the earlier iteration, which only contains spoilers through The Spoils of War, the fourth episode of
the seventh series.
Over time, my husband and I started to suspect that Sam’s musings on doxxing and other dark arts might not be theoretical. One weekend morning as we were folding laundry in our
room, Sam sat on the edge of our bed and instructed us on how to behave if the FBI ever appeared at our door.
What was posturing and what was real? We suspected the former and doubted the latter, but we had no way to be sure. The situation evolved faster than we could frame the questions,
much less figure out the answers. When we did confront Sam—say, if we caught a glimpse of a vile meme on his phone—he assured us that it was meant to be funny and that we didn’t get
it. It was either “post-ironic” or referenced multiple other events that created a maze-like series of in-jokes impossible for us to follow.
The reality is that your sensitive data has likely already been stolen, multiple times. Cybercriminals have your credit card information. They have your social
security number and your mother’s maiden name. They have your address and phone number. They obtained the data by hacking any one of the hundreds of companies you entrust with the
data — and you have no visibility into those companies’ security practices, and no recourse when they lose your data.
Given this, your best option is to turn your efforts toward trying to make sure that your data isn’t used against you. Enable two-factor authentication for all important
accounts whenever possible. Don’t reuse passwords for anything important — and get a password manager to remember them all.
Like Automattic (Matt’s company), Three Rings has also long been ahead of the curve from a “recruit
talent from wherever it is, let people work from wherever they are” perspective. Until I was recently reading (more than I had previously) about the way that Automattic “works” I was
uncertain about the scalability of Three Rings’ model. Does it work for a commercial company (rather than a volunteer-run non-profit like Three Rings)? Does it work when you make the
jump from dozens of staff to hundreds? It’s reassuring to see that yes, this kind of approach certainly can work, and to get some context on how it does (in Automattic’s case,
at least). Nice video, Matt!
Israel has acknowledged that its recent airstrikes against Hamas were a
real-time response to an ongoing cyberattack. From Twitter:
CLEARED FOR RELEASE: We thwarted an attempted Hamas cyber offensive against Israeli targets. Following our successful cyber defensive operation, we targeted a building where the
Hamas cyber operatives work.
I expect this sort of thing to happen more — not against major countries, but by larger countries against smaller powers. Cyberattacks are too much of a nation-state equalizer
otherwise.
I doubt that this is actually the first “kinetic” retaliation to a cyber attack; however it’s probably the first one to be openly acknowledged by either of the parties
involves. Schneier’s observation that cyberwarfare is an equaliser is correct and it’s exactly why a savvy nation-state would consider this kind of response… but let’s not forget that
such cyberattacks are only as viable as they are because nation-states favour cyber-offense over cuber-defence in the first place: they’re interested in building 0-day weapons that they
can use against their enemies (and their own citizens) and this entire approach runs counter to the idea of improving defensive security.
The plan was very simple. We would put a small banner above the video player that would only show up for IE6 users. It would read “We will be phasing out support for your browser
soon. Please upgrade to one of these more modern browsers.” Next to the text would be links to the current versions of the major browsers, including Chrome, Firefox, IE8 and
eventually, Opera. The text was intentionally vague and the timeline left completely undefined. We hoped that it was threatening enough to motivate end users to upgrade without
forcing us to commit to any actual deprecation plan. Users would have the ability to close out this warning if they wanted to ignore it or deal with it later. The code was designed
to be as subtle as possible so that it would not catch the attention of anyone monitoring our checkins. Nobody except the web development team used IE6 with any real regularity, so
we knew it was unlikely anyone would notice our banner appear in the staging environment. We even delayed having the text translated for international users so that a translator
asking for additional context could not inadvertently surface what we were doing. Next, we just needed a way to slip the code into production without anyone catching on.
…
The little-told story of how a rogue team of YouTube engineers in 2009 helped hasten IE6‘s downfall by adding a deprecation warning
to the top of the site’s homepage… without getting the (immediate) attention of the senior developers and management who’d have squashed their efforts.
In the future, media organizations might have to do away with the “film” and “TV” tags entirely, if indeed there are media organizations as we currently think of them.
…
Based on my own experience chronicling both art forms, I’m increasingly convinced that film and TV started merging a long time ago, before most of us were aware of what was going
on. Some of us have accepted the change. Others are in denial about it. But as my grandfather used to say, there’s no point trying to close the barn doors after the horses have
already escaped.
…
Interesting article summarising the ongoing changes to the concepts of what we consider “film” versus “television” and the increasingly blurred distinction, and an exploration of how
that’s embodied by phenomena like Avengers: Endgame and the final series of Game of Thrones. Spoilers about the former and about the first three episodes of the
latter, obviously.
Hi @avapoet, I’m the author of the JavaScript for the WorldWideWeb project, and I did read your thread on the user-agent missing and I thought I’d land the fix ;-)
The original WorldWideWeb browser that we based our work on was 0.12 with screenshots from 0.16. Both browsers supported HTTP 0.9 which didn’t send headers. Obviously unintentional
that I send the `request` user-agent, so I spent some painful hours trying to get my emulator running NeXT with a networked connection _and_ the WorldWideWeb version 1.0 – which
_did_ use HTTP 1.0 and would send a User-Agent, so I could copy it accurately into the emulator code base.
So now metafilter.com renders in the emulator, and the User Agent sent is: CERN-NextStep-WorldWideWeb.app/1.1 libwww/2.07
This comment on the MetaFilter thread, which I only just noticed, is by Remy Sharp, who was part of the team that reimplemented WorldWideWeb as part
of that hackathon (his blog posts about the experience: 1, 2,
3, 4, 5),
and acknowledges my contribution. Squee!
My 17 year old daughter generously sat down with me to talk about consent — her personal experiences with it, humor of it, nonverbal versions, and how to respond to rejection. We
talked about her thoughts on the Dear Boy Who Likes My Daughter episode, how she perceives my romantic relationships, what makes a good cuddle partner, and being resourceful after
trauma. There’s laughing and crying and lots of proud mama.
I’ve been gradually catching up on Dr. Doe‘s Sexplanations podcast; I’m up into the 30-somethings now but my favourite so far might have been
episode 25, which presents a very authentic and raw look at Lindsey and her daughter Des’s thoughts on sex, romance, and consent. Adorable.
