How to Make Websites That Will Require Lots of Your Time and Energy - Jim Nielsen’s Blog
- Install Stuff Indiscriminately From npm
- Pick a Framework Before You Know You Need One
- Always, Always Require a Compilation Step
This ties in nicely with the new talk I’m doing on evaluating technology. Zell proposes a five-step process:
- Figure out what [insert tool] does.
- Figure out what sucks right now
- Determine if it’s worth the investment
- Learn it (if it’s worth it)
- Differentiate opinions from facts
Most of the examples he gives are tools used before deployment—I have a feeling that different criteria should apply when weighing up technologies written directly in user-facing code (HTML, CSS, and JavaScript).
- Install Stuff Indiscriminately From npm
- Pick a Framework Before You Know You Need One
- Always, Always Require a Compilation Step
Want to use all those great features that have been in landing in browsers over the past year or two? View transitions! Scroll-driven animations! So much more!
Well, your coding co-pilot is not going to going to be of any help.
Large language models, especially those on the scale of many of the most accessible, popular hosted options, take humongous datasets and long periods to train. By the time everything has been scraped and a dataset has been built, the set is on some level already obsolete. Then, before a model can reach the hands of consumers, time must be taken to train and evaluate it, and then even more to finally deploy it.
Once it has finally released, it usually remains stagnant in terms of having its knowledge updated. This creates an AI knowledge gap. A period between the present and AI’s training cutoff. This gap creates a time between when a new technology emerges and when AI systems can effectively support user needs regarding its adoption, meaning that models will not be able to service users requesting assistance with new technologies, thus disincentivising their use.
So we get this instead:
I’ve anecdotally noticed that many AI tools have a ‘preference’ for React and Tailwind when asked to tackle a web-based task, or even to create any app involving an interface at all.
A good ol’ rant by Vasilis on our design tools for the web.
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.
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.
It’s almost as though humans prefer to use post-hoc justifications rather than being rational actors.
Try writing your HTML in HTML, your CSS in CSS, and your JavaScript in JavaScript.
The driven division.
Is your design system really a system …or is it more like a collection of components?
Worst buddy movie ever.