Rust to TypeScript, React Native 2026, and Cloud Architecture
Published on 23.03.2026
Rewriting our Rust WASM Parser in TypeScript
TLDR: A team built a custom DSL parser in Rust compiled to WASM, but discovered the WASM-JavaScript boundary overhead was the bottleneck, not computation. Rewriting in TypeScript eliminated the boundary entirely and improved performance.
Summary:
This is a fascinating case study in optimization assumptions. The team started with what seemed like the perfect architecture: a custom domain-specific language parser built in Rust, compiled to WebAssembly for maximum performance. On paper, it was brilliant. Rust's safety and speed, WASM's near-native performance. But reality hit hard.
The bottleneck wasn't where they expected. It wasn't the parsing computation itself. The real killer was the WASM-JavaScript boundary overhead. Every time data crossed that boundary, performance took a hit. They tried optimizing with serde-wasm-bindgen to skip JSON serialization, but that made things 30% slower due to fine-grained boundary crossings. Each tiny data transfer added up.
The solution? They rewrote the entire parser in TypeScript. Yes, TypeScript. The language they were already using everywhere else. By eliminating the WASM boundary entirely, they removed the overhead and actually improved overall performance. Sometimes the best optimization isn't adding complexity, it's removing it.
Key takeaways:
- WASM-JavaScript boundary overhead can negate computational performance gains
- serde-wasm-bindgen fine-grained crossings made performance 30% worse
- Rewriting in TypeScript eliminated boundary and improved overall performance
- Measure real-world performance, not just computational benchmarks
Why do I care:
As a senior frontend developer and architect, this hits home. We often reach for the "optimal" technology without measuring the real bottlenecks. Rust and WASM sound impressive, but if your application spends most of its time crossing language boundaries, you're optimizing the wrong thing. TypeScript might not be as fast computationally, but eliminating serialization and boundary overhead can make the entire system faster. This is a reminder to profile first, optimize second, and never underestimate the cost of abstraction boundaries.
Rewriting our Rust WASM Parser in TypeScript
State of React Native - What's new in 2026
TLDR: The 2025 State of React Native survey reveals Expo Router dominating navigation at 71%, NativeWind growing to 42% for styling, and React Native Reanimated at 93% for animations.
Summary:
The React Native ecosystem has matured significantly, and the 2025 survey results show clear winners emerging. Expo Router has become the dominant force in navigation, with 71% of developers choosing it. That's a massive consolidation around a single solution. For styling, NativeWind continues its meteoric rise, now at 42% adoption. Developers are clearly gravitating toward Tailwind-style development even in mobile contexts.
Animation is essentially a solved problem, with React Native Reanimated at 93% adoption. When you have numbers that high, you're looking at the de facto standard. The survey also covers testing tools, analytics solutions, and build tooling, with EAS Build leading the pack. What's striking is how much the ecosystem has standardized. Five years ago, you'd have a dozen viable options for each category. Now, clear leaders have emerged.
This consolidation is good for the ecosystem. It means better documentation, more community support, and less decision fatigue for new projects. But it also means we need to be thoughtful about which tools we bet on, because the winners are becoming harder to displace.
Key takeaways:
- Expo Router dominates navigation with 71% adoption
- NativeWind growing rapidly to 42% for styling
- React Native Reanimated at 93% for animations
- EAS Build leading in build tooling
- Clear ecosystem consolidation around established tools
Why do I care:
If you're starting a React Native project in 2026, the decision matrix has never been clearer. Expo Router, NativeWind, Reanimated, EAS Build. These aren't just popular choices, they're the standard. This matters for hiring, for finding help, for long-term maintenance. As an architect, I care deeply about reducing risk. Betting on the clear winner in each category reduces the risk of abandonment, improves hiring prospects, and ensures better community support. The only downside is vendor lock-in with Expo, but at this point, that's a calculated risk worth taking for most projects.
State of React Native - What's new in 2026
18 Months of Code, Gone. Here's What We Learned.
TLDR: A startup founder shares hard lessons from scrapping 18 months of code at their QA automation company, including the cost of skipping tests and a detailed critique of Next.js Server Actions.
Summary:
This is a painful but invaluable post-mortem from a founder who had to throw away 18 months of development work. The core issue? Skipping tests early on to move fast. That speed came due with interest. The accumulated technical debt led to bugs that cost them a major client. Sometimes moving fast means you arrive nowhere, faster.
The post includes a particularly detailed critique of Next.js Server Actions. The author calls out sequential global execution as a performance problem, poor observability making debugging a nightmare, and security footguns that are too easy to trigger. Errors are swallowed in ways that make production debugging nearly impossible. These aren't minor complaints. They're fundamental architectural issues that become apparent only at scale.
The lesson isn't that Server Actions are bad. It's that every abstraction has trade-offs, and those trade-offs only become visible under real production pressure. What feels productive in a tutorial can become a maintenance nightmare at scale. The author learned this the hard way, over 18 months.
Key takeaways:
- Skipping tests early led to bugs and lost clients
- Next.js Server Actions have sequential execution, poor observability issues
- Security footguns in Server Actions are easy to trigger
- Technical debt compounds faster than feature velocity
Why do I care:
I've seen this pattern too many times. Move fast, break things, skip tests. It works until it doesn't. And when it breaks, it breaks catastrophically. The Server Actions critique is particularly relevant. As a senior frontend architect, I need to evaluate technologies not just for their tutorial experience, but for their production characteristics. Observability, error handling, security. These matter more than initial developer velocity. This post is a reminder that production-hardened patterns exist for a reason. Tests aren't optional. Observability isn't optional. And new abstractions need to be evaluated with a critical eye, not just adopted because they're trendy.
18 Months of Code, Gone. Here's What We Learned.
Better Fullstack
TLDR: Better Fullstack is a CLI tool scaffolding production-ready fullstack applications with 270+ options across TypeScript, Rust, Python, and Go ecosystems.
Summary:
Better Fullstack is an ambitious scaffolding tool that lets developers mix and match from 270+ options across four language ecosystems. You can choose from 15 frontend frameworks, 17 backend frameworks, 6 databases with 13 ORMs, plus auth providers, payment integrations, and AI tooling. It's like create-react-app, but for entire production applications.
The value proposition is clear. Instead of spending days wiring together your stack, you run a CLI command and get a production-ready setup. Authentication, payments, database, testing. All configured and ready to go. For consultants and agencies, this could be a massive time-saver. For startups wanting to validate quickly, even more so.
But there's a catch. Scaffolding is easy. Maintaining what's scaffolded is harder. When you generate 270+ combinations, you're also generating 270+ different maintenance profiles. Debugging becomes harder because you didn't wire it together yourself. And when something breaks, you're at the mercy of the tool's maintainers to fix it.
Key takeaways:
- 270+ options across TypeScript, Rust, Python, Go ecosystems
- 15 frontend frameworks, 17 backend frameworks supported
- 6 databases with 13 ORMs, auth, payments, AI integrations
- CLI scaffolds production-ready applications instantly
Why do I care:
As someone who's architected systems for multiple clients, I see the appeal. Rapid prototyping is valuable. But I've also inherited generated code before, and it's never as clean as hand-crafted solutions. The real question is: what happens after generation? Can you eject from the tool? How well-documented is the output? For greenfield projects where speed matters more than long-term maintainability, this could be perfect. For systems you'll maintain for years, I'd still prefer understanding every line from day one. Use it for prototypes, but think twice before using it for your core product.
My React ecosystem stack in 2026
TLDR: A developer shares their stable React ecosystem toolkit for 2026: Zustand, Tanstack Query, Tailwind, Shadcn/ui, Vitest, React Testing Library, and Vite.
Summary:
Sometimes the most interesting news is no news at all. This developer's 2026 React stack is almost identical to their 2025 stack. Zustand for client state, Tanstack Query for server state, Tailwind and Shadcn/ui for styling, Vitest and React Testing Library for testing, Vite for bundling. The stability is the story.
The React ecosystem has finally matured past the constant churn phase. Remember when we'd reinvent the stack every 18 months? Redux to MobX to Recoil to Zustand. Class components to hooks to server components. CSS-in-JS to CSS Modules to Tailwind. The dust is settling. Clear winners have emerged, and they're staying put.
The only notable change mentioned was switching from React Router to TanStack Router. That's significant. TanStack has built a reputation for rock-solid, well-typed solutions. Moving routing into that ecosystem makes sense for consistency and type safety. But even that's an evolution, not a revolution.
Key takeaways:
- Zustand for state management remains the choice
- Tanstack Query for server state, TanStack Router for routing
- Tailwind and Shadcn/ui for styling
- Vitest and React Testing Library for testing
- Vite for bundling
- Ecosystem stability over constant churn
Why do I care:
This stability is good for our industry. It means we can invest in deep expertise rather than constantly relearning the basics. As an architect and consultant, I can recommend these tools with confidence that they'll still be relevant in two years. It also means hiring becomes easier. More developers know these tools. The only risk is complacency. Just because the stack is stable doesn't mean we stop evaluating new options. But for now, this is a solid, battle-tested foundation for any React project in 2026.
My React ecosystem stack in 2026
How to Diagram Your Cloud Architecture
TLDR: Datadog's eBook provides cloud architecture diagramming best practices from AWS solutions architects, covering high-level overviews, maintaining source of truth, and budget-conscious planning.
Summary:
This is a sponsored resource from Datadog, but the underlying advice is solid. The eBook presents a framework from AWS Solution Architects for diagramming cloud architecture. The core principles are straightforward. Start with a high-level overview before diving into specifics. Keep diagrams updated as a source of truth. Plan environments with cloud budget in mind.
The challenge with cloud architecture isn't just building it. It's understanding what you've built six months later. Teams change. People leave. Documentation drifts. Diagrams become outdated. This resource emphasizes keeping diagrams current, which is harder than it sounds. The best diagram is one that updates automatically, but that's also the hardest to build.
The budget-conscious planning angle is interesting. Cloud costs can spiral if you're not intentional. Diagramming with cost in mind means visualizing not just architecture, but expense. Which services are running? Which are over-provisioned? Where can you consolidate? A good diagram answers these questions at a glance.
Key takeaways:
- Start with high-level overview, then dive deeper
- Keep diagrams updated as source of truth
- Plan with cloud budget constraints in mind
- Visualize both architecture and cost implications
Why do I care:
This is primarily a best practices and operational excellence story. As a frontend architect, you might think cloud diagrams aren't your concern. But full-stack developers and architects absolutely need this skill. Understanding your cloud topology affects everything from latency to cost to security. If you're making frontend decisions that trigger backend calls, you need to understand the path that request takes. I'd recommend this for anyone designing systems, but take the vendor perspective with a grain of salt. Datadog benefits from complex, monitored architectures. Your needs may differ.