Should you learn [insert shiny new tool]? | Zell Liew

This ties in nicely with the new talk I’m doing on evaluating technology. Zell proposes a five-step process:

  1. Figure out what [insert tool] does.
  2. Figure out what sucks right now
  3. Determine if it’s worth the investment
  4. Learn it (if it’s worth it)
  5. 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).

Tagged with

Related links

How to Make Websites That Will Require Lots of Your Time and Energy - Jim Nielsen’s Blog

  1. Install Stuff Indiscriminately From npm
  2. Pick a Framework Before You Know You Need One
  3. Always, Always Require a Compilation Step

Tagged with

AI is Stifling Tech Adoption | Vale.Rocks

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.

Tagged with

Our web design tools are holding us back ⚒ Nerd

A good ol’ rant by Vasilis on our design tools for the web.

Tagged with

Reflections on Design Systems and Boundaries - Jim Nielsen’s Blog

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.

Tagged with

The Case for Design Engineers - Jim Nielsen’s Blog

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.

Tagged with

Related posts

Mismatch

It’s almost as though humans prefer to use post-hoc justifications rather than being rational actors.

Manual ’till it hurts

Try writing your HTML in HTML, your CSS in CSS, and your JavaScript in JavaScript.

Chain of tools

The driven division.

Declarative design systems

Is your design system really a system …or is it more like a collection of components?

Sass and clamp

Worst buddy movie ever.