There are two wolves inside you…
My Builder side won’t let me just sit and think about unsolved problems, and my Thinker side is starving while I vibe-code. I am not sure if there will ever be a time again when both needs can be met at once.
- Install Stuff Indiscriminately From npm
- Pick a Framework Before You Know You Need One
- Always, Always Require a Compilation Step
I love the interactive illustrations in this article filled with type and architecture nerdery!
The joy came flooding back to me! It turns out browser APIs are really good now.
This is grim:
If you look at the data below on how popular websites today are actually transpiling and deploying their code to production, it turns out that most sites on the internet ship code that is transpiled to ES5, yet still doesn’t work in IE 11—meaning the transpiler and polyfill bloat is being downloaded by 100% of their users, but benefiting none of them.
I really, really like Paul’s idea of splitting up the indie web principles into one opinionated nerdy list of dev principles, and a separate shorter list of core principles for everyone:
- Own your identity An independent web presence starts with an online identity you own and control. The most reliable way to do this today is by having your own domain name.
- Own your content You should retain control of the things you make, and not be subject to third-parties preventing access to it, deleting it or disappearing entirely. The best way to do this is by publishing content on your own website.
- Have fun! When the web took off in the 90’s people began designing personal sites with garish backgrounds and animated GIFs. It may have been ugly but it was fun. Let’s keep the web weird and interesting.
Robin Sloan on The Culture:
The Culture is a utopia: a future you might actually want to live in. It offers a coherent political vision. This isn’t subtle or allegorical; on the page, citizens of the Culture very frequently articulate and defend their values. (Their enthusiasm for their own politics is considered annoying by most other civilizations.)
Coherent political vision doesn’t require a lot, just some sense of “this is what we ought to do”, yet it is absent from plenty of science fiction that dwells only in the realm of the cautionary tale.
I don’t have much patience left for that genre. I mean … we have been, at this point, amply cautioned.
Vision, on the other hand: I can’t get enough.
I didn’t want to play the game of striving to be seen.
I just wanted to be.
If you have a project that uses just plain HTML, CSS, and JavaScript, you can just open up the files and start working on them at any time. A project from 20 years ago will still work just fine, and can be easily modified.
Projects that use build tools? Well… to work with them, you need your build tools to actually build. And that’s not always guaranteed.
Also, it me:
One of my least favorite things as a developer is wanting to do a quick patch fix on an older project—I’m talking a simple one-line of CSS kind of fix—but first having to spend 30 minutes patching my build tools to get them running again.
I really enjoyed hanging out with Paul at Indie Web Camp in Nuremberg last weekend. And I like the iconography he’s proposing:
This design attempts to bring together a set of icons that share the concept of a node – a line and a point – and use this to add counters to each letter shape.
The best reason to write a library in plain JavaScript is that it lasts forever. This is arguably JavaScript’s single most underrated feature. While I’m sure there are some corner cases, JavaScript from 1999 that ran in Netscape Navigator will run unaltered, alongside modern code, in Google Chrome downloaded yesterday. That is true for very few programming environments.
And yet:
Of course, most people’s experience with JavaScript is that it ages like milk. Reopen a node repository after 3 months and you’ll find that your project is mired in a flurry of security warnings, backwards-incompatible library “upgrades,” and a frontend framework whose cultural peak was the exact moment you started the project and is now widely considered tech debt.
There is something divine about creating. From building software to writing a book to completing a self-portrait, every act of creation is a miniature Genesis.
Speaking of doing things the long hard stupid way:
If you want to leave a fingerprint of talent on the world that lasts, get your hands dirty and practice your skill, because work that is beautiful and timeless demands dedication.
Back in 2017 when I was in New York, I went on a self-guided infrastructure tour: 32 Avenue of the Americas, 60 Hudson Street, and the subject of this article, 33 Thomas Street. One of my pictures is used to illustrate its creepiness, both in real life and as an evil lair in fiction:
A windowless telecommunications hub, 33 Thomas Street in New York City embodies an architecture of surveillance and paranoia. That has made it an ideal set for conspiracy thrillers.
The pros and cons of dependencies in your toolchain.
For me, a complicated Javascript build system just doesn’t seem worth it for small 500-line projects – it means giving up being able to easily update the project in the future in exchange for some pretty marginal benefits.
This! Also, this:
I’m writing this because most of the writing I see about JS assumes that you’re using a build system, and it can be hard to navigate for folks like me who write very simple small Javascript projects that don’t require a build system.
A beautiful meditation on Christopher Alexander by Claire L. Evans.
My talk, Building, was about the metaphors we use to talk about the work we do on the web. So I’m interested in this analysis of the metaphors used to talk about markup:
- Data is documents, processing data is clerking
- Data is trees, processing data is forestry
- Data is buildings, processing data is construction
- Data is a place, processing data is a journey
- Data is a fluid, processing data is plumbing
- Data is a textile, processing data is weaving
- Data is music, processing data is performing
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).
A cautionary tale on why you should keep your dependencies to a minimum and simplify your build process (if you even need one):
If it’s not link rot that gets you then it’s this heat death of the universe problem with entropy setting in slowly over time. And the only way to really defend against it is to build things progressively, to make sure that you’re not tied to one dependency or another. That complex build process? That’s a dependency. Your third party link to some third party font service that depends on their servers running forever? Another dependency.
Now you can play a demo of Townscaper right in your browser.
There goes your productivity.