Spaces

I took over stewardship of the Spaces Chrome extension recently (open source repo). Dean, the original developer, no longer wanted to maintain it. Chrome Extension Manifest V3 had caused the extension to be broken for a couple years, and then eventually taken down from the Chrome Web Store. I have been a heavy daily user of this extension for over a decade.

Ok, he wants to sell me on this "Spaces" thing now...

beer

A "Space" is just a named browser window with a set of tabs, for example "Beers to Brew". Now that you've given the Space a name, if you don't immediately need it, just close the browser window and let those beer recipe tabs go, man. Your RAM and CPU will thank you for it. Later, when you want to decide which recipe to brew, reopen the space, and all those tabs magically re-appear. Yep, it's kind of like bookmarks in folders, but better because Spaces automatically remembers as you add/remove tabs from the window.

And in case you're curious, Tab Groups don't quite work for me, I context switch at work so much that I eventually end up with many many Spaces, like 100+. In fact, I still don't know why browsers don't just do what Spaces does by default, but maybe there are fewer people like me with hundreds of tabs open at a time.

Once you get over that hump of closing the window and trusting the extension to do its job you will go from a person who might have hundreds of tabs open to maybe only 20-30 at a time.

tools

Anyway, since I've never written a browser extension before, I thought I'd use it as an opportunity to also pair program with an AI Agent and learn things that way. GitHub offered me Copilot to me for free, and I found Claude Sonnet 4 pretty capable, so I went for it. For some tasks, I'd occasionally swap out the LLM model (Gemini, GPT) and with other tasks I'd use Gemini Code Assist and Gemini CLI. It's good to understand the "personalities" of the models and to try out other agent user interfaces so that you can see where the game changes are.

My experience with this so far has been best described as "working with a variety of eager interns who needs a lot of guidance", matching a lot of other experiences I've read about. Is it saving me time? - oh yes indeed. I mean it's not a total obvious win, but for things like creating unit test suites and things of that nature it's great. Maybe a 2x improvement in velocity? Just be prepared to type at it a lot and to exercise your patience if you're particular.

gift

If you're turning your nose up at this point, I'd suggest you think about the opportunity here. Take advantage of the enormous amounts of free compute that big corporations are laying at your fingertips to move faster and build more, bro. The window of free compute is closing fast.

§1429 · September 18, 2025 · Agentic, Chrome, JavaScript, Open Source, Software, Technology, Tips · (No comments) ·


JavaScript

Oh, remember that time six years ago when I said one day soon we'll be able to use ES Modules everywhere, even inside Web Workers and Service Workers? Well that day is next week when the last browser ships support for ES Modules in Workers - finally!

Yes, I know that ES Modules are terrible, actually - but the fact is that they are the future of JavaScript / TypeScript / Node / Deno development so we all might as well accept it. I actually think they're great. I've been using them for hobby projects forever - though I rarely use transpilers, bundlers, etc.

Celebrate

Sure, it will be some time before CommonJS modules are resigned to the ash heap of history, until then https://esm.sh/#docs can help... but I for one welcome our Isomorphic JavaScript overlords.

§1350 · May 31, 2023 · JavaScript, Software, Technology, Web · Comments Off on All We Need is Just a Little Patience ·


Logo for JSON

I decided to learn a bit of React again for some toy projects (my day job JS framework is Angular). Most of the tutorials for setting up a React project "from scratch" ultimately result in using the create-react-app library to hide a lot of the complexity (transpilers, bundlers), but I'm not interested in Webpack or Babel - primarily because I know browsers don't need them anymore. Also, I like to learn about how the bits and bobs work together for small projects like this. Here are the 3 things I want: Typescript, JSX, and compile/deploy to ES modules. Can this actually be done? Yes, and it's not that difficult.

Read the rest of this entry ...
§1318 · April 8, 2023 · JavaScript, React, Software, Technology, Web · Comments Off on Dead Simple: TSX, ES Modules, Preact ·


Logo for JSON

The elder days of my blog are littered with useless musings on XML and JSON. So why not throw another one on the pile? 🙂

I wish JSON supported:

  1. Multi-line strings (but no string interpolation)
  2. Trailing commas (in arrays and object property lists)
  3. Comments

Of course none of these will probably ever happen, but having any of these three would keep JSON wonderfully simple but vastly improve the user experience of those who have to hand-tweak JSON files (which is a lot of people!). I kept these feature requests to only things supported by ECMAScript itself. I also note that several parsers seem to accept JSON with #2 and #3.

YAML has all these, but of course it has many other features that, I assume, make it burdensome to write a fully compliant parser.

[Update Jan 2023: I finally filed a bug on VS Code for this idea of back-ticked string support in their tasks.json. Maybe it's crazy, I haven't decided... but feel free to vote it up!]

§1306 · October 26, 2022 · JavaScript, Software, Technology · Comments Off on 3 Wishes for JSON · Tags: , ,


JavaScript logo

The esteemed Dr. Axel Rauschmayer has written a blog post about a new proposal for JavaScript: Types as Comments. It definitely has got me thinking.

On the one hand, I'm a huge fan of JavaScript evolution over the last decade or so. Arrow functions, const/var, classes, modules - that's all good stuff that has improved the language.

Typescript logo

Seemingly on the same side of this argument: I'm also a huge fan of Typescript. It changed how I do large-scale frontend development four or so years ago - static typing in a language helps me write clear code, catches a huge number of bugs at compile-time, and the tooling and overall ecosystem around it is top-notch. Kudos to Microsoft on this one.

But I'm not convinced the value of this proposal nets out positive. The proposal itself says that the primary motivation is to inch JavaScript evolution towards eventually supporting static types:

Does JavaScript need static type-checking?

"Given how much effort organizations and teams have put into building type-checkers and adopting them, the answer is yes."

Why?

Tools

You have to accept that JavaScript is the language of the runtime. We shouldn't be caring about types at runtime - that's the job of the toolchain prior to deploying. That's the way every other language works (feel free to tell me how wrong I am in the comments - I am no language expert!).

Static typing only helps developers, not users.

Think about it this way: what level of performance degradation are you willing to accept for full support of static types? Is it ok for the JavaScript parser and runtime to be 5% slower for every web page or 15% larger in code size? Of course I'm pulling these numbers out of my ass.

When I was first fanboying out on TS, I used to think "gee, wouldn't it be really cool for browsers to support Typescript natively". Wouldn't that be an awesome way to learn and view source, etc. But you know what's good for that instead? Super-fast and small JavaScript for best performance and if you want to share your developer brilliance, have an optional compile-mode and source maps that point to your awesome Typescript.

Patrick the Star

Another thing I don't like about the proposal is that, while they are clearly heavily influenced by Typescript, they hedge:

How does this proposal relate to TypeScript?

"This proposal is a balancing act: trying to be as TypeScript compatible as possible while still allowing other type systems"

You are JavaScript - if you are adamant about eventually supporting static types, why not boldly point towards a "north star" of a language that has already proven itself? Is it that you don't want to admit Typescript won? Is it lingering anti-Microsoft bias?

My opinion: If we are going to add static typing for web apps, we should just use Typescript as a new script type. <script type="application/x-typescript"> seems a better option to me so that the browser can choose an appropriate parser, etc.

§1296 · March 10, 2022 · JavaScript, Software, Technology, Uncategorized, Web · 1 comment ·