Saturday, October 11th, 2014

When Jeremy met Jason

I first met Jason at South By Southwest 2011, having admired his work from afar. Here’s a picture of me and Jason.

When I was giving a talk on digital preservation at Beyond Tellerrand in 2013 referencing Jason’s work, I used that picture.

Then Jason gave a talk at a conference where he referenced me referencing him. Here’s a picture of Jason presenting a picture of me presenting a picture of me and Jason.

At this year’s Decentralize Camp, I spoke about digital preservation again. Here’s a picture of me presenting a picture of Jason presenting a picture of me presenting a picture of me and Jason.

Then Jason gave another talk. Here’s a picture of Jason presenting a picture of me presenting a picture of Jason presenting a picture of me presenting a picture of me and Jason.

I referenced that when I spoke in Riga a few months back. Here’s a picture of me presenting a picture of Jason presenting a picture of me presenting a picture of Jason presenting a picture of me presenting a picture of me and Jason.

Finally, Jason gave a barnstorming talk at the final Brooklyn Beta yesterday. As we were both in the same room at the same time, Jason took the opportunity to draw a line under this back-and-forth with his final volley. Here’s a picture of me and Jason in front of a picture of me presenting a picture of Jason presenting a picture of me presenting a picture of Jason presenting a picture of me presenting a picture of me and Jason.

Presentation Inception.

Thursday, October 2nd, 2014

Polyfills and products

I was chatting about polyfills recently with Bruce and Remy—who coined the term:

A polyfill, or polyfiller, is a piece of code (or plugin) that provides the technology that you, the developer, expect the browser to provide natively. Flattening the API landscape if you will.

I mentioned that I think that one of the earliest examples of what we would today call a polyfill was the IE7 script by Dean Edwards.

Dean wrote this (amazing) piece of JavaScript back when Internet Explorer 6 was king of the hill and Microsoft had stopped development of their browser entirely. It was a pretty shitty time in browserland back then. While other browsers were steaming ahead with browser support, Dean’s script pulled IE6 up by its bootstraps and made it understand CSS2.1 features. Crucially, you didn’t have to write your CSS any differently for the IE7 script to work—the classic hallmark of a polyfill.

Scott has a great post over on the Filament Group blog asking To Picturefill, or not to Picturefill?. Therein, he raises the larger issue of when to use polyfills of any kind. After all, every polyfill you use is a little bit of a tax that the end user must pay with a download.

Polyfills typically come at a cost to users as well, since they require users to download and execute JavaScript in order to work. Sometimes, frequently even, that cost outweighs the benefits that the polyfill would bring. For that reason, the question of whether or not to use any polyfill should be taken seriously.

Scott takes a very thoughtful approach to using any polyfill, and I try to do the same. I feel that it’s important to have an exit strategy for every polyfill you decide to use. After all, the whole point of a polyfill is that it’s a stop-gap measure until a particular feature is more widely supported.

And that’s where I run into one of the issues of working at an agency. At Clearleft, our time working with a client usually lasts a few months. At the end of that time, we’ll have delivered whatever the client needs: sometimes that’s design work; sometimes its design and a front-end pattern library.

Every now and then we get to revisit a project—like with Code for America—but that’s the exception rather than the rule. We’ve had to get very, very good at handover precisely because we won’t be the ones maintaining the code that we deliver (though we always try to budget in time to revisit the developers who are working with the code to answer any questions they might have).

That makes it very tricky to include a polyfill in our deliverables. We’d need to figure out a way of also including a timeline for revisiting that polyfill and evaluating when it’s time to drop it. That’s not an impossible task, but it’s much, much easier if you’re a developer working on a product (as opposed to a developer working at an agency). If you’re going to be the same person working on the code in the future—as well as working on it right now—it gets a lot easier to plan for evaluating polyfill usage further down the line. Set a recurring item in your calendar and you should be all set.

It’s a similar situation with vendor prefixes. Vendor prefixes were never intended to be a long-lasting part of any style sheet. Like polyfills, they’re supposed to be used with an exit strategy in mind: when the time is right, remove the prefixed styles, leaving only the unprefixed standardised CSS. Again, that’s a lot easier to do if you’re working on a product and you know that you’ll be the one revisiting the CSS later on. That’s harder to do at an agency where you’re handing over CSS to someone else.

I’m quite reluctant to use any vendor prefixes at all—which is at should be; vendor prefixes should not be used lightly. Sometimes they’re unavoidable, but that shouldn’t stop us thinking about how to remove them at a later date.

I’m mostly just thinking out loud here. I guess my point is that certain front-end development techniques and technologies feel like they’re better suited to product work rather than agency work. Although I’m sure there are plenty of counter-examples out there too of tools that really fit the agency model and are less useful for working on the same product over a long period.

But even though the agency world and the product world are very different in lots of ways, both of them require us to think about the future. How will long will the code you’re writing today last? And do you have a plan for when it needs updating or replacing?

Thursday, September 25th, 2014

On tour

I’ve just returned from a little European tour of Germany, Italy, and Romania, together with Jessica.

More specifically, I was at Smashing Conference in Freiburg, From The Front in Bologna, and SmartWeb in Bucharest. They were all great events, and it was particularly nice to attend events that focussed on their local web community. Oh, and they were all single-track events, which I really appreciate.

Now my brain is full of all the varied things that all the excellent speakers covered. I’ll need some time to digest it all.

I wasn’t just at those events to soak up knowledge; I also gave a talk at From The Front and SmartWeb—banging on about progressive enhancement again. In both cases, I was able to do that first thing and then I could relax and enjoy the rest of the talks.

I didn’t speak at Smashing Conf. Well, I did speak, but I wasn’t speaking …I mean, I was speaking, but I wasn’t speaking …I didn’t give a talk, is what I’m trying to say here.

Instead, I was MCing (and I’ve just realised that “Master of Ceremonies” sounds like a badass job title, so excuse me for a moment while I go and update the Clearleft website again). It sounds like a cushy number but it was actually a fair bit of work.

I’ve never MC’d an event that wasn’t my own before. It wasn’t just a matter of introducing each speaker—there was also a little chat with each speaker after their talk, so I had to make sure I was paying close attention to each and every talk, thinking of potential questions and conversation points. After two days of that, I was a bit knackered. But it was good fun. And I had the pleasure of introducing Dave as the mystery speaker—and it really was a surprise for most people.

It’s always funny to return to Freiburg, the town that Jessica and I called home for about six years back in the nineties. The town where I first started dabbling in this whole “world wide web” thing.

It was also fitting that our Italian sojourn was to Bologna, the city that Jessica and I have visited on many occassions …well, we are both foodies, after all.

But neither of us had ever been to Bucharest, so it was an absolute pleasure to go somewhere new, meet new people, and of course, try new foods and wines.

I’m incredibly lucky that my job allows me to travel like this. I get to go to interesting locations and get paid to geek out about web stuff that I’d be spouting on about anyway. I hope I never come to take that for granted.

My next speaking gig is much closer to home; the Generate conference in London tomorrow. After that, it’s straight off to the States for Artifact in Providence.

I’m going to extend that trip so I can get to Science Hack Day in San Francisco before bouncing back to the east coast for the final Brooklyn Beta. I’m looking forward to all those events, but alas, Jessica won’t be coming with me on this trip, so my enjoyment will be bittersweet—I’ll be missing her the whole time.

Thank goodness for Facetime.

Saturday, September 13th, 2014

Other days, other voices

I think that Mandy’s talk at this year’s dConstruct might be one of the best talks I’ve ever heard at any conference ever. If you haven’t listened to it yet, you really should.

There are no videos from this year’s dConstruct—you kind of had to be there—but Mandy’s talk works astoundingly well as a purely audio experience. In fact, it’s remarkable how powerful many of this year’s talks are as audio pieces. From Warren’s thoughtful opening words to Cory’s fiery closing salvo, these are talks packed so full of ideas that revisiting them really pays off.

That holds true for previous years as well—James Burke’s talk from two years ago really is a must-listen—but there’s something about this year’s presentations that really comes through in the audio recordings.

Then again, I’m something of a sucker for the spoken word. There’s something about having to use the input from one sensory channel—my ears—to create moving images in my mind, that often results in a more powerful experience than audio and video together.

We often talk about the internet as a revolutionary new medium, and it is. But it is revolutionary in the way that it collapses geographic and temporal distance; we can have instant access to almost any information from almost anywhere in the world. That’s great, but it doesn’t introduce anything fundamentally new to our perception of the world. Instead, the internet accelerates what was already possible.

Even that acceleration is itself part of a longer technological evolution that began with the telegraph—something that Brian drove home in in his talk when he referred to Tom Standage’s excellent book, The Victorian Internet. It’s probably true to say that the telegraph was a more revolutionary technology than the internet.

To find the last technology that may have fundamentally altered how we perceive the world and our place in it, I propose the humble gramophone.

On the face of it, the ability to play back recorded audio doesn’t sound like a particularly startling or world-changing shift in perspective. But as Sarah pointed out in her talk at last year’s dConstruct, the gramophone allowed people to hear, for the first time, the voices of people who aren’t here …including the voices of the dead.

Today we listen to the voices of the dead all the time. We listen to songs being sung by singers long gone. But can you imagine what it must have been like the first time that human beings heard the voices of people who were no longer alive?

There’s something about the power of the human voice—divorced from the moving image—that still gets to me. It’s like slow glass for the soul.

In the final year of her life, Chloe started publishing audio versions of some of her blog posts. I find myself returning to them again and again. I can look at pictures of Chloe, I can re-read her writing, I can even watch video …but there’s something so powerful about just hearing her voice.

I miss her so much.

Friday, September 12th, 2014

Indie Web Camp UK 2014

Indie Web Camp UK took place here in Brighton right after this year’s dConstruct. I was organising dConstruct. I was also organising Indie Web Camp. This was a problem.

It was a problem because I’m no good at multi-tasking, and I focused all my energy on dConstruct (it more or less dominated my time for the past few months). That meant that something had to give and that something was the organising of Indie Web Camp.

The event itself went perfectly smoothly. All the basics were there: a great venue, a solid internet connection, and a plan of action. But because I was so focused on dConstruct, I didn’t put any time into trying to get the word out about Indie Web Camp. Worse, I didn’t put any time into making sure that a diverse range of people knew about the event.

So in the end, Indie Web Camp UK 2014 was quite a homogenous gathering. That’s a real shame, and it’s my fault. My excuse is that I was busy with all things dConstruct, but that’s just that; an excuse. On the plus side, the effort I put into making dConstruct a diverse event paid off, but I’ll know better in future than to try to organise two back-to-back events. I need to learn to delegate and ask for help.

But I don’t want to cast Indie Web Camp in a totally negative light (I just want to acknowledge how it could have been better). It was actually pretty great. As with previous events, it was remarkably productive. The format of one day of talks, followed by one day of hacking is spot on.

Indie Web Camp UK attendees

I hadn’t planned to originally, but I spent the second day getting adactio.com switched over to https. Just a couple of weeks ago I wrote:

I’m looking forward to switching my website over to https:// but I’m not going to do it until the potential pain level drops.

Well, I’m afraid that potential pain level has not dropped. In fact, I can confirm that get TLS working is massive pain in the behind. But on the first day of Indie Web Camp, Tim Retout led a session on security and offered up his expertise for day two. I took full advantage of his generous offer.

With Tim’s help, I was able to get adactio.com all set. If I hadn’t had his help, it probably would’ve taken me days …or I simply would’ve given up. I took plenty of notes so I could document the process. I’ll write it up soon, but alas, it will only be useful to people with the same kind of hosting set up as I have.

By the end of Indie Web Camp, thanks to Tim’s patient assistance, quite a few people has switched on TSL for their sites. The https page on the Indie Web Camp wiki is turning into quite a handy resource.

There was lots of progress in other areas too, particularly with webactions. Some of that progress relates to what I’ve been saying about Web Components. More on that later…

Throw in some Transmat action, location-based hacks, and communication tools; all-in-all a very productive weekend.

Thursday, September 11th, 2014

Web Components

The Extensible Web Summit is taking place in Berlin today because Web Components are that important. I wish I could be there, but I’ll make do with the live notes, the IRC channel, and the octothorpe tag.

I have conflicting feelings about Web Components. I am simultaneously very excited and very nervous. That’s probably a good sign.

Here’s what I wrote after the last TAG meetup in London:

This really is a radically new and different way of adding features to browsers. In theory, it shifts the balance of power much more to developers (who currently have to hack together everything using JavaScript). If it works, it will be A Good Thing and result in expanding HTML’s vocabulary with genuinely useful features. I fear there may be a rocky transition to this new way of thinking, and I worry about backwards compatibility, but I can’t help but admire the audacity of the plan.

And here’s what I wrote after the Edge conference:

If Web Components work out, and we get a kind emergent semantics of UI widgets, it’ll be a huge leap forward for the web. But if we end up with a Tower of Babel, things could get very messy indeed. We’ll probably get both at once.

To explain…

The exciting thing about Web Components is that they give developers as much power as browser makers.

The frightening thing about Web Components is that they give developers as much power as browser makers.

When browser makers—and other contributors to web standards—team up to hammer out new features in HTML, they have design principles to guide them …at least in theory. First and foremost—because this is the web, not some fly-by-night “platform”—is the issue of compatability:

Support existing content

Degrade gracefully

You can see those principles at work with newly-minted elements like canvas, audio, video where fallback content can be placed between the opening and closing tags so that older user agents aren’t left high and dry (which, in turn, encourages developers to start using these features long before they’re universally supported).

You can see those principles at work in the design of datalist.

You can see those principles at work in the design of new form features which make use of the fact that browsers treat unknown input types as type="text" (again, encouraging developers to start using the new input long before they’re supported in every browser).

When developers are creating new Web Components, they could apply that same amount of thought and care; Chris Scott has demonstrated just such a pattern. Switching to Web Components does not mean abandoning progressive enhancement. If anything they provide the opportunity to create whole new levels of experience.

Web developers could ensure that their Web Components degrade gracefully in older browsers that don’t support Web Components (and no, “just polyfill it” is not a sustainable solution) or, for that matter, situations where JavaScript—for whatever reason—is not available.

Web developers could ensure that their Web Components are accessible, using appropriate ARIA properties.

But I fear that Sturgeon’s Law is going to dominate Web Components. The comparison that’s often cited for Web Components is the creation of jQuery plug-ins. And let’s face it, 90% of jQuery plug-ins are crap.

This wouldn’t matter so much if developers were only shooting themselves in the foot, but because of the wonderful spirit of sharing on the web, we might well end up shooting others in the foot too:

  1. I make something (to solve a problem).
  2. I’m excited about it.
  3. I share it.
  4. Others copy and paste what I’ve made.

Most of the time, that’s absolutely fantastic. But if the copying and pasting happens without critical appraisal, a lot of questionable decisions can get propagated very quickly.

To give you an example…

When Apple introduced the iPhone, it provided a mechanism to specify that a web page shouldn’t be displayed in a zoomed-out view. That mechanism, which Apple pulled out of their ass without going through any kind of standardisation process, was to use the meta element with a name of “viewport”:

<meta name="viewport" value="...">

The value attribute of a meta element takes a comma-separated list of values (think of name="keywords": you provide a comma-separated list of keywords). But in an early tutorial about the viewport value, code was provided which showed values separated with semicolons (like CSS declarations). People copied and pasted that code (which actually did work in Mobile Safari) and so every browser must support that usage:

Many other mobile browsers now support this tag, although it is not part of any web standard. Apple’s documentation does a good job explaining how web developers can use this tag, but we had to do some detective work to figure out exactly how to implement it in Fennec. For example, Safari’s documentation says the content is a “comma-delimited list,” but existing browsers and web pages use any mix of commas, semicolons, and spaces as separators.

Anyway, that’s just one illustration of how code gets shared, copied and pasted. It’s especially crucial during the introduction of a new technology to try to make sure that the code getting passed around is of a high quality.

I feel kind of bad saying this because the introductory phase of any new technology should be a time to say “Hey, go crazy! Try stuff out! See what works and what doesn’t!” but because Web Components are so powerful I think that mindset could end up doing a lot of damage.

Web developers have been given powerful features in the past. Vendor prefixes in CSS were a powerful feature that allowed browsers to push the boundaries of CSS without creating a Tower of Babel of propietary properties. But because developers just copied and pasted code, browser makers are now having to support prefixes that were originally scoped to different rendering engines. That’s not the fault of the browser makers. That’s the fault of web developers.

With Web Components, we are being given a lot of rope. We can either hang ourselves with it, or we can make awesome …rope …structures …out of rope this analogy really isn’t working.

I’m not suggesting we have some kind of central authority that gets to sit in judgement on which Web Components pass muster (although Addy’s FIRST principles are a great starting point). Instead I think a web of trust will emerge.

If I see a Web Component published by somebody at Paciello Group, I can be pretty sure that it will be accessible. Likewise, if Christian publishes a Web Component, it’s a good bet that it will use progressive enhancement. And if any of the superhumans at Filament Group share a Web Component, it’s bound to be accessible, performant, and well thought-out.

Because—as is so often the case on the web—it’s not really about technologies at all. It’s about people.

And it’s precisely because it’s about people that I’m so excited about Web Components …and simultaneously so nervous about Web Components.

Monday, September 8th, 2014

dConstruct 2014

dConstruct is all done for another year. Every year I feel sort of dazed in the few days after the conference—I spend so much time and energy preparing for this event looming in my future, that it always feels surreal when it’s suddenly in the past.

But this year I feel particularly dazed. A little numb. Slightly shellshocked even.

This year’s dConstruct was …heavy. Sure, there were some laughs (belly laughs, even) but overall it was a more serious event than previous years. The word that I heard the most from people afterwards was “important”. It was an important event.

Here’s the thing: if I’m going to organise a conference in 2014 and give it the theme of “Living With The Network”, and then invite the most thoughtful, informed, eloquent speakers I can think of …well, I knew it wasn’t going to be rainbows and unicorns.

If you were there, you know what I mean. If you weren’t there, it probably sounds like it wasn’t much fun. To be honest, “fun” wasn’t the highest thing on the agenda this year. But that feels right. And even though it wasn’t a laugh-fest, it was immensely enjoyable …if, like me, you enjoy having your brain slapped around.

I’m going to need some time to process and unpack everything that was squeezed into the day. Fortunately—thanks to Drew’s typical Herculean efforts—I can do that by listening to the audio, which is already available!

Slap the RSS feed in your generic MP3 listening device of choice and soak up the tsunami of thoughts, ideas, and provocations that the speakers delivered.

Oh boy, did the speakers ever deliver!

Warren Ellis at dConstruct Georgina Voss at dConstruct Clare Reddington at dConstruct Aaron Straup Cope at dConstruct Brian Suda at dConstruct Mandy Brown at dConstruct Anab Jain at dConstruct Tom Scott at dConstruct Cory Doctorow at dConstruct

Listen, it’s very nice that people come along to dConstruct each year and settle into the Brighton Dome to listen to these talks, but the harsh truth is that I didn’t choose the speakers for anyone else but myself. I know that’s very selfish, but it’s true. By lucky coincidence, the speakers I want to see turn out to deliver the best damn talks on the planet.

That said, as impressed as I was by the speakers, I was equally impressed by the audience. They were not spoon-fed. They had to contribute their time, attention, and grey matter to “get” those talks. And they did. For that, I am immensely grateful. Thank you.

I’m not going to go through all the talks one by one. I couldn’t do them justice. What was wonderful was to see the emerging themes, ideas, and references that crossed over from speaker to speaker: thoughts on history, responsibility, power, control, and the future.

And yes, there was definitely a grim undercurrent to some of those ideas about the future. But there was also hope. More than one speaker pointed out that the future is ours to write. And the emphasis on history highlighted that our present moment in time—and our future trajectory—is all part of an ongoing amazing collective narrative.

But it’s precisely because the future is ours to write that this year’s dConstruct hammered home our collective responsibility. This year’s dConstruct was a grown-up, necessarily serious event that shined a light on our current point in history …and maybe, just maybe, provided some potential paths for the future.

Thursday, September 4th, 2014

This week in Brighton

This is my favourite week of the year. It’s the week when Brighton bursts into life as the its month-long Digital Festival kicks off.

Already this week, we’ve had the Dots conference and three days of Reasons To Be Creative, where designers and makers show their work. And this afternoon Lighthouse are running their annual Improving Reality event.

But the best is yet to come. Tomorrow’s the big day: dConstruct 2014. I’ve been preparing for this day for so long now, it’s going to be very weird when it’s over. I must remember to sit back, relax and enjoy the day. I remember how fast the day whizzed by last year. I suspect that tomorrow’s proceedings might display equal levels of time dilation—I’m excited to see every single talk.

Even when dConstruct is done, the Brighton festivities will continue. I’ll be at Indie Web Camp here at 68 Middle Street on Saturday on Sunday. Also on Saturday, there’s the brilliant Maker Faire, and when the sun goes down, Brighton will be treated to Seb’s latest project which features frickin’ lasers!

This is my favourite week of the year.

Friday, August 22nd, 2014

Georgina Voss at dConstruct

It’s exactly two weeks until dConstruct. I AM EXCITE!!!11ELEVEN!! If you’ve already got your ticket: excellent! If not, you can still get one. It’s not too late.

There is a change to the advertised line-up…

Alas, Jen can no longer make it to Brighton. Circumstances have conspired to make trans-atlantic travel an impossibility. It’s a real shame because I was really looking forward to her talk, but these things happen (and she’s gutted too: she was really looking forward to being in Brighton for this year’s dConstruct).

But never fear. We’ve swapped out one fantastic talk for another fantastic talk. Brighton’s own Georgina Voss has very kindly stepped into the breach. She’s going to knock your socks off with her talk, Tethering the Hovercraft:

A careen through grassroots innovation, speculative design, supply chains and sexual healthcare provision, lashing down over-caffeinated flailing into the grit of socio-technical systems.

Awwww yeah!

I had the chance to see Georgina speak a few months back at Lighthouse Arts and it was terrific. She is the perfect fit for this year’s dConstruct—she really is living with the network.

It’s a shame that Jen can’t join us for this year’s dConstruct but, my goodness, what a great day it’s going to be—now with added Vossomeness!

Wednesday, August 20th, 2014

Security for all

Throughout the Brighton Digital Festival, Lighthouse Arts will be exhibiting a project from Julian Oliver and Danja Vasiliev called Newstweek. If you’re in town for dConstruct—and you should be—you ought to stop by and check it out.

It’s a mischievous little hardware hack intended for use in places with public WiFi. If you’ve got a Newstweek device, you can alter the content of web pages like, say, BBC News. Cheeky!

There’s one catch though. Newstweek works on http:// domains, not https://. This is exactly the scenario that Jake has been talking about:

SSL is also useful to ensure the data you’re receiving hasn’t been tampered with. It’s not just for user->server stuff

eg, when you visit http://www.theguardian.com/uk , you don’t really know it hasn’t been modified to tell a different story

There’s another good reason for switching to TLS. It would make life harder for GCHQ and the NSA—not impossible, but harder. It’s not a panacea, but it would help make our collectively-held network more secure, as per RFC 7258 from the Internet Engineering Task Force:

Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.

I’m all for using https:// instead of http:// but there’s a problem. It’s bloody difficult!

If you’re a sysadmin type that lives in the command line, then it’s probably not difficult at all. But for the rest of us mere mortals who just want to publish something on the web, it’s intimidatingly daunting.

Tim Bray says:

It’ll cost you <$100/yr plus a half-hour of server reconfiguration. I don’t see any excuse not to.

…but then, he also thought that anyone who can’t make a syndication feed that’s well-formed XML is an incompetent fool (whereas I ended up creating an entire service to save people from having to make RSS feeds by hand).

Google are now making SSL a ranking factor in their search results, which is their prerogative. If it results in worse search results, other search engines are available. But I don’t think it will have significant impact. Jake again:

if two pages have equal ranking except one is served securely, which do you think should appear first in results?

Ashe Dryden disagrees:

Google will be promoting SSL sites above those without, effectively doing the exact same thing we’re upset about the lack of net neutrality.

I don’t think that’s quite fair: if Google were an ISP slowing down http:// requests, that would be extremely worrying, but tweaking its already-opaque search algorithm isn’t quite the same.

Mind you, I do like this suggestion:

I think if Google is going to penalize you for not having SSL they should become a CA and issue free certs.

I’m more concerned by the discussions at Chrome and Mozilla about flagging up http:// connections as unsafe. While the approach is technically correct, I fear it could have the opposite of its intended effect. With so many sites still served over http://, users would be bombarded with constant messages of unsafe connections. Before long they would develop security blindness in much the same way that we’ve all developed banner-ad blindness.

My main issue—apart from the fact that I personally don’t have the necessary smarts to enable TLS—is related to what Ashe is concerned about:

Businesses and individuals who both know about and can afford to have SSL in place will be ranked above those who don’t/can’t.

I strongly believe that anyone should be able to publish on the web. That’s one of the reasons why I don’t share my fellow developers’ zeal for moving everything to JavaScript; I want anybody—not just programmers—to be able to share what they know. Hence my preference for simpler declarative languages like HTML and CSS (and my belief that they should remain simple and learnable).

It’s already too damn complex to register a domain and host a website. Adding one more roadblock isn’t going to help that situation. Just ask Drew and Rachel what it’s like trying to just make sure that their customers have a version of PHP from this decade.

I want a secure web. I’d really like the web to be https:// only. But until we get there, I really don’t like the thought of the web being divided into the haves and have-nots.

Still…

There is an enormous opportunity here, as John pointed out on a recent episode of The Web Ahead. Getting TLS set up is a pain point for a lot of people, not just me. Where there’s pain, there’s an opportunity to provide a service that removes the pain. Services like Squarespace are already taking the pain out of setting up a website. I’d like to see somebody provide a TLS valet service.

(And before you rush to tell me about the super-easy SSL-setup tutorial you know about, please stop and think about whether it’s actually more like this.)

I’m looking forward to switching my website over to https:// but I’m not going to do it until the potential pain level drops.

For all of you budding entrepreneurs looking for the next big thing to “disrupt”, please consider making your money not from the gold rush itself, but from providing the shovels.