Hi friends 👋 Welcome to a special Monday afternoon edition of Frontend at Scale. It's just like the usual Sunday morning edition, but with 50% less punctuality.

This week's edition is a special one though, because a) it's Frontend at Scale's 2nd Birthday!*, and b) we have a brand new section called Code Showdown 🥊, which is the first one in a series of recurring sections I'm planning to experiment with over the next few weeks to keep things light and fun.

We also have a short essay about spec-driven development, a bunch of tools to add to your frontend toolkit, and a great list of articles to last you the whole week.

Let's dive in.

(*) The newsletter's anniversary was actually a couple of weeks ago. But hey, you can't say I didn't warn you about the punctuality, or lack thereof.

MAXI'S RAMBLINGS

The Rise of Spec-Driven Development

A couple of weeks ago, Amazon launched Kiro, a new VS Code-based IDE with surprisingly zero AI features.

Ok, that was a lie. Of course it has AI. It also has a quite unique feature called “Spec Mode”, which helps you generate a detailed spec and task breakdown of whatever you’re trying to build before jumping into the implementation.

This guided approach to coding with AI, which all the cool kids are calling spec-driven development, is becoming quite popular among developers looking for ways to build software with a bit more structure and a bit less vibes. I certainly count myself among those in that group, so I thought I’d share my thoughts on Kiro and its approach with you all today.

In Kiro’s Spec Mode, instead of vibing your way through a solution, you start with a prompt about what you’re trying to build, and the AI agent helps you break it down into three documents:

1. Requirements: a set of user stories describing all of the features in detail.
2. Design: a document describing the overall architecture, data model, and other tech-related information about the project.
3. Tasks: a breakdown of tasks, each implementing a subset of the app’s requirements, which can be executed one by one by Kiro or the coding agent of your choice.

I’ve been using Kiro for the last couple of weeks and there’s a lot I like about its spec-driven development philosophy. It’s a great fit for greenfield projects and mid- to large-sized features where you actually care about the quality of code you produce, and the guided process makes it feel more like an actual system and less like a magic box where your results depend on whether you remembered to tell the AI to “ultrathink”.

Of course, SDD is not a one-size-fits-all solution. For UI-heavy work, a non-visual spec is not terribly helpful. And for smaller features or bug fixes, creating a full-blown spec is a total overkill that will likely result in an overengineered solution.

Sometimes, a more lightweight approach to AI-assisted coding is the right way to go. Structured processes like SDD and freeform techniques like vibe coding sit at opposite ends of a spectrum, and a large part of our jobs as the accountable humans in this relationship is choosing which approach is the most appropriate for the task at hand.

I’ve found that most of my day-to-day work falls somewhere in the middle of this spectrum. For UI work, for instance, I like to start with a manual review of the existing code to help me identify the components I’ll need to touch and create, then some light prompting to help me get the structure in place, and then back to manual editing for polishing and pixel-perfection.

For backend/full-stack features, I work close to the right side of the spectrum, perhaps manually creating data models but then letting the AI write the spec and execute the work. For prototyping and experimentation, I lean towards the left side of the spectrum, but not all the way, since prototyping a feature that hooks into an existing codebase still requires quite a bit of context and knowledge sharing.

Every task is different, and I find that I’m relying more on my intuition than on an actual system to figure out what process to follow each time. And maybe that's OK? As Scott Werner puts it in one of my favorite articles from this week, "The future of software development might just be jazz. Everyone improvising. Nobody following the sheet music."

Back to Kiro and its approach to SDD, I have some bad and good news to share.

The bad news is that you can’t download Kiro anymore. Because of “unprecedented demand” and what I can only imagine as a room full of Anthropic servers on fire, the Kiro team removed the download link from their website and replaced it with a link to join the waitlist.

The good news is that Kiro doesn’t have a trademark on SDD (that I know of, please don’t quote me on that), so you can absolutely use this approach with your coding agent of choice. If you use Claude Code, there’s a package you can use to set up a bunch of custom commands that will walk you through the different steps of the process. And if you use a different tool, you can grab the prompts from GitHub, and they should work just as well.

🥊 CODE SHOWDOWN

Optional Chaining vs Guard Clause

Welcome to a brand new section of the newsletter—the Code Showdown 🥊. Each week, we'll look at two small pieces of code that do the same thing in slightly different ways, and we'll let the Frontend at Scale hive mind choose the best approach.

We're kicking things off with a modern classic debate: 🅰️ optional chaining vs. 🅱️ guard clause. Shorter and punchier, or longer but more readable? There can only be one winner. Choose your champion by voting in the poll below—I'll share the results in the next issue.

WEEKLY SNACKS

Links Worth Checking Out

• In sync with the rise of spec-driven development, Sean Grove from the OpenAI team gave a talk at the AI Engineer conference last month, telling us that specs are the new code. Sean says that 80-90% of our work as programmers is structured communication, and specs are the best way to communicate what the software should do. Lots of things "ring true" for me in this talk, but the thing I'm most enthusiastic about is seeing the trend of shipping specs and documentation in version control in addition to the code, rather than letting prompts and instructions get lost in the wind.
• Corbin Crutchley wrote The History of React Through Code—an overview of the past, present, and future of the Internet's favorite UI framework, illustrated with beautiful diagrams and code examples.
• Speaking of React, there's now an official set of docs for the React Compiler, with all the details on how to install it, tips for adopting it incrementally, and answers to our burning questions, like... what does the React Compiler do, exactly?
• ​A Friendly Introduction to SVG by Josh W Comeau is the perfect way to learn the basics of this technology. It's fun, it's interactive, and it has some truly satisfying slide inputs that I may or may not have spent way too much time playing with.
• Jamie Birch spent over a year documenting the many, many, many JavaScript runtimes of the last decade—from Node.js, to Bun, to Cloudflare Workers, and everything in between. If you've found it hard to keep up with all the ways you have to run JavaScript these days, this article is a great way to see exactly why.
• Tom Barrasso wrote a great article about the lost art of building web apps for feature phones and how, thanks to technologies like CloudPhone, these low-end devices have access to features way beyond their capabilities. Tom was my guest on episode 4 of the Frontend.fm podcast, in case you wanted to dive deeper into the fascinating world of flip phones.
• Adam Rackis wrote an introduction to Zustand, the state management library for people who want to use Svelte stores in React.
• A short one from Sophie Alpert: TODOs aren't for doing. Thanks, Sophie. I feel much better about all those TODOs I wrote without even the slightest intention of coming back to them.

🛠️ NPM Install This

• ​es-toolkit — A state-of-the-art JavaScript utility library that promises to be 2-3x faster than lodash.
• ​kibo-ui — A registry of beautiful UI components designed to be used with shadcn/ui.
• ​EsJs — It's JavaScript... but in Spanish. Useful? Not sure. A good way to practice Spanish? Probably. Fun? Absolutamente!

That’s all for today, friends! Thank you for making it all the way to the end. If you enjoyed the newsletter, it would mean the world to me if you’d share it with your friends and coworkers. (And if you didn't enjoy it, why not share it with an enemy?)

Did someone forward this to you? First of all, tell them how awesome they are, and then consider subscribing to the newsletter to get the next issue right in your inbox.

I read and reply to all of your comments. Feel free to reach out on Twitter, LinkedIn, or reply to this email directly with any feedback or questions.

Have a great week 👋

– Maxi