My candid advice:
- Use SvelteKit for better DX+AX (agent experience) with less foot-guns, you can’t go back once you fully adopt async + remote functions.
- Durable stream for AI agents.
If you're on your way to building a billion dollar company that involves a web app, here are some of my notes on architecting the frontend.
if you don't do this, it's probably fine but one day you'll hire someone to fix it but truly that person could be doing some other higher value thing if you make some key optimizations on day 1
you don't even have to learn anything you're gonna tell your agents to do it anyways!
okay here it goes:
- Make your server code generate a openapi spec which then generates all the relevant client side code. Never do this by hand. Typing backend types instead of generating them should be banned
- You need to make a decision on how the client talks to the backend. rest/graphql works in which case please just use tanstack query. other libraries will look similar but tanstack query truly is goated.
- if you want linear style sync setups or offline mode, think about this HARD and architect it from day 1. Bolting this on later is so tedious.
- People like using plain react router but things have gotten a lot better since then. Try their new framework mode or just even use tanstack router. Use route data loaders.
- If you store a lot of state in query params, make that a first class citizen and make sure its type safe. use nuqs or tanstack query.
- Most apps just need a single state management situation for server state and thats it. If you have other bespoke needs, i have quite like zustand and xstate/store.
- If you have a super interactive app where things come in and out of view, theres a lot of frontend state to maintain, music is playing and what not, lock in and learn xstate. Trust me if you wanna keep ur sanity, you need to model ur frontend as a state machine otherwise you're gonna be deep in useEffect hell
- React compiler is here my friends, the days of useMemo and useCallback are gone. Update your priors accordingly
- Tailwind is easy and fun but makes it really hard to maintain a large app with consistent styling. You need a "agent-first design system/component library" but maybe this is a rant for another day
- Don't be afraid to hack your routing library to fit your needs more closely. A lot of apps have "drawers" to show additional info. You should 100% be able to say "here's a route, make it a drawer" and everything should be handled from there.
- Managing loading and error states using isPending and isError is madness. Lean into Suspense and ErrorBoundary.
- Figuring out a blessed path for websockets and SSE on day 1 i think will pay dividends in the long term if you're building anything AI related.
- If you're building a SPA, don't use next.js. it literally makes no sense. Why would you do this.
- Definitely deploy on Cloudflare or vercel. There are other services but trust, there have weird missing features.
- Assuming you build something people want, the next job is to build the factory so it can efficiently build the thing. Act accordingly.
@trq212@markmdev Same, and I’ve already provided evidence and submitted the form, no go.
I’m the owner of the organization, it’s funny that only I got banned.
[email protected]
“Dream big, be ambitious” is no longer just a bold claim.
I’ve used Claude Code, Cursor, Windsurf, Gemini, Codex, Amp, Factory Droid, and Pi since each first launched. Today my daily stack is Claude Code for engineering, Cowork for product management and company ops, Gemini CLI for GCP, and Codex for the hard math problems (we’re building an agent-native graphic editor powered by WebGPU).
Here’s what I’ve noticed: it’s getting harder and harder to estimate any task.
Not because things are slower — the opposite. Everything ships so fast that the old constraints disappear. In the past, as an engineer with limited time, you’d play it safe. You’d pick the pragmatic solution, not the ambitious one. But now with AI, you can reach for the high-stakes approach — and still finish faster than the conservative estimate would have taken.
The ceiling keeps rising. That’s what breaks estimation: it’s not just faster, it’s a different category of what’s possible.
As a CPTO wearing the strategy hat, the PM hat, and the engineering hat — often in the same hour — this is the first time I genuinely feel the “dream big” energy. The feedback loop between idea and execution has collapsed to something almost unreasonable.
Yes, work has intensified. How to avoid burnout in this new reality is a topic for another post.
Happy CNY! 🧧
The boundaries between different roles are blurring.
I have viewed myself as a product engineer for many years, or more precisely, as a problem solver or builder.
Embrace uncertainty, engage with customers, take full ownership of problems, and effectively manage stakeholders. These skills are essential for any knowledge worker.
The Jevons Paradox: Why "Cheaper" Code Means Your Job Just Got Bigger
We are witnessing the Jevons Paradox play out in real-time for software engineers.
The paradox states that as technology increases the efficiency with which a resource is used, the total consumption of that resource increases rather than decreases.
As AI drives the cost of generating code toward zero, coding is becoming commoditized. But this doesn't mean the end of the engineer—it means the explosion of software. We are entering the era of software "written for one person," where the demand for custom tools will skyrocket.
Here is how the role shifts:
1. From Crafter to Orchestrator: Handcrafted code is no longer the bottleneck. The bottleneck is now the "quality of ideas". We are shifting from individual contributors to managers of agent swarms.
2. The Rise of the T-Shaped Engineer: When the "how" becomes easy, the "what" and "why" become premium. You need to understand the business, product management, and stakeholder needs deeper than ever before.
3. Communication is the New Syntax: Your output is now defined by how well you communicate context to an agent. As hinted in recent insights on scaling ecosystems, the win comes from "fixing the flow" of information, not just automating the task.
My advice: Stop identifying merely as a coder. Start identifying as an architect of knowledge. If you can structure your knowledge so it is shareable and understandable by both humans and agents, you become the most valuable asset in the loop.
The "Core Competency" Trap
I was watching Harvey CEO Winston Weinberg discuss scaling, and he asked the question that perfectly diagnosed the friction we felt in our early days:
"Are you trying to automate the core competency?"
Winston noted that if you touch the expert's craft, you hit a wall. But if you solve the "broader ecosystem pain point," you win the enterprise.
We lived this struggle.
When we started, we saw designers drowning in scattered PSDs. But we couldn't pitch "automating design"—that’s their core competency. Instead, we pitched standardization. We automated the tedious resizing and edits so they could escape the update loop.
That won us the users. But to win the organization, we had to go deeper.
We realized the real bottleneck wasn't the file itself—it was the handoffs. It was the chaotic game of ping-pong where briefs, local market checks, and manual data entry collided. The campaign wasn't stuck in design; it was stuck in the friction between teams.
Winston is right. To scale from a tool to a platform, you need two pitches:
1. For the User: "I'll automate the grunt work you hate."
2. For the Exec: "I'll orchestrate the fragmented chaos that slows you down."
We moved from fixing files to fixing the flow.
Hi, I'm David, CPTO of Muse AI.
I'll be sharing more about our learnings and my takes on product and engineering. Stay tuned!
Amp Free just got a BIG upgrade: ~65% faster, *much* smarter model (ads pay well, we 5x'd ALL rate limits!).
Happy weekend coding. Will keep this if our tests and your feedback are all positive.
(`amp update` or update Amp extension to use.)
“But the ecosystem is too small, what about hiring?”
Ecosystem -> most libraries in React, you don’t need them in Svelte
Hiring -> Hire engineers who know JavaScript HTML CSS, not those who only know React.
BTW, Svelte MCP autofixer is the next level, don’t sleep on it.
I try so hard to not dunk on NextJS, but man I have to take this one:
The irony is that having built serious stuff with both SvelteKit & NextJS, SvelteKit is a much better experience. If you are a competent React dev, I'm telling you it is NOT hard to switch over to Svelte
Signals are magical when they click for you, you can never go back. Remote functions are the best RPC implementation in the industry right now (single flight mutations, deep progressive enhancement out of the box, and they feel like just functions).
This is a comparison between sveltekit and tanstack start (I really like Tanstack start! If you want to write React, USE IT): https://t.co/U0GWuu58Eu Just look at how simple, easy to understand, and nice the SvelteKit code is.
"bUt It'S nOT JuST Js" oh no you have to use a "SvelteMap" instead of a "Map" (it has the same interface) and a special if and each block in the markup. WHO FUCKING CARES GET OVER YOURSELF. IT'S AN IF STATEMENT. YOU KNOW WHAT AN IF STATEMENT IS, I'LL TAKE A COMPILER OVER SHITTY TERNARIES ANY DAY OF THE WEEK. and for all you fuckers who love to bitch about "but it has a compiler it's too magical" I know how much you love the react compiler and I raise you "use no memo"
And to be crystal clear: I do not hate nextjs or think less of anyone for using it. There is some genuinely dope stuff in that framework that I really respect:
- "use cache" is a sick primitive
- server components/suspense are more powerful than people give them credit
- the breadth of features they support and their commitment to backwards compatibility is amazing
It is a great framework, we can just do better (sveltekit, solid start, or tanstack start)
The guest blog post is finally out!
"Incremental Migration of a Production React App to Svelte 5: A Practical Guide"
Huge thanks to @itschrisjayden and @budivoogt for accepting my proposal.
Hope you have a good read.
https://t.co/f9mnGYUGyi
It’s great to share our migration story at COSCUP!
I believe it can inspire and support the growth of the Svelte community in Asia!
Also, I met a new Svelte friend @HenryLie17 !
I’ll be giving my first-ever public tech talk at COSCUP 2025—all about Svelte 5!
I hope more people give Svelte a try, make their lives easier, touch grass, and meet new friends.
Start your journey with a smooth, incremental migration 🪄
We're looking for a Special Sponsor for Bits UI + shadcn-svelte to help keep the momentum alive.
- 1.2M+ pageviews/mo
- 70k+ unique devs/mo
If your company supports OSS and wants to partner, let's talk.
The guest blog post is finally out!
"Incremental Migration of a Production React App to Svelte 5: A Practical Guide"
Huge thanks to @itschrisjayden and @budivoogt for accepting my proposal.
Hope you have a good read.
https://t.co/f9mnGYUGyi
I frequently used the "watch" function from the runed package, ultimately replacing all effect runes with it.
It’s so effective that it inspired me to create a “resource” function, also influenced by createResource from Solid.
Made a video going over my main issues with Svelte in 2025:
- Runes have some footguns
- 3rd party support
- One component per file
I've pretty quickly realized that only 1 of these is actually a big issue, vid below
We've been using this internally for more than a month and it's great to have a component-level fetching strategy in Svelte 5!
Now it's available in runed 0.24.0.