François is here at Indie Web Camp Germany helping out anyone who wants to get their site running on https. He wrote this great post to get people started.
Did you know Google runs a free an open image resizing service?
I did not! This could be quite useful. Seeing as it’s an https endpoint, it could be especially useful on https sites that pull images from http domains (and avoid those mixed-content warnings).
This is a really good point from Tim Berners-Lee: there’s no good reason why switching to TLS should require a change of URLs from http:// to https://
There are some good points here comparing HTTP2 and SPDY, but I’m mostly linking to this because of the three wonderful opening paragraphs:
A very long time ago —in 1989 —Ronald Reagan was president, albeit only for the final 19½ days of his term. And before 1989 was over Taylor Swift had been born, and Andrei Sakharov and Samuel Beckett had died.
In the long run, the most memorable event of 1989 will probably be that Tim Berners-Lee hacked up the HTTP protocol and named the result the “World Wide Web.” (One remarkable property of this name is that the abbreviation “WWW” has twice as many syllables and takes longer to pronounce.)
Tim’s HTTP protocol ran on 10Mbit/s, Ethernet, and coax cables, and his computer was a NeXT Cube with a 25-MHz clock frequency. Twenty-six years later, my laptop CPU is a hundred times faster and has a thousand times as much RAM as Tim’s machine had, but the HTTP protocol is still the same.
I’m always surprised to find that working web developers often don’t know (or care) about basic protocol-level stuff like when to use GET and when to use POST.
My point is that a lot of web developers today are completely ignorant of the protocol that is the basis for their job. A core understanding of HTTP should be a base requirement for working in this business.
A really handy command-line tool that scans your site for mixed content — very useful if you’re making the switch from http to https.
This is a great development! The EFF are working on a creating a new certificate authority that will issue certs for free.
I am so happy that the certificate authority racket is getting this shake-up.
A friendly challenge from The Grey Lady for news sites to enable TLS.
Make a commitment to have your site fully on HTTPS by the end of 2015 and pledge your support with the hashtag #https2015.
Great news from Cloudflare—https endpoints by default!
This means that if you’re planning on switching on TLS for your site, but you’re using Cloudflare as a CDN, you’ve got one less thing to change (and goodness knows you’re going to have enough to do already).
I really like their reasoning for doing this, despite the fact that it might mean that they take a financial hit:
Having cutting-edge encryption may not seem important to a small blog, but it is critical to advancing the encrypted-by-default future of the Internet. Every byte, however seemingly mundane, that flows encrypted across the Internet makes it more difficult for those who wish to intercept, throttle, or censor the web. In other words, ensuring your personal blog is available over HTTPS makes it more likely that a human rights organization or social media service or independent journalist will be accessible around the world. Together we can do great things.
It’s very early days for ServiceWorker, but Jake is on hand with documentation and instructions on its use. To be honest, most of this is over my head and I suspect it won’t really “click” until I try using it for myself.
Where it gets really interesting is in the comments. Stuart asks “What about progressive enhancement?” And Jake points out that because a ServiceWorker won’t be installed on a first visit, you pretty much have to treat it as an enhancement. In fact, you’d have to go out of your way to make it a requirement:
You could, of course, throw up a splash screen and wait for the ServiceWorker to install, creating a ServiceWorker-dependant experience. I will hunt those people down.
Josh walks through the process he took to enabling SSL on his site (with particular attention to securing assets on CloudFront).
John echoes some of my recent thinking about what qualifies as a web browser and, by extension, what qualifies as the web:
We shouldn’t think of “the web” as only what renders in web browsers. We should think of the web as anything transmitted using HTTP and HTTPS. Apps and websites are peers, not competitors. They’re all just clients to the same services.
That said, I think he is perhaps underestimating the power of URLs. Addressability—particularly over an extended time period—remains the powerful feature of the web.
This is a great explanatory piece from James Bridle in conjunction with Mozilla’s Webmaker. It’s intended for a younger audience, but its clear description of how web requests are resolved is pitch-perfect primer for anyone.
The web isn’t magic. It’s not some faraway place we just ‘connect’ to, but a vast and complex system of computers, connected by actual wires under the ground and the oceans. Every time you open a website, you’re visiting a place where that data is stored.
My presentation from the Industry conference in Newcastle a little while back, when I stepped in for John Allsopp to deliver the closing talk.
Design principles for APIs.
An API is a user interface for developers. Put the effort in to ensure it’s not just functional but pleasant to use.
A lovely description by Paul Ford of the Hypertext Transfer Protocol.
That simple handshake is the firmament upon which we have built trillion-dollar cathedrals and bazaars, the base upon which we construct other protocols and networks.
I like these design principles for server-side and client-side frameworks. I would say that they’re common sense but looking at many popular frameworks, this sense isn’t as common as it should be.
A really good introduction to front-end performance techniques. Most of this was already on my radar, but I still picked up a handy tip or two (particularly about DNS prefetching).
At this stage it should go without saying that you should be keeping up with this kind of thing: performance is really, really, really important.
A well-reasoned argument for tackling image optimisation on the server, using content-type negotiation.
Luke’s notes from my talk at An Event Apart in Chicago.
An in-depth analysis (graphs! data!) of how popular sites are using—or not using—compression.
Oh, this is very handy indeed: a quick lint tool for HTTP so you can see what kind of headers are being sent. There’s a bookmarklet in the footer too.
This is wonderful. A web server powered by people. Change the URL and a person will manually fetch the corresponding resource.
You can be part of the server team too.
A handy tool for checking page load times.
James follows up on his previous excellent post on hashbangs by diving into the situations where client-side routing is desirable. Watch this space for a follow-up post on performance.
This is wonderful stuff: a long-term project to track the performance of high-traffic sites over time: oodles of lovely data and some quite shocking stats.
Anil Dash writes about the realtime web, calling it Pushbutton.
A classic essay from Clay Shirky on the dumb nature of the web.
Eleven years old and more relevant than ever.
Friendlier HTTP errors.
Easy as Pie Ajax Requests - Create compelling ajax in minutes with simple examples. | Notes from Phazm
This is a good straightforward hands-on explanation of Ajax: succinct and clear.
Want to indicate that something is happening on a web page, like... oh, I don't know... an Ajax request or something? Here's a cornucopia of animated progress indicators.
My fellow Brightonian geek, Dom, has written an article about using Perl and Ajax.
"...it must degrade well. It must still be accessible. It must be usable. If not, it is a cool useless piece of rubbish for some or many people."
Who knew? The way I do my Ajax is a microformat. AHAH: Asynchronous HTML and HTTP.
Ajax in The Guardian.
A nice introduction the XMLHttpRequest object by Cameron Adams.