the difference between can and should...

 Today I saw some JS code that was like:
   const counterAxisAlignItems === 'MIN'
      ? 'flex-start'
      : counterAxisAlignItems === 'MAX'
      ? 'flex-end'
      : counterAxisAlignItems === 'CENTER'
      ? 'center'
      : undefined;

took me a minute to realize that was essentially a select case statement using the ternary operator. Though it's kind of more like rewriting if/else statements. But I'm not sure why they didn't use a simple lookup object - this is just a mapping and an unknown key will return undefined as expected...

keeping it real

 Mastodon post about important sites aimed at people experiencing poverty taking multiple MB of JS to load even the very first view.

I'm sometimes discouraged by the gap between the technology I am skilled in for work and what I will put together for a quick personal project. But crufty old technologies still get a lot of things right by default- and in terms of maintainability over years and even decades, they make up for their costs in bespoke weirdness by having a reduced cross section in what frameworks you need to know.

There are absolutely more modern technologies that can get to the same place in terms of not shipping the factory down the wire just to display the showroom (next.js doing static rendering, etc) - but it takes thought and time that people disposed to the "kitchen sink approach" (that, say, create-react-app gives you by default) won't necessarily want to apply.

I am on a job hunt for a UI Engineering role, remote or in the Boston area, where I can use my React and TypeScript abilities (or potentially even the older ones if that's how your company rolls!) to make terrific user experiences, so if you think I might be a fit for your place let me know!

text with gradiant colors

I continue to be impressed with ChatGPT's ability to know about small tasks. Some specs at work wanted text with a gradient, and ChatGPT came up with

.gradient-text {
  background: linear-gradient(to right, #ff0000, #0000ff);
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
}

giving something like

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam finibus interdum hendrerit. Proin et suscipit quam, ac feugiat velit. In tristique vel dolor quis egestas. Fusce et metus a lacus tincidunt maximus id sed felis. Sed nec magna ut orci pellentesque interdum. Praesent ut auctor ex, a auctor leo. Sed a eros viverra, luctus risus at, fermentum erat. Nulla nec vestibulum dolor. Nulla posuere molestie est sed scelerisque. Nam ut tortor varius, hendrerit nibh eu, interdum libero.

the ol' juice

10 or so years ago, I was a big advocate for "Juicy" UI - interactions with just a splash of gratuitous kinesthetic pleasure.

I do suspect that was a little easier to achieve in the bad old jQuery days - adding an easing or extra animation to a specific action (as an adverb, so to speak) is more direct than setting up a CSS animation (which is more like working with adjectives) Especially for chaining multiple animations, where I think you still have to dip into JS.

But you still see signs of it - I love Material UI's react button that sends a sonar blip of color out from wherever you click it.

My project manager at work was talking about Rive, especially the delightful cat paw interaction (on hover) with the "Get Started" button at top.

It seems Rive's space is a bit closer to what used to be done in Flash - larger animations and fancier mini-cartoons - than jQuery, but still. That cats paw button is great!

General self-plug: if your company might be looking for a Boston-based UI dev (with midtier / whole-site background) for React/Typescript, and with an eye for the old "juiciness" and other ways of delighting users - I might be that guy! https://kirk.is/portfolio

[Re: structuring and working in React]

Jacob Paris has some hot takes on twitter:

"You probably don’t need - useEffect - Postgres - serverless - state management - dark mode"

State Management is an interesting one. (Especially given Paris' followup: "Not one person has tried defending state management - Truly a sign of the times") My first professional React project was making heavy use of Redux, but given its complexity... as soon as other alternates to bad old "prop drilling" (especially useContext) emerged, I'm not surprised they took over.

Looking over technologies that have come and gone, I've noticed that simplicity usually wins. Going way back, it (plus performance) is why Java EJBs flamed out - or more universally why JSON came in and wiped out use of XML in so much infrastructure. It is also why React muscled out Angular. (But the other part of that is, simplicity isn't enough if a framework isn't offering enough solutions, which is why Angular was previously able to gain traction in a JQuery-world.)

My hot take: I think more projects might do what Svelte is doing in terms of switching to JSDoc annotations vs TypeScript. You can read a response to the hub-bub that created... TypeScript can add a lot of visual complexity to function declarations and the like, and the errors and warnings it generates (especially when dealing with layers of React components that use polymorphism) can be arcane and difficult to interpret. I am not surprised that people are looking to alternatives for ensuring compile-time correctness.

Caveat: I know I am FAR more comfortable with duck typing than most of my peers. I'm certainly not calling for a return to the wild west of loose typing, but right now TypeScript doesn't feel like it has the simplicity that so many enduring technologies share. (Counterpoint disclaimer: TypeScript DOES seem to be firmly establishing itself as a de facto standards - much like React rose to predominance - and so this prediction might not be worth the paper it isn't written on.)

what's next

Takeaways from Putting Next JS App Router in production...

the problem of chatgpt

 I had a thought I wanted to express visually:

I really do think this previews some of the biggest problems of the online folk for the next few years, if not more.

In terms of design, I looked at some online Venn Diagram tools (all of which required signup) but realized I'd be better served writing it in code, via P5. You can play with the code at https://editor.p5js.org/kirkjerk/sketches/9r6jEiaHs though it's messy - I only had a vague idea of what I wanted so I iterated and tweaked by hand and didn't bother to clean up after.

Venn/Euler Diagrams had some interesting limits - at first I wanted "true things" and "false things" to cover the space completely, but A. that's not how these diagrams work and B. actually there are a lot of things that aren't fully true or false.

Also I wanted to put a space on "Things ChatGPT knows it doesn't know" but these diagrams don't show the empty set very well.

(Thanks to Arnaud, Melissa and Topher.)