A few days ago, a Flutter developer wrote a profiling post about sorting 10,000 timeline events. Under a section they called "The Original Sin", they pointed out the culprit:

items.sort((a, b) => DateTime.parse(a.start).compareTo(DateTime.parse(b.start)));

In an O(N log N) sort, that callback runs over 215,000 times for 10,000 items. On a mobile isolate, parsing 215,000 ISO strings takes 180ms+ and drops a dozen frames.

To fix it, they mapped the list to a temporary helper object with pre-parsed dates, sorted by the cached key, and unwrapped it.

That Map -> Sort -> Map pattern was actually what I posted to Usenet back in 1994 (what became known as the Schwartzian Transform). But what surprised me running benchmarks in modern Dart: package:collection's sortedBy does not cache keys either—it still ran 127,000 redundant key evaluations because mergeSortBy re-evaluates keys during merges.

With Dart 3 records, you don't even need throwaway helper classes anymore—a boxed record one-liner or simple extension method runs in 14ms (13x faster).

Have you ever caught a subtle frame stutter hiding inside a sort or compare callback?

Most of us know Provider was built on InheritedWidget, but I recently revisited the exact mechanical reason Rémi had to abandon it to create Riverpod.

It comes down to a fundamental design choice in dependOnInheritedWidgetOfExactType: the Flutter framework never unregisters a dependency once registered.

If you read state conditionally behind an if check, that element stays locked in InheritedElement._dependents until it unmounts. Even after the condition flips to false, that widget keeps rebuilding on every single ancestor change forever.

In May 2019, Rémi opened PR #33213 to add an unlisten hook to InheritedElement. Hixie closed it to avoid adding overhead to the hot reconciliation loop. Because Provider had no way to know when widgets stopped listening, autoDispose was impossible—forcing Rémi to hoist state completely out of the tree.

Looking back, it’s wild how much of the state management wars over the last five years really just came down to working around that one framework limitation.

Did you ever run into those conditional "ghost rebuilds" in Provider back in the day?

Ever caught yourself putting technical counters like droppedEventsCount or lastFetchLatency into your UI state models?

Most state management frameworks only tell you WHAT happened mechanically (a state changed, or an error threw). But when event concurrency transformers (droppable, restartable, sequential) discard or queue incoming events, they behave like opaque black boxes.

Stuffing those dropped counters into domain state creates two subtle traps:

1. Rebuild Storms: Every dropped event forces active widgets to rebuild during high-speed gestures.
2. Hardware Coupling: On a 120 Hz ProMotion screen, an infinite-scroll fling drops ~29 events. On a 60 Hz display, it drops ~14. On desktop web with a mouse wheel, it drops 2. Your domain state is now tracking the user's physical display glass rather than business truth.

Worse, classic transformers wrap heavy Rx stream pipelines. A 250 ms scroll fling allocates dozens of stream controllers and microtask queue hops right when Flutter needs every microsecond of its 8.3 ms frame budget for rasterization.

The solution is recognizing the boundary: Observability is mechanical (UI state transitions and error boundaries), but Telemetry is operational physics (why an event dropped, queue wait times, task preemptions). Operational physics belongs in a dedicated telemetry channel that bypasses UI rebuilds entirely and routes straight to DevTools and OpenTelemetry.

How does your team handle visibility into dropped events and concurrency pipelines in production? Do you leave them as black boxes, or do you have a pattern for tracking them without polluting UI state?

For the past eight years, the Flutter community has treated state management like isolated silos: you’re either a BLoC shop, a Riverpod shop, or looking at Signals.

If your team is maintaining a massive, battle-tested flutter_bloc authentication pipeline or a complex Riverpod dependency graph, you’ve probably hit this wall: you want instant, synchronous signal reactivity for a new feature (real-time forms, charts, animations), but the cost is a painful multi-month rewrite or leaky, second-class wrapper boilerplate.

With the release of bloc_signals_bloc and a major update to bloc_signals_riverpod (v1.2.0), we set out to solve this by turning BLoC, Riverpod, and BlocSignal into first-class, bidirectional peers:

• 🚂 Classic BLoC ➔ BlocSignal: classicBloc.toBlocSignal() gives you synchronous .state signals while forwarding .add(event) directly to the underlying BLoC.
• 🚚 Riverpod ➔ BlocSignal: provider.toBlocSignal(ref) gives you synchronous signals + typed .notifier mutations, while binding ref.onDispose for automatic cleanup.
• 🚄 BlocSignal ➔ Legacy BLoC UI: Drop streamless CubitSignal / BlocSignal containers directly into existing BlocBuilder widgets via .toClassicCubit().
• 🌊 BlocSignal ➔ Riverpod UI: Expose any BlocSignal to ref.watch / ref.read via .toProvider().

Because they operate as peers without microtask hops or customs fees, you can compose them seamlessly—like computing a single reactive total across a BLoC, a Riverpod Notifier, and a CubitSignal in the exact same frame.

Curious how other teams are approaching this:

1. Is your team currently locked into one state management approach across your entire codebase, or are you bridging tools across feature modules?
2. What has been your biggest hurdle when trying to introduce Signals or modernize an existing production app?

(Detailed architecture breakdown and a 60-line runnable triple-counter demo linked in the first comment)

Every Flutter developer remembers the magic of their first FutureBuilder.

You drop an HTTP call directly into a widget’s build() method, show a CircularProgressIndicator while waiting, render your model on completion, and suddenly your app is alive with real-time data in fewer than 20 lines of code.

It feels like superpowers. Introductory tutorials celebrate it. And then your codebase grows.

Suddenly, users report that typing into a text field reloads the entire screen. Opening the keyboard triggers duplicate network requests. Sibling widgets flicker and jump out of sync. And writing automated widget tests turns into an exhausting battle with pumpAndSettle(), fake async timers, and microtask queues.

Here is why raw asynchrony inside the presentation layer breaks separation of concerns, user experience, and testability—and what we should be doing instead.

🚨 The Foundational Principle: UI = ƒ(State)

Flutter widgets are designed to be pure, synchronous projections of state. Given a snapshot of data at time t, a widget function should execute synchronously, instantiate a subtree of render objects, and return immediately.

When you drop a FutureBuilder or StreamBuilder into your widget tree, you violate this contract by introducing raw time, transport mechanics, and asynchronous lifecycle orchestration directly into the presentation layer.

This creates four fatal flaws:

1. Layering Collapse

In clean architecture (Domain ← Data ← Application ← Presentation), the presentation layer has one job: translating state into visual pixels. With FutureBuilder, that widget suddenly takes on massive infrastructure responsibilities:

• Managing ConnectionState.waiting, active, and done
• Decoding HTTP 500s, socket timeouts, and parsing exceptions inside if (snapshot.hasError)
• Deciding whether old data stays visible during a refresh or gets wiped out
• Wiring retry logic that must somehow re-trigger the widget's internal future

2. The Accidental Refetch Hazard

Because build() can run 60 to 120 times per second during animations, keyboard popups, theme switches, or route transitions, any Future instantiated inside build() will re-fire on every single frame.

3. The "Spinner Storm" & Cumulative Layout Shift (CLS)

When multiple child widgets independently manage their own async fetches, they resolve out of order. Instead of a single coordinated page load, the user experiences jarring layout shifts as independent spinners pop in and out at different speeds.

4. The Async Testing Tax

Testing a FutureBuilder requires mocking HTTP clients, setting up async event loops, and using tester.pumpAndSettle(). If a microtask queue doesn't drain properly, tests flake or time out.

🛡️ The Solution: "Async at the Edge, Synchronous in the Core"

The architectural cure is simple: Quarantine async operations at the physical perimeter of your system (the repository/data layer).

1. The Repository wraps raw async operations into reactive async signals (such as FutureSignal / AsyncSignal).
2. The Business Logic (Cubit/Bloc) coordinates the synchronous state without needing manual try/catch boilerplate, because the signal automatically captures exceptions into AsyncError.
3. The Widget consumes synchronous state:

​

// The View is a pure, synchronous projection of state!
class UserProfileView extends StatelessWidget {
  const UserProfileView({super.key});
  u/override
  Widget build(BuildContext context) {
    return BlocSignalBuilder<ProfileCubit, ProfileState>(
      builder: (context, state) {
        return state.profile.when(
          data: (profile) => ProfileDetailsCard(profile: profile),
          loading: () => const Center(child: CircularProgressIndicator()),
          error: (error, _) => ErrorRetryCard(
            message: '$error',
            onRetry: () => context.read<ProfileCubit>().refresh(),
          ),
        );
      },
    );
  }
}

Notice what happens:

• Zero transport awareness: The widget has no idea if the data came from REST, GraphQL, WebSocket, or local cache.
• Zero in-view async: No FutureBuilder, no connection states.
• Deterministic 0ms Testing: Because the state is synchronous, widget tests run on Frame 1 without pumpAndSettle() delays or fake async timers.

💬 Discussion:

What is the policy regarding FutureBuilder and StreamBuilder in your team's codebases? Do you strictly forbid them in presentation code, or do you still find valid use cases for them?

In software engineering, we usually measure framework upgrades by what they add: new syntax, new macros, new features, new abstractions.

But after years of building and consulting on large Flutter applications, the most profound upgrade in developer experience isn't what new concepts you are forced to memorize—it’s the mental gymnastics, framework-specific edge cases, and defensive rituals you finally get to forget and unlearn.

A Quick Word of Respect

Before diving into technical details, let's establish something essential: Rémi Rousselet is a pioneer and a brilliant engineer. When Rémi built provider and later Riverpod, he solved real, glaring flaws in Flutter's core InheritedWidget mechanics (such as conditional dependency leaks and lack of compile safety). The entire Flutter ecosystem owes Rémi immense gratitude.

For years, I was a vocal, passionate—at times almost zealous—advocate for Riverpod. In discussions, podcasts, and client work, I routinely recommended Riverpod above classic BLoC, Provider, and nearly every alternative.

However, over the course of Riverpod's evolution across v1, v2 (code-gen), and v3, solving every edge case inside a global declarative provider graph led to a staggering accumulation of cognitive surface area. Building real-world Flutter apps with Riverpod today requires developers to maintain a complex internal rules engine just to avoid subtle runtime footguns.

When you switch to BlocSignal (which combines the architectural discipline of BLoC/Cubit with the synchronous speed and fine-grained reactivity of Signals), you realize just how much mental baggage you were carrying.

Here are a few of the biggest things you get to forget:

---

1. 🗑️ Forget build_runner and .g.dart Code Generation

• No more CPU fans spinning at 100% while waiting for build_runner watch.
• No more broken IDE autocomplete while waiting for _$MyNotifier part files to generate.
• No more build_runner build --delete-conflicting-outputs rituals after simple refactors.
• BlocSignal is 100% pure, standard Dart. Zero code generation required.

2. 🗑️ Forget the "Ref World vs. Non-Ref World" Boundary

In Riverpod, reactive state is strictly confined inside a ProviderContainer (the "Ref World"). If you are inside a ConsumerWidget, life is good. But the moment you step outside into standard Dart—HTTP interceptors, WebSocket handlers, background services, or routing—you are stranded in the "Non-Ref World" and forced to drill Ref parameters everywhere.

bloc_signals is a 100% pure Dart package with zero Flutter dependencies. A CubitSignal can be instantiated and observed anywhere—in Flutter widgets, CLI tools, Jaspr web apps, or Serverpod backend services.

3. 🗑️ Forget the routerProvider Navigation Stack Nuke

Because routers like GoRouter live in standard Dart, developers frequently wrap their router in a Riverpod Provider to watch authentication state.

Whenever auth changes, ref.watch recreates the entire GoRouter instance—silently destroying the user's navigation history stack, collapsing nested modal sheets, and resetting scroll positions with zero error logs or stack traces.

In BlocSignal, your router is a permanent, stable singleton. You simply pass cubit.state.toListenable() to GoRouter's refreshListenable. Zero router destruction. Unbroken navigation stacks.

4. 🗑️ Forget "Self-Disposing" Async Mutation Crashes

In Riverpod 3.0, auto-disposal is default. If a user navigates away while an async mutation is awaiting a network request, the controller is garbage-collected mid-flight, throwing "Cannot use Ref after it has been disposed" when it resumes.

To work around this in Riverpod, developers are forced into:

• Sprinkling if (ref.mounted) checks after every await.
• Creating separate "action controller" classes just for single method calls.
• Manually acquiring and releasing KeepAliveLink link = ref.keepAlive() tokens.

Think about how absurd that is: you end up writing meta-state management just to manage the lifecycle of your state management system.

In BlocSignal, state containers are standard Dart objects with explicit ownership. Async methods execute to completion, and if a Bloc is closed, emit() is safely dropped with zero runtime crashes.

5. 🗑️ Forget the AI & LLM Hallucination Nightmare

If you pair-program with AI coding assistants (Claude, Cursor, Copilot, ChatGPT, Gemini), Riverpod is notoriously difficult for LLMs:

• Version Multi-Verse: Training data mixes 4 conflicting Riverpod eras (v0.14 ChangeNotifierProvider, v1.0 StateNotifierProvider, v2.0 @riverpod, and v3.0 Notifier), leading to constant hallucinated syntax.
• Code-Gen Blindness: LLMs cannot inspect ungenerated .g.dart files, routinely botching synthesized class inheritance.
• Ref Scope Confusion: AI models constantly attempt to call ref in widget constructors or pass WidgetRef into deep business logic.

LLMs generate exceptionally accurate BlocSignal and blocSignalTest code on the first shot because BLoC and standard Dart OOP patterns are among the most represented and consistent paradigms in AI training sets.

---

🌉 Currently Mired in Riverpod? You Don’t Need a Big-Bang Rewrite

If your codebase is already invested in Riverpod, you don't have to rewrite from scratch.

Through bloc_signals_riverpod, you get a seamless, bidirectional interop bridge:

• Expose new BlocSignal features to existing Riverpod widgets via cartCubit.toProvider().
• Consume legacy Riverpod providers inside BlocSignal via legacyProvider.toBlocSignal(ref).

You can migrate your application incrementally at your own pace.

---

Curious to hear thoughts and experiences from others who have navigated the evolving state management landscape over the years!

Every few months, like clockwork, the tech blogosphere gets flooded with the same recycled clickbait: "Is Flutter Dying?", "Why CTOs Are Quietly Leaving Flutter", or "Why Google is Killing Cross-Platform."

As someone who has been a Flutter Google Developer Expert for eight years now (literally from day one of the GDE program) and a five-decade software industry veteran, I usually just chuckle at the headlines. But having watched this ecosystem evolve from an experimental alpha into an enterprise powerhouse, I wanted to share the real insider story on what’s actually happening on the ground.

1. What Actually Happened at Google?

When tech companies restructured engineering teams recently, the internet spun a wild narrative that Google put Flutter on life support.

Having direct access to internal teams, I watched the commitment to Dart and Flutter remain steadfast. However, there was a temporary disconnect: internal engineering activity was roaring, but external communications and public advocacy had slowed down, leaving an information vacuum that clickbait writers eagerly filled.

I personally called out to team leaders and senior VPs that this perception gap needed immediate correction. And leadership responded strongly: revitalized DevRel, transparent enterprise roadmaps, and aggressive core investment into the Impeller GPU engine, Dart 3.x ergonomics, and Wasm web compilation. Flutter powers critical Google apps (Google Ads, Google Pay, Family Link, Google Classroom) and continues to receive deep internal backing.

2. The Mobile Team Consolidation Paradox

Critics often look at public board listings and claim there are fewer dedicated Flutter listings than native Android or iOS.

What they fail to realize is how enterprises actually adopt Flutter: When an enterprise migrates to Flutter, they rarely expand outward with massive external listings. Instead, they merge their existing 5-person iOS team and 5-person Android team into a single, unified Flutter team—often cutting total team headcount in half while doubling feature velocity. Flutter's sheer efficiency creates the illusion of fewer raw openings.

And when greenfield Flutter positions do open up, applicants aren't competing in a vacuum—they are competing against senior mobile engineers with a decade of native iOS and Android experience who upskilled into Flutter. That’s a sign of a mature, competitive engineering discipline.

3. "State Management Fatigue" Is a Solved Problem

Another frequent complaint is that Flutter has "too many state management libraries."

Yes, Flutter gave developers freedom. Over the years, the community experimented with everything from ScopedModel and Provider to BLoC, MobX, and Riverpod.

That evolution isn’t a sign of fragmentation—it’s the natural progress of modern software engineering. We learned what worked (unidirectional data flow, state machines, fine-grained reactivity) and discarded what didn't (excessive code generation, microtask queue latency, and lingering build dependencies). Today, with modern solutions like pure Dart Signals and modern architectures, state management in Flutter is faster and more reliable than it has ever been.

4. The Measurable Reality

If you look at the hard data:

• Over 1,000,000+ Flutter apps published on app stores and growing.
• Impeller delivers smooth 60/120fps GPU pipelines, eliminating shader jank.
• Wasm compilation brings near-native performance to the browser.
• Universal Reach: Seamless execution across iOS, Android, macOS, Windows, Linux, Embedded, and Web (via Jaspr).
• Modern Dart 3.x: Sealed classes, pattern matching, records, and primary constructors.

Flutter is firmly in the Plateau of Productivity. It is mature, stable, blazingly fast, and supported by one of the most vibrant developer communities in software history.

So the next time you see a headline asking "Is Flutter Dying?"... smile, close the tab, and go build something great. 🚀

Please publish the changelog FIRST before deploying to customers. {hrmph}

It seems not too unlike a smoky meat flavor, but without the wonderful flavor of meat behind it.

I think the last time I was like this was back in what 87 when we had all the wildfires that blew smoke to the portland metro area?

To celebrate the launch of BlocSignal and our new website at https://blocsignal.dev, we built an interactive, playable Minesweeper case study app running live on the web!

⚡ What makes it cool under the hood (BlocSignal + Jaspr):

• 0ms Synchronous Flood Fill: Zero microtask queue latency when uncovering blank areas. • 100% Shared Business Logic: The exact same MinesweeperCubit runs in Flutter mobile/desktop apps AND Jaspr web apps with 0 code changes. • Zero-Backend State Hydration: Active game state restores synchronously across tab refreshes. • Shareable Challenge Seeds: Export & import Base64 seeds to challenge friends on identical minefield layouts! • Live GA4 Game Telemetry: Custom event tracking dispatched directly from Cubit state transitions.

👉 Come for the game, stay for the info! 🎮 Play now: https://blocsignal.dev/minesweeper ⭐️ GitHub: https://github.com/RandalSchwartz/BlocSignal

I've just published a consumable AI Coding Skill alongside the latest releases of bloc_signals (0.1.10), bloc_signals_flutter (0.1.6), and otel_bloc_signals (0.1.4).

If you are using AI code assistants (like Gemini, Claude Code, or Cursor) to pair-program, you can install this skill directly into your workspace to instantly guide your assistant on best practices, APIs, and architecture rules.

👉 Consumable Skill Directory: BlocSignal Skills Folder

⚙️ How to Install

Run this simple command in your project root to download and register the skill context for your local agent:

npx ctx7@latest skills install RandalSchwartz/BlocSignal bloc-signals

📚 What's Covered:

• 🔄 BLoC to BlocSignal Migration: A step-by-step walkthrough detailing how to transition from classic stream-based BLoC to synchronous signals.
• 🛡️ Sealed Class Exhaustiveness: How to override onEvent using Dart 3 switch statements and switch expressions to guarantee compile-time safety.
• ⚡ Computed & Effect Lifecycle Rules: Best practices for declaring reactive primitives. You'll definitely want to see how easy it is to add computed() and effect() properties for both producers (internal constructors) and consumers (external stateful widgets/Flutter Hooks) without leaking memory.
• 🔄 Stateful & Hooks Integration: Leveraging standard Stateful Widget lifecycles or eliminating boilerplate entirely using flutter_hooks and signals_hooks.
• 📊 OpenTelemetry Observability: Instrumenting dynamic zones, transition logging, and span correlation.
• 🧪 Synchronous Testing: Writing fast, synchronous unit tests without needing async microtask pump/waiting code.

#HumpdayQandA with Live Coding! in 30 minutes at 5pm BST / 6pm CEST / 9am PDT today!

The tech world is experiencing an identity crisis. Pundits are shouting from the digital rooftops that traditional coding is over, replaced by natural human language interfaces. They're calling it a radical new paradigm.

But if you’ve been paying attention to Perl since 1987, you know this isn’t a revolution—it’s a homecoming.

When Larry Wall created Perl, he didn’t just build a language to sit closer to the metal; he built it to sit closer to speech. While computer science worshiped at the altar of rigid mathematical purism, Perl introduced a context-aware structure built on nouns, verbs, singulars, and plurals.

Today, Large Language Models operate entirely on probability, semantics, and context. We've spent decades forcing humans to think like transistors; now, we've successfully forced silicon to learn human.

Perl programmers are uniquely wired for this future. We’ve spent forty years treating programming as an exercise in linguistics and context.

The community isn't fading into the past; it’s providing the blueprint for what's next. Case in point: The Public Enrichment and Robotics Laboratories (RoboPerl) are currently engineering PerlGPT—a model trained specifically to understand best practices, architectures, and the nuanced wisdom of "Perl poets."

The future of engineering belongs to those who can speak fluent intent.

👉 Watch Randal's full talk on how structural context is dominating the modern landscape

#SoftwareEngineering #ArtificialIntelligence #Perl #ProgrammingLanguages #LLM #TechHistory

(Not my article, but a good summary.)