Latest Posts (18 found)
Jim Nielsen 4 days ago

Notes From an Interview With Jony Ive

Patrick Collison, CEO of Stripe, interviewed Jony Ive at Stripe Sessions . Below are my notes from watching the interview. I thought about packaging these up into a more coherent narrative, but I just don’t have the interest. However, I do want to keep these notes for possible reference later, so here’s my brain dump in a more raw form. On moving fast and breaking things: breaking stuff and moving on quickly leaves us surrounded by carnage. There’s an intriguing part in the interview where Ive reflects on how he obsessed over a particular detail about a cable’s packaging. He laughs at the story, almost seemingly embarrassed, because it seems so trivial to care about such a detail when he says it out loud. But Collison pushes him on it, saying there’s probably a utilitarian argument about how if you spend more time making the packaging right, some people mights save seconds of time and when you multiply that across millions of people, that's a lot of savings. But Collison presumes Ive isn’t interested in that argument — the numbers, the calculation, etc. — so there must be something almost spiritual about investing in something so trivial. Ive’s response: I believe that when somebody unwrapped that box and took out that cable, they thought “Somebody gave a shit about me.” I think that’s a nice sentiment. I do. But I also think there’s a counter argument here of: “They cared when they didn’t have to, but they were getting paid to spend their time that way. And now those who can pay for the result of that time spent get to have the feeling of being cared for.” Maybe that’s too cynical. Maybe what I’m getting at is: if you want to experience something beautiful, spend time giving a shit about people when you don’t stand to profit from it. To be fair, I think Ive hints at this with his use of “privilege” here: I think it’s a privilege if we get to practice and express our concern and care for one another [by making things for one another at work] People say products are a reflection of an organization’s communication structure. Ive argues that products are a function of the interpersonal relationships of those who make them: To be joyful and optimistic and hopeful in our practice, and to be that way in how we relate to each other and our colleagues, [is] how the products will end up. Ive talking about how his team practiced taking their design studio to someone’s house and doing their work there for a day: [Who] would actually want to spend time in a conference room? I can’t think of a more soulless and depressing place…if you’re designing for people and you’re in someone’s living room, sitting on their sofa or floor and your sketchbook is on their coffee table, of course you think differently. Of course your preoccupation, where your mind wanders, is so different than if you’re sitting in a typical corporate conference room. Everybody return to the office! Ive conveying an idea he holds that he can’t back up: I do believe, and I wish that I had empirical evidence What is the place for belief in making software? Ive speaks about how cabinet makers who care will finish the inside parts of the cabinet even if nobody sees them: A mark of how evolved we are as people is what we do when no one sees. It’s a powerful marker of who we truly are. If you only care about what's on the surface, then you are, by definition, superficial. Reply via: Email · Mastodon · Bluesky

0 views
Jim Nielsen 1 weeks ago

My Number One “Resource Not Found”

The data is in. The number one requested resource on my blog which doesn’t exist is: According to Netlify’s analytics, that resources was requested 15,553 times over the last thirty days. Same story for other personal projects I manage: “That many requests and it serves a 404? Damn Jim, you better fix that quick!” Nah, I’m good. Why fix it? I have very little faith that the people who I want most to respect what’s in that file are not going to do so . So for now, I’m good serving a 404 for . Change my mind. Reply via: Email · Mastodon · Bluesky iOS Icon Gallery : 18,531 requests. macOS Icon Gallery 10,565 requests.

0 views
Jim Nielsen 1 weeks ago

Podcast Notes: Feross Aboukhadijeh on The Changelog

I enjoyed listening to Feross Aboukhadijeh , founder and CEO of the security firm Socket, on the Changelog podcast “npm under siege” . The cat-and-mouse nature of security is a kind of infinite source of novel content, like a series of heist movies that never produces the same plot so you can never quite guess what happens next. I like how succintly Feross points out the paradox of trying to keep your software safe by upgrading packages on npm: The faster you upgrade your packages, the safer you are from software vulnerabilities. But then the faster you upgrade the more vulnerable you are to supply chain attacks He points out (and I learned) that pnpm has a feature called that lets you avoid installing anything super new. So you can, for example, specify: “Don’t install anything published in the last 24 hours.” In other words: let’s slow down a bit. Maybe we don’t need immediacy in everything, including software updates. Maybe a little friction is good . And if security vulnerabilities are what it took to drive us to this realization, perhaps it’s a blessing in disguise. (Until the long running cat-and-mouse game of security brings us a bad actor who decides to exercise a little patience and creates some kind of vulnerability whose only recourse requires immediate upgrades and disabling the flag, lol.) Later in the podcast Feross is asked whether, if he was the benevolent dictator of npm, he would do things the same. He says “yes”. Why? Because the trade-offs of “trust most people to do the right thing and make it easy for them” feels like the better decision over “lock it down and make it harder for everyone”. He’s a self proclaimed optimist: There’s so much good created when you just trust people and you hope for the best. Obviously Feross has an entire business based on the vulnerabilities of npm, so his incentives are such that if he did change things, he might not exist ha. So read that how you will. But I like his optimistic perspective: try not to let a few bad actors ruin the experience for everyone. Maybe we can keep the levers where they are and try to clean up what remains. Reply via: Email · Mastodon · Bluesky

0 views
Jim Nielsen 2 weeks ago

Data Storage As Files on Disk Paired With an LLM

I recently added a bunch of app icons from macOS Tahoe to my collection . Afterwards, I realized some of them were missing relational metadata. For example, I have a collection of iMove icons through the years which are related in my collection by their App Store ID. However, the latest iMovie icon I added didn’t have this ID. This got me thinking, "Crap, I really want this metadata so I can see apps over time . Am I gonna have to go back through each icon I just posted and find their associated App Store ID?” Then I thought: “Hey, I bet AI could figure this out — right? It should be able to read through my collection of icons (which are stored as JSON files on disk), look for icons with the same name and developer, and see where I'm missing and .” So I formulated a prompt (in hindsight, a really poor one lol): look through all the files in and find any that start with and then find me any icons like iMovie that have a correlation to other icons in where it's missing and But AI did pretty good with that. I’ll save you the entire output, but Cursor thought for a bit, then asked to run this command: I was like, “Ok. I couldn’t write that myself, but that looks about right. Go ahead.” It ran the command, thought some more, then asked to run another command. Then another. It seemed unsatisfied with the results, so it changed course and wrote a node script and asked permission to run that. I looked at it and said, “Hey that’s probably how I would’ve approached this.” So I gave permission. It ran the script, thought a little, then rewrote it and asked permission to run again. Here’s the final version it ran: And with that, boom! It found a few newly-added icons with corollaries in my archive, pointed them out, then asked if I wanted to add the missing metadata. The beautiful part was I said “go ahead” and when it finished, I could see and review the staged changes in git. This let me double check the LLM’s findings with my existing collection to verify everything looked right — just to make sure there were no hallucinations. Turns out, storing all my icon data as JSON files on disk (rather than a database) wasn’t such a bad idea. Part of the reason I’ve never switched from static JSON files on disk to a database is because I always figured it would be easier for future me to find and work with files on disk (as opposed to learning how to setup, maintain, and query a database). Turns out that wasn’t such a bad bet. I’m sure AI could’ve helped me write some SQL queries to do all the stuff I did here. But what I did instead already fit within a workflow I understand: files on disk, modified with scripting, reviewed with git, checked in, and pushed to prod. So hey, storing data as JSON files in git doesn’t look like such a bad idea now, does it future Jim? Reply via: Email · Mastodon · Bluesky

0 views
Jim Nielsen 2 weeks ago

Tahoe’s Terrible Icons: The B-Sides

This post is a continuation of Paul Kafasis’ post “Tahoe’s Terrible Icons” where he contrasts the visual differences across a number of Apple’s updated icons in macOS Tahoe (a.k.a. the Liquid Glass update). While Paul’s post mostly covers icons for the apps you’ll find in the primary folder, there’s also a subset of possibly lesser-known icons in the folder which have suffered a similar fate. When I first got a Mac back in college, one of the things I remember being completely intrigued by — and then later falling in love with — was how you could plumb obscure areas of the operating system and find gems, like the icons for little OS-level apps. You’d stumble on something like the “Add Printer” app and see the most beautiful printer icon you’d ever seen. Who cares what the app did, you could just stare at that icon. Admire it. Take it in. And you’d come away with a sense that the people who made it really cared . Anyhow, enough reminiscing. Let’s get to the icons. I’m saving these pre-Tahoe icons for posterity’s sake because they’re beautiful. On the left is the pre-Tahoe icon, on the right is Tahoe. (Psst: I’ve got a long-running collection of icons for iOS and macOS if you want some eye candy.) Reply via: Email · Mastodon · Bluesky

0 views
Jim Nielsen 3 weeks ago

Leveraging a Web Component For Comparing iOS and macOS Icons

Whenever Apple does a visual refresh in their OS updates, a new wave of icon archiving starts for me. Now that “Liquid Glass” is out, I’ve begun nabbing the latest icons from Apple and other apps and adding them to my gallery. Since I’ve been collecting these icons for so long, one of the more interesting and emerging attributes of my collection is the visual differences in individual app icons over time. For example: what are the differences between the icons I have in my collection for Duolingo? Well, I have a page for that today . That’ll let you see all the different versions I’ve collected for Duolingo — not exhaustive, I’m sure, but still interesting — as well as their different sizes . But what if you want to analyze their differences pixel-by-pixel? Turns out, There’s A Web Component For That™️. Image Compare is exactly what I was envisioning: “A tiny, zero-dependency web component for comparing two images using a slider” from the very fine folks at Cloud Four . It’s super easy to use: some HTML and a link to a script (hosted if you like, or you can vendor it ), e.g. And just like that, boom, I’ve got a widget for comparing two icons. For Duolingo specifically, I have a long history of icons archived in my gallery and they’re all available under the route for your viewing and comparison pleasure . Wanna see some more examples besides Duolingo? Check out the ones for GarageBand , Instagram , and Highlights for starters. Or, just look at the list of iOS apps and find the ones that are interesting to you (or if you’re a fan of macOS icons, check these ones out ). I kinda love how easy it was for my thought process to go from idea to reality: And I’ve written the post, so this chunk of work is now done. Reply via: Email · Mastodon · Bluesky “It would be cool to compare differences in icons by overlaying them…“ “Image diff tools do this, I bet I could find a good one…“ “Hey, Cloud Four makes a web component for this? Surely it’s good…” “Hey look, it’s just HTML: a tag linking to compiled JS along with a custom element? Easy, no build process required…“ “Done. Well that was easy. I guess the hardest part here will be writing the blog post about it.”

1 views
Jim Nielsen 3 weeks ago

Down The Atomic Rabbit Hole

Over the years, I’ve been chewing on media related to nuclear weapons. This is my high-level, non-exhaustive documentation of my consumption — with links! This isn’t exhaustive, but if you’ve got recommendations I didn’t mention, send them my way. Reply via: Email · Mastodon · Bluesky 📖 The Making of the Atomic Bomb by Richard Rhodes. This is one of those definitive histories (it’s close to 1,000 pages and won a Pulitzer Prize). It starts with the early discoveries in physics, like the splitting of the atom, and goes up to the end of WWII. I really enjoyed this one. A definite recommendation. 📖 Dark Sun: The Making of the Hydrogen Bomb by Richard Rhodes is the sequel. If you want to know how we went from atomic weapons to thermonuclear ones, I think this one will do it. It was a harder read for me though. It got into a lot of the politics and espionage of the Cold War and I fizzled out on it (plus my library copy had to be returned, somebody else had it on hold). I’ll probably go pick it up again though and finish it — eventually. 📖 The Bomb: A Life by Gerard J. DeGroot This one piqued my interest because it covers more history of the bomb after its first use, including the testing that took place in Nevada not far from where I grew up. Having had a few different friends growing up whose parents died of cancer that was attributed to being “downwinders” this part of the book hit close to home. Which reminds me of: 🎥 Downwinders & The Radioactive West from PBS. Again, growing up amongst locals who saw some of the flashes of light from the tests and experienced the fallout come down in their towns, this doc hit close to home. I had two childhood friends who lost their Dads to cancer (and their families received financial compensation from the gov. for it). 📖 Command and Control: Nuclear Weapons, the Damascus Accident, and the Illusion of Safety by Eric Schlosser Read this one years ago when it first came out. It’s a fascinating look at humans bumbling around with terrible weapons. 🎥 Command and Control from PBS is the documentary version of the book. I suppose watch this first and if you want to know more, there’s a whole book for you. 📖 Nuclear War: A Scenario by Annie Jacobsen Terrifying. 🎥 House of Dynamite just came out on Netlify and is basically a dramatization of aspects of this book. 📖 The Button: The New Nuclear Arms Race and Presidential Power from Truman to Trump by William J. Perry and Tom Z. Collina How did we get to a place where a single individual has sole authority to destroy humanity at a moment’s notice? Interesting because it’s written by former people in Washington, like the Sec. of Defense under Clinton, so you get a taste of the bureaucracy that surrounds the bomb. 🎧 Hardcore History 59 – The Destroyer of Worlds by Dan Carlin First thing I’ve really listened to from Dan. It’s not exactly cutting-edge scholarship and doesn’t have academic-level historical rigor, but it’s a compelling story around how humans made something they’ve nearly destroyed themselves with various times. The part in here about the cuban missile crisis is wild. It led me to: 📖 Nuclear Folly: A History of the Cuban Missile Crisis by Serhii Plokhy is a deep look at the Cuban Missile crisis. This is a slow burning audiobook I’m still chewing through. You know how you get excited about a topic and you’re like “I’m gonna learn all about that thing!” And then you start and it’s way more than you wanted to know so you kinda back out? That’s where I am with this one. 🎥 The Bomb by PBS. A good, short primer on the bomb. It reminds me of: 🎥 Turning Point: The Bomb and the Cold War on Netflix which is a longer, multi-episode look at the bomb during the Cold War. 📝 Last, but not least, I gotta include at least one blog! Alex Wellerstein, a historian of science and creator of the nukemap , blogs at Doomsday Machines if you want something for your RSS reader.

0 views
Jim Nielsen 4 weeks ago

Browser APIs: The Web’s Free SaaS

Authentication on the web is a complicated problem. If you’re going to do it yourself, there’s a lot you have to take into consideration. But odds are, you’re building an app whose core offering has nothing to do with auth. You don’t care about auth. It’s an implementation detail. So rather than spend your precious time solving the problem of auth, you pay someone else to solve it. That’s the value of SaaS. What would be the point of paying for an authentication service, like workOS, then re-implementing auth on your own? They have dedicated teams working on that problem. It’s unlikely you’re going to do it better than them and still deliver on the product you’re building. There’s a parallel here, I think, to building stuff in the browser. Browsers provide lots of features to help you deliver good websites fast to an incredibly broad and diverse audience. Browser makers have teams of people who, day-in and day-out, are spending lots of time developing and optimizing new their offerings. So if you leverage what they offer you, that gives you an advantage because you don’t have to build it yourself. You could build it yourself. You could say “No thanks, I don’t want what you have. I’ll make my own.” But you don’t have to. And odds are, whatever you do build yourself, is not likely to be as fast as the highly-optimized subsystems you can tie together in the browser . And the best part? Unlike SasS, you don’t have to pay for what the browser offers you. And because you’re not paying, it can’t be turned off if you stop paying. , for example, is a free API that’ll work forever. That’s a great deal. Are you taking advantage? Reply via: Email · Mastodon · Bluesky

0 views
Jim Nielsen 1 months ago

Don’t Forget These Tags to Make HTML Work Like You Expect

I was watching Alex Petros’ talk and he has a slide in there titled “Incantations that make HTML work correctly”. This got me thinking about the basic snippets of HTML I’ve learned to always include in order for my website to work as I expect in the browser — like “Hey I just made a file on disk and am going to open it in the browser. What should be in there?” This is what comes to mind: Without , browsers may switch to quirks mode, emulating legacy, pre-standards behavior. This will change how calculations work around layout, sizing, and alignment. is what you want for consistent rendering. Or if you prefer writing markup like it’s 1998. Or even if you eschew all societal norms. It’s case-insensitive so they’ll all work. Declare the document’s language. Browsers, search engines, assistive technologies, etc. can leverage it to: Omit it and things will look ok, but lots of basic web-adjacent tools might get things wrong. Specifying it makes everything around the HTML work better and more accurately, so I always try to remember to include it. This piece of info can come back from the server as a header, e.g. But I like to set it in my HTML, especially when I’m making files on disk I open manually in the browser. This tells the browser how to interpret text, ensuring characters like é, ü, and others display correctly. So many times I’ve opened a document without this tag and things just don’t look right — like my smart quotes . For example: copy this snippet, stick it in an HTML file, and open it on your computer: Things might look a bit wonky. But stick a tag in there and you’ll find some relief. Sometimes I’ll quickly prototype a little HTML and think, “Great it’s working as I expect!” Then I go open it on mobile and everything looks tiny — “[Facepalm] you forgot the meta viewport tag!” Take a look at this screenshot, where I forgot the meta viewport tag on the left but included it on the right: That ever happen to you? No, just me? Well anyway, it’s a good ‘un to include to make HTML work the way you expect. I know what you’re thinking, I forgot the most important snippet of them all for writing HTML: Reply via: Email · Mastodon · Bluesky Get pronunciation and voice right for screen readers Improve indexing and translation accuracy Apply locale-specific tools (e.g. spell-checking)

1 views
Jim Nielsen 1 months ago

Everything Is Broken

Chris Coyier wrote about it . Now it’s my turn. Last week I’m flying home. My flight gets delayed in air, then lands late so I miss my connecting flight… [Skip over all the stuff about airline customer support, getting rebooked, etc.] It’s ~10pm and I’m stranded overnight. I need a last-minute hotel room. I figure I’ll try HotelTonight because that’s their shtick, right? “Incredible last-minute hotel deals” says their homepage hero banner. I find the closest hotel, click “Purchase” it takes me to checkout, I do the whole Apple Pay thing, then it says “failed to book” because there are no more rooms left. Ok? Would’ve been nice to know that before going through all the checkout stuff, but ok. I’ll find another. Two more hotels, same deal. Click through, checkout, blah blah blah, payment won’t go through. It says there are no more rooms left. No I’m getting frustrated. I’ll try one more time… Same flow. Finally! Payment goes through. Confirmation number and all — I’m good to go! I leave the airport and get a rideshare to the hotel. Go up to the desk. “Yes, I’m checking in please.” They ask for my name. I give it. They can’t find me. “Oh, no…” I think. “Do you have a reservation number?” Hell yes I do! Right here in the email HotelTonight sent me. I give it to them. It’s not in their system. “Ok well, can you get me a room?” Nope, they are completely full for the night. Knowing that I booked through a third-party system, and it’s not in the first-party system, I know there’s no chance I’m getting a room. So now it’s 10:30pm. I’m in the lobby of the hotel for which I have a bogus confirmation and I begin my search for the next-closest hotel. I know at this point I’m not using anything internet-based to make a reservation. Over-the-phone only! I call a bunch of nearby hotels. Every one is giving me their automated phone system — “If you want to book a reservation, press 1. If you want to…” I sit through the first couple calls and eventually connect to a human: “Do you have any rooms available tonight?” “Yes sir, can you confirm which location you are calling for?” They don’t know because this isn’t someone at the hotel. This is a call center somewhere. I quickly realize this ain’t gonna work. New rule: if the number online is a centralized number that gives me your automated phone system, I’m out. Next hotel. I just need to connect to a human at a front desk. I call maybe 12 hotels. About two give me humans at the front desk. Both of those are booked solid for the night. But you know what? Props to those hotels for having direct lines to a human. YUGE props. A direct line to a human feels like the ultimate luxury at this point. “Hey you got any rooms tonight? No? That’s ok. I appreciate you being there to answer my call, friend. You have a good night.” Eventually I find a hotel 20 minutes down the road where somebody at the front desk answers and says they have a room. “It’s twice the cost since it’s our last room.” I don’t care, I book it. This is a phone call with a person at the front desk, I know I’m getting a room. Postscript: I also spent several days going back and forth with a rep at HotelTonight to get a refund. I guess it’s hard to prove that their system sold me a room that did not exist. Reply via: Email · Mastodon · Bluesky

0 views
Jim Nielsen 1 months ago

AI Browsers: Living on the Frontier of Security

OpenAI released their new “browser” and Simon Willison has the deets on its security , going point-by-point through the statement from OpenAI’s Chief Information Security Officer. His post is great if you want to dive on the details. Here’s my high-level takeaway: Everything OpenAI says they are doing to mitigate the security concerns of an LLM paired with a browser sounds reasonable in theory. However, as their CISO says, “prompt injection remains a frontier, unsolved security problem”. So unless you want to be part of what is essentially a global experiment on the frontier of security on the internet, you might want to wait before you consider any of their promises “meaningful mitigation”. (Aside: Let’s put people on the “frontier” of security for their daily tasks, that seems totally fine right? Meanwhile, Tom MacWright has rationally argued that putting an AI chatbot between users and the internet is an obvious disaster we’ll all recognize as such one day .) What really strikes me after reading Simon’s article is the intersection of these two topics which have garnered a lot of attention as of late: This intersection seems primed for exploitation, especially if you consider combining different techniques we’ve seen as of late like weaponizing LLM agents and shipping malicious code that only runs in end-users’ browsers . Imagine, for a second, something like the following: You’re an attacker and you stick malicious instructions — not code, mind you, just plain-text English language prose — in your otherwise helpful lib and let people install it. No malicious code is run on the installing computer. Bundlers then combine third-party dependencies with first-party code in order to spit it out application code which gets shipped to end users. At this point, there is still zero malicious code that has executed on anyone’s computer. Then, end users w/AI browsers end up consuming these plain-text instructions that are part of your application bundle and boom, you’ve been exploited. At no point was any “malicious code” written by a bad actor “executed” by the browser engine itself. Rather, it’s the bolted on AI agent running alongside the browser engine that ingests these instructions and does something it obviously shouldn’t. In other words: it doesn’t have to be code to be an exploit. Plain-text human language is now a weaponizable exploit, which means the surface for attacks just got way bigger. But probably don’t listen to me. I’m not a security expert. However, every day that voice in the back of my head to pivot to security gets louder and louder, as it’s seemingly the only part of computer science that gets worse every year . Reply via: Email · Mastodon · Bluesky npm supply chain attacks AI browsers

0 views
Jim Nielsen 1 months ago

Write Code That Runs in the Browser, or Write Code the Browser Runs

I’ve been thinking about a note from Alex Russell where he says: any time you're running JS on the main thread, you're at risk of being left behind by progress. The zen of web development is to spend a little time in your own code, and instead to glue the big C++/Rust subsystems together, then get out of the bloody way. In his thread on Bluesky, Alex continues : How do we do this? Using the declarative systems that connect to those big piles of C++/Rust: CSS for the compositor (including scrolling & animations), HTML parser to build DOM, and for various media, dishing off to the high-level systems in ways that don't call back into your JS. I keep thinking about this difference: There’s a big difference between A) making suggestions for the browser, and B) being its micromanager . Hence the title: you can write code that will run in the browser, or you can write code that calls the browser to run. So what are the browser ‘subsystems’ I can glue together? What are some examples of things I can ask the browser to do rather than doing them myself? A examples come to mind: requestAnimationFrame -> document.startViewTransition -> @view-transition" data-og-image /> The trick is to let go of your need for control. Say to yourself, “If I don’t micromanage the browser on this task and am willing to let go of control, in return it will choose how to do this itself with lower-level APIs that are more performant than anything I can write.” For example, here are some approaches to animating transitions on the web where each step moves more responsibility from your JavaScript code on the main thread to the browser’s rendering engine: It’s a scale from: I want the most control, and in exchange I’ll worry about performance. I don’t need control, and in exchange you’ll worry about performance. I don’t know about you, but I’d much rather hand over performance, accessibility, localization, and a whole host of issues to the experts who build browsers. Building on the web is a set of choices: Anytime you choose to do something yourself, you’re choosing to make a trade-off. Often that increase in control comes at the cost of a degradation in performance. Why do it yourself? Often it’s because you want a specific amount of control over the experience you’re creating. That may be perfectly ok! But it should be a deliberate choice, not because you didn’t consider (or know) the browser offers you an alternative. Maybe it does! So instead of asking yourself, “How can I write code that does what I want?” Consider asking yourself, “Can I write code that ties together things the browser already does to accomplish what I want (or close enough to it)?” Building this way will likely improve your performance dramatically — not to mention decrease your maintenance burden dramatically! Reply via: Email · Mastodon · Bluesky I need to write code that does X. I need to write code that calls a browser API to do X. View transitions API (instead of JS DOM diffing and manual animation). CSS transitions or (GPU-accelerated) vs. manual JS with updates. in CSS vs. JS scroll logic. CSS grid or flexbox vs. JS layout engines (e.g., Masonry clones). and elements with native decoding and hardware acceleration vs. JS media players. or with for responsive images vs. manual image swapping logic in JS. Built-in form state ( ) and validation ( , , etc.) vs. JS-based state, tracking, and validation logic. Native elements like , , , etc., which provide built-in keyboard and accessibility behavior vs. custom ARIA-heavy components. JS timers, DOM manipulation, browser repaints when it can. Dropped frames. Syncs to browser repaint cycle. Smooth, but you gotta handle a lot yourself (diffing, cleanup, etc.) View Transitions in JS JS triggers, browser snapshots and animates. Native performance, but requires custom choreography on your part. View Transitions in CSS Declare what you expect broadly, then let the browser take over. Do it yourself. Let the browser do it. Somewhere in between.

0 views
Jim Nielsen 1 months ago

Research Alt

Jeremy imagines a scenario where you’re trying to understand how someone cut themselves with a blade. It’d be hard to know how they cut themselves just by looking at the wound. But if you talk to the person, not only will you find out the reason, you’ll also understand their pain. But what if, hear me out here, instead we manufactured tiny microchips with sensors and embedded them in all blades? Then we program them such that if they break human flesh, we send data — time, location, puncture depth, current blade sharpness, etc. — back to our servers for processing with AI. This data will help us understand — without bias, because humans can’t be trusted — how people cut themselves. Thus our research scales much more dramatically than talking to individual humans, widening our impact on humanity whilst simultaneously improving our product (and bottom line)! I am accepting venture funds for this research. You can send funds to this bitcoin address: . Reply via: Email · Mastodon · Bluesky

0 views
Jim Nielsen 1 months ago

Social Share Imagery via a Data Attribute

I’ve done something few on the internet do. I’ve changed my mind. A few posts on my blog have started to unfurl social share imagery. You might be wondering, “Wait Jim I thought you hated those things?” It’s not that I hate social share imagery. I just think…well, I’ve shared my thoughts before (even made a game ) so I won’t get on my soapbox. But I think these “previews” have their place and, when used as a preview — i.e. an opportunity to graphically depict a brief portion of the actual, underlying content — these function well in service of readers . For example, I often write posts that have zero images in them. They’re pure text. I don’t burden myself with the obligation to generate a graphical preview of the ideas contained in those posts. But, sometimes, I create posts that have lots of imagery in them , or even just a good meme-like photo and it feels like a shame to not surface that imagery in some way. So, in service of that pursuit, I set out to resolve how I could do og:images in my posts. It’s not as easy as “just stick it your front-matter” because my markdown files don’t use front-matter . And I didn’t want to “just add front-matter”. I have my own idiosyncratic way of writing markdown for my blog, which means I need my own idiosyncratic way of denoting “this post has an og:image and here’s the URL”. After giving it some thought, I realized that all my images are expressed in markdown as HTML (this lets me easily add attributes like , , and ) so if I wanted to mark one of my images as the “preview” image for a post, I could just add a special data attribute like so: Then my markdown processor can extract that piece of meta information and surface it to each post template, essentially like this: I love this because it allows me to leverage existing mechanisms in both the authoring and development processes (data attributes in HTML that become metadata on the object), without needing to introduce an entirely new method of expression (e.g. front-matter). It also feels good because: It’s technology in service of content, rather than content in service of technology. Or at least that’s what I like to tell myself :) Reply via: Email · Mastodon · Bluesky It’s good for me . It doesn’t require any additional work on my part. I don’t have to create additional images for my posts. I’m merely marking images I’ve already created — which were done in service of a post’s content — as “previews” for the post. It’s good for users . Readers of my site get image previews that are actually, well, previews — e.g. a graphical representation that will contextually reappear in the post, (as opposed to an image template whose contents do nothing to provide an advanced graphical preview of what’s to follow in the post itself).

0 views
Jim Nielsen 1 months ago

Doing It Manually

I have a standing desk that goes up and down via a manual crank. I’ve had it for probably ten years. Every time I raise or lower that thing, it gets my blood pumping. I often think: “I should upgrade to one of those standing desks that goes up and down with the push of a button.” Then there’s the other voice in my head: “Really? Are you so lazy you can’t put your snacks down, get out of your comfy chair, in your air conditioned room, and raise or lower your desk using a little elbow grease? That desk is just fine.” While writing this, I get out of my chair, star the timer, and raise my desk to standing position. 35 seconds. That’s the cost: 35 seconds, and an elevated heart rate. As I have many times over the last ten years, I recommit to keeping it — mostly as a reminder that it’s ok to do some things manually. Not everything in my life needs to be available to me at the push of a button. Reply via: Email · Mastodon · Bluesky

0 views
Jim Nielsen 2 months ago

Running Software on Software You’ve Never Run

I love a good look at modern practices around semantic versioning and dependency management ( Rick Hickey’s talk “Spec-ulation” is the canonical one I think of). Niki recently wrote a good ‘un at tonsky.me called “We shouldn’t have needed lockfiles” . What struck me was this point about how package manifests allow version ranges like which essentially declare support for future versions of software that haven’t yet been written: Instead of saying “libpupa depends on liblupa ”, [version ranges] are saying “libpupa depends on whatever the latest liblupa version is at the time of the build.” Notice that this is determined not at the time of publishing, but at the time of the build! If the author of libpupa has published 1.2.3 a year ago and I’m pulling it now, I might be using a liblupa version that didn’t even exist at the time of publishing! The funny thing is, we use version ranges only to go freeze them with lock files: version ranges end up not being used anyway. You lock your dependencies once in a lockfile and they stay there, unchanged In other words: we avoid locking ourselves to specific versions in by using version ranges, only to then go lock ourselves to specific versions in — lol! I mean, that’s funny when you think about it. But to go back to Niki’s earlier point: version ranges let us declare to ourselves that some code that exists today is compatible with some other future code that has yet to be written. This idea allows us to create automated build systems that resolve to an artifact whose dependencies have never existed before in that given combination — let alone tested and executed together in that combination. Now I get it, semantic versioning is an idea not a guarantee. But it’s also pretty wild when you think about it — when you encounter the reality of how semantic versioning plays out in the day-to-day world of building software. I guess that’s a way of acknowledging out loud that we have normalized shipping production systems on top of the assumption that untested, unwritten combinations of software will behave well together — if not better, since patch updates fix bugs right? And that’s not even getting into the security side of the equation. Future versions of packages have no guarantee to be as safe as previous ones, as we’ve seen with some of the npm supply chain attacks which rely on version ranges for their exploits. (Funny, isn’t it? Upgrading to the latest version of a package can get you into trouble. The solution? Upgrading to the latest version of a package.) Anyhow, this all gets me thinking that version ranges and dependency management were the gateway drug to the non-determinism of LLMs. Reply via: Email · Mastodon · Bluesky

0 views
Jim Nielsen 2 months ago

The Risks of NPM

There was a time when I could ask, “Did you see the latest NPM attack?” And your answer would be either “Yes” or “No”. But now if I ask, “Did you see the latest NPM attack?” You’ll probably answer with a question of your own: “Which one?” In this post, I’m talking about the Qix incident : When I first heard about it, I thought “Oh boy, better not on the old personal machine for a little while.” But as details began to emerge, I realized the exploit wasn’t targeting my computer. It was targeting the computers of people downstream from me: end users. The malicious code didn’t do anything when running . Instead, it laid there dormant, waiting to be bundled up alongside a website’s otherwise normal code and served to unsuspecting end users. Maybe we should rename “bundlers” to “trojan horses”, lol. That’s all to say: you didn’t have to run to be affected by this attack. You just had to visit a website whose code was sourced via . (You needed a bitcoin wallet too, as that was the target of the exploit.) It’s wild because browsers work really hard to make it safe to visit any webpage in the world — to do a GET to any URL. But attacks like this chip away at those efforts. So while it’s easy to think NPM can be unsafe for your computer because running allows running arbitrary code, that’s not the whole story. can be unsafe for: Reply via: Email · Mastodon · Bluesky Related posts linking here: (2025) Social Share Imagery via a Data Attribute · (2025) AI Browsers: Living on the Frontier of Security Prolific maintainer Qix was phished. Qix is a co-maintainer on many packages with Sindre Sorhus, the most popular maintainer on NPM (by download count). Attackers pushed malicious code to packages that are indirectly depended by a huge portion of the ecosystem (hundreds of millions of downloads a week). Your computer (install time execution) Lifecycle scripts ( , , ) allow running arbitrary code which can read/write files locally, steal keys and tokens, install malware, and otherwise exfiltrate data. Your dev/CI computer(s) (build time execution) Compilers, bundlers, transpilers, plugins, etc., can all execute arbitrary code and leak secrets, corrupt build artifacts, add hidden payloads, etc. Your application server (server runtime execution) Any dependency runs top-level in production and exposes risk to data exfiltration, unsafe privilege escalation, remote command execution, etc. Your users’ computers (client runtime execution) Bundled dependencies ship with your website, exposing your users to malicious code that runs in their browser and can exfiltrate data, insert hidden trackers/miners, etc.

0 views
Jim Nielsen 2 months ago

Anti-*: The Things We Do But Not All The Way

I was reading Chase McCoy’s article “Antibuildings” where he cites Wikipedia’s entry on the term “Antilibrary” which points to another entry about the Japanese concept of Tsundoku , all of which deal with this idea of things we do with intention but that never make it to fruition. Antilibraries are the books we buy but never read. Antibuildings the architect’s version of sketches and plans drafted but buildings never made. It got me thinking about the stuff I’ve started with intention but never brought to fruition — my own anti-*’s. To name a few: And last, but certainly not least — in fact, probably grandest of them all: Reply via: Email · Mastodon · Bluesky Related posts linking here: (2025) Social Share Imagery via a Data Attribute Antidomains : the domains I bought and had big plans for, but they never progressed beyond being parked at my registrar. ( Zach Leatherman recently made a list kinda like this , if you haven’t seen it.) Antiwebsites : the sites I was gonna make, but never shipped. Antilayers : the Photoshop, Sketch, or Figma designs I painstakingly crafted to the level of “completeness”, but then never began building with code. Anticode : the changes I made that functioned to the level of being usable and shippable, but then I never could pull the trigger on ‘em. Antiposts : (also known as “drafts”, lol) all those blog posts I poured time and energy into researching, writing, and editing, but never could take all the way to “published”. Antitweets : all the Tweets/Toots/Skeets I meticulously crafted as witty comebacks or sarcastic quips, but then never posted (honestly, probably for the better). Antitabs : all the browser tabs of articles, videos, recipes, and other good things I collected and was going to read, watch, bake, etc. but never did.

0 views