Tags: browser

717

sparkline

Saturday, December 14th, 2019

Building The Web

An interview conducted by Vitaly Friedman ahead of the 2019 View Source conference in Amsterdam.

Do you think, as of today, the Web is in the best shape it will ever be?

Well, to paraphrase Charles Dickens, “It is the best of the times; it is the worst of times,” because, in a sense, things are absolutely great today. Let’s just take it from the point of view of browsers and browser support for standards.

What you can do in a browser today just straight out of the box is amazing compared to the past. There are some little differences between browsers but, honestly, not like it used to be. Back in the day, if you were a Web developer, you spent maybe 50% of your time battling specific browser bugs trying to make one browser work like another browser, all this stuff, trying to make up for lack of standards.

It’s funny. I was listening to panel discussions we did at a conference I think 11 years ago, the AtMedia Conference in London. One of the questions I was asking the panelists was like, “What’s your wish list for CSS or browsers, in general?” They were saying things like, “Oh, if we had multiple background images, everything would be perfect. All my problems would be solved.”

They were all saying things that we have. They were all saying things that we have today, and we’ve got more. We have so much today that you couldn’t even imagine in the past, things like service workers where you can literally control network level stuff, amazing CSS things with Grid now and Flexbox. Amazing, right? One the one hand, yes, things are better than they’ve ever been.

Then, on another hand, not so much because, first of all, in the area of browsers, the fact that making a browser is now so complicated that only very, very, very, very few companies and organizations could do it and we’re kind of down to just two or three browser rendering engines, that’s not very healthy for something like the Web, which has always thrived on diversity. That’s something we’ll see how that plays out, so I’m uncomfortable about that but it remains to be seen.

Then, in terms of things being, in my opinion, worse than they were before, it’s less to do with what we get from browsers and more to do with how we choose to make things on the Web. We seem to have collectively decided to make things really complicated in terms of, I want to put something on the Web that used to be relatively straightforward.

I know there were all sorts of problems with the way we used to do it and maybe it didn’t scale so well, but we seem to have collectively decided that the barrier to entry to putting something on the Web requires loads of technologies, not browser technologies, but technologies that sit on our computers or sit on our servers. It’s great that we’ve got version control, build tools, automatic bundlers, and all this stuff, but the level of complexity is extremely high, it seems to me.

I know I’m slow and maybe that’s the reason I’m just not very good at picking this stuff up, but it seems to be objectively quite complex. That strikes me as strange because, like I was saying, you can do more with less these days in a browser. It’s easier than ever to build something interactive in a browser with quite minimal HTML, a bit of JavaScript, CSS, right? You can do loads with what you get out of the browser. Yet, we’ve decided to almost reinvent everything for ourselves.

Even though the browser will let us do all this really smart stuff, let’s reinvent it in JavaScript for ourselves. Let’s reinvent going from URL to URL. We’ll call it rooting, and we’ll do all that ourselves. We’ll do it all in JavaScript, and that means now we have to manage state, and so we’re keeping track of all this stuff.

It’s weird because it’s a choice to do that stuff. Yet, we’re acting as though it’s the default.

People are constantly saying, “Oh, well, expectations are different now.” I will say that’s true. People’s expectations of the Web are different, but not in the way that people mostly talk about it.

When people use that phrase, “Oh, people’s expectations of the Web are different now,” what they usually mean is, “Oh, people expect more from the Web. People expect the Web to be fast and interactive like native apps and stuff. I think that would be great if that were true, but my observation from talking to people is that people’s expectations of the Web have changed.

People expect the Web to be terrible. I talk to people and they’ve simply given up on the Web. Certainly, on mobile, they just try to avoid going on the Web.

Yes, people’s expectations of the Web have changed but not for the better. They’re associating the Web with bad experiences, with things being slow, with constantly being bombarded with, you know, sign up to my newsletter, accept cookies, dark patterns, all this stuff.

The solution to that is not, well, let’s throw more complicated toolchains, JavaScript libraries, and frameworks at it. The solution is to pull things back. How about if we didn’t have terrible user experiences that bombard people with stuff? How about if we just made websites using the bare minimum technology so that they’re fast and respond quickly?

Yet, weirdly, we’ve gotten into this cycle where people say, “Oh, people’s expectations of the Web are so high now that we must use all this complex technology,” which just ends up making the Web feel, frankly, even worse. From that perspective, things are in a pretty terrible state for the Web. Yet, like I said in terms of what you can do out of the box in a browser, just get a text editor and write some HTML, a bit of CSS, a bit of JavaScript; you can make amazing things straight out of the box that 10, 15 years ago we literally couldn’t have imagined.

What are the most important things for people coming into the industry to understand? Thinking about how to ensure the things they are building will be reliable and maintainable in the future?

I think the first thing to establish is that people learn in different ways. The answer to this question kind of depends on the person. I’ve experienced this myself, talking to students in, say, Codebar and stuff, is that some people really want to know why something is working, first. Give me the fundamentals. Give me almost a bit of theory but build things up from the fundamentals upwards until we’ve got a thing that works.

Other people, they don’t work that way. They say, “I want to build something as quickly as possible.” Okay, let’s start with a framework. Let’s create React App or something, something that gets you something straight away and then work backward from there.

I say, “Okay, but what’s actually going on here? Why does this work? What’s happening under the hood?”

There are two different ways of learning there. Neither is right and neither is wrong. There are just different ways.

I think the important thing is that, at some point, you end up with this kind of layered level of knowledge that you’ve got the fundaments in the grounding and then you can add things on top like a framework at the tippy top of that stack. Whether you start with the framework and work down to the fundamentals or start with the fundamentals and work up to the framework, I don’t think that matters as long as what you end up with is a nice rounded kind of stack of technologies.

Then, I think, what you learn over time, and I feel is something you could be told but you kind of have to just learn it yourself and experience it, is that the stuff further down, the fundamentals will change at a much slower pace and the stuff higher up, the abstractions, the frameworks, the tools, they will change at a faster pace. Once you know that, then it’s okay. Then that feeling of being overwhelmed, like, “Oh, there’s so much to learn,” you can start to filter it and figure out, “Well, where do I want to concentrate? Do I want to learn stuff that I know I will have to swap out in another year, two years, three years, or will I concentrate my time on this lower level fundamental stuff that will last for maybe decades, or do I split it? Do I dedicate some of my time to fundamentals and some of my time to the abstractions?”

I think the key thing is that you go in with your eyes open about the nature of the thing you’re learning. If I’m going to learn about HTML and, to a certain extent, CSS and stuff, then I will know this is knowledge that will last for quite a while. It’s not going to change too quickly. But if I’m learning about a framework, a build tool, or something like that, then I will say, “Okay. It’s fine that I’m learning this,” but I shouldn’t be under any illusions that this is going to be forever and not be surprised when, further down the line, people say, “Oh, you’re still using that framework? We don’t use that anymore. We use this other framework now,” right?

I think that’s the key thing is going in with your eyes open. It’s totally fine to study all the stuff, learn all the stuff, as long as you’re not disappointed, like, “Oh, I invested all my time in that framework and now nobody is using that framework anymore. We’ve all moved on to this other framework.”

There’s a phrase from DevOps where you talk about your servers. They say, treat your servers like cattle, not pets. Don’t get too attached to them.

I feel like that’s the case with a lot of the tools we use. I would consider frameworks and libraries to be tools. They’re tools. You use them to help you work faster, but don’t get too attached to them because they will change whereas, the more fundamental stuff, you can rely on.

Now, when I say fundamental stuff, to a certain extent I’m talking about the technology stuff like HTML. That moves at a slow pace. HTTP and how the Internet works, that’s not going to change very fast.

When I say fundamentals, I think you can go deeper than that even, and you can talk about philosophies, attitudes, and ways of approaching how to build something on the Web that’s completely agnostic to technologies. In other words, it’s like what your mindset is when you approach building something, what your priorities are, what you value. Those kinds of things can last for a very, very long time, longer than any technologies.

For example, over time, on the Web, I’ve come to realize that progressive enhancement, which is completely technology agnostic—it’s just a way of thinking—is a good long-term investment. Even as technologies come and go, this approach of thinking in a sort of layered way and building up from the most supported thing to least supported thing works really well no matter what the technology is that comes along.

When Ajax came along in 2005, I could take the progressive enhancement approach and apply it to Ajax. When responsive design came along in 2010, I could take progressive enhancement and apply it to responsive design. When progressive Web apps come along, whatever it happens to be, I can take this approach, this fundamental approach and apply it to whatever the new technology is. Those things tend to be really long-lasting. Those kinds of approaches, almost strategies I guess, are things that can last a long time.

You should always be questioning them. You should always be saying, “Is this still relevant? Does this still work in this situation? Does it still apply?” Over a long time period, you start to get an answer to that. It’s like, “Yeah, actually, it’s funny. Even over 20 years, this particular strategy works really well,” whereas some other strategy that worked well 15 years ago, it turns out, just doesn’t even apply today because some technology has made it obsolete.

Yeah, fundamental things aren’t necessarily technologies. I think a Web developer is well versed in getting to grips with those fundamental things but, at the same time, I’m not sure if you could learn those first. I’m not sure if you could be like, “Okay, we’re going to learn about these fundamental things without touching a line of code.” You kind of have to learn them for yourself by doing it and learning over time, I think.

Do you think frameworks, for example, will be replaced by the establishment of long-lasting Web components with CSS routines where we can adjust everything? Is this the world we’re moving toward or is it going to stay simple after all?

Yes, absolutely, the things that people are pushing the envelope with, in terms of frameworks today, will become the standards of tomorrow. I think I would put good money on that because I’ve seen it happen. I’ve seen it happen in the past, generally.

It’s usually in JavaScript that we figure something out, we figure out what we want, and we make it work in JavaScript first. If it’s a really powerful idea that solves a common problem, it will find its way further down.

The classic example, early on, I’m talking in the ’90s now, the first pieces of JavaScript were things like doing image rollovers. Now we don’t need JavaScript for that because we use hover in CSS. It’s such a common use case, it moved down into the declarative layer.

The same with form validation. You have to write your own form validation. Now you can just do required in HTML and stuff like that. This pattern plays out over and over again. With responsive images, we figured out what we wanted in JavaScript and then we got it in HTML with pictures.

Yes, I think the goal of any good framework or library should be to make itself redundant. A classic example of this would be jQuery. You don’t need jQuery today because all the stuff that jQuery did for you like using CSS selectors to find DOM nodes, you can do that now in the browser using querySelector, querySelectorAll. But of course, the only reason why querySelector exists is because jQuery proved it was powerful and people wanted it.

I think, absolutely, a lot of the things that people are currently using frameworks and libraries for will become part of the standard, whether that has to do with the idea of a virtual DOM, state management, managing page transitions, giving us control over that. Yes, absolutely, that will find its way.

Now, whether the specific implementations will be these things like Web components, Houdini, and stuff like that, that’s interesting. We’ll see how that plays out. That’s all part of this bigger idea of the extensible Web where, in the past, we would get specific things like, here is the picture element, here is this new JavaScript API or whatever, here is querySelector. Whereas now, we’ve sort of been given, okay, here are the nuts and bolts of how a browser works. You build a solution and then we’ll see what happens. That’s an interesting idea.

I guess the theory is then that, okay, let’s say we get Web components, we get Houdini. Now we all start building our own widgets and we all start building our own CSS functions. The theory is that the ones that are really popular and really goodwill then get standardized and end up in the standards.

I’m not sure if that’s actually going to happen because I wonder what a standards body or browser maker would actually say is, “Oh, well, we don’t need to make it part of the standard because everyone can just use the Web component, everyone can just use this Houdini thing,” right? We’ll see whether that works out.

I wonder if it’ll end up maybe like the situation with jQuery plugins. I mentioned that jQuery was great, it showed this is what people want, and it ended up as a standard. As well as jQuery the library, you also had jQuery plugins, the ecosystem where everybody built a thousand different carousels, a thousand different widgets. There was no quality control and you couldn’t figure out which was the right one to use. I worry that might be where we end up with things like Web components, Houdini, and stuff like that. But it’s an interesting idea, this extensible Web thing.

How will we build? How will the workflow or the tooling change and evolve as we move forward?

Well, that’s up to us. These things are created by people, so that’s something to be aware of. When people come to the Web think, “Oh, what should I learn? What’s the tool? What’s the methodology? How will we be building websites?” It’s almost like, what horse should I be backing here? What’s a safe bet?

You’ve got to step back and realize these things aren’t handed down from heaven as some kind of decision has been made and then passed on to us. We make those decisions. We decide how the Web gets built. There’s no central authority on this stuff. We collectively decide it.

You can choose how the future of Web development is going to look. You could choose what a workflow is going to look like that works for you and works for other people.

The Web is super flexible. You can choose to build in this layered way that I’ve talked about, progressive enhancement, very resilient way of working, but you don’t have to. The Web doesn’t mandate that you work that way. You could choose to build in a way that you just do everything in JavaScript and make JavaScript do the rooting, the DOM, and everything in JavaScript.

It’s a choice. It’s not something that, oh, in the future, we will all do this; in the future, we will all do that. In the future, you will make a choice about how you want to build.

I think, too often, though, when we’re making those decisions of how should I build or what’s the best way to build something on the Web, I worry that sometimes we think about it a bit too much from our perspective. What’s the best way for me to build on the Web? What’s going to make things easiest for me as a developer?

I don’t want to make things hard for us. I don’t want life to be difficult, but I do think our priorities should actually be what’s going to make things better for the user, even if that means more work from us.

If you’re getting paid, if you’re getting a paycheck to make things on the Web—then again, kind of going back to responsibility—it’s not about you now. You have a duty of care to the people who will be using the thing you’re building. Decisions about how to build on the Web shouldn’t just be made according to what you like, what you think is nice for you, what makes your life easy, what saves you typing, but should be more informed by what’s going to be better for users, what’s going to be more resilient, what’s going to leave nobody behind, you know, something that’s available to everyone.

I know I’m talking a lot in abstractions and vagaries, but the talk at View Source will go into a little more detail.

People are often disappointed in the state of the Web today. How do you see the Web evolving over the years? Do you think that privacy and ethics will become a standard?

I think the first thing to establish is that I don’t want to paint too rosy a picture of how things were in the past. There have always been problems. It’s just that we might have different problems today.

I remember the days of literal pop-up windows or pop-under windows, things like that, really annoying things that eventually browsers had to come in and kind of stamp down on that stuff. That’s sort of happening today as well with some of the egregious tracking and surveillance you see Safari and Firefox taking steps to limit that.

In the past, I would have said, “Oh, we need to figure this out. We need to almost self-regulate,” you know, before it’s too late. At this point, I think, “No, it is too late,” and regulation is coming. GDPR is a first step in that and there will be more.

We deserve it. We had our chance to figure this stuff out for ourselves and do the right thing. We blew it, and things are really bad when it comes to surveillance and tracking.

A lot of the business models seem to be predicated on tracking. I’m saying tracking here, not advertising. Advertising isn’t the issue here. It’s specifically tracking.

It’s a bit of a shame that we talk about ad blockers as a software. Most people are not blocking ads. What they’re blocking is tracking. Again, the same way that browsers had to kind of step in and stop popups and pop-under windows, now we see ad blockers, tracking blockers stepping in to solve this.

We get this kind of battle, right? It’s almost like an arms race that’s been going on. I think regulation is going to come in on top of that. Guaranteed it’s going to happen.

You’re right; the fundamental business models in use today are kind of at odds with privacy and surveillance, so they might need to change. Although, I don’t think advertising requires tracking. I know a lot of people talk as though it does. People talk about, “Oh, you can’t have advertising without a tracking link.” You absolutely can. Sponsorship, other kinds of advertising absolutely work.

The other thing is that tracking is not very good. If I’m advertised to with something that absolutely suits my needs then it kind of ceases to be advertising. It just becomes useful, right? That’s not what I experience. What I experience is just really badly targeted things. It’s not even like the tracking works. Yet, people claim tracking is essential.

Anyway, when I say business models need to change, I don’t mean advertising. I think advertising is actually a reasonable business model for some kinds of services. That connection between advertising and tracking, that needs to be severed.

Some people think that’s impossible. They say, “No, it’s just a law of nature that those two things go together.” That’s not true. We choose that. 
The other thing to remember is that we sometimes look around to see how things are today and we can’t imagine it could be any different. We see one dominant search engine and so we think there could only ever be one dominant search engine, but that’s not true. That’s just the way things have turned out. We see a big social network like Facebook and we think, “Oh, there could ever be one big social network.” Again, that’s just the way things have turned out in our situation.

I think the worst thing we can do is assume things are inevitable and it’s inevitable that things end up that way. That’s particularly true when it comes to surveillance and tracking and things that are antiprivacy to say, “Well, that’s just the way it is. It’s inevitable and it couldn’t be any other way.” I think the first step is that we have to have the imagination to think about how things could be different, how things could have turned out differently, and then work towards making that a reality.

Also, this is a huge opportunity. People are clearly fed up with the tracking. They’re fed up with the surveillance. They don’t mind the advertising. There is a separation there. There is an opportunity here to take on these big organizations who literally can’t change their business model.

Someone like Google, the idea of tracking and surveillance is kind of intrinsically linked to their core business model. That gives a huge opportunity. You can see Apple already starting to exploit this opportunity, but other people, too, where you can make privacy and lack of tracking your selling point. It’s a way for a small player to suddenly maybe disrupt the incumbents because the incumbents are so reliant on tracking.

You can’t take on Facebook by trying to be another Facebook, but you can take on Facebook by being what Facebook can’t do. Not what Facebook won’t do, what Facebook literally can’t do. There’s actually a big opportunity there.

Yeah, when we talk about the good old days of keeping track of things, blogs, I kind of share that because I remember the good old days as well. But I’ll say I see a bit of a resurgence as well. Enough people are getting fed up with just posting on silos like Twitter, Facebook, and stuff that I see more and more people launching their own websites again and publishing there. I hope we’ll see more of that.

What are you most excited about on the Web these days?

Yeah, this is an interesting question because it’s happened over and over again over the course of my career, about 20 years now, where I’ll think, like, “Oh, there’s nothing really exciting me,” and then something comes along and I get, ooh, really excited. Almost kind of puttering along when CSS came along, “Oh, this is really interesting.” Then, years later, Ajax, like, “Ah, this is really interesting.”

I think currently service workers are the things that get me excited, get me thinking about, oh, the potential for what the Web could be. The potential for the user experience on the Web is huge. I don’t even think the challenges are technological because it’s pretty straightforward using service workers.

It’s more changing people’s expectations of the Web, the idea that, oh, you should be able to open a browser or hit a bookmark and have something happen even if you don’t have an Internet connection or even if you are on a crappy network that things could still be quite reliable. That’s such a fundamental change and that gets me very, very excited. It’s also, obviously, a huge challenge to change that.

I have to say, over a long enough time period, the things that I start to think about start to be less and less about specific technologies and more and more about just the Web, in general, and the people making the Web.

I certainly have fears for the Web. They aren’t so much around technologies, like, “Oh, will one particular browser make or dominate,” or, “Will one particular framework be the only technology around?” Those things are concerning. It’s more about, “Will the idea of being able to make for the Web start to get reduced down to an elite kind of priesthood of a certain kind of person?” Frankly, the kind of person who looks like me, right? White, male, privileged, European. If we’re the only people who get to make for the Web, that will be terrible.

I think the real potential of the Web and the promise of the Web from the early days was that it’s for anyone. Anybody should be able to not just use the Web and consume it, but anyone should be able to add to it and build for it.

The thing that actually motivates me now is less about a specific technology and more about how can I try and get a more diverse range of people making the Web, making their own careers out of making for the Web rather than it being reduced, reduced, reduced to a certain kind of person. When I’m done with all this, if I look around and all the other people making websites look just like me, then I think we’ll have failed.

Friday, December 13th, 2019

The Origin Story of Container Queries—zachleat.com

Everyone wants it, but it sure seems like no one is actively working on it.

Zach traces the earliest inklings of container queries to an old blog post of Andy’s—back when he was at Clearleft—called Responsive Containers:

For fun, here’s some made-up syntax (which Jeremy has dubbed ‘selector queries’)…

Why `details` is Not an Accordion - daverupert.com

At the risk of being a broken record; HTML really needs <accordion> , <tabs>, <dialog>, <dropdown>, and <tooltip> elements. Not more “low-level primitives” but good ol’ fashioned, difficult-to-get-consensus-on elements.

Hear, hear!

I wish browsers would prioritize accessibility improvements over things like main thread scheduling optimization to unblock tracking pixels and the Sisyphean task of competing with native.

If we really want to win, let’s make it easy for everyone to access the Web.

Wednesday, December 11th, 2019

Saron Yitbarek and Jeremy Keith - Command Line Heroes Live Podcast - View Source 2019 - YouTube

Here’s the live podcast recording I was on at the View Source conference in Amsterdam a while back, all about the history of JavaScript.

My contribution starts about ten minutes in. I really, really enjoyed our closing chat around the 25 minute mark.

It was such a pleasure and an honour to watch Saron at work—she did an amazing job!

Sunday, December 8th, 2019

2019 Firefox Flashback

Here’s an end-of-year roundup of all the data that Mozilla have gathered through their Firefox browser—very impressive!

Monday, December 2nd, 2019

Six Web Performance Technologies to Watch in 2020 – Simon Hearne

The inexorable rise of frameworks such as Angular, React, Vue and their many cousins has been led by an assumption that managing state in the browser is quicker than a request to a server. This assumption, I can only assume, is made by developers who have flagship mobile devices or primarily work on desktop devices.

Thursday, November 21st, 2019

A Non-Business Case for Supporting Old Browsers « Texte | ovl – code & design

Supporting Internet Explorer 11 doesn’t mean you need to give it the same experience as a modern browser:

Making sure (some of) your code works in older browsers, does not mean all functionality has to work everywhere. But, mind you, ninety percent of web development means putting text and images in boxes.

And to be honest, there is no reason to not enable this everywhere. Same for form submissions. Make it boring. Make it solid. And sprinkle delight on it.

Sunday, November 17th, 2019

Firefox’s fight for the future of the web | Technology | The Guardian

A good overview of the unfair playing field of web browsers, dominated by the monopolistic practices by Google and Apple.

Mozilla is no longer fighting for market share of its browser: it is fighting for the future of the web.

A Web Developers New Working Week

I think these are great habit-forming ideas for any web designer or developer: a day without using your mouse; a day with your display set to grayscale; a day spent using a different web browser; a day with your internet connection throttled. I’m going to try these!

Saturday, November 16th, 2019

What would happen if we allowed blocking 3rd-Party JavaScript as an option?

This would be a fascinating experiment to run in Firefox nightly! This is in response to that post I wrote about third-party scripts.

(It’s fascinating to see how different this response is to the responses from people working at Google.)

Tuesday, November 12th, 2019

Third party

The web turned 30 this year. When I was back at CERN to mark this anniversary, there was a lot of introspection and questioning the direction that the web has taken. Everyone I know that uses the web is in agreement that tracking and surveillance are out of control. It seems only right to question whether the web has lost its way.

But here’s the thing: the technologies that enable tracking and surveillance didn’t exist in the early years of the web—JavaScript and cookies.

Without cookies, the web was stateless. This was by design. Now, I totally understand why cookies—or something like cookies—were needed. Without some way of keeping track of state, there’s no good way for a website to “remember” what’s in your shopping cart, or whether you’ve authenticated yourself.

But why would cookies ever need to work across domains? Authentication, shopping carts and all that good stuff can happen on the same domain. Third-party cookies, on the other hand, seem custom made for tracking and frankly, not much else.

Browsers allow you to disable third-party cookies, though it’s not yet the default. If enough people do it—and complain about the sites that stop working when third-party cookies are disabled—then maybe it can become the default.

Firefox is taking steps in this direction, automatically disabling some third-party cookies—the ones that known trackers. Safari is also taking steps to prevent cross-site tracking. It’s not too late to change the tide of third-party cookies.

Then there’s third-party JavaScript.

In retrospect, it seems unbelievable that third-party JavaScript is even possible. I mean, putting arbitrary code—that can then inject even more arbitrary code—onto your website? That seems like a security nightmare!

I imagine if JavaScript were being specced today, it would almost certainly be restricted to the same origin by default. But I guess the precedent had been set with images and style sheets: they could be embedded regardless of whether their domain names matched yours. Still, this is executable code we’re talking about here: that’s quite a footgun that the web has given site owners. And boy, oh boy, has it been used by the worst people to do the most damage.

Again, as with cookies, if we were to imagine what the web would be like if JavaScript was restricted by a same-domain policy, there are certainly things that would be trickier to do.

  • Embedding video, audio, and maps would get a lot finickier.
  • Analytics would need to be self-hosted. I don’t think that would bother any site owners. An analytics platform like Google Analytics that tracks people across domains is doing it for its own benefit rather than that of site owners.
  • Advertising wouldn’t be creepy and annoying. Instead of what’s so euphemistically called “personalisation”, advertisers would have to rely on serving relevant ads based on the content of the site rather than an invasive psychological profile of the user. (I honestly think that advertisers would benefit from this kind of targetting.)

It’s harder to imagine putting the genie back in the bottle when it comes to third-party JavaScript than it is with third-party cookies. All the same, I wish that browsers made it easier to experiment with it. Just as I can choose to accept all cookies, reject all cookies, or only accept same-origin cookies, I wish I could accept all JavaScript, reject all JavaScript, or only accept same-origin JavaScript.

As it is, browsers are making it harder and harder to exercise any control over JavaScript at all. So we reach for third-party tools. We don’t call them JavaScript managers though. We call them ad blockers. But honestly, most of the ad-blocker users I know—myself included—are not bothered by the advertising; we’re bothered by the tracking. We should really call them surveillance blockers.

If third-party JavaScript weren’t the norm, not only would it make the web more secure, it would make it way more performant. Read the chapter on third parties in this year’s newly-released Web Almanac. The figures are staggering.

93% of pages include at least one third-party resource, 76% of pages issue a request to an analytics domain, the median page requests content from at least 9 unique third-party domains that represent 35% of their total network activity, and the most active 10% of pages issue a whopping 175 third-party requests or more.

I don’t think all the web’s performance ills are due to third-party scripts; developers are doing a bang-up job of making their sites big and bloated with their own self-hosted frameworks and code. But as long as third-party JavaScript is allowed onto a site, there’s a limit to how much good developers can do to improve the performance of their sites.

I go to performance-related conferences and you know who I’ve never seen at those events? The people who write the JavaScript for third-party tracking scripts. Those developers are wielding an outsized influence on the health of the web.

I’m very happy to see the work being done by Mozilla and Apple to normalise the idea of rejecting third-party cookies. I’d love to see the rejection of third-party JavaScript normalised in the same way. I know that it would make my life as a developer harder. But that’s of lesser importance. It would be better for the web.

Chromium Blog: Moving towards a faster web

It’s nice to see that the Chrome browser will add interface enhancements to show whether you can expect a site to load fast or slowly.

Just a shame that the Google search team aren’t doing this kind of badging …unless you’ve given up on your website and decided to use Google AMP instead.

Maybe the Chrome team can figure out what the AMP team are doing to get such preferential treatment from the search team.

CSS for all

There have been some great new CSS properties and values shipping in Firefox recently.

Miriam Suzanne explains the difference between the newer revert value and the older inherit, initial and unset values in a video on the Mozilla Developer channel:

display: revert;

In another video, Jen describes some new properties for styling underlines (on links, for example):

text-decoration-thickness:  0.1em;
text-decoration-color: red;
text-underline-offset: 0.2em;
text-decoration-skip-ink: auto;

Great stuff!

As far as I can tell, all of these properties are available to you regardless of whether you are serving your website over HTTP or over HTTPS. That may seem like an odd observation to make, but I invite you to cast your mind back to January 2018. That’s when the Mozilla Security Blog posted about moving to secure contexts everywhere:

Effective immediately, all new features that are web-exposed are to be restricted to secure contexts. Web-exposed means that the feature is observable from a web page or server, whether through JavaScript, CSS, HTTP, media formats, etc. A feature can be anything from an extension of an existing IDL-defined object, a new CSS property, a new HTTP response header, to bigger features such as WebVR.

(emphasis mine)

Buzz Lightyear says to Woody: Secure contexts …secure contexts everywhere!

Despite that “effective immediately” clause, I haven’t observed any of the new CSS properties added in the past two years to be restricted to HTTPS. I’m glad about that. I wrote about this announcement at the time:

I am in total agreement that we should be encouraging everyone to switch to HTTPS. But requiring HTTPS in order to use CSS? The ends don’t justify the means.

If there were valid security reasons for making HTTPS a requirement, I would be all for enforcing this. But these are two totally separate areas. Enforcing HTTPS by withholding CSS support is no different to enforcing AMP by withholding search placement.

There’s no official word from the Mozilla Security Blog about any change to their two-year old “effective immediately” policy, and the original blog post hasn’t been updated. Maybe we can all just pretend it never happened.

Tuesday, November 5th, 2019

JavaScript isn’t always available and it’s not the user’s fault by Adam Silver

It’s not a matter of if your users don’t have JavaScript—it’s a matter of when and how often.

The answer to that is around 1% of the time.

If you had an application bug which occurred 1% of the time, you’d fix it. No team I’ve come across would put up with that level of reliability.

The same goes for JavaScript. It’s not about people who turn it off. It’s about the nature of the web itself.

Tuesday, October 29th, 2019

Periodic background sync

Yesterday I wrote about how much I’d like to see silent push for the web:

I’d really like silent push for the web—the ability to update a cache with fresh content as soon as it’s published; that would be nifty! At the same time, I understand the concerns. It feels more powerful than other permission-based APIs like notifications.

Today, John Holt Ripley responded on Twitter:

hi there, just read your blog post about Silent Push for acthe web, and wondering if Periodic Background Sync would cover a few of those use cases?

Periodic background sync looks very interesting indeed!

It’s not the same as silent push. As the name suggests, this is about your service worker waking up periodically and potentially fetching (and caching) fresh content from the network. So the service worker is polling rather than receiving a push. But I’ll take it! It’s definitely close enough for the kind of use-cases I’ve been thinking about.

Interestingly, periodic background sync also ties into the other part of what I was writing about: permissions. I mentioned that adding a site the home screen could be interpreted as a signal to potentially allow more permissions (or at least allow prompts for more permissions).

Well, Chromium has a document outlining metrics for attempting to gauge site engagement. There’s some good thinking in there.

Using the Platform | TimKadlec.com

Tim ponders the hard work that goes into adding standards to browsers, giving us a system with remarkable longevity.

So much care and planning has gone into creating the web platform, to ensure that even as new features are added, they’re added in a way that doesn’t break the web for anyone using an older device or browser. Can you say the same for any framework out there?

His parting advice is perfect:

Use the platform until you can’t, then augment what’s missing. And when you augment, do so with care because the responsibility of ensuring the security, accessibility, and performance that the platform tries to give you by default now falls entirely on you.

Monday, October 28th, 2019

Silent push for the web

After Indie Web Camp in Berlin last year, I wrote about Seb’s nifty demo of push without notifications:

While I’m very unwilling to grant permission to be interrupted by intrusive notifications, I’d be more than willing to grant permission to allow a website to silently cache timely content in the background. It would be a more calm technology.

Phil Nash left a comment on the Medium copy of my post explaining that Seb’s demo of using the Push API without showing a notification wouldn’t work for long:

The browsers allow a certain number of mistakes(?) before they start to show a generic notification to say that your site sent a push notification without showing a notification. I believe that after ~10 or so notifications, and that’s different between browsers, they run out of patience.

He also provided me with the name to describe what I’m after:

You’re looking for “silent push” as are many others.

Silent push is something that is possible in native apps. It isn’t (yet?) available on the web, presumably because of security concerns.

It’s an API that would ripe for abuse. I mean, just look at the mess we’ve made with APIs like notifications and geolocation. Sure, they require explicit user opt-in, but these opt-ins are seen so often that users are sick of seeing them. Silent push would be one more permission-based API to add to the stack of annoyances.

Still, I’d really like silent push for the web—the ability to update a cache with fresh content as soon as it’s published; that would be nifty! At the same time, I understand the concerns. It feels more powerful than other permission-based APIs like notifications.

Maybe there could be another layer of permissions. What if adding a site to your home screen was the first step? If a site is running on HTTPS, has a service worker, has a web app manifest, and has been added to the homescreen, maybe then and only then should it be allowed to prompt for permission to do silent push.

In other words, what if certain very powerful APIs were only available to progressive web apps that have successfully been added to the home screen?

Frankly, I’d be happy if the same permissions model applied to web notifications too, but I guess that ship has sailed.

Anyway, all this is pure conjecture on my part. As far as I know, silent push isn’t on the roadmap for any of the browser vendors right now. That’s fair enough. Although it does annoy me that native apps have this capability that web sites don’t.

It used to be that there was a long list of features that only native apps could do, but that list has grown shorter and shorter. The web’s hare is catching up to native’s tortoise.

Friday, October 25th, 2019

Latest Firefox Brings Privacy Protections Front and Center Letting You Track the Trackers - The Mozilla Blog

I really like this latest addition in Firefox to show how many tracking scripts are being blocked. I think it’s always good to make the invisible visible (one of the reasons why I like RequestMap so much).

Tuesday, October 22nd, 2019

203221 – Web Share API: should prefer URL to text when both available

That unusual behaviour I wrote about with the Web Share API in Safari on iOS is now officially a bug—thanks, Tess!

Friday, October 18th, 2019

Web talk

At the start of this month I was in Amsterdam for a series of back-to-back events: Indie Web Camp Amsterdam, View Source, and Fronteers. That last one was where Remy and I debuted talk we’d been working on.

The Fronteers folk have been quick off the mark so the video is already available. I’ve also published the text of the talk here:

How We Built The World Wide Web In Five Days

This was a fun talk to put together. The first challenge was figuring out the right format for a two-person talk. It quickly became clear that Remy’s focus would be on the events of the five days we spent at CERN, whereas my focus would be on the history of computing, hypertext, and networks leading up to the creation of the web.

Now, we could’ve just done everything chronologically, but that would mean I’d do the first half of the talk and Remy would do the second half. That didn’t appeal. And it sounded kind of boring. So then we come up with the idea of interweaving the two timelines.

That worked remarkably well. The talk starts with me describing the creation of CERN in the 1950s. Then Remy talks about the first day of the hack week. I then talk about events in the 1960s. Remy talks about the second day at CERN. This continues until we join up about half way through the talk: I’ve arrived at the moment that Tim Berners-Lee first published the proposal for the World Wide Web, and Remy has arrived at the point of having running code.

At this point, the presentation switches gears and turns into a demo. I do not have the fortitude to do a live demo, so this was all down to Remy. He did it flawlessly. I have so much respect for people brave enough to do live demos, and do them well.

But the talk doesn’t finish there. There’s a coda about our return to CERN a month after the initial hack week. This was an opportunity for both of us to close out the talk with our hopes and dreams for the World Wide Web.

I know I’m biased, but I thought the structure of the presentation worked really well: two interweaving timelines culminating in a demo and finishing with the big picture.

There was a forcing function on preparing this presentation: Remy was moving house, and I was already going to be away speaking at some other events. That limited the amount of time we could be in the same place to practice the talk. In the end, I think that might have helped us make the most of that time.

We were both feeling the pressure to tell this story well—it means so much to us. Personally, I found that presenting with Remy made me up my game. Like I said:

It’s been a real treat working with Remy on this. Don’t tell him I said this, but he’s kind of a web hero of mine, so this was a real honour and a privilege for me.

This talk could have easily turned into a boring slideshow of “what we did on our holidays”, but I think we managed to successfully avoid that trap. We’re both proud of this talk and we’d love to give it again some time. If you’d like it at your event, get in touch.

In the meantime, you can read the text, watch the video, or look at the slides (but the slides really don’t make much sense in isolation).