Chris makes the very good point that the J in JAMstack isn’t nearly as important as the static hosting part.
This is my maj.
Trust no one! Harry enumerates the reason why you should be self-hosting your assets (and busts some myths along the way).
There really is very little reason to leave your static assets on anyone else’s infrastructure. The perceived benefits are often a myth, and even if they weren’t, the trade-offs simply aren’t worth it. Loading assets from multiple origins is demonstrably slower.
Anchor seems to be going for the YouTube model. They want a huge number of people to use their platform. But the concentration of so much media in one place is one of the problems with today’s web. Massive social networks like Facebook, Instagram, and YouTube have too much power over writers, photographers, and video creators. We do not want that for podcasts.
Hadley points to the serious security concerns with AMP:
Fundamentally, we think that it’s crucial to the web ecosystem for you to understand where content comes from and for the browser to protect you from harm. We are seriously concerned about publication strategies that undermine them.
The anchor element is designed to allow one website to refer visitors to content on another website, whilst retaining all the features of the web platform. We encourage distribution platforms to use this mechanism where appropriate. We encourage the loading of pages from original source origins, rather than re-hosted, non-canonical locations.
That last sentence there? That’s what I’m talking about!
It’s all very admirable, but it also feels a little bit 927.
If you’re planning the move to TLS and your server is on Digital Ocean running Nginx, Graham’s here to run you through the (surprisingly simple) process.
Sorting out hosting is a big stumbling block for people who want to go down the Indie Web route. Frankly it’s much easier to just use a third-party silo like Facebook or Twitter. I’ve been saying for a while now that I’d really like to see “concierge” services for hosting—”here, you take care of all this hassle!”
Well, this initiative looks like exactly that.
Aaron raises a point that I’ve discussed before in regards to the indie web (and indeed, the web in general): we don’t buy domain names; we rent them.
It strikes me that all the good things about the web are decentralised (one-way linking, no central authority required to add a node), but all the sticking points are centralised: ICANN, DNS.
Aaron also points out that we are beholden to our hosting companies, although—having moved hosts a number of times myself—that’s an issue that DNS (and URLs in general) helps alleviate. And there’s now some interesting work going on in literally owning your own website: a web server in the home.
A rallying cry for the Indie Web.
Let’s build this.
Dan’s blog is rapidly turning into one of my favourite destinations on the web.
I hope he comes to an Indie Web Camp.
Honestly, if you value the content you create and put online, then you need to be in control of your own stuff.
A truly excellent article outlining the difference between share-cropping and self-hosting. It may seem that the convenience of using a third-party service outweighs the hassle of owning your own URLs but this puts everything into perspective.
This looks like it might be worth investigating as one potential solution to the sharecropping problem: code for decentralising your data; you allow apps to access your data but you get to decide where that data lives. Intriguing.
A comprehensive look at some of the problems with taking self-hosting to its logical conclusion: running your own web server.
Yet another reason to host your own content instead of sharecropping; danah boyd wakes up one morning to find her Tumblr account has been moved to a different URL.