DEV Community: Ruben Casas

Chrome Just Dropped Web MCP (and That’s Kind of a Big Deal)

Ruben Casas — Fri, 13 Feb 2026 23:48:55 +0000

The Chrome team announced experimental support for Web MCP landing in Chrome 146

// Detect dark theme var iframe = document.getElementById('tweet-2020903127428313461-968'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2020903127428313461&theme=dark" }

WebMCP is one of those things that sound super niche… until you realise it’s implications for the future of user / machine interaction are bigger than you think!

“agents can now use the web like we do, but faster and more efficiently!” 🤖

But wait... Ai agents can already use websites today using automation tools like Playwright or Puppeteer, so what's the problem?

We’ve spent decades polishing UX for humans.
Now suddenly Agents are using UX that wasn't built for them!

What even is Web MCP?

I would like to explain this with a great video I found of a Robotic Arm landing a plane!

It works! but it is not efficient because the machine is using human controls... a more efficient way is let the computers control the plane directly (autopilot) because the computer doesn't need levers and buttons like humans do.

So Web MCP is basically a plane autopilot for the web. It allows web application to expose functionality as "tools" with natural language descriptions and structured schemas that can be invoked by AI agents. This interaction model is more efficient than expensive and brittle direct DOM manipulation.

Yes web automation... like Playwright but removing the workarounds and "DOM levers" and creating a better standardised Agent Experience

I’ve been playing with this concept since “February last year” (~ 7 Ai years ago)

Last February at Postman (Which in AI time is… basically a geological era. 😅) one of my colleagues created a POC where he connected the Postman User Interface to Cursor via MCP.

// Detect dark theme var iframe = document.getElementById('tweet-1950588464480555218-200'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1950588464480555218&theme=dark" }

The way this worked was by exposing an MCP Server in our Electron Desktop application that agents could connect to directly. The tools exposed had callbacks that performed side effects on the UI (opening a new tab, sending a request, typing in an input box)

The limitation here is that we needed a "server" to expose the tools and this server had to be connected to a running local instance of the application.

Web MCP solves the need for a server and let's the frontend (JavaScript) register these tools. The concept is very similar to our POC and also is very heavily inspired by MCP itself.

Demo vibes: “driving the UI” is cool, but what's the end game here?

Yes, watching an agent drive a UI is cool.

Yes, it makes for great tweets.

Yes, it feels a bit like magic the first time.

But the real question is:

What does this mean for the future of user interaction?

Because this isn’t just a new automation trick; it’s a bridge toward the kind of human machine collaboration I’m envisioning. Web MCP isn’t the destination, but it makes the transition possible.

The mobile boom déjà vu

I remember when the iPhone exploded in the late 2000s, suddenly every business had a hard choice:

Make your site mobile-friendly... Or slowly leak users and revenue

The funny part? We still have websites in 2026 that are not mobile friendly! and work only on desktop and internal enterprise tools are the slowest worst offenders.

So when people say:

“Every website will just add AI / agent support.”

Or in this case... every website will add WebMCP support... My reaction is: maybe. But also… probably not.

Web MCP is exciting. I just don’t think the future is to “retrofit every website with agent UX.”

The real shift: Collapsing Layers

My version of the future of user interaction is all about collapsing layers.

Less:

Human → Agent → UI → Backend → Database

Intent → System → Result

Sometimes with a UI.

Sometimes without.

Sometimes with a UI that’s more like a visualisation than a control surface.

Let me break this into three buckets.

1) Some websites (and UIs) just… shouldn’t exist

Hot take, but:

“The best interface is no interface.”

If something the OpenClaw craze taught us is that Agents today can "just do things"

If an agent can:

Call an API directly
Or fetch structured data
Or trigger a workflow

…then why making it click through 7 screens of UI? Or call 7 different client side tools? that is just latency with extra steps? Those steps were needed for humans, but machines can get the job done without the extra fluff.

However...

This doesn’t mean all UI disappears.

Sometimes:

A button click is faster than a prompt
A form is safer than a fuzzy instruction
A visual overview beats a wall of text

The reality is: UI becomes optional, not default.

2) Go straight to the API (because agents can actually do things)

Everything is an API.

Or at least, everything should be.

// Detect dark theme var iframe = document.getElementById('tweet-2020049883311534415-377'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2020049883311534415&theme=dark" }

WebMCP is great and much better than the current browser automation tools, but in a hypothetical world where architecture is not purely driven by tradeoffs, costs and business constraints...

Then the more interesting future is:

Agent talks to the backend API directly
Backend exposes real capabilities
Frontend becomes a reactive, visual layer

Think:

Sync engines
Local First - state-driven UIs
The UI as a projection, not the source of truth

The UI is no longer “the thing you operate.”

It’s “the thing you look at while things happen.”

But what about "client state"?

I don't think there will be a huge portion of surviving "client only state", it will either not be needed or there will be alternatives like "Local first" with a sync engine.

This future is elegant and exciting... I can only dream!

3) True human machine collaboration

This is the part I’m actually most excited about. Not everything is just a visualisation or an action.

Not:

“You do everything for me.”

But:

“You do some things. I do some things. We meet in the middle.”

I think we’ll see the rise of:

Ai native apps
Interfaces designed for machine / human collaboration
Tools where the agent and the human share context, state, and intent

Not just automation. Not just chat. Not just pretty visualisations.

More like a shared workspace with two kinds of brains in it. A native collaborative canvas.

A great example of this direction is the recent release of the Excalidraw MCP App:

// Detect dark theme var iframe = document.getElementById('tweet-2021284377506742331-35'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2021284377506742331&theme=dark" }
I love this example because it is where I see the most value in Ui that is not just useful but crucial to unlock the power of machines that will come from a combined collaborative effort.

How Web MCP fits into this

If the sections above sounded like I was arguing against Web MCP, here’s the twist: I’m not. I’m arguing that it’s a necessary bridge, a needed improvement, not the destination. It’s how we move from today’s click-driven web to a world of capabilities, APIs, and collaboration. And we can do it without waiting for a perfect rewrite that’s unlikely to happen anytime soon.

WebMCP is the perfect tool to align the current web with the new reality of not just humans consuming it.

But the future of the web and the future of user interaction goes beyond what we can imagine today. Ask someone in the 20s to describe what the future would look like in 100 years because we’re famously bad at predicting real discontinuities they would paint a picture that resembles their current understanding of the world... not today's reality where machines became a fundamental part of our lives.

I Reverse Engineered ChatGPT Apps Iframe Sandbox

Ruben Casas — Thu, 22 Jan 2026 23:59:40 +0000

Before ChatGPT Apps, I Had to Solve The Same Problem!

When I was working on the first MCP-UI Client in production at Postman, I hit a brick wall fast. MCP-UI apps render untrusted code inside an iframe, and most real-world production applications block third party content and enforce it via their Content Security Policy (CSP). If the host only whitelists known domains, how do you load arbitrary apps? You do not! That is the point! 😅

I've been fighting CSPs since my Amex days. We built a dynamic CSP generator for micro‑frontend apps at runtime so each page could assemble the right script-src/frame-src on the fly. That taught me early: The CSP is never the easy part, but it's the part you can't dodge.

So I reached out to Liad and Ido from MCPI-UI and worked with them to come up with a solution on how to allow untrusted third party apps (the point of MCP-UI) while ensuring the host application remained secure, keeping the host's CSP tight and without having to whitelist the whole internet. The solution was a double iframe architecture safe enough for production.

here's the demo!

The ChatGPT Apps SDK

Fast forward to the ChatGPT Apps SDK release. I found a lot of gaps in the developer experience while building ChatGPT apps, i.e having to connect via an ngrok tunnel, setting up a CDN server that was available to the tunnel, caching issues etc. So my first thought was to allow ChatGPT apps to render inside Postman so you can build and debug them faster! (We are probably one of the only MCP Hosts where it makes sense to render ChatGPT apps outside of ChatGPT).

This is the video of explaining the DX gaps and how Postman MCP inspector support for chatGPT apps solves the problem

Hmmm, that Looks familiar 🤔

For this I had to figure out how the ChatGPT Apps SDK client implementation worked, with no public facing documentation! (nobody apart from ChatGPT needs this! 😅). I started poking around the dev console inside ChatGPT and saw a very familiar setup. Same idea: a sandbox proxy iframe wrapping an inner iframe, with a message bridge in the middle! I had already built this once for MCP-UI, so I reverse engineered their flavor and used it to unlock ChatGPT Apps inside Postman.

Iframes, magnets How do they work?

If your host enforces a CSP, you cannot just drop in any third-party iframe frame-src is an allowlist. An allowlist of "every MCP app that will ever exist" is not a thing.

Also, you cannot just disable the CSP. That is a non starter for security teams. So the only way out is a fixed, trusted domain that the host can allow, and then a controlled way to render the actual app behind it.

This is the core trick. Without this, MCP‑UI apps were basically dead in real enterprise hosts.

The double-iframe trick

The proxy is not a real proxy server. It is a static HTML page hosted on its own origin different to the host's origin. The host only whitelists that one domain. Everything else is controlled by the sandbox iframe.

Host loads the proxy on an allowlisted domain.
Proxy signals ready; host posts HTML + CSP metadata.
Proxy creates the inner iframe, sends the HTML via document.write() and relays messages.

Why the double iframe matters

You need two layers to make the security model work:

1) The outer iframe (sandbox proxy) is on a different origin and sandboxed with a configured CSP
2) The inner iframe hosts the untrusted app with a relaxed CSP

The CSP can also be enforceable per app. The MCP server (app) can provide a custom CSP to the sandbox.

The spec caught up (and improved it)

With the launch of MCP Apps, this architecture is now formalised and accepted as the default security model for third party UI via MCP.

The MCP Apps working group took the learnings from MCP-UI and ChatGPT apps and added to the spec:

Host and sandbox must be different origins
Sandbox must be allow-scripts allow-same-origin
Proxy must enforce CSP derived from UI metadata
Proxy must forward messages between host and guest

The MCP Apps spec also added the use of metadata on UI resources so a server can declare what it needs:

connectDomains for API calls
resourceDomains for scripts, styles, images, fonts
frameDomains for nested iframes
baseUriDomains for base tags

The host then builds CSP headers from that list. If the list is empty, defaults are restrictive.

Conclusion

The CSP is annoying, but it is also the best guardrail we have for untrusted UI. You do not remove it. You configure it! and the double iframe trick was perfect for this use case!

Disclaimer: This is by no means an obscure / innovative technique, it is what most of the industry uses in these cases for untrusted embedded UI. ChatGPT told me that during my research! 😂

If you want the deep docs, start here:

The Reality of AI Coding in Production (and My Poor Man’s Setup)

Ruben Casas — Sat, 10 Jan 2026 23:52:23 +0000

For the past few weeks, My timeline has been filled with a lot of developers showcasing (and showing off) the projects they built during the holidays using claude code and the insane progress and that both Opus 4.5 and Codex 5.2 have made to "solve software engineering"

// Detect dark theme var iframe = document.getElementById('tweet-2009161942339080204-484'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2009161942339080204&theme=dark" }

If you feel FOMO, overwhelmed, don't know where to start... you are not alone! This stuff is moving so fast that is normal to feel a bit of whiplash... but fear not, this piece of advice is still very relevant:

Keep it simple… just talk to it!

Here is the current way I build with Ai at work, this is what works for me... for production code that cannot be "slop", that needs to be reviewed and approved by co-workers and that has to deal with the realities of production software, like large brownfield codebases, trade offs, business priorities and tech debt...

Caveats / Constraints Working with Production Software

The way I use AI to code on a greenfield project, differs significantly from coding on old / production codebases. Models can now work effectively in large codebases, but there are constraints we should aware of and improvements to the code itself that you can make and could increase speed and output considerably.

Spaghetti Code

Models that have to traverse large parts of unrelated code bloats the context window, is slow and token inefficient. Reducing circular dependencies and encapsulating components, functions, modularity, great boundaries and architecture has ever been more important!

If your application is rotten, it will also rot your context!

To Rewrite or Not Rewrite

When models context windows fill, they use something called "context compaction". I can use the same analogy with old codebases, when they fill up with tech debt and old decisions that are no longer relevant, sometimes is better to capture the intent, summarise the current state and commit it into a new session (some people call this a "rewrite") and guess what! it's never been cheaper to rewrite something!

Missing Verification Loop

Models that cannot verify their work, require more steering and cannot work continuously. Human verification is ever more important but that verification needs to be committed and saved (via tests, lint rules, type checking, agent context) for future changes. Models are very good at writing tests! but they will not replace the true verification which is when humans decide if the system is "correct" or not.

Testing Chicken and Egg paradox

Code that is not modular is hard to test, missing tests break the verification loop which produces code that is difficult to change and test. To break this vicious cycle, the code needs to be tested (human verified and that committed) and closing the verification loop to ensure new code and improvements can be safely added by humans and coding agents in the future.

Code is not the bottleneck anymore, verification is!

“If your pull request doesn’t contain evidence that it works, you’re not shipping faster - you’re just moving work downstream” - Addy Osmani

Agents can produce reliable code fast, ensuring that code is correct and it does what is intended without breaking the rest of the system is now the bottleneck. The major culprits include code reviews, manual testing and slow automated testing. Improvements to spedup and unblock these areas will improve the velocity of shipping code to production.

The Kitchen Sink paradox

Models are like humans if they see a dirty sink they will just add another plate on top!. Models will not refactor and make the code better unless you tell them to. Every time you make a change, also ask the model to ship an improvement to that part of the code especially around verification loops (test, types etc)

Risk of change is a limiting factor

Code is cheap now, we should try more things and not be afraid of significant changes and improving existing code just because it is “old” or too long / complex to understand. The problem with changing too many things in a established codebase / product is the risk of regressions. Tight verification loops are key and could mitigate the risk. But even with excellent testing practices (which are rare) more code, more changes, means more bugs, more risks which businesses need to accept.

How I Actually Use Ai Coding In My Day Job

With those constraints in mind, this is how I actually apply Ai in my daily work, not for demos or side projects, but inside real production codebases.

This is not a guide... all of these are subjective and matter of preference

My Setup

I use both Codex and Claude Code and use them in parallel or interchangeably depending on the task.

I use the VSCode / Cursor IDE extensions one on each side, easier to add context and see the code and make adjustments.

I rarely use Cursor Agent Mode or Composer these days. (Even if you use Opus 4.5 there, the harness matters and I get better results with Claude Code CLI or the extensions).

There are still some features in Cursor that I find handy, like browser editing especially useful for frontend coding.

I run both at the same time on different parts of the code or a complementary task and often ask Codex to review Claude’s work and make changes to it with follow up prompts.

IDE Extensions! Blasphemy! Get out of here! 😂 stay with me!

Codex GPT 5.2 (thinking high)

Codex doesn’t require a lot of context, planning or complex prompts it usually gets it right first time with the right pointers but it is very, very slow!

I use it mostly for complex tasks that require deep thinking:

Complex bugs
Strong types
Strong data accuracy (convert or scrape data without hallucinations)
Code review
Refactors.
Explaining the codebase or the code

Favourite Follow up Prompts:

Is there anything we should refactor?
Simplify this file
This works but are there any maintenance, security, architecture issues
This works but is there a better way of achieving the same outcome? show me options

Claude Code / Opus 4.5

Claude Code with Opus 4.5 is very fast and accurate. It sometimes requires more handholding than codex. It will be very eager to start implementation and will sometimes ask you questions and add a “plan”. You can also trigger “plan mode” and create it manually. I have mixed results using plan mode, I like it, but for established codebases I prefer smaller encapsulated changes + Codex usually works better even without a plan.

I use it for most coding tasks:

New features
Adding tests / types
Creating React Components
Quick prototypes

Favourite Prompts:

Design an interface for a library
Implement a similar method based on this pattern
Create a component to do X (it will one shot it with great UX)
Rename this function / file and update all references and tests

Claude Code and Codex CLIs

I also have the CLIs installed! Allegedly they have a more powerful harness and some features make it first to the CLIs and the IDE extensions lag behind.

Working with the IDE extensions is a single threaded task where you need to steer the models constantly, look at every single line of code produced, make inline changes to the code test and verify. The limitation is you can only have one concurrent session at the time (unless you clone the repo into different folder and have a separate IDE window, which I do sometimes)

With the CLIs you can do more parallel hands off work (don’t confuse this with “Vibe coding” you still need to verify, read the code and ensure it does what is intended)

They also require you to think about conflicts and branching / worktrees stuff if you have them working concurrently on the same codebase. Surprisingly sometimes they stay clear of each other but is not always the case. I find this a faff and avoid it unless I really want to push to do a lot of things at the same time.

Not all types of work and repositories are suited for parallel coding with CLIs

I have found them useful in the following cases:

Throw away POCs
Migrations (see Ralph Loop coding)
As a starting point before transferring to hands on in the editor
Well defined work in projects with strong verification loops (tests)

Ralph Loop Coding

The technique everyone is talking about... I started experimenting with it and it seems like the end game for hands off / parallel automated work.

Codex is really good at one shot single prompt small migrations but for longer, more complex and repeatable tasks (think what codemods used to do poorly) running the CLIs in a loop could produce incredible results.

The trick is to make the model work on one single thing at the time stopping, starting a new session (after committing and saving context), picking the next thing and so on. effectively “hacking the context window”. The main prerequisite is a strong verification loop (tests) a well defined problem with a clear outcome and a very detailed plan (PRD style doc) that splits the work into small chunks. without these, this technique is not only not effective at all but also very wasteful and token inefficient!

I tried the claude code built-in plugin... and was very disappointed! It kept killing my memory even when restarting and during the first iteration!

// Detect dark theme var iframe = document.getElementById('tweet-2008511712060993564-69'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2008511712060993564&theme=dark" }

But the Claude plugin doesn't make it justice... If you want to see the comparison between the two and really understand the subtle but big difference when running the loop inside the harness vs outside watch this great video from Chief Wiggum himself, creator or Ralph:

Miscellaneous / Tips and Tricks

What about MCPs? (use them only when needed. i.e the chrome / playwright when writing frontend code, Context7 for documentation etc)
What about Cursor Rules, Agents.md, Claude.md? Models are getting better at finding the right context themselves but if they keep making the same mistake over and over, then it is time to add it to the .MD rules files. (theres' a nice gh action that could be triggered during code review to update those)
Voice Mode: I started using Wisprflow more but still like typing so I can order my thoughts
Context Window: you shouldn’t worry too much these days (Codex is very good, Claude has auto-compact) but I recommend starting a new session as many times as possible to reset your context window (without loosing context of course)
Automate repetitive tasks: Claude Code supports slash commands and subagents to automate repetitive tasks (push commit, review, tests etc)

Conclusion

You are not behind, keep it simple, just give it a go and improve everyday... anyway... it sounds better when it comes from Sunil:

// Detect dark theme var iframe = document.getElementById('tweet-2007842239012126805-590'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2007842239012126805&theme=dark" }

Side Projects? I don't have time for that!

Ruben Casas — Thu, 08 Jan 2026 23:25:51 +0000

The importance of Side Projects

When I was doing my Masters degree I used to come back from my part time job at 7pm and start working on side projects until 11pm. I didn't even have time for cooking so I used to get a chinese takeaway and start playing with whatever new technology I was interested in.

Proof of how many fortune cookies I collected in those days in a single week 😅

That's why I recommend to anyone getting started in tech to do things on the side, I learned more from side projects than the stuff I learned during my Master's degree which I had to pay £13k for!

Time? I don't know that Pokemon!

Fast forward a few jobs and a family and I found less and less time to do things on the side, I kept blogging and learning things but not at the same pace and consistency than those early days. It is not like I didn't want to, I felt guilty sometimes but I also learned that you should prioritise family and other things which are more important.

// Detect dark theme var iframe = document.getElementById('tweet-1965143376422207757-163'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1965143376422207757&theme=dark" }

However, this year I found the joy of building things, I still don't have time but thanks to Ai and coding agents I found that spending only a few hours has a great compounding effect!

Gergely from The Pragmatic Engineer puts it nicely:

| "I get a lot more work done on my side projects, with far less effort"

// Detect dark theme var iframe = document.getElementById('tweet-2006301134236135708-333'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2006301134236135708&theme=dark" }

The tipping point for me was the release of Codex (and Claude Code). All I needed was an idea (not even a good one, just some half baked thoughts) and a few hours some time just a few minutes each night to achieve great outcomes.

All of those unfinished projects from the wishlist finally found someone who could complete them (the clanklers... not me!)

// Detect dark theme var iframe = document.getElementById('tweet-1989473815983001613-253'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1989473815983001613&theme=dark" }

Too Much Talk, Show me the stuff!

Here are the things I shipped, with some small amount of effort in the second half of this year (2025). Working between 10pm and 12am while my wife and the kids are asleep and still spending an unhealthy amount of time on twitter:

1. Weather Agent with MCP-Ui

I have been playing with MCP-UI since it was launched and wanted to sprinkle a little bit of generative UI on top. So I built a weather agent that gets the current temperature and styles it on the fly with any style provided by the user i.e Windows 95 retro

Tech Stack:

Postman Flows
MCP-UI
Weather API

Youtube Video: https://www.youtube.com/watch?v=z1fD9-1R_rw

2. Time Machine with Nano Banana!

The Launch of Nano banana definitely changed my Vibe Coding game, I built most of my prototypes with it and pushed my imagination. I built a website that allows you to transport you back in time just by uploading your picture:

Website: www.iwasthere.today
Youtube Video: https://www.youtube.com/watch?v=y9dDVLVIGTA

Tech Stack

React + TypeScript
Cloudflare Workers + R2 Storage
Postman Flows
Nano Banana (Gemini Flash Image 2.5)

3. Shopify Store MCP-Ui.shop

I didn't think that in 2025 I would launch my own e-commerce store, but here we are! One of the most compelling use cases of MCP-Ui (MCP Apps) is e-commerce. so I decided to launch my own shop to sell t-shirts that can be purchased using MCP and any of the clients that support MCP-UI

Website: https://mcp-ui.shop/
Youtube Video: https://www.youtube.com/watch?v=cM6nYANYxFc

Tech Stack

Shopify
MCP StoreFront
MCP-Ui
Goose

4. Children's Book: "The Adventures of Fluffy"

I vibecoded a book from scratch for my 4 year old who's obsessed with her stuffed dog. She came up with the story, the locations, we generated the images together and then stitched it up using Canva. This was a great time bonding with my kiddo and showing her what's possible (anything) with technology. We have created 3 books now!

Tech Stack

Nano Banana
Gemini Pro
ChatGPT
Canva

5. TBPN Video Generator

My friend Tobin South nerd snipped me one night, after he created a picture of the tbpn style announcements for Liad and Ido joining Monday.com so I decided to build a TBPN generator but not for images but for video!

It creates a comedy story for when someone joins a company and generates a slide show on the fly using "generative UI / Video". I also ended up adding a bunch of templates including one for when you attend a conference and you meet someone in person.

Website: https://tbpn-video-generator.vercel.app/
Youtube Video: https://www.youtube.com/watch?v=42B_ia64QZU&t=4s

Tech Stack

React + Typescript
React Router
Remotion
Postman Flows
Nano Banana

6. ChatGPT App to buy T-Shirts

When ChatGPT launched apps, was a great moment of validation for MCP-UI! I decided to build my first app on top of my Shopify Store and allow people not just to buy the t-shirts, but also try them on, with some Ai magic ✨

Youtube Video: https://www.youtube.com/watch?v=XHgxGczwERo

Tech Stack

NextJS
ChatGPT Apps SDK
Postman Flows
Nano Banana
Shopify Headless CMS

7. Postman Welcome Video

After building the TBPN Video generator, I decided to make something a bit more useful with it. So when someone new joins postman, there is a welcome message that gets posted in one of the public slack channels. When I add the 📽️ emoji reaction to the message. An automated workflow takes the person who joined information (profile picture, job title, etc) summarises the message and creates a personalised welcome video.

Website: https://postman-new-hire-video.vercel.app

Tech Stack

React + Typescript
React Router
Remotion
Postman Flows
Nano Banana
Slack API

8. City Quest: The First Original ChatGPT Game!

I joined the TanStack Start Hackathon as the push I needed to finally build an idea I came up with during my first visit to NYC early in the year. The result was this ChatGPT App game, which I think is the first of its kind. It helps players discover their city with ChatGPT as their companion while collecting quests and getting a personalised Instagram ready to share video at the end.

I played it with Erik from Code Rabbit and a few friends after AI Engineer conference and we had a ton of fun! we even rescued people stuck in a lift and ended up singing Karaoke.

A newly added feature was "Kitze Mode" to conquer all the fast food places in America with TheKitze as your coach! 😂

Website: https://city-quest.netlify.app
Youtube Video: https://www.youtube.com/watch?v=MJ5RtWxOiZc&t=30s

Tech Stack

TanStack Start
ChatGPT Apps SDK
Convex
Nano Banana

9. My Personal Site

I finally decided to rewrite my personal site, the previous one was embarrassing, not maintained and on a broken version of NextJ 10. I refused to do it for a long time until I had an innovative idea but at the end, I applied the rule of side projects and vibe coding. Shipping something is better than shipping nothing... hopefully I will include cool easter eggs and ideas to my site... but I am quite pleased with it.

Website: https://infoxicator.com/

Tech Stack

TanStack Start
Netlify

Conclusion

There are a few learnings and a few caveats:

** Compounding is powerful!**
Every project builds on top of the one before... the stack the learnings the ideas can be combined.
Don't over do it!
I started to over do it sometimes... even vibecoded on a plane at some point but it was because I was enjoying it too much. Suffice to say it could become a problem, always prioritise family and other things...

There's always time!

During the holidays I decided to intentionally take a break so I could play Ghost of Yotēi so it is always about what you want to prioritise and what's important

// Detect dark theme var iframe = document.getElementById('tweet-1996343569456697721-273'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1996343569456697721&theme=dark" }

I finished the game now, so don't worry my Vibe Coding career is safe! and onto 2026!

Rethinking UI in Agent Driven Systems

Ruben Casas — Thu, 24 Jul 2025 19:38:20 +0000

Chat interfaces have surged in popularity, becoming a common entry point to intelligent systems. But while text excels at expressiveness and simplicity, it's often limiting for structured interactions. Booking a meeting, selecting options, or reviewing results all demand more than just words. The immediate solution that comes to mind is to render traditional user interfaces (components) inside the agentic system, but what does that look like in practice?

What are the viable strategies for embedding UI into chat-driven workflows? And even better: should you be embedding UI at all? If so, will these new approaches eventually replace traditional interfaces, or simply augment them?

In this article, we are going to look at the three emerging strategies for returning UI from agents:

First-party UI: Component rendering from within the agent’s codebase
Third-Party UI: Server-generated and delivered via MCP
Generative UI: Let the LLM create interfaces on the fly

These modes reflect not just technical choices but broader design philosophies about how software should be delivered when the interface becomes a dialogue, not a static representation of data.

Each approach solves the "how do I show a button" problem differently. In fact, they solve different problems altogether, but it’s easy to mix and confuse these approaches due to their similarities.

1. First-Party UI Rendering: Components from Within

This is the simplest to understand and implement if you own both the agent and the application frontend.

The tool (or function) returns a UI descriptor that directly maps to a component you already have in the client codebase. In some systems, this means passing back a component name and props. In others, it may be fully serialised elements.

// Example: a tool response returning a UI
{
  type: "tool-response",
  tool: "getUserApproval",
  content: ["ok", {...}, {
    type: "custom",
    component: "ApprovalBanner",
    props: { user: "alice", reason: "dangerous command" }
  }]
}

This flexibility not only allows for reusing and rendering existing UI, but also unlocks new interaction patterns like "driving the UI from the agentic system."

Here is an example of what this looks like in practice:

This demo showcases the agent driving the user interface like if it was a human agent. It opens a requests in a new tab, changes some scripts, sends the request and then displays the results in a nicely formatted component.

👉 Full resolution Video

Pros

Total control: You can render any UI the client app already supports.
Feature parity: Complex interactivity (modals, animations, hooks) are possible.
Simple for internal tools: Tools can assume the client knows how to handle specific components.

Cons

Tight coupling: Bespoke and custom-built. It only works in the client that implements it.
Hard to externalise: You cannot expose these tools to third-party systems via MCP or otherwise.
State and serialisation: To reconstruct the UI from previous conversations, components must be stateless. They need to rebuild state from the data stored in the conversation and be passed as props.

Ideal for:

Web apps shipping their own agentic interfaces inside their product
Agents that need to “drive” the UI and take steps on the user’s behalf

Examples:

Postman Agent Mode
Cursor
TLDraw Agent Mode

2. Third-Party UI: Server-Generated UI Delivered via MCP

The rise of the MCP protocol has made it easier for third-party tools to plug into assistant ecosystems, enabling remote invocation and integration. However, one limitation is that most implementations today focus on returning plain text. That works well for many workflows, but it quickly breaks down when richer user interaction is needed.

What if a third-party MCP tool wants to return a map, an interactive widget, or a custom data viewer? That's where third-party UI comes in.

Instead of returning components, the tool responds with plain HTML or structured and serialised components that describe what should be rendered. The client, which speaks the schema format, interprets and renders the UI. This adds an interactive layer on top of otherwise text-only conversations, unlocking a much richer experience.

Frameworks like mcp-ui, Adaptive Cards, and Remote DOM are converging here:

The server describes the what, and the client decides how.

Plain text example:

{
  "type": "resource",
  "resource": {
    "uri": "ui://my-component/instance-1",
    "mimeType": "text/html",
    "text": "<p>Hello World</p>"
  }
}

Remote resource example:

{
  "type": "resource",
  "resource": {
    "uri": "ui://analytics-dashboard/main",
    "mimeType": "text/uri-list",
    "text": "https://my.analytics.com/dashboard/123"
  }
}

Remote DOM example:

{
  "type": "resource",
  "resource": {
    "uri": "ui://remote-component/action-button",
    "mimeType": "application/vnd.mcp-ui.remote-dom+javascript; framework=react",
    "text": "\n  const button = document.createElement('ui-button');\n  button.setAttribute('label', 'Click me for a tool call!');\n  button.addEventListener('press', () => {\n    window.parent.postMessage({ type: 'tool', payload: { toolName: 'uiInteraction', params: { action: 'button-click', from: 'remote-dom' } } }, '*');\n  });\n  root.appendChild(button);\n"
  }
}

This schema uses the official MCP specification. There is a proposal under discussion to add a specific type of resource for UI, however the mcp-ui library is full spec compliant.

The client receives the response from an MCP tool invocation, reconstructs the UI, and renders it in the agent’s host using the preferred rendering method. The client ensures the UI is mounted inside a secure and sandboxed environment like an iframe or a worker.

To match styling, reuse component libraries, and support frontend frameworks of choice, tools like Remote DOM help bridge the gap while keeping the server implementation generic.

This demo uses the mcp-ui library to send UI components from a shopify store via the Model Context Protocol (MCP)

👉 Full resolution video here

Pros

Extensible: Builds on top of existing schema and technologies.
Stateless: UI components can be serialised and sent across the network.
Client agnostic: As long as the client supports the schema, tools that return UI can be used by any client.

Cons

Limited expressiveness: App-specific interactions are difficult to support.
Styling constraints: Custom theming and layout are limited and harder to implement.
Authoring complexity: The MCP server must serialise components to comply with the schema.

Ideal for:

Existing MCP tools that want to enhance user experience beyond text.
Products with plugin ecosystems.
E-commerce and agentic systems where tools don’t have direct access to the frontend.

Examples:

MCP-UI: Shopify Store Front MCP servers
Postman MCP Inspector

3. Generative UI:

This is the most speculative and also the most exciting approach. Instead of explicitly returning UI, the LLM generates it directly from the conversation context, injecting the data into interactive elements, not just for display, but for action.

What makes generative UI especially powerful is how it mirrors the trend of vibe coding where users or agents compose small applications on the fly to solve personalised tasks. This goes beyond prompting or one-off responses. It becomes a way of assembling functionality contextually.

With the right schema and execution model, generative UI isn’t just a mockup, it becomes a live surface inside the agentic loop: capable of executing functions, calling tools, validating input, and even interacting with third-party systems via the MCP protocol.

Imagine a scenario where the agent, based on context and goals, produces a multi-step workflow UI part form, part calendar, part dashboard. The user fills it in, submits it, and the agent takes action, all within a single conversational pass.

This bridges the gap between unstructured input and structured actions. It unlocks a middle layer of interaction too fluid for hardcoded UIs and too structured for plain text.

User: "I want to send flowers to someone in Berlin on Tuesday"

The LLM could generate a UI like so:

Generative UI will most likely be implemented as an extension of first-party UI due to the control and sandboxing requirements involved in running generated code safely. An interesting approach could involve using “sampling” from the Context Model Protocol specification to dynamically request UI from the active agent.

That said, third-party tools can also leverage generative UI. Backend systems can use LLMs to create UIs on the fly and return the resulting schema or code as a valid response—so long as it complies with what the client expects.

This demo by Evan Bacon uses an LLM to interpret natural language queries and determine which components to display based on the responses.

Pros

Flexible: The same agent can generate different UIs based on context.
Emergent UX: Users help shape the flow rather than being constrained by predefined templates.
Integrated orchestration: Enables LLMs to drive workflows with third-party tools via standard protocols.

Cons

Validation overhead: Generated UIs must be schema-validated for safety.
Fragility: LLMs may hallucinate structure or mislabel schema fields.
Debugging challenges: Behavior is non-deterministic and hard to trace.

Ideal for:

Visualizations: Let users view data in a format that suits them.
Flexible interaction: Move beyond static forms to dynamic UIs tailored in real time.

Choosing a Strategy

You don't need to pick one. These strategies are complementary and solve different use cases.

At Postman, the agentic system we’re building supports a mix of all three:

First-party UI: React components in Postman Agent Mode display code editors, visualizations, approval flows, and deterministic workflows via tool call chaining.
Third-party UI: Using the mcp-ui package to render UI from MCP servers. This supports both our Agent Mode and the MCP Inspector tool for debugging UI responses.
Generative UI: We're exploring this space with our “Flows agent” that dynamically generates UI consumed by our Agent Mode.

Final Thoughts

Just like designers had to rethink shape and granularity in the age of mobile, we now need to rethink UI in the age of agents.

Not every assistant needs to return UI. But once it does, the architecture behind that decision becomes a core part of your product surface. It affects what tools you can build, how partners can extend your system, and how safely and reliably users can interact with it.

Ooops! nearly forgot… I didn’t dive deep into the question should you be embedding UI at all? That probably deserves a separate article.

Introducing a New Web Vital: Time to Usability (TTU)

Ruben Casas — Tue, 11 Mar 2025 21:58:56 +0000

Introducing a New Web Vital: Time to Usability (TTU)

When thinking about application performance, the go to strategy is to "Measure, Measure, Measure." But not all metrics are created equal. Tools like Lighthouse and Core Web Vitals provide a great high-level view and are useful for debugging, but they don’t capture performance issues specific to your app’s core functionality.

What if we had a metric that measured when users can start using your app, not just when the page loads, but when it becomes truly usable? That’s why I’m introducing Time to Usability (TTU): a new way to measure performance that focuses on real user experience rather than just technical readiness.

In this guide, I’ll show you how to use the Performance API to instrument your app, break down every millisecond and capture TTU to optimize performance where it really matters.

How to Measure TTU:

Not everything that can be measured matters when applied to your application context. Traditional performance metrics like First Contentful Paint (FCP) or Largest Contentful Paint (LCP) tell us when content appears on screen, but they don’t indicate when an app is actually usable.

To measure TTU, you can ask the following question: How quickly can users start using the app’s core feature?

Some real-world examples:

• VS Code → How fast until the user gets a blinking cursor and can start coding?
• Slack → How fast until the user can open a chat and send a message?
• Postman → How fast until the user can send an API request?

Unlike generic performance scores, TTU is application-specific. It shifts the focus from technical implementation details to real usability, helping developers measure what truly impacts user experience.

How TTU Differs from Time to Interactive (TTI)

I can hear you thinking, hold on a minute, we already have a metric for that is called Time to Interactive (TTI)

Both Time to Usability (TTU) and Time to Interactive (TTI) measure when an app becomes usable, but they focus on different aspects:

Metric	What It Measures	Why It Matters	Limitations
Time to Interactive (TTI)	When the page is fully interactive (event handlers registered, main thread idle).	Ensures the app won’t feel sluggish when users try to interact.	A page can be "interactive" but still not functional for its core task.
Time to Usability (TTU)	When users can start using the app’s main feature (e.g., sending a message in Slack, coding in VS Code).	Aligns performance measurement with real-world usability.	Requires application-specific instrumentation—generic tools don’t track it automatically.

While TTI ensures technical readiness, TTU reflects real usability and helps developers optimize what actually matters to users.

Instrumenting Your App with Performance Markers

One of the best places to start is app launch performance, the one thing every single user experiences and directly impacts the first impression and usability.

The Performance API’s mark and measure methods let us place custom timestamps at key points in the user journey and calculate the time between them.

Collect the Data Using `performance.mark()`

Just like adding console.log() statements to debug your code, you can use performance markers to log how long key operations take. The Performance API’s mark method allows you to timestamp specific points in your app’s execution.

As an example, we’ll divide the app launch process into five key phases and then aggregate them into Time to Usability (TTU):

Platform Initialization – App container, browser, or runtime initialization. (As an example, in an Electron App, this is the main process bootstrap until the renderer process initialises)
Downloading, Parsing & Compiling JavaScript – First page load, downloading and executing scripts.
Fetching Data – Making API calls to retrieve necessary data.
Rendering the Critical Flow – Displaying the UI needed for interaction.
Core Feature Ready – When the main feature is rendered and fully usable (TTU).

Here’s how you can track each phase of app launch using performance.mark():

// Mark platform initialization start
performance.mark("platform_init_start");

// Simulate platform setup
await setupPlatform();
performance.mark("platform_init_end");

// JavaScript loading phase
performance.mark("js_loading_start");
await loadJavaScriptBundles();
performance.mark("js_loading_end");

// Fetching data phase
performance.mark("fetch_data_start");
await fetchInitialData();
performance.mark("fetch_data_end");

// Rendering the critical flow
performance.mark("render_start");
await renderCriticalUI();
performance.mark("render_end");

// Mark when core feature is ready (TTU)
performance.mark("core_feature_ready");

// Aggregate total TTU
performance.measure("Platform Initialization", "platform_init_start", "platform_init_end");
performance.measure("JS Processing", "js_loading_start", "js_loading_end");
performance.measure("Data Fetching", "fetch_data_start", "fetch_data_end");
performance.measure("Rendering", "render_start", "render_end");
performance.measure("Time to Usability (TTU)", "platform_init_start", "core_feature_ready");

// Log all performance measures
const measures = performance.getEntriesByType("measure");
measures.forEach(entry => {
  console.log(`${entry.name}: ${entry.duration.toFixed(2)}ms`);
});

You can also see the performance markers using Chrome Developer Tools under the Performance tab -> Timings when running a performance profile.

Measuring performance locally is useful, but real-world performance varies across devices, networks, and user environments. To get meaningful insights, you need to send this data to a telemetry, logging or analytics platform where you can aggregate, analyze, and visualize it.

For example, you can send the collected TTU data to an observability tool or a custom logging service.

Measuring Page Load Performance with The Resource and Navigation Performance Entries

Once you have identified the bottlenecks, you can go deeper. For example, inspecting the page navigation and the resources (i.e JavaScript assets) that are downloaded during the initial page load.

1. Measuring Document Load with PerformanceNavigationTiming

The PerformanceNavigationTiming API gives you a detailed breakdown of the navigation process, from the first request to when the page is fully loaded:

const navigation = performance.getEntriesByType("navigation")[0];

console.log(`DNS Lookup: ${navigation.domainLookupEnd - navigation.domainLookupStart}ms`);
console.log(`TCP Connection: ${navigation.connectEnd - navigation.connectStart}ms`);
console.log(`TTFB (Time to First Byte): ${navigation.responseStart - navigation.requestStart}ms`);
console.log(`DOM Load: ${navigation.domContentLoadedEventEnd - navigation.startTime}ms`);
console.log(`Page Load: ${navigation.loadEventEnd - navigation.startTime}ms`);

2. Measuring Individual Resources with performance.getEntriesByType('resource')

Beyond document load times, you can track how long each JavaScript file, CSS, image, or API request takes:

const resources = performance.getEntriesByType("resource");

resources.forEach(resource => {
  console.log(`${resource.name}: ${resource.duration.toFixed(2)}ms`);
});

This is especially useful for tracking third-party scripts, which can slow down page performance.

3. Advanced: Identifying Network vs. Service Worker Loads with Server Timing API

A more advanced technique is using a Server-Timing header to tag responses. An example use case is to differentiate network loads (cache misses) vs. service worker cache loads (cache hits).

The Service Worker can add a custom header to all requests that are intercepted and served from it:

Server-Timing: cache-hit;desc="Loaded from Service Worker"

And retrieve this information for each resource (asset downloaded by the page)

const resources = performance.getEntriesByType("resource");

resources.forEach(resource => {
  if (resource.serverTiming.length > 0) {
    console.log(`${resource.name} loaded via: ${resource.serverTiming[0].description}`);
  }
});

This is one of the use cases, but you can also send a custom server timing header to capture database read/write operation times, CPU time, and file system access.

Synthetic Monitoring vs. Real User Monitoring (RUM)

Performance isn’t a one-time optimization, it’s an ongoing process. This is where Synthetic Monitoring and Real User Monitoring (RUM) complement each other.

• RUM gives you real-world data from actual users, but it’s a lagging metric, it tells you what happened after users experience an issue.
• Synthetic Monitoring proactively runs tests in controlled environments, helping detect regressions before they impact users.

The good news? The performance markers are useful in both Synthetic tests and Real User Metrics, you just need to send the data to your telemetry systems.

Conclusion

The bad news? There are a couple of caveats to keep in mind:

The Performance API itself has a small overhead. While minimal, instrumenting too many markers or collecting excessive data could impact performance. However, the benefits far outweigh the cost, the insights you gain will help you optimize the real bottlenecks in your app.
Measuring TTU is a manual and custom process. Unlike generic performance metrics, Time to Usability (TTU) requires thoughtful instrumentation based on your app’s core functionality. There’s no one-size-fits-all solution, it’s up to you to define and measure what truly matters for your users.

With the Performance API, you have the tools to go beyond generic benchmarks and truly understand what makes your app feel fast. By combining custom markers, resource timing, and telemetry, you can continuously measure, optimize, and improve your app’s real-world performance.

Performance isn’t just about numbers, it’s about user experience! 🚀

Embracing Public Speaking: From Fear to Stage

Ruben Casas — Fri, 19 Jul 2024 12:06:09 +0000

Recently my dear friend Kent C. Dodds posted a video encouraging people to attend conferences and get into public speaking to supercharge their careers.

// Detect dark theme var iframe = document.getElementById('tweet-1811059773359673721-725'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1811059773359673721&theme=dark" }

But what if you have never done it before or cannot imagine yourself standing on a stage talking to a large crowd?

I am not a perfect speaker or an expert, but I love sharing my passion and knowledge with others. Let me walk you through my journey and share some insights on how you can make your mark in the world of conferences and meetups.

My First Steps into Public Speaking

I began my journey in 2020, an awesome year to get into public speaking! 😅. I didn't start on a big stage or big events, I started by reaching out to communities and participating in online meetups. My friend Niall Maher trusted me (not sure how!) and invited my colleague Nelly and me to speak about Micro-Frontends at the Codu Community meetup, now one of the largest meetups in Ireland and the world. I am sure only my colleagues and a couple of hard-core followers of Niall watched it live, but hey! it was a start!

Finding Your Unique Style

I got invited to a couple of "big-name" online conferences. For me it was easier to present live, I am not very good at doing pre-recorded talks, however, if you feel more comfortable doing a recording, it is a great way to get started, meet the organisers and discover the process of applying, preparing and delivering a talk. Some conferences have online days where you can apply to speak and you might get more chances to get accepted, but you get to be part of the in-person day and might even get invited to the speaker's dinner 😉.

There are a lot of people like you and me out there trying to do the same, so standing out can be challenging. Finding your style is important, for example, Kent C. Dodds signature style is to do "air squats" before a talk. I started using hand-drawn animations in my presentations to explain complex topics, but even more important is to be yourself, what you have to say is important to the audience and they would love to hear it!

Engaging Your Audience

The content of your presentation is the most important piece. If you don't know what to talk about, just talk about something cool, something that you are passionate about or a recent experience that you had.

Tell a story! the best presentations are the ones that follow the "hero's journey" and where you tell the audience how you overcame difficulty and implemented a cool technology that provided value to the company you work for instead of a "how to" tutorial and not just delivering a lecture.

Engagement is also key! I like to be dynamic and energetic on stage, you can use humour to connect with the audience, and body language to present yourself as open by extending your arms, you can ask questions, or even "doing squats" can help maintain that vital connection.

Overcoming the nerves

I get really nervous on stage, I get physically sick, and my stomach hurts for a good hour after a talk. It is normal, even seasoned speakers will tell you that those nerves never go away. When you choose the right topic and you know very well what you are talking about, it becomes easier and helps you get into the "flow" state.

Here are my tips on how to get rid of the nerves:

A Practical Tip: If you are right-handed clench your left fist as hard as you can, it is scientifically proven that it helps to calm down the nerves.
A Mind Tip: If you feel like running away, just remember, what you are about to tell the audience could change their careers or even their lives, if you don't do it, they will miss out. You are on a mission, don't think about going back until that mission is complete because what you have to say is important.

Reflecting on Your Performance

I like reviewing the recordings of my talks to make my next presentation even better. After my first on-stage presentation at React Advanced in London, I watched the recording and I realised I sounded like I was telling people off! 😂 I was so passionate about the topic that I sounded like my grandmother warning me why using Micro-Frontends was a bad idea!

The worst thing you can do as a speaker is to make the audience uncomfortable. So it is essential not to appear aggressive or attack the audience. I also realised my pacing was off, I gave my back to the audience a couple of times and noticed all those "umms" and "amms" that are still there today, so I strongly recommend reviewing your recordings.

What If Public Speaking is Not for You?

If you have stage fright or simply are not interested in public speaking, then get involved in other ways. Help organise the meetup or the conference, become part of the technical committee and help review the proposals, or it could be as simple as turning up early and putting the chairs out or setting up the refreshments.

Helping out and being part of the organisers is the best role, you don't have to worry about delivering a talk, everybody knows you, everyone is looking up to you and you can make great connections as well.

Conclusion

If you have never tried speaking at conferences, give it a go! and get out there, you don't need to be a professional, none of us are!

If you tried and you didn't like it, go find a local meetup or contact a conference organiser and offer to give them a hand, I am sure they would be grateful for the extra help.

Also, remember to have fun! what I love the most about conferences is the amazing people I get to hang out with and have amazing discussions about not just tech but also about life.

See ya at the next one! 👋

My Experience at JSNation and React Summit Amsterdam

Ruben Casas — Tue, 18 Jun 2024 13:52:33 +0000

This was my first time at the biggest JavaScript Festival and React Conference in the world (not an exaggeration). It was also my first time as an attendee and I enjoyed not having to worry about giving a talk and just experiencing the conference!

Apart from photobombing the stage TVs every single time I had a chance 😅, I was also lucky enough to have 1 on 1 conversations with the smartest and most influential speakers and library authors in our industry.

Here's what we talked about!

Ryan Carniato, Creator of SolidJS

Ryan and I discussed the “missing link” in the evolution of client-side applications. There is still a gap between Multiple Page applications (MPAs) and Single Page Applications (SPAs) with client-side routing where we are still forced to choose one or the other. There have been improvements with Astro and React Server Components but they still have a performance degradation element that stops it from being complete. My question to him was if the current stack is not enough for most use cases (sites that are not e-commerce and so sensitive to performance impact) his answer was (paraphrasing): "Mediocrity should not stop progress".

He is doing some work on Solid Start that might bring a breakthrough in this area, so I am really excited about what he's cooking 👀. We also discussed migrations, how difficult it is for a company to adopt a new technology and how the landscape is very different from when React came out. Applications are getting old and we are due to a new wave of technologies that use the best parts of what we learned in the past 10 years.

// Detect dark theme var iframe = document.getElementById('tweet-1801517170850967767-982'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1801517170850967767&theme=dark" }

Tobias K, Creator of Webpack

I had a long chat with Tobias about improving chunking in large applications to reduce bundle size. We also discussed the lack of a visualisation tool to represent the module graph. I am using the tool he created https://webpack.github.io/analyse/ but it hasn't been maintained for a while and he acknowledged it doesn’t work well with large stats files.

I also asked of course, what's the status of TurboPack, his thoughts on RSPack and support for Module Federation. He was very diplomatic and asked me to keep an eye out for later this year.

Dominik, Maintainer of React Query

Spend a lot of time with Dominik walking around Amsterdam and helping him #FreeSuspense 😂. Apart from having fun, missing the walking tour and trying to find presents for our kids, we also had the chance to talk about Local First applications, State Management in large apps, how we at Postman are pushing React Query to the limit and our custom implementation of "Mobx Query" and "Broadcast client". He asked me to write some articles about those usages of React Query that we could showcase and share with the community. It was also great to be there during the conversation with Sathya from the React Core team at Meta when the decision was made to hold React 19 to ensure the client-side suspense data fetching story was correctly implemented. React history was made and I was there for it!

(Special thanks to Dominik for recommending me the best present for my daughter, what a legend!)

// Detect dark theme var iframe = document.getElementById('tweet-1801669381182685508-233'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1801669381182685508&theme=dark" }

Evan Bacon, Creator of Expo Router

Had a great long chat with Evan. Went over so many topics including, Generative UI, Full Self Driving, Expo router, how to make cool demos, Apple and how they are good at marketing but not so good at execution. We talked about the difficulties in the distribution of native applications, multiple versions, backward compatibility, major version policy, rollbacks and forward. He also mentioned the cool features of Expo that help with the distribution of Native Apps.

We also discussed his demo of React Server Components generated by Ai and streamed to React Native, the future after the Demo what it means for Server Driven UI, personalisation and the usefulness of generative UI beyond cool demos.

// Detect dark theme var iframe = document.getElementById('tweet-1801630044030111889-484'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1801630044030111889&theme=dark" }

Brooks Lybrand, Devrel React Router (Remix)

I watched Brooks talk about bringing React Router and the newer features of React to existing CRA and Webpack apps. React Router v7 and the migration path look very promising and it aligns with the architecture I have been working on which will make it so simple to eventually upgrade to React 19. My only complaint was he didn't have any spare Limited Edition Remix hoodies to give away. I also helped him design the new React Router Remix logo but Ryan got very mad at us 😂

// Detect dark theme var iframe = document.getElementById('tweet-1801624394466476066-342'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1801624394466476066&theme=dark" }

Juri S, Developer Relations, NX

Juri and I talked about how we are using the NX monorepo at Postman and how it would be a good idea to showcase the architecture and improvements we made to NX for Micro-Frontends and independent app deployments as a case study. I also gave him a demo of the breaking change detection system that my colleague Patrick and our team created to suggest semantic versioning package versions and that it would be awesome to include it in the NX release command.

Mo Khazali

I discussed with Mo and Evan about bringing Module Federation to React Native, Evan is not that keen since it is an “organisational issue” not a user-facing or a DX issue but it was interesting to show our perspective on where it could be useful to send runtime modules over the air for native apps when multiple teams are deploying different parts of a large React Native Application. After our chat I found out that Module Federation is already supported in React Native if you use Re-Pack

Una Kravets

It was great to meet Una in person finally. I watched her talk at C3 DevFest and even though I had seen the ThunderCats intro before it was still really funny. I hope she doesn't remember my name because I am in trouble with the Google Developer Experts program for not reporting my engagements... oops 😅

Special Mentions

These are just summaries of what I remember, some conversations went off for hours sometimes. I should have a hidden microphone and release these chats as a podcast series.

Thanks to Niall Maher, Carolina, Jesse Hall and the Irish mafia for putting up with me for 3 days straight.

Daniel A(l)fonso, Atila, Mi Parcero Erick Wendel and David K for hanging out with me as the infiltrated non-speaker and for giving me free food truck tokens.

Finally thanks Josh Goldberg, for being a great friend and listening to me yapping until 2 AM. We didn't talk about tech at all but we talked about so many things! Next time he's going to convince me TypeScript is not considered self-harm at this point 😂

// Detect dark theme var iframe = document.getElementById('tweet-1802131541687927171-753'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1802131541687927171&theme=dark" }

One last thing... The Conference!

This is the best frontend conference, full stop. I have been going to GitNation events for a while and it is always a pleasure to be part of this community. Rob, Daria, Anna, Alex, Lera and the rest of the crew are amazing at what they do and they really care about the details and the community. Congratulations on another amazing event! and see you at React Advanced London.

Building a Loading Component with ChatGPT

Ruben Casas — Sat, 28 Jan 2023 00:27:04 +0000

Have you ever seen the red progress bar on Youtube or the blue progress bar on GitHub when navigating from one page to the next?

I like that little component; it's elegant and subtle and perfectly fits with Remix and React Router transitions.

So I decided to build my own

Here are the rules:

I am really lazy! Can ChatGPT write for me?
I want to use React, no vanilla JS
No external dependencies (duh)
It needs to support animations

Here we go! 💪

ChatGPT first attempt:

Prompt:

"Write a react component that creates a red bar 3px in height with a dynamic width that starts at 0% and start incrementing every 10ms and dissapears when it reaches 100% width with a fade out animation. Reply with code blocks"

import React, { useState, useEffect } from 'react';
import './ProgressBar.css';

const ProgressBar = () => {
  const [width, setWidth] = useState(0);

  useEffect(() => {
    const intervalId = setInterval(() => {
      setWidth(prevWidth => (prevWidth >= 100 ? 100 : prevWidth + 1));
    }, 10);

    return () => clearInterval(intervalId);
  }, []);

  return (
    <div
      className={`progress-bar ${width === 100 ? 'fade-out' : ''}`}
      style={{ width: `${width}%`, height: '3px' }}
    />
  );
};

export default ProgressBar;

.progress-bar {
  background-color: red;
}

.fade-out {
  animation: fade-out 0.5s;
}

@keyframes fade-out {
  from {
    opacity: 1;
  }
  to {
    opacity: 0;
  }
}

That was a good start!

Next Prompt:

"Now, I want the progress bar to conditional render and mount an unmount when a condition is true or false, when it is unmounted it should fill the width to 100% and then fade out and disappear."

export const ProgressBar2 = ({ show }) => {
  const [width, setWidth] = useState(0);
  const [isAnimating, setIsAnimating] = useState(false);

  useEffect(() => {
    let intervalId;
    if (show && !isAnimating) {
      setIsAnimating(true);
      intervalId = setInterval(() => {
        setWidth((prevWidth) => {
          if (prevWidth >= 100) {
            return prevWidth;
          }
          return prevWidth + 1;
        });
      }, 10);
    }
    return () => clearInterval(intervalId);
  }, [show, isAnimating]);

  useEffect(() => {
    if (!show && width === 100) {
      setTimeout(() => {
        setWidth(0);
        setIsAnimating(false);
      }, 500);
    }
  }, [show, width]);

  if (!show) {
    return null;
  }

  return (
    <div
      className={`progress-bar ${width === 100 ? 'fade-out' : ''}`}
      style={{
        width: `${width}%`,
        height: '3px',
        position: 'fixed',
        top: 0,
        left: 0,
      }}
    />
  );
};

Prompt:
"What? That doesn't work at all! the bar never appears!"

ChatGPT:
I apologize for the confusion, it looks like my previous response did not include the necessary CSS for the animation.

...

What CSS? That code doesn't even make sense!

...

Many prompts later... an increasing list of useEffect functions, and a very apologetic ChatGPT, I decided to give up and build it myself.

Boy, that was a big mistake!

Random trickle:

The width increments were gradual every 10ms, but I want to add some randomness to the bar progress to give the impression that some non-deterministic async operation is actually happening... (Seriously, the bar is an illusion! It doesn't have anything to do with how long the operation takes 😂)

const Bar = (props: ProgressBarProps) => {
  const [width, setWidth] = useState(0);
  const progressSpeed = 10;

  useEffect(() => {
    const interval = setInterval(() => {
      setWidth((prevValue: number) => {
        const random = Math.random() / 100;
        if (prevValue + random >= 0.95) {
          clearInterval(interval);
          return prevValue;
        }
        return prevValue + random;
      });
    }, progressSpeed);

    return () => clearInterval(interval);
  }, [progressSpeed]);
...

That was easy wasn't it?

React Animations

You know what's not easy? Animations in React

It turns out that Animations in React are a pain!

When the component is unmounted, I want to fill the bar to 100% then show a fade animation.

In good old JQuery is a one-liner, as simple as:

$('#progress-bar').fadeOut(300, function(){ $(this).remove();});

Oh, but not React; React wants you to suffer! (unless you use a library like react-transition-group, of course.

But the rules are the rules, and I said no libraries... 😅

So after consulting with ChatGPT's arch enemy and more reliable predecessor, StackOverflow. I found that you can wrap your component in a container and use a method called onAnimationEnd to detect when the animation finishes and then hide the element.

So here is the result:

import React, { useEffect, useState } from 'react';
import './progress-bar.css';

interface ProgressBarProps {
  show: boolean;
}

export const ProgressBar = (props: ProgressBarProps) => {
  const { show } = props;
  const [shouldRender, setRender] = useState(show);

  useEffect(() => {
    if (show) setRender(true);
  }, [show]);

  const onAnimationEnd = () => {
    if (!show) {
      setRender(false);
    }
  };

  return (
    shouldRender && (
      <div
        aria-label="progress-bar-container"
        style={{
          animation: `${show ? '' : 'fadeOut 0.5s'}`,
        }}
        onAnimationEnd={onAnimationEnd}
      >
        <Bar {...props} show={show} />
      </div>
    )
  );
};

const Bar = (props: ProgressBarProps) => {
  const { show } = props;
  const [width, setWidth] = useState(0);
  const progressSpeed = 10;

  useEffect(() => {
    const interval = setInterval(() => {
      setWidth((prevValue: number) => {
        const random = Math.random() / 100;
        if (prevValue + random >= 0.95) {
          clearInterval(interval);
          return prevValue;
        }
        return prevValue + random;
      });
    }, progressSpeed);

    return () => clearInterval(interval);
  }, [progressSpeed, show]);

  return (
    <div
      aria-label="progress-bar"
      style={{
        position: 'fixed',
        top: 0,
        left: 0,
        zIndex: 2147483647,
        backgroundColor: '#FF0000',
        height: '3px',
        width: `${10 + width * 90}%`,
        transition: `width ${progressSpeed}ms`,
        transform: 'translate3d(0, 0, 0)',
      }}
    />
  );
};

It works!

Except it doesn't! There is an annoying "flashing glitch" when the component unmounts that I couldn't be bothered finding out why (I am lying; I spent way too long trying but then gave up)

Conclusion

Use nProgress 😂

That's it!

Real Conclusion:

This was a fun exercise to stretch the limits of ChatGPT and how far it can go in creating entire components and UI. It did very well with the basics, but when you start adding more complex interactions, it just goes round and round in circles spitting out incoherent and repetitive code. (not without apologising, of course 😅)

Worth noting that I couldn't make the component work 100% either!, mainly due to lack of time (or lack of React expertise 😂).

If anyone wants to judge my midnight coding and fix the bug, and let me know why the glitch happens, here is the link to the code:
https://stackblitz.com/edit/github-9eintn-ru5xtl?file=src%2Fprogress-bar.tsx

My Conclusion:

I need to get better at React animations.

Why React Router is excellent for Micro-Frontends

Ruben Casas — Sat, 21 Jan 2023 10:29:27 +0000

As you probably noticed, I am a huge fan of React Router 6!

It is Remix for Single Page Applications and gives your apps "super powers" while taking you closer to the platform.

You also know that I love working with large frontend applications, and my passion is frontend architecture at scale, especially Micro-Frontends. So, where is the intersection between these two technologies?

React Router 3

My journey with React Router and Micro-Frontends started at American Express, working as one of the maintainers of One App, a server-side rendered React Micro-Frontend framework (That's a mouthful!)

At the core of this framework was React Router 3. It was so powerful, versatile, and one of the best-designed libraries for React. (At over 1 Billion downloads, the team behind it must have done something right 👏)

React Router 4/5 was released with improved support for hooks. Still, we could not upgrade because of missing features from v3, like the ability to pull the entire route tree programmatically using childRoutes so we created and maintained a fork of it.

Then React Router 6 came along 🎉, bringing back most of the great concepts from v3 and doubling down on one of its killer features, Nested Routing.

Nested Routing

First, what's Nested Routing? An image speaks volumes, so take a look at this:

I haven't found a better explanation than this visual demo from the Remix page, but in Michael Jackson's words:

"It's a way to split a webpage into more granular pieces. Those pieces match a segment of the URL. When you have such granularity, you can perform lots of really interesting optimisations and enable workflows that are difficult when you don't have that concept."

Hold on a second, "Split a webpage into more granular pieces." That's precisely what Micro-Frontends are about!

Combined with techniques like "Runtime Composition", those smaller pieces can be developed, tested and deployed independently by separate teams. React Router nested routing will take you halfway there, helping you split your application in a predictable and performant way.

Decoupling

"For a system to be distributed, it has to be decoupled first."

React Router builds on top of Nested Routing to separate your application's data loading, error handling and rendering.

In a Micro-Frontend architecture, it is essential that your UI is composable, encapsulated and, most importantly, decoupled.

Data Loaders

Separating the data loading from the rendering is a fantastic decision for performance (Fetch before you render) and parallel fetching, but this also has a nice side effect on composability and separation of concerns.

One of my "Rules for Micro-Frontends" is that each Micro-Frontends should load its own data. Having every route segment matched to a loader ensures that your data dependencies are explicit and removes indirection.

This makes ownership, refactoring and flexibility features that are baked-in into your architecture.

State

Another of my recommendations is to avoid sharing state to prevent "accidental coupling". This will keep your application from becoming a "distributed monolith", and you will get most of the benefits of a Micro-Frontend architecture.

React Router 6 loaders and actions remove most of the "global state" needs and greatly simplify React Applications. The URL becomes the "global state" and keeps things decoupled while ensuring all the different parts of your UI are in sync while relying on the web platform.

Migrations

React Router and Micro-Frontends are great for migrations! (I need to write a separate blog post on this section alone) but in summary, the flexibility and route-matching algorithm of React Router enables you to migrate legacy applications piece by piece and do a "Reverse Strangler Pattern" migration.

What about Remix?

Remix shares most of the best traits of React Router, and I recommend it 100% for new applications. It removes a lot of the pain points that tend to send people down the Micro-Frontends path; however, Micro-Frontends are meant to solve an organisational scaling problem, so at some point, for large organisations it would be great to have independent deployability of segments of a Remix application that are owned by an entire team.

The technical problem is runtime composition. It is possible, it has been done before by Jacob from Remix and my friend Adrien, but for a Framework like Remix, there are loads of nuances that need to be addressed to get the benefits of independent deployability.

TLDR; it is possible, but someone needs to sit down and design a good playbook around it and tweak the tech to support it. (don't look at me!)

Conclusion

React Router is a fantastic tool! Add independent deployments and runtime composition on top of it, and you end up with a robust Micro-Frontend architecture that can help you scale your teams and solve your organisational scaling problems.

Modals with React Router 6 and Remix

Ruben Casas — Thu, 19 Jan 2023 23:53:59 +0000

Popularized by Pinterest, Instagram, and others in the 2010s. Modals are typically used as a kind of "detail" view to focus on a particular object in a collection (like a Pinterest board) while not taking you completely out of the context of the parent page.

There is an example on the React Router 6 Repository on how to implement this pattern by using state and backgroundLocation to keep the parent page visible and show the modal on top.

How do you achieve the same results with React Router Data Routers (^6.4.0) and Remix? Let's find out!

First, when using loaders we will be unable to use the same mechanism of setting a state.backgroundLocation because the route state doesn't exist at the point where we define our routes:

// We can't access state here!
const router = createBrowserRouter([
  {
    path: '/',
    element: <App />,
    children: []
  }
)]

Source Code of this attempt here

So there are two options for Modals with Data Loaders, both of them have their own pros and cons depending on your use case:

Modals using Nested Routing

The first option is to use React Router's nested routing capabilities to enable a modal that can be shown inside its parent route:

Let's use the same example from the React Router repository. We want to show a modal whenever the user clicks on an image and then have the image detail view inside the modal instead of a new page.

Routing configuration:

const router = createBrowserRouter([
  {
    path: '/',
    element: <App />,
    children: [
      {
        element: <Layout />,
        children: [
          {
            index: true,
            element: <Home />,
          },
          {
            path: 'img/:id',
            element: <ImageView />,
          },
          {
            path: 'gallery',
            element: <Gallery />,
            children: [
              {
                path: 'img/:id',
                element: <Modal />,
              },
            ],
          },
          {
            path: '*',
            element: <NoMatch />,
          },
        ],
      },
    ],
  },
]);

The Modal component is now a nested route inside the Gallery component.

In Remix just create a new file folder structure to create the nested route

routes 
| index.tsx 
| gallery   
    | index.tsx
    | modal.tsx

Next step, we need to add an Outlet to the Gallery component to render the modal

export function Gallery() {

  return (
    <div style={{ padding: '0 24px' }}>
      <h2>Gallery</h2>
     ...
      <Outlet />
    </div>
  );
}

Pros:

Modals can use their own loaders: If your modals need to access data fetching, they can be assigned their own loader to separate them from the parent route and work independently.
It doesn't require a lot of setup: They are just nested routes that render on top of the parent route.
Persistent navigation: Because the modals are just regular routes, you can reference them, open and close them using the URL path.

Cons:

Modals need to be configured under a route, which means that it's not possible to render them in the root / URL
Modals will be displayed only inside a defined nested route and cannot be accessed from any page. If you want to show them on a different path, you need to create those routes manually over and over again.
If you want to move a modal, you must refactor the entire route segment that uses it.
It is sometimes hard to keep the context of the background page because outlets have to be in the right place.

Link to entire code Example

Modals Using Search Params

An alternative to Nested Routes is to use the Search Params in the URL (Use the platform! 💪)

To open a modal with the picture from the gallery, we will need to navigate to the following URL path:

?modal-type=gallery-img&gallery-img-id=1

Then we can access the URL Search Params in the root loader of the application:

export const loader: LoaderFunction = ({ request }) => {
  const queryParams = new URL(request.url).searchParams;
  const modalType = queryParams.get('modal-type');
  const galleryImgId = queryParams.get('gallery-img-id');
  if (modalType === 'gallery-img') {
    if (!galleryImgId) {
      console.error(
        "must pass the gallery-img-id param if you want to render the 'gallery-img' modal"
      );
      return null;
    }
    return {
      modalType: 'gallery-img',
      galleryImgId,
    };
  }
  return null;
};

Then in the render function of the root of your application, we check for the modal type and the parameters.

export default function App() {
  const modalProps = useLoaderData() as ModalProps;
  return (
    <div>
      <h1>Modal Example</h1>
      <Modal modalProps={modalProps || null} />
      <Outlet />
    </div>
  );
}

Inside the Modal Component, we can check for the modalType and render a different modal and content depending on that value. You can
register and create as many modals as required using a simple interface and conditional rendering.

Pros:

Modals are global; You can use them in the root URL path / and can be opened from anywhere in the application.
Easy to refactor and move around within the application.
They also support persistent navigation and manage their visibility state using the URL.

Cons:

These modals can't have their own loaders, so they either need to request their data inside their render function (Render then Fetch) or get their data passed as props from a parent.
They have to be "registered" in the root of your application using a modal rendering engine or utility which could be harder to maintain in the long term.
The Search Params in the root will trigger all the other loaders, which could cause re-rendering and performance issues. A potential solution is to introduce shouldRevalidate() if you don't want to re-run loaders.

Link to the source code

Conclusion

One pattern is not better than the other; both have advantages and disadvantages, depending on your use case.

If you need your modals to have their own loaders, then use the nested routing approach but bear in mind that they are not very flexible and easy to refactor.

If you want to create "global modals" that can be opened from anywhere and are more flexible, you can use the Search Params approach; however, be aware of tight coupling in the root of the application and the performance implications of not using loaders.

Credits:

Jon, who made a video on how to create Modals using Search Params and also a repository with the complete example here

And as usual Matt from the Remix team who's always so helpful in answering these type of questions on Discord.

Module Federation Shared API

Ruben Casas — Tue, 03 Jan 2023 19:35:04 +0000

This is one of the most potent APIs of Module Federation, yet there needs to be more documentation on how it works and how it could help with the performance of your distributed applications.

In this post, we will explore every aspect of the Shared API, explaining how to use it and when it might come in handy. 🔍

What's the Shared API?

So, what is the Shared API exactly? 🤔 It's part of the plugin configuration options in Module Federation. You can pass it an array or object called shared, which contains a list of dependencies that can be shared and used by other federated apps (aka "remotes").

new ModuleFederationPlugin({
  name: "host",
  filename: "remoteEntry.js",
  remotes: {},
  exposes: {},
  shared: [],
});

API Definition:

shared (object | [string]): An object or Array of strings containing a list of dependencies that can be shared and consumed by other federated apps.

eager (boolean): If true, the dependency will be eagerly loaded and made available to other federated apps as soon as the host application starts. If false, the dependency will be lazily loaded when it is first requested by a federated app.

singleton (boolean): If true, the dependency will be treated as a singleton and only a single instance of it will be shared among all federated apps.

requiredVersion (string): Specifies the required version of the dependency. If a federated app tries to load an incompatible version of the dependency, two copies will be loaded. If the singleton option is set to true a warning will be printed in the console.

Why do you need it?

When you have federated modules, they're bundled separately and include all the dependencies they need to function. However, when they're used in a host application, it's possible for multiple copies of the same dependency to be downloaded. This can hurt performance and make users download more JavaScript than necessary. 😰

This is where the shared API becomes really handy: You can avoid downloading multiple copies of the same dependency and improve the performance of your application. 🚀

Preventing Duplication

Let's stick to the typical example of Webpack, and share and deduplicate lodash:

Let's say you have two modules, Module A and Module B, and both of them require lodash in order to function independently.

But when they're used in a host application that brings both modules together, the Shared API comes into play. If there is already a preloaded, shared copy of lodash available, Module A and Module B will use that copy instead of loading their own independent copies.

This copy could be loaded by made available by the host or another remote application inside it.

new ModuleFederationPlugin({
  ...
  shared: ["lodash"],
});

Tip: Both the remote and host have to add the same dependency in "shared" for it to be available for consumption.

How does it work?

If you are familiar with Dynamic Imports, Module Federation is nearly identical; it requests a module and returns a promise that fulfils with an object containing all exports from the moduleName declared in the exposes object.

Module Federation's async nature makes the shared API so flexible.

Async Dependency Loading

When a module is required, it will load a file called remoteEntry.js listing all the dependencies the module needs. Because this operation is asynchronous, the container can check all the remoteEntry files and list all the dependencies that each module has declared in shared; then, the host can load a single copy and share it with all the modules that need it.

Because shared relies on an asynchronous operation to be able to inspect and resolve the dependencies, if your application or module loads synchronously and it declares a dependency in shared, you might encounter the following error:

Uncaught Error: Shared module is not available for eager consumption

To solve the error above, there are two options:

Eager Consumption

new ModuleFederationPlugin({
  ...
  shared: { 
      lodash: {
          eager: true,
        },
});

Individual dependencies can be marked as eager: true; this option doesn't put the dependencies in an async chunk, so they can be provided synchronously; however, this means that those dependencies will always be downloaded, potentially impacting bundle size. The recommended solution is to load your module asynchronously by wrapping it into an async boundary:

Using an Async Boundary:

Note: this only applies to the application's entry point; remote modules consumed via module federation are automatically wrapped in an Async Boundary.

To create an async boundary, use a dynamic import to ensure your entry point runs asynchronously:

index.js

import('./bootstrap.js');

bootstrap.js

import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';
ReactDOM.render(<App />, document.getElementById('root'));

Versioning

So what happens if two remote modules use different versions of the same dependency?

💥?

Nope... everything just works™️!

Versioning is probably one of the best (if not the best) features of the shared API, and it is also enabled by default 🙌

If the semantic version ranges for those dependencies don't match, then Module Federation is powerful enough to identify them and provide separate copies, so you don't accidentally load the wrong version containing breaking changes. This obviously can cause issues with performance because you end up downloading different versions of a dependency, but at least your app doesn't break.

Singleton Loading

I know what you are thinking; what if I want to guarantee that only one copy of a given dependency is loaded at all times. (cough cough React, cough cough)

Passing singlton: true to the dependency object achieves precisely that...

shared: {
        react: {
          singleton: true,
          requiredVersion: "^18.0.0",
        },
        "react-dom": {
          singleton: true,
          requiredVersion: "^18.0.0"
        },
      },

Here's something to be aware of: if one of your remote modules tries to load an incompatible dependency version that has been marked as a singleton, Webpack will print the following warning in the console:

But don't panic! The build won't actually break, and Webpack will continue to bundle and load your applications. However, the warning is there to let you know that there may be some unexpected behaviour due to compatibility issues. So, if you see this warning, it's a good idea to go and align your dependencies to avoid any problems.

Downsides / Trade-Offs

Everything is a trade-off, but you can only accept and mitigate them if you are aware they exist. Here are some issues that you might encounter using the Shared API:

Dependencies mismatches at Runtime

Because the applications are built at a different point in time by another Webpack process, they don't share the same dependency graph, and we can only rely on Semantic Versioning ranges to deduplicate and provide the same dependency version.

There could be a case where you have built and tested your remote with version 1.0.0 of a library, but then when loaded by the host, because the Semantic Versioning Range ^1.0.0 satisfies 1.1.0, you might end up loading 1.1.0 at Runtime in production that might or might not have compatibility issues.

This can be mitigated by aligning versions as much as possible (Using a monorepo with a single package JSON might help).

This downside concerns our trust in Semantic Versioning ranges rather than Module Federation and the Shared API. In Distributed Systems (similar to Microservices), a contract is required to guarantee the stability and reliability of the system. In the case of the Shared API, the Semantic Version Range is the contract (potentially not a good one).

From my experience, there isn't a better alternative to shared dependencies on a distributed frontend application, and even though the Share API is not perfect, it is the best we have right now.

Conclusion

In conclusion, the Module Federation Shared API is a powerful tool for improving the performance of distributed applications. It allows you to share dependencies between modules and avoid unnecessary duplication, resulting in faster load times and better overall performance

DEV Community: Ruben Casas

Chrome Just Dropped Web MCP (and That’s Kind of a Big Deal)

What even is Web MCP?

I’ve been playing with this concept since “February last year” (~ 7 Ai years ago)

Demo vibes: “driving the UI” is cool, but what's the end game here?

The mobile boom déjà vu

The real shift: Collapsing Layers

1) Some websites (and UIs) just… shouldn’t exist

2) Go straight to the API (because agents can actually do things)

3) True human machine collaboration

How Web MCP fits into this

I Reverse Engineered ChatGPT Apps Iframe Sandbox

Before ChatGPT Apps, I Had to Solve The Same Problem!

The ChatGPT Apps SDK

Hmmm, that Looks familiar 🤔

Iframes, magnets How do they work?

The double-iframe trick

Why the double iframe matters

The spec caught up (and improved it)

Conclusion

The Reality of AI Coding in Production (and My Poor Man’s Setup)

Caveats / Constraints Working with Production Software

Spaghetti Code

To Rewrite or Not Rewrite

Missing Verification Loop

Testing Chicken and Egg paradox

Code is not the bottleneck anymore, verification is!

The Kitchen Sink paradox

Risk of change is a limiting factor

How I Actually Use Ai Coding In My Day Job

My Setup

Codex GPT 5.2 (thinking high)

Favourite Follow up Prompts:

Claude Code / Opus 4.5

Claude Code and Codex CLIs

I have found them useful in the following cases:

Ralph Loop Coding

Miscellaneous / Tips and Tricks

Conclusion

Recommended Reading

Side Projects? I don't have time for that!

The importance of Side Projects

Time? I don't know that Pokemon!

Too Much Talk, Show me the stuff!

1. Weather Agent with MCP-Ui

2. Time Machine with Nano Banana!

3. Shopify Store MCP-Ui.shop

4. Children's Book: "The Adventures of Fluffy"

5. TBPN Video Generator

6. ChatGPT App to buy T-Shirts

7. Postman Welcome Video

8. City Quest: The First Original ChatGPT Game!

9. My Personal Site

Conclusion

Rethinking UI in Agent Driven Systems

1. First-Party UI Rendering: Components from Within

Pros

Cons

Ideal for:

Examples:

2. Third-Party UI: Server-Generated UI Delivered via MCP

Pros

Cons

Ideal for:

Examples:

3. Generative UI:

Pros

Cons

Ideal for:

Choosing a Strategy

Final Thoughts

Further Reading & Inspirations

Introducing a New Web Vital: Time to Usability (TTU)

Introducing a New Web Vital: Time to Usability (TTU)

How to Measure TTU:

How TTU Differs from Time to Interactive (TTI)

Instrumenting Your App with Performance Markers

Collect the Data Using performance.mark()

Measuring Page Load Performance with The Resource and Navigation Performance Entries

Synthetic Monitoring vs. Real User Monitoring (RUM)

Collect the Data Using `performance.mark()`