I enjoyed reading this interview with Jim Nielsen, much as I enjoy reading Jim’s blog. He says:
The best part of blogging is what you discover and learn experientially along the way.
That chimes with what Matthias says in the first issue of his new newsletter:
On your personal site, getting it wrong is not a bug, it’s a feature. It’s a chance to start small, take first steps, learn, edit, and improve. It’s an invaluable opportunity to evolve and to grow.
Prompted by the rhetorical question at the end of my post Today, the distant future, Jim casts his gaze into a crystal ball. I like what he sees.
It’s possible the behemoth that is JavaScript in 2022 continues to metastasize as we move towards 2036, especially with technologies like WASM. I wouldn’t rule out the lordship of JavaScript as a possibility of the future.
However, I also think it’s possible—and dare I predict—to say we are peaking in our divergence and are now facing a convergence back towards building with the grain of the web and its native primitives.
Why do I say that? In our quest for progress, we explored so far beyond the standards-based platform that we came to appreciate the modesty of the approach “use the platform”.
He also makes one prediction that lies within his control:
This blog post will still be accessible via its originally published URL in 2036.
Jim mashes up Ilya Grigorik’s book High Performance Browser Networking with my talk on the layers of the web and Nassim Taleb’s idea of antifragility.
Well, this is just wonderful! Jim has written copious notes after listening to my favourite episode of season three of the Clearleft podcast, measuring design:
I’m going to have to try really, really hard to not just copy/paste the entire transcript of this podcast. It‘s that good. Don’t miss it.
Rather than thinking, “how do I combine a bunch of disparate content, templates, and tooling into a functioning website?”, you might think “how do I start at a functioning website with content and then use templates and build tooling to enhance it?”
I think Jim is onto something here. The more dependencies you have in your build process, the likelier it is that over time one of them will become a single point of failure. A progressive enhancement approach to build tools means you’d still be able to launch your site (even if it’s not in its ideal state).
I want to be able to view, edit, and if need be ship a website, even if the build process fails. In essence, if the build does fail I can still take all the source files, put them on a server, and the website remains functional (however crude).
This is really interesting. I hadn’t thought too much about the connection between design engineering and declarative design before now, but Jim’s post makes the overlap very clear indeed.
Jim shares his thoughts on my recent post about declarative design systems. He picks up on the way I described a declarative design systems as “a predefined set of boundary conditions that can be used to generate components”:
I like this definition of a design system: a set of boundaries. It’s about saying “don’t go there” rather than “you can only go here”. This embraces the idea of constraints as the mother of invention: it opens the door to creativity while keeping things bounded.
I really like this experiment that Jim is conducting on his own site. I might try to replicate it sometime!
Because I want my site to be progressively-enhanced (e.g. the core feature of the site — viewing icons — works without JS), I didn’t want a “shell” web component that’s merely an empty HTML tag in the initial HTML that later renders everything.
Jim seems bashful about calling what he’s built a true web component:
Maybe I shouldn’t be using the term “web component” for what I’ve done here. I’m not using shadow DOM. I’m not using the templates or slots. I’m really only using custom elements to attach functionality to a specific kind of component.
Au contraire! For me, this exemplifies the best mindset to have when wielding this technology.
Jim’s thoughts on HTML web components:
I like that term “HTML web component”. It stands in contrast to a “JavaScript web components” which would be an empty element whose functionality and contents rely exclusively on JavaScript.
Here’s an excellent case study of an HTML web component. Jim starts by showing how you’d create the component in React; then he shows how you’d do it as a JavaScript web component; finally he shows the way to do it as an HTML web component:
The point is we’re starting with a baseline, core experience that will provide basic functionality and content to a wide array of user agents before any JavaScript is required.
Once you’ve done everything you can in vanilla HTML to provide core elements of your baseline experience, you can begin enhancing the existing markup with additional functionality.
This is where HTML web components shine.
- Each voice is individual and matters
- Slow is ok
- Diversified and independent is good
- Not fitting a pattern is ok
- Not being easily commodified is ok
This is wonderful meditation on the history of older technologies that degrade in varied conditions versus newer formats that fall of a “digital cliff”, all tied in to working on the web.
When digital TV fails, it fails completely. Analog TV, to use parlance of the web, degrades gracefully. The web could be similar, if we choose to make it so. It could be “the analog” web in contrast to “the digital” platforms. Perhaps in our hurry to replicate and mirror native platforms, we’re forgetting the killer strength of the web: universal accessibility.
This is an excellent case study!
The technical details are there if you want them, but far more important is consideration that went into every interaction. Every technical decision has a well thought out justification.
Growing—that’s a word I want to employ when talking about my personal sites online. Like a garden, I’m constantly puttering around in them. Sometimes I plow and sow a whole new feature for a site. Sometimes I just pick weeds.
I like this analogy. It reminds me of the the cooking analogy that others have made.
Most of my favorite websites out there are grown—homegrown in fact. They are corners of the web where some unique human has been nurturing, curating, and growing stuff for years. Their blog posts, their links, their thoughts, their aesthetic, their markup, their style, everything about their site—and themselves—shows growth and evolution and change through the years. It’s a beautiful thing, a kind of artifact that could never be replicated or manufactured on a deadline.
This part of the web, this organic part, stands in start contrast to the industrial web where websites are made and resources extracted.
I click the link. The page loads fast. I navigate the surprisingly sparse yet clear form inputs. And complete the whole thing in less than thirty seconds.
Oh, how I wish this experience weren’t remarkable!
Simple forms with clear labels. Little to no branding being shoved down my throat. No array of colors, big logos, or overly-customized UI components.
It feels like the web we’re making now is a web designed for commercial interests.
If the web is “for everyone”, how and where are “everyone’s” interested being represented?
Browsers are not an enterprise of the people. We do not elect our browser representatives who decide what a browser is and is not.
…you would be forgiven if you saw an API where a feature went from green (supported) to red (unsupported) and you thought: is the browser being deprecated?
That’s the idea behind my new shiny domain: canistilluse.com. I made the site as satire after reading Jeremy Keith’s insightful piece where he notes:
the onus is not on web developers to keep track of older features in danger of being deprecated. That’s on the browser makers. I sincerely hope we’re not expected to consult a site called canistilluse.com.
It’s weirdly gratifying to see a hastily-written sarcastic quip tuned into something real.
Your attentive kindness doesn’t get picked up by any analytical tool I’ve got other than my heart and my memory—however short lived.
I like this advice: write for you, not for others. And if you can’t think of what to “write”, document something for yourself and call it writing.
If there’s one thing I’ve learned about the mystery of blogging, it’s that the stuff you think nobody will read ends up with way more reach than anything you write thinking it will be popular.
So write about what you want, not what you think others want, and the words will spill out.
I couldn’t agree more!
This is something I bump against over and over again: so-called evergreen browsers that can’t actually be updated because of operating system limits.
From what I could gather, the version of Chrome was tied to ChromeOS which couldn’t be updated because of the hardware. No new ChromeOS meant no new Chrome which meant stuck at version 76.
But what about the iPad? I discovered that my Mom’s iPad was a 1st generation iPad Air. Apple stopped supporting that device in iOS 12, which means it was stuck with whatever version of Safari last shipped with iOS 12.
So I had two older browsers that couldn’t be updated. It was device obsolescence because you couldn’t install the latest browser.
Websites stop working and the only solution is to buy a whole new device.
“Be linkable and accessible to any client” is a provocative test for whether something is “of the web”.
Some thoughts on CSS, media queries, and fluid type prompted by Utopia:
We say CSS is “declarative”, but the more and more I write breakpoints to accommodate all the different ways a design can change across the viewport spectrum, the more I feel like I’m writing imperative code. At what quantity does a set of declarative rules begin to look like imperative instructions?
In contrast, one of the principles of Utopia is to be declarative and “describe what is to be done rather than command how to do it”. This approach declares a set of rules such that you could pick any viewport width and, using a formula, derive what the type size and spacing would be at that size.
I love these notes on my recent talk!
The day we started to allow email clients to be full-blown web browsers (but without the protections of browsers) was the day we lost — time, security, privacy, and effectiveness. Now we spend all our time fighting with the materials of an email (i.e. color and layout) rather than refining its substance (i.e. story and language).
It sounds like Remix takes a sensible approach to progressive enhancement.
I can now have
adactio.comon speed dial for search — a valid use case indeed.
😊
Funnily enough, I tend to use tags more often than my own site search. I type adactio.com/tags/… followed by whatever I think past me would’ve used. So my browser’s address bar is kind of a sitesearch interface already.
This is a very handy tip if you’re adding view transitions to your website!
I realized why I hadn’t yet added any rules to my
robots.txt: I have zero faith in it.
I absolutely love the idea of actively preserving a low barrier to entry for future generations of people.
💯
Over time, the direction of web technology always trends towards complexity. Simplicity is achieved as a concerted, mindful fight against this.
My secret is safe.
Subvert the status quo. Own a website. Make and share links.
The bar to overriding browser defaults should be way higher than it is.
Amen!
We’re all tired of: write some code, come back to it in six months, try to make it do more, and find the whole project is broken until you upgrade everything.
Progressive enhancement allows you to do the opposite: write some code, come back to it in six months, and it’s doing more than the day you wrote it!
There’s a big difference between the interface to a thing being one line of code, and the cost of a thing being one line of code.
A more acute rendering of this sales pitch is probaly: “It’s just one line of code to add many more lines of code.”
And as Chris puts it:
Every dependency is a potential vulnerability
Lessons for web development from a home renovation project:
- Greenfield Projects Are Everyone’s Favorite
- The Last Person’s Work Is Always Bewildering
- It’s All About the Trade-Offs
- It ALWAYS Takes Longer Than You Think
- Communication, Communication, Communication!
And there’s this:
You know those old homes people love because they’re unique, have lasted for decades, and have all that character? In contrast, you have these modern subdivision homes that, while shiny and new, are often bland and identical (and sometimes shoddily built).
node_modulesis like the suburbia/subdivision of modern web development: it seems nice and fancy today, and most everyone is doing it, but in 30 years everyone will hate the idea. They’ll all need to be renovated or torn down. Meanwhile, the classical stuff that’s still standing from 100 years ago lives on but nobody seems to be building houses that way anymore for some reason. Similarly, the first website ever is still viewable in all modern web browsers. But many websites built last year on last year’s bleeding edge tech already won’t work in a browser.
Tyring to do make screenshots of agency websites is tricky if the website is empty HTML with everything injected via JavaScript.
Granted, agencies are usually the ones pushing the boundaries. “Pop” and “pizazz” are what sell for many of them (i.e. “look what we can do!”) Many of these sites pushed the boundaries of what you can do in the browser, and that’s cool. I like seeing that kind of stuff.
But if you asked me what agency websites inspired both parts me, I’d point to something like Clearleft or Paravel. To me, they strike a great balance of visual design with the craft of building for an accessible, universal web.
I’m not the only one swapping out Sass with CSS for colour functions:
Because of the declarative nature of CSS, you’re never going to get something as terse as what you could get in Sass. So sure, you’re typing more characters. But you know what you’re not doing? Wrangling build plugins and updating dependencies to get Sass to build. What you write gets shipped directly to the browser and works as-is, now and for eternity. It’s hard to say that about your Sass code.
An ode to the network architecture of the internet:
I believe the DNA of resiliency built into the network manifests itself in the building blocks of what’s transmitted over the network. The next time somebody calls HTML or CSS dumb, think about that line again:
That simplicity, almost an intentional brainlessness…is a key to its adaptability.
It’s not a bug. It’s a feature.
Yes! I wish more web developers would take cues from the very medium they’re building atop of.
Syntactic sugar can’t help you if you don’t understand how things work under the hood. Optional chaining in JavaScript and !important in CSS are ways of solving your immediate problem …but unless you know what you’re doing, they’re probably going to create new problems.
The removal of all friction should’t be a goal. Making things easy and making things hard should be a design tool, employed to aid the end user towards their loftiest goals.
I do think large tech companies employ JavaScript frameworks because, amongst other things, it saves them money at their scale. And what Big Tech does trickles down in the form of default choices for many others (“they’re doing it and are insanely successful, so mimicking them can’t be a bad idea”). However, the scale at which smaller projects operate doesn’t necessarily translate to the same kind of cost savings.
You might not think this is a big deal, and maybe it’s not, but I love the idea behind the indie web: a people-focused alternative to the corporate web. Seeing everything you’ve ever linked to in one place really drives home how much of the web’s content, made by individuals, is under corporate control and identity.
This post really highlights one of the biggest issues with the convoluted build tools used for “modern” web development. If you return to a project after any length of time, this is what awaits:
I find entropy staring me back in the face: library updates, breaking API changes, refactored mental models, and possible downright obsolescence. An incredible amount of effort will be required to make a simple change, test it, and get it live.
Take a moment and think about this super power: if you write vanilla HTML, CSS, and JS, all you have to do is put that code in a web browser and it runs. Edit a file, refresh the page, you’ve got a feedback cycle. As soon as you introduce tooling, as soon as you introduce an abstraction not native to the browser, you may have to invent the universe for a feedback cycle.
Maintainability matters—if not for you, then for future you.
The more I author code as it will be run by the browser the easier it will be to maintain that code over time, despite its perceived inferior developer ergonomics (remember, developer experience encompasses both the present and the future, i.e. “how simple are the ergonomics to build this now and maintain it into the future?) I don’t mind typing some extra characters now if it means I don’t have to learn/relearn, setup, configure, integrate, update, maintain, and inevitably troubleshoot a build tool or framework later.
Per Axbom quite rightly tears Jakob Nielsen a new one.
I particularly like his suggestion that you re-read Nielsen’s argument but replace the word “accessibility” with “usability”:
Assessed this way, the
accessibilitymovement has been a miserable failure.
Accessibilityis too expensive for most companies to be able to afford everything that’s needed with the current, clumsy implementation.
The case may be a little overstated, but I agree with the sentiment of this. The web is always playing catch-up to something. For a while, it was Flash; now it’s native.
Flash was a great stopgap measure. But it outlived its usefulness and has been reduced to niche status.
Today, we’re seeing the nearly exact same scenario with native apps on mobile devices.
Native mobile apps are a temporary solution. We’re just over 4 years into the Appstore era and this has already become apparent. Open web technologies are catching up to the point that the vast majority of web apps no longer need a native counterpart.
The circlemakers work with vegetation. Andy Goldsworthy works with the landscape. Jim Denevan works with sand.
This post absolutely nails what’s special about CSS …and why supersmart programmers might have trouble wrapping their head around it:
Other programming languages often work in controlled environments, like servers. They expect certain conditions to be true at all times, and can therefore be understood as concrete instructions as to how a program should execute.
CSS on the other hand works in a place that can never be fully controlled, so it has to be flexible by default.
Max goes on to encapsulate years of valuable CSS learnings into some short and snappy pieces of advices:
No matter what your level of CSS knowledge, this post has something for you—highly recommended!
Owning your own piece of the Internet (to borrow a recent phrase from Anil Dash) is itself a radical act. Linking to others at will is subversive all on its own. Or as Jeremy Keith once put it, “it sounds positively disruptive to even suggest that you should have your own website.” The web still exists for everyone. And beneath this increasingly desiccated surface, there is plenty of creators still simply creating.
People create these sites simply so that they exist. They are not fed to an algorithm, or informed by any trends. It is quieter and slower, meant to tether us to a more mechanical framework of the web.
This is the analog web.
Jim experiments with canvas and audio.
Jim premiered this film at An Event Apart in Chicago. The whole room was in stitches.
A satirical parody of post-singularity existence by Tom Scott inspired by Jim Munroe’s Everyone in Silico and Rudy Rucker’s Postsingular.
See that helmet? That’s my helmet. Jim borrowed it for this video.
And now I think that the Future Friendly posse has a theme song.
I was going to say that this is a really lovely post from Jim about Second Life, but it’s no actually about Second Life at all: it’s about a person.
I listen to a lot of podcast episodes. The latest episode of the User Defenders podcast (which is very different from the usual fare) is one of my favourites—the life and times of a NASA engineer working on everything from Apollo to the space shuttle.
You know how they say it doesn’t take a rocket scientist? Well, my Dad is one. On a recent vacation to Florida to celebrate his 80th birthday, he spent nearly three hours telling me his compelling story.
Jim Lovell, Frank Borman, and Bill Anders describe the overview effect they experienced on the Apollo 8 mission …and that photo.
Number one:
Do things in the most straightforward way possible. It’s easy to fall into the trap of clever solutions, or clever applications of technology, or overbuilding something because you’re anticipating the future. Don’t do it. You will hate yourself for it later when you have to maintain it.
A fascinating four-part series by Lisa Charlotte Muth on colour in data visualisations:
Blog!
Blog your heart! Blog about something you’ve learned, blog about something you’re interested in.
Excellent advice from Robin:
There are no rules to blogging except this one: always self-host your website because your URL, your own private domain, is the most valuable thing you can own. Your career will thank you for it later and no-one can take it away.
When I write a blog post, I want it to live on my blog, rather than a platform. I can thus invest my time thinking about how to make my blog better and backing it up, rather than having to worry about where my writing is, finding ways to export data from a platform, setting up persistent backups, etc.
The working example from Richard's chapter in Blog Design Solutions. It's a home-rolled PHP/MySQL blog for Samuel Pepys featuring beautiful typography... natch.
This blog by the visual effects supervisor on Moon is packed full of wonderfully geeky sci-fi movie stories.
It’s a bit finger-pointy but this blog should be useful for anyone working on internationalisation.
This blog has two general aims: to show the fundamental flaws in using flags to represent languages and how to create good experiences when dealing with multilingual and multi-regional content.
Following on from Stackbit’s tool, here’s another (more code-heavy) way of migrating from Ev’s blog to your own site.
Just look at these fantastic pictures that Trys took (very unobstrusively) at Patterns Day—so rock’n’roll!
James is featuring a different blog every day of Christmas and he chose mine for day three. What a lovely project!
I love writing this series. For the last three days, one of the first things on my mind after waking up is “what blog am I going to feature today?” I have seen so many interesting websites in the last few years. If you ever feel like the web is all the same, I’d recommend checking out the IndieWeb or clicking through the websites I feature in this series. You’ll realise there is still a great deal of creative content on the web written by independent bloggers: you just have to know where to start looking.
This is a pithy one-sentence description of a blog post, praising the author's insight.
Hixie has been making changes to microdata in HTML5 based, not on opinion or theory, but on the results of user testing.
The official word on that darned space.
Trammell outlines the thoughtful, research-based approach that Digg will be taking in phasing out IE6 support.
I can't wait to get my personal annual report from Dopplr! In the meantime, I'll content myself with the very pretty example of Barack Obama's annual report.
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).
I’ve got a lot of photos on Flickr (even though I don’t use it directly much these days) and I’ve paid up for a pro account to protect those photos, but I’m very worried about this:
Beginning January 8, 2019, Free accounts will be limited to 1,000 photos and videos.
That in itself is fine, but any existing non-pro accounts with more than 1000 photos will have older photos deleted until the total comes down to 1000. This means that anyone linking to those photos (or embedding them in blog posts or articles) will have broken links and images.
Tears in the rain.
In a similar treatment to the Pepys blog, the diary of George Orwell is being republished as a blog offset by 70 years.
Delicious has finally launched its redesign. It feels weird linking to it from Magnolia.
Here are the fruits of the latest code push at Pownce: the ability to share files with the public and a tenfold increase in the file size limit.
Weighing up the pros and cons of allowing comments on blog posts.
A match made in heaven: update your Fire Eagle location from Plazes.
If you haven’t done so already, you should really switch to Firefox.
Then encourage your friends and family to switch to Firefox too.
On moving from silos to your own website:
Over the last year, especially, it has seemed much more like “blog to write, tweet to fight.” Moreover, the way that our writing and personal data has been used by social media companies has become more obviously problematic—not that it wasn’t problematic to begin with.
Which is why it’s once again a good time to blog, especially on one’s own domain.
But on the other hand…
It is psychological gravity, not technical inertia, however, that is the greater force against the open web. Human beings are social animals and centralized social media like Twitter and Facebook provide a powerful sense of ambient humanity—the feeling that “others are here”—that is often missing when one writes on one’s own site.
That’s true …which is why brid.gy is such an incredibly powerful service for, well, bridging the gap between your own personal site and the silos, allowing for that feeling of ambient humanity.
Sir Tim Berners-Lee has a blog.
Matt is, as usual, eloquent and inspiring.
A thoughtful piece on how Twitter can complement blogging, but is far too often used as an impermanent substitute.
…if you didn’t blog it, it didn’t happen. In fact, I first wrote about this idea a bit on Twitter a few years ago. See if you can find it.
Ariel pens a guest post for Scientific American all about Science Hack Day.
Andy responds to Joe Hewitt’s recent despondent posts about the web. I tend to agree with Andy: I think comparing the web to other “platforms” is missing the point of what the web is.
See also: http://benward.me/blog/understand-the-web
A blog post can be a plain text document uploaded to a server. It can be an image hosted on a social network. It can be a voice note shared with your friends.
Title, dates, comments, links, and text are all optional.
No one is policing this.
It’s hard to overstate how important my blog has been, but if I were to try to distill it down into one word, it would be: “amplifier.”
Khoi talks about writing on his own website.
I personally can’t imagine handing over all of my labor to a centralized platform where it’s chopped up and shuffled together with content from countless other sources, only to be exploited at the current whims of the platform owners’ volatile business models.
I’m syndicating my notes to micro.blog now.
Ostensibly about gaming (and written by Matt Colville who works in the games industry), this blog actually has a lot of interesting observations on sci-fi cinema. I like it.
Shutterstock are running a series on their blog called “The Best Thing I Ever Created” and they asked me for a contribution. So I wrote about The Session.
There is something about the personal blog, yourname.com, where you control everything and get to do whatever the hell pleases you. There is something about linking to one of those blogs and then saying something. It’s like having a conversation in public with each other. This is how blogging was in the early days. And this is how blogging is today, if you want it to be.
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.
Bravo!
In the web developer community’s collective drive to be more App Like and compete with native apps we may lose or weaken some of the web’s strongest features and we need to consider carefully before we throw away urls or the entire browser chrome in an effort to look like and behave like the cool kids of native.
You can hear more of Ada’s thoughts on progressive web apps on a recent episode of JavaScript Air.
Having your independent blog is an excellent way to share what you think in a decentralized way, independent of any major company that may add a paywall to it (Medium, I am looking at you).
This looks like a nice way to get a blog up and running:
Blot turns a folder into a blog. Drag-and-drop files inside to publish. Images, text files, Word Documents, Markdown and more become blog posts automatically.
Simon has revived his blog …and he’s importing his writings from not-his-blog too.
The Long Now Foundation has been posting some great stuff on their blog lately. The latest is a look at orreries, clocks, and computers throughout history …and into the future.