惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

爱范儿
爱范儿
T
The Blog of Author Tim Ferriss
G
Google Developers Blog
博客园_首页
博客园 - 【当耐特】
量子位
S
SegmentFault 最新的问题
B
Blog RSS Feed
酷 壳 – CoolShell
酷 壳 – CoolShell
V
Visual Studio Blog
T
Tailwind CSS Blog
阮一峰的网络日志
阮一峰的网络日志
V
V2EX
Y
Y Combinator Blog
博客园 - 聂微东
The Cloudflare Blog
小众软件
小众软件
J
Java Code Geeks
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
月光博客
月光博客
H
Help Net Security
Jina AI
Jina AI
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
宝玉的分享
宝玉的分享

Jim Nielsen’s Blog

Preserving Netlify Analytics Data Beyond 30 Days An Ode to Links Don’t Let Anyone Take Away Your Big Box of Cables The Bulldozing of an Interface Can We Stop With the Uptime Percentages? Nobody Believes It, Everybody Does It My Experience Has Nuance, Yours Is a Data Point A Calendar View For My Blog Have You Heard the Good News About Microlighter? Getting an LLM to Make Me a Tool for Enriching the Color Metadata in My Icon Collection A Sloppy Interface Is a Security Liability  Oops, Should’ve Thought of That Oh Hey, It’s Not Just Me The Fruits of AI A License to Act The AI Aesthetic Can the Tide of AI Investment Life All Boats on the Web? Podcast Notes: Ed Catmull on David Senra Make It Work vs. Make It Good Podcast Notes: Iain McGilchrist on “The Great Simplification” What’s an Icon in 2026? Family Feud: Mac-assed Mac App Edition Making a Shuffle Button This Page Left Intentionally Blank Notes from Bryan Cantrill’s “Intelligence is not Enough” My Om Malik Story Blogging Can Just Be Stating The Obvious Consistency, But in Excellence Not Appearance Full Page Paralysis Being “Good” at Things
Out With the JS, In With the HTML
Jim Nielsen · 2026-05-11 · via Jim Nielsen’s Blog

I’ve been posting about how you can make lots of HTML pages and leverage navigations over in-page, JS-dependent interactions.

Now I’m gonna post another example.

On my icon sites, I have a little widget that allows you to resize the icons you’re looking at.

Previously, I implemented this functionality as a web component that looked something like this:

<icon-list size="md">
  <a href=""><img src="" width="128" height="128" /></a>
  <a href=""><img src="" width="128" height="128" /></a>
  <!-- more -->
</icon-list>

The size attribute corresponded to an enumeration like sm | md | lg | xl which mapped to actual pixel dimensions like 64×64 or 512×512.

When the little widget was clicked to render icons at a different size, JavaScript changed the size attribute on the <icon-list> custom element. From there, the web component’s JS took over changing the dimensions of the children <img> elements, their src attributes, etc.

It all worked pretty well. However, because that was a client-side solution to my otherwise entirely pre-rendered static site, it required some templating logic and data be duplicated and sent over the wire to every client.

I didn’t love that for various reasons — like “Crap, I updated this one small part of how my icon list renders on the server, but forgot to tweak it on the client, so things are slightly broken now.”

Then one day the thought hit me: instead of relying on JS to make that interaction work (click, execute JS, modify in-page DOM to a new list), what if I just made that interaction a navigation? Click, navigate to a new list.

Instead of “every list of icons ships with some JS that allows them to re-render at four different sizes” I could do “every list of icons ships in four different sizes”.

  • Previously: one page, like /colors/red/, with JS to re-render the icon list based on user interactions.
  • Idea: four pages, like /colors/red/{sm|md|lg|xl}, each a different icon list size.

So I tried it. And guess what? Once I added some code to support CSS view transitions, I got a cool effect amongst the icons for free — that’s right, by removing code!

Works nice on mobile too!

I know I’m not doing anything particularly novel here, but as we continue to get new, powerful primitives on the web — like CSS view transitions — I find it really interesting to revisit basic patterns and explore what’s possible now that wasn’t previously.

It’s fun to ask yourself: “Could I remove some client-side JS and get a better overall experience?” If the answer is yes, I’ll bet you the development experience (and maintenance burden) is much improved too!