feeling loopy

Today at work I was solving two infinite loops, both based on having to finesse dependency arrays in useEvent() or useMemo() type things in React.

Hopefully this is less of an unpopular opinion than it was a while back (I think the industry as a whole is more aware of React's limitations) but React's flavor of declarative programming is so damn "jumpy" compared to, say, the jQuery stuff that preceded it. jQuery coding could suck if you weren't sure what was modifying the DOM, but in general the DOM was stable and the methods to change it (often after doing server side rendering, another technology people had to reinvent for some reason) were more or less transparent.

(And hell... when you have React controlling an <input> tag by using state? So that every thing the user types in changes the state, and then React sets the value tag? The ONLY reason the cursor doesn't jump to a default position is because of React's optimizations to recognize it doesn't actually need to rerender that text box. It seems crazy to me that a fundamental UX experience of being able to type anywhere in an input field is dependent on an optimization like that, since cursor position is some kind of hand-wave-y implied state.)

But now with React... like we used to have MVC, Model-View-Controller as a no frills way of doing UI. But React has always mashed together the Controller into the View. And when it's hard to realize you're modifying the Model, aka the state, or accidentally looking at the wrong state to trigger more actions, man, that's just a recipe for infinite loops and rendering that never ends.

Maybe some year the industry will recognize the power of simplicity. Or not, and we'll just hope the AI bots are doing a good job of thinking through the edge cases.

unix quotes

 I like this page of Unix quotes especially 

Contrary to popular belief, Unix is user friendly. It just happens to be very selective about who it decides to make friends with.   -- unknown

 and

UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity.   -- Dennis Ritchie

but most importantly 

UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things.   -- unknown (generally attributed to a Doug Gwyn, but no information found about him) 

 

thoughts on AI and autocomplete

Heh. Over the weekend I was thinking about that "TypeScript Origins: The Documentary" documentary a coworker linked.

I've only watched the first part one of the big points was the the in-editor/developer experience - especially stuff like autocomplete etc being much more robust when you have everything typed, and some of the devs complained about wasting half day chunks so much time with typos etc. (Which to me seems a little exaggerated maybe? Like if I have my tight iterative code-run loop going, if I don't immediately notice that I typo'd a field, something is probably really wrong.)

 

But it does make me think about the experience of code editors in general. One thing that shocks me is how popular autocomplete of quotes, braces, parens, and tags has become - like it seems weird to me that that's the default, and people are ok with it - for me the extremely minor convenience of saving a keystroke is vastly outweighed by the unpredictability of it all... I type code like syntax in a number of environments, and some complete and some don't, and while I'm barely a touch typist I really do like the idea that "what you type is what you get".

 

And now with AI being thrown into VS Code, my wide ranging ambivalence grows. Like sometimes it's hella helpful and the ChatGPT hints are just the right thing. But man... visually it's a mess. Sometimes it's literally difficult to see, is this code that's there, or is this code proposed by AI. (And a few times the AI - with its "this sounds very likely!" mentality - is actually fighting with the "old school autocomplete" that TypeScript was designed to support... I remember one humble refactor of some relative imports that was made maddeningly difficult as the AI tried to override what the older version of the editor could have done automagically) It's like you're constantly dealing with a pile of AI hallucinations...

 

This is why sometimes I still like sandboxing AI, but then I'm worried I might be a little left behind, that these systems with more collaboration and proactive file manipulation by LLM might be the neartime future

the not-so-hidden costs of "simplicity and elegance"

 (This one for my fellow UI tech heads. Especially folks who cut their teeth on earlier eras of tech.)

Video: React is imploding, and that's a good thing...

My favorite comment comes early:

"But with the latest advancements, I was feeling like maybe I’m too old, too busy or maybe just too dumb to use this new modern flavor of React. And, by the looks of it, this feeling was shared by many other developers."

It goes on to explore how weird it is that Dan Abramov uses a different framework, Astro, to explain how React Server Components are doing their division of server vs client activity (as the video says "Dan is a core team member of the React team, and he spends most of his time explaining and shaping the mental models around React. Having a designated person in charge of  “explaining the mental models” behind a UI library that paints buttons on the screen should already be a red flag")

Besides the horrendous push to vendor lock-in, RSC's agenda seem bizarre - to paraphrase Ben Franklin it pays too much for the whistle of potentially having the same code bits reused back end and front (especially since because the serverside stuff can't use hooks? like what non-trivial component of the past 5 years would have avoided using a hook for managing its state?) Muddling the two codebase sides seems weird. (Hell, I feel like my ancient preferred evergreen/buildless stack of PHP plus Vanilla JS shares Astro's concise division, and that both offer a cleaner, more honest approach than Vercel's stepchild)

All this is part of a wider industry trend towards ignoring complexity as a significant developer cost multiplier. Often we are sold paradigms that sound simpler in the abstract but then the implementation ends up with huge complexity costs. Module Federation seems like a great way to break up a monolith and let separate teams cook, but WOW is its mix of "every client piece has its own server" rough to untangle when things go wrong. TypeScript - yes, there are many benefits of not having a morass of unclear JSON-y jumbles, but man the syntax is HARSH to read. (Maybe I'm biased but I think Java/C's way of showing primitive types was a world better - "int foo" vs foo:int where the meaning of any ":" character is utterly context dependent...)

(Those are two hot takes and potentially unpopular opinions so don't assume I CAN'T use these when called upon, I just think they have questionable cost/benefit ratios)

Sometimes it feels like a huge pile of "lets ensure job security" but if you've been in the industry for decades, it can really take its toll. UI is still addressing the fundamental problem of "how do we get information on and off some centralized computer" that we were 20 years ago, but the techniques now tend to be wolves in sheep's clothing of complexified 'simplicity', not to mention how we've eaten so much "flavor of the month" we're all feeling a bit sick.

smattering of applause for teams

A moment to think about the UX of tools used by (in my case) those making UX.

I think most devs who have used both Slack and Teams would prefer Slack. I've griped about Teams before - the "Teams" part of it feels more like shared email threads or blog-posts-with-comments than dynamic conversation. 

A recent update to Teams helped mediate that a bit; now a single "Chat" sidebar (which is where a lot of devs will live) includes Teams and channels, and both chats and teams posts can appear under a single unified "favorites" section.

I think there's still a conceptual problem where a persistent sense of "group chat" doesn't exist in Teams as an entity; while in theory a team could invite the right people to a group chat and rename that group, in practice I find most teams doing Agile gravitate to using the chat attached to the daily standup for intra-day chat, since there's a strong correlation with who needs to be there and who is in standup. It's simpler than having people have to think about which chat to use, or in which an earlier message is likely to be  found.