This is useful if you’re making the switch to HTTPS: choose your web server software and version to generate a configuration file.
Remember when I mentioned that you can get free certificates from Amazon now? Well, Oliver has written an in-depth step-by-step description of how he got his static site all set up with HTTPS.
More of this please! Share your experiences with moving to TLS—the more, the better.
If you’re hosting with Amazon, you now get HTTPS for free.
How the Web Works: A Primer for Newcomers to Web Development (or anyone, really) by Preethi Kasireddy
This is a great reminder of the fundamental nuts’n’bolts of the internet and the World Wide Web: clients, servers, URLs, DNS, HTTP, TCP/IP, packet switching, and all the other building blocks we sometimes take for granted.
This is part one of a four-part series:
- A Primer for Newcomers to Web Development (or anyone, really)
- Client-Server Model & the Structure of a Web Application
- HTTP & REST
- Stay tuned…
A hands-on look at building a progressive web app with Service Workers, manifest files, HTTPS, and all that good stuff. This is nice and balanced, extolling the virtues but also warning about the potential difficulties in implementing this stuff.
One nitpick though: there’s talk of graceful degradation, and while I get that that’s the outcome, I think it’s better to think in terms of progressive enhancement, which is the approach.
Written in 2001, this history of the web takes in CERN, hypertext, the ARPANET, SGML, and lots more.
Tim outlines the process for getting up and running with HTTPS using Let’s Encrypt. Looks like it’s pretty straightforward, which is very, very good news.
I’m using the Salter Cane site as a test ground for this. I was able to get everything installed fairly easily. The tricky thing will be having some kind of renewal reminder—the certificates expire after three months.
Still, all the signs are good that HTTPS is about to get a lot less painful.
A fascinating ten-year old essay looking at the early days of the web and how it conquered FTP and Gopher.
And though glitz, politics, hard work, and competitors’ mistakes all played a role in the success of the web, there are also aspects of the architecture that ensured the web would catch on. I think the web won because of the URI.
URIs are everywhere, and what’s vaguely funny now is the idea that they’re something special. But they’re very special: URI management is the fundamental consideration behind the design of web sites, web applications, and web services. Tim Berners-Lee originally intended URIs to be invisible, but they’re too useful for that.
Bruce gives a great run-down of what’s involved in creating one of those new-fangled progressive apps that everyone at Google and Opera (and soon, Mozilla) are talking about: a secure connection, a service worker, and a manifest file.
Crucially, in browsers that don’t support it, you have a normal website. It’s perfect progressive enhancement.
Funnily enough, this here website—adactio.com—is technically a progressive app now.
At their simplest, Progressive Web Apps are application-like things hosted on your web server. If you’re as old as me, you might call them “web sites”
The title is hyperbolic, and while I certainly think that the criticisms of HTTP here are justified, I don’t think it will be swept aside by IPFS—I imagine more of a peaceful coexistence. Still, there’s some really good thinking in here and this is well worth paying attention to.
Aaron collects some recent examples that demonstrate
- why we should use HTTPS and
- why we should use progressive enhancement.
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.