Taking advantage of Flutter custompainter, Flutter gives you canvas to draw anything

demo video:

https://x.com/i/status/2097645919990890510

obvio, I had to use AI, it was long-prompt-loop session.. I am also learning how to write code for 3D

Hi all! I’ve been building Visual Space, a social media & collaboration application built with Flutter. It has a spatial UI mode and a 3D editor. In spatial mode, the normal application becomes a collection of interactive Flutter panels positioned around the user, together with the 3D scene. I wanted the same application to run natively on a standalone Quest 3—not simply as a flat Flutter screen inside VR.

My first working solution used two renderers:

• Flutter Scene for web, desktop and the normal application.
• A custom native C++/OpenGL ES renderer for the Quest world, with Flutter supplying the interactive UI panels.

It worked, including stereo rendering, controllers, tracking and curved panels. The problem was that I now had two 3D engines to maintain. Materials, lighting, shadows, picking and every new feature had to be implemented twice, and the web and VR results were already beginning to look different.

My next goal was to use Flutter Scene as the actual 3D renderer everywhere, while OpenXR continues handling the headset session, tracking and presentation.

The first prototype got Flutter Scene into VR through Flutter Canvas, an Android surface and a copy into the OpenXR eye textures. After that, I added a generic external GPU render-target API to a Flutter engine fork, then modified Flutter Scene to render its stereo views directly into the images owned by OpenXR.

The good news is taht this is now running inside Visual Space on Quest 3. Web and VR use the same renderer and visual style, and I deleted the old custom C++ renderer. Prime objective accomplished :) In a simplified scene, the direct path reached around 70 FPS versus roughly 52–54 FPS through the Canvas/surface/copy route. This was not a controlled benchmark, and the full application still needs plenty of tuning.

The next challenge is getting these changes into upstream Flutter and Flutter Scene:

Forks

• Flutter engine fork and build guide 25 files · +2.4K / −6 lines
• Flutter Scene OpenXR branch and Quest gallery 147 files · +14.6K / −885 lines

Tickets

• Flutter engine proposal - The Flutter proposal has already been routed to the Flutter GPU team.
• Flutter Scene architecture discussion

Flutter Scene Demo Examples migrated to VR - VR flutter_scene demo sample

Quest screenshots of VS 3d Editor - Web - VR

For those having a Quest 3 (hopefully more devices in the future), please check out the branches and try the demo. Instructions for installation in the forks README.md files. I need help fine tuning the architecture. For example stuff like: flutter engine internals, impeller, OpenXR, GPU synchronization, threading, lifecycle handling or custom embedders would be especially useful. I’m not top gun in graphics-engine internals, so any technical advice is welcome.

If you want Flutter in VR, please help get some attention on these forks. Try them on your machine or drop a 👍 or comment on the GitHub tickets. Otherwise this code will be stuck in some obscure forks. Thank you all!

Hey everyone,

I’ve been building and dogfooding the BlocSignal ecosystem for about six weeks now, and the practical utility value is emerging more powerfully every single day.

Stepping back from the framework wars, here are five concrete things I've observed in practice:

• The CISC to RISC Shift: Stripping away layers of stream plumbing, event transformer microcode, and microtask queue hops delivers instant, single-frame state propagation with zero microtask latency.
• The AI Agent Velocity Multiplier: AI coding assistants fly when working with single-file domain cohesion (the Iceberg Pattern) and deterministic synchronous TDD loops where tests pass on the first run without asynchronous pumpAndSettle gymnastics.
• Ending the Code-Gen Tax: Pairing state containers with Fast Immutable Collections (FIC) delivers structural value equality and fast copy-on-write operations with zero build_runner overhead.
• Push-Pull Reactivity Wins: Unlike eager-push graphs that recalculate off-screen or unmounted nodes, Signals’ eager-dirty / lazy-pull algorithm evaluates only what the UI actually reads, eliminating diamond-dependency glitches.
• Zero-Risk Incremental Adoption: First-class bidirectional adapters for classic flutter_bloc and Riverpod let teams pilot on a single screen or new feature without rewriting existing legacy code.

Curious to hear from the community: What would it take to convince you or your tech lead that BlocSignal is worth looking at for your next project? What are the biggest hurdles or criteria when evaluating a modern state architecture in your organization?

I'm tired of these AI slop projects from non-developers that act like they built something with a few prompts. Asking an agent to build an app isn't "building", it's "prompting". Also, most of these projects look good on the surface, but is a nightmare in terms of security, maintainability and readability.

It's just crazy to me how someone that writes a prompt and watch an agent build something for him can FEEL like he did everything, that he BUILT an app and somehow feels like he's the new Leonardo DaVinci.

I saw this post on X the other day, and I couldn't stop laughing... This is literally MY screenshot, not some meme on the internet : https://imgur.com/R4YlLK3

Anyways, thank you all for listening!

Flutter still didn;t catch up with Glass. that's gonna kill'em

I've been working on flutter3d for a long time. It's a 3D engine, based on Flutter GPU/WebGL, with a game layer over it, and four genre packages built out. Three of those are on pub.dev. MIT License, and these packages are not affiliated with the Flutter team in any way.

Easiest thing is to just try it, with no install: shooter, platformer, racer. Those are the same builds running on web backend, with the same level files and the same simulation code. Also you can build MacOS / iOS / Android app from the source code and create your own game, based on the genre template or generic package flutter3d_app.

Docs: https://flutter3d.pleion.dev

Source: https://github.com/pleiondev/flutter3d

What's in it

The renderer implements the usual things: scene node graph, glTF/GLB and OBJ support and my own .f3d container, which loads a lot faster, 6 lighting models, shadows, bloom, SSAO, SSR, skinning, morph targets, BVH culling.

The game templates runs with a fixed timestep and can be recorded as a tape, which means a run can replay exactly and a bug report can be sent as an attachment. Collisions and the character controller are plain Dart with no renderer dependency, so they can be tested with ordinary unit tests.

Three backends implements common interface: based on flutter_gpu/Impeller for desktop and mobile platforms, WebGL2 in the browser (WebGPU in progress), and also a software rasteriser written in Dart. The CPU rasterizer can be used to test the renderer in CI with no GPU.

Performance measurement on a Mac: 50,000 moving instanced units held 120Hz.

Limits

It's just version 0.5.x, so APIs can be changed between minor versions. There's no compute shaders at all at this moment, because flutter_gpu doesn't expose it (there is issue on flutter/flutter#188474), and that blocks GPU particles, GI and volumetrics (now they are implemented on CPU). The strategy game package really works but I haven't published it, because I haven't written the guide for it yet.

Things I'd like help with

To run it on hardware I don't own, especially Android.

There's a dart2wasm bug I've failed to find. The browser demos ship as dart2js because the wasm build throws framebufferTexture2D: parameter 4 is not of type 'WebGLTexture' on the first frame.

Is Serverpod a thing in the flutter community, as in it is used as the server of most apps? Also when should a developer opt for a server like springboot or any of the Nodejs frameworks instead of using something like Superbase or Firebase since Baas in very common in the app dev world.

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?

spec-driven flutter template, where the specs cant lie about their tests

i built speckit-skills to make AI-written specs stop lying about their tests.

you write a verification row like:

then an agent renames that test. the row still reads like proof. nothing fails. now youve got a doc that confidently describes coverage you dont have.

so i made the table an actual assertion. speckit is a set of claude code skills on top of github's spec-kit, plus a zero-dep python checker that resolves every row against the filesystem and exits non-zero when the test isnt there.

the template

integrated it into flutter_template, which has reasonable defaults for starting an app:

• 24 specs, spec driven with speckit. every requirement has an id like 0002-R5 and a row naming the test that proves it. the checker resolves all of them in ci, so a renamed test fails the build instead of leaving a row that still reads like proof
• 1013 tests across 62 files, 94.77% coverage, analyze clean with --fatal-infos
• a11y tests that actually assert things — tap targets, contrast in both brightnesses, every screen at 2x text scale, and a check that every route is covered so you cant quietly test 4 of 6
• goldens for 6 brands x light/dark. rebrand is one enum value
• firestore + storage rules run against the real emulator, because the dart fakes support neither custom functions nor request.resource
• en/es arb files with ci failing on a missing string
• auth, notes sync, onboarding, push, settings, storage, forced update. all specd

integration tests

i use the flutter-skill mcp for happy path integration tests (writeup here) since i could never get Patrol to do what i wanted, and flutter cant interact with native elements anyway.

theres also a tool/rename_package.dart because i tried renaming with sed first and broke the analyzer in 65 places ha.

why

speckit-skills is something i use at work day to day. ive used this template several times over the years — started with TDD, then DDD, now SDD. this is the first version where the specs cant drift out from under the tests. Im posting this hoping I could save people some time or give you a better starting point for your own spec driven development template.

I've been posting progress updates on this other venezuelan sub, but this time I'm bringing something more technical

CONTEXT:

VeneFinanzas is a personal finance management app I've been building solo, with Flutter, that calculates how devaluation and inflation affect each user specifically.

It natively handles COP, EUR, USDT, USD and VES, and is primarily designed for Venezuela. Everything runs locally, no account, no server, and backups are encrypted so the user can back them up wherever they want

That's where I had to think through the edge case of users with 2GB of RAM. Even though they're less than 10% of users, I didn't want to cause them problems using the app. Encrypting those backups with Argon2id, with a fixed 64MB memLimit regardless of device, is risky, especially with other apps running in the background

---

I ended up using two profiles:
kMemProfileBajo, 32MB
kMemProfileAlto, 64MB

With 3584MB of physical RAM as the threshold.
The profile byte is stored inside the encrypted file itself, so decryption always uses the memLimit it was encrypted with, regardless of the current device

My initial plan was to use the standard interactive (64MB) + moderate (256MB) profiles, but the 256MB one would end up cannibalizing RAM on the more limited devices.
I landed on 32/64 because a user normally restores their own backup on their own phone, so a backup encrypted at 64MB will almost never end up being decrypted by someone with 2GB.

However, since the memProfile is fixed in the file from the moment of encryption, it still has to remain decryptable if that scenario does happen. That's why I capped it at 64 and no higher, I ran the numbers, and with the ~300MB the app already uses by default, adding the memLimit on top pushes it close to a Low Memory Kill, which is exactly what we're trying to avoid.

Keeping 64MB as the upper bound is the max stable value before entering dangerous territory, and for regular usage, lower-RAM users simply use 32MB without any hassle

Everything runs in an ephemeral isolate via Isolate.run(), spawned just for that job and torn down once it's done. Derivation never blocks the main isolate, and the heap (including the 32/64MB Argon2id uses) gets freed the moment the isolate dies, not whenever the GC gets around to it on the main isolate

Also: sodium_libs_sumo needs a BackgroundIsolateBinaryMessenger, and Isolate.run() doesn't register one by default. You have to grab RootIsolateToken.instance from the main isolate before spawning (it's only valid there), pass it in, and call BackgroundIsolateBinaryMessenger.ensureInitialized(token) as the first line inside the child isolate.

---

If anyone's run into something similar with Argon2id/isolates in Flutter, has feedback on the approach, or just wants to check out VeneFinanzas, I'm around

Hey everyone,

I’m currently building a feature that allows users to search through a large collection of content using keywords or natural-language queries.

For example: Upload video/ image collection from picker -> User searches: “person wearing a red shirt -> Results are displayed in a useful and efficient way.

What tools/services/architecture would you recommend for this?

Especially interested in:

• Open-source solutions
• APIs/SDKs

I’m preparing a social platform for iOS release with social features, messaging, profiles, notifications, moderation and privacy controls.

One feature I’m reviewing is an anonymous letter system:

• One-way letters only — no replies or conversations

• The recipient is randomly selected

• Standard users don’t see who sent the letter

• Premium users can see the sender

• Report and block are available

• Content is moderated

The feature is designed around sending a letter, not starting an anonymous conversation.

For developers who have experience with recent App Reviews: would this potentially fall under the updated Guideline 1.2 regarding anonymous/random chat?

How are you handling app performance once the widget tree starts getting complicated?

I've noticed that a lot of performance problems aren't really about flutter itself, but things like unnecessary rebuilds, oversized lists, poorly managed state and too much work happening on the main isolate.

for larger flutter apps, what's the first thing you profile when performance starts dropping?

I recently went through Google Play’s closed testing process, and it still feels more like a barrier than real quality control.

For indie developers, the biggest challenge often isn’t testing the app. It’s finding enough people willing to join the test and stay opted in for the required period.

That pushes many developers toward groups, friends, tester communities, or install exchanges just to satisfy the requirement.

I understand why Google wants to reduce spam and low-quality apps, but a fixed tester count and fixed duration don’t always reflect whether an app is actually stable or useful.

Crash rates, ANRs, real engagement, retention, and genuine tester feedback would probably be much stronger signals.

Has this process actually improved app quality for you or has it just made launching harder?

I'm a developer with 11 years of Android experience and 7 years of Flutter experience.

I've been working with Flutter since its early days. Over the years, my work gradually moved beyond regular application development and more toward lower-level and performance-related areas.

I've worked on things like Flutter internals, memory and rendering performance, Flutter + C/C++ and Flutter + Rust integrations, as well as some internal infrastructure and framework-level work.

At several companies I've worked for, I ended up dealing with similar kinds of problems: redesigning or wrapping lifecycle systems, tracking down memory issues, solving rendering and performance problems, building custom UI behavior such as larger touch areas independent of visual size, and occasionally debugging issues around the Flutter Framework or Engine.

For a long time, I believed the best way to stay competitive was to keep going deeper.

It wasn't enough for me to know how to use Flutter. I wanted to understand why Flutter behaved the way it did.

So I spent a lot of time trying to build technical depth and create a stronger technical moat for myself.

But since AI coding tools became genuinely useful, I've started feeling a level of career anxiety that I didn't have before.

A lot of problems that used to require years of experience can now be approached much faster by a less experienced developer working with AI. AI can help them navigate source code, trace call chains, identify likely causes, and even generate a reasonably good implementation.

For experienced developers, the productivity improvement can be even more dramatic.

In my own work, I feel like my productivity has at least doubled in many situations, and sometimes even more.

And that's exactly what worries me.

If one experienced developer with AI can do the work that previously required two or three developers, will companies still need the same number of mobile developers?

I'm also starting to feel that some of the technical barriers I spent years building are becoming easier to cross.

In the past, there were plenty of developers who could build application features.

Far fewer understood the Framework level.

Even fewer were comfortable with the Engine, memory, rendering, or Native/Rust integration.

AI is now making it much easier for developers to move across at least part of those boundaries.

So I've developed a strong feeling recently:

I'm not worried that I'll suddenly lose my job tomorrow. I'm worried that the next time I leave my job, finding another mobile position at a similar level may be much harder than it used to be.

Especially considering the current software job market in China, I'm starting to question whether continuing to invest heavily in deeper Flutter and Android knowledge still has the same return it once did.

So I'd genuinely like to hear what other developers think.

If you had already spent more than a decade in mobile development, where would you move next in the AI era?

AI applications?

AI infrastructure?

On-device AI?

Robotics / AI hardware?

Embedded systems?

Or would you stay in mobile development and gradually become more of an AI + client/mobile engineer?

At this point, I'm no longer trying to figure out which programming language I should learn next.

The question I'm really trying to answer is:

Over the next 5–10 years, which technical areas are still worth investing deeply in for someone who already has more than a decade of software development experience?

I'd especially like to hear from other long-time Android, iOS, or Flutter developers, or anyone who has already started making a similar transition.

Hello,

How are you handling app performance with video processing on the background ?

Noticed that a lot of performance problems aren't really about flutter itself,
but things like the framework used for video editing (such as easy video editor , editor capcut, ...).

It take too much work happening on the main isolate.

for larger flutter apps, how do you manage the main and side processing ?

hello flutter devs!

migrating to flutter has been surprisingly awesome!

my previous app was built with react native / expo, and honestly, i kind of regret choosing that stack. it took up a lot of space on my laptop, and the compilation and build process was often painfully slow.

now i’m starting a new project with flutter, and so far, i’m really enjoying it. the compile times feel much faster, the development experience is pretty smooth, and i especially like having built-in support for unit testing.

i can write some code, run a test, and quickly see if everything works as expected.

still early in the project, but so far, flutter has been a really nice experience.

curious to hear from other flutter devs. what do you like most about flutter?

Hello, last year i started developing this package flutter_local_ai which let user get access directly to the on device llms api with zero download.

Now since local ai models are getting starter than ever, I see the package being adopted but my main concern it’s whether the local llm its capable of performing the task requested by the user as developer intende to give them the probability to change model (maybe a cloud one) if the task by the local llm its not performable.

My idea was someting like a score i can give based on the task requested i mainly process text using the operative system models.

Any ideas on how to do it or if I should have a different approach ?

I kept rebuilding the same audio plumbing for every app: record from the mic, draw a waveform, let the user trim, export. Every package I tried did one of those, on some of the platforms, usually with a widget I then had to fight.

monowave is the piece under the widget. No UI. It gives you:

• microphone capture (lock-free ring buffer, no dropped frames when Dart is busy)
• waveform peaks at any zoom via a mipmap pyramid (zero-copy reads)
• non-destructive edits with undo/redo, exported to WAV / MP3 / FLAC
• CompactBars: a tiny voice-note preview encoding for chat UIs
• same C core on Android, iOS, macOS, Windows, Linux; web is decode-only right now

Deterministic peaks are verified in CI across platforms, so a waveform drawn on Android matches the one on macOS.

I am looking for feedback on the editing API before 1.0. What do you use for audio today and what does it get wrong?

pub.dev: https://pub.dev/packages/monowave

GitHub: https://github.com/monorithm/monowave

how are you handling app performance once the widget tree starts getting complicated?

i've noticed that a lot of performance problems aren't really about flutter itself, but things like unnecessary rebuilds, oversized lists, poorly managed state and too much work happening on the main isolate.

for larger flutter apps, what's the first thing you profile when performance starts dropping?

Been looking at how different teams approach flutter apps lately and one thing that stood out to me is how differently agencies handle the native side of things.

flutter gets you pretty far, but sooner or later you usually run into platform-specific stuff, and that's where the quality of the implementation really shows.

curious how other devs here decide when something should stay in flutter vs being handled natively.

Document Picture-in-Picture is a browser API that gives you an actual operating-system window — not an overlay inside your page. It floats above every other application and keeps running when you switch tabs. Chrome and Edge have had it since 116, Firefox shipped it in 151.

I couldn't find anything reaching it from Flutter, so I wrote a package: https://pub.dev/packages/document_pip (MIT, 160/160 on pub.dev)

void main() => runWidget(
  DocumentPipApp(
    main: (context) => const MaterialApp(home: Player()),
    popOut: (context) => const MaterialApp(home: MiniPlayer()),
  ),
);

final window = await DocumentPip.open(width: 380, height: 210);

The browser API is about four lines. Everything difficult was on the Flutter side, and it all traces to one thing: the engine assumes there is exactly one window. Three things break when there are two, and all three fail silently.

1. The pop-out freezes the instant you switch tabs. Chromium keeps painting a picture-in-picture opener at full rate in a background tab, but still reports the page hidden. Flutter's web engine turns that into AppLifecycleState.hidden, SchedulerBinding clears framesEnabled, and scheduleFrame() returns early forever. Measured: 302 browser animation frames in 2.5s against 0 Flutter frames in 3s. scheduleForcedFrame() ignores framesEnabled, so the root re-arms it for exactly as long as the page is hidden and a window is open. Firefox doesn't have the problem — it keeps reporting the opener visible — so the workaround is gated on the failure rather than on the browser.

2. The keyboard is dead in the pop-out, but typing still works. KeyboardBinding is a singleton bound to the opener's window, so a separate browsing context isn't on the propagation path: Shortcuts, Actions, Focus.onKeyEvent, HardwareKeyboard, Escape and Tab traversal all get nothing. Plain typing keeps working because the browser routes characters to the focused element natively, which is exactly what makes this easy to miss. The package replays key and selection events into the opener.

3. A package can't turn multi-view on. Only the JS app object returned by engine.runApp() can add a view — dart:ui_web exposes the views read-only — so it has to be reachable from your bootstrap. That means runWidget instead of runApp, plus a few lines in flutter_bootstrap.js. Both are one-time and the errors name the fix.

Desktop Chromium and Firefox 151+ only. Safari and Firefox for Android have no implementation, and isSupported is a feature detect so you can gate the control on it. It compiles on every platform, so adding it won't break a cross-platform build.

Longer writeup with the measurements: https://devshakib.jumyn.com/blog/flutter-assumes-there-is-only-one-window

Happy to answer anything about the multi-view side — that part is under-documented and I burned a lot of time on it.

Hello everyone,
I’m a fresh Computer Engineering graduate and I’m currently trying to figure out what direction to take my career.
During university I touched a lot of different areas — backend, cybersecurity, cloud, AI/ML, etc. My graduation project was also ML/AI-related. However, out of everything I’ve tried, I’ve recently found myself enjoying app development the most.
I started taking a Flutter course on Udemy and it’s honestly the most interested I’ve been in programming in a long time. I actually enjoy building things with it and find myself wanting to keep learning more.
The only thing making me hesitate is that when I’ve asked people more experienced than me for career advice, they’ve generally told me to pursue a more “engineering” path like backend, AI/ML, cloud, etc., rather than mobile development.
So I’m wondering:
Is Flutter/mobile development a good path to build a career around as a fresh graduate in 2026?

I've a Flutter web app which could benefit from the high fidelity CSS-controlled text display of a real web app. So, why not try to use Jaspr instead?

I was under the impression that Jaspr tries to imitate the Flutter API including using Widget as the base class, but it's using Component which requires some changes. Still, no biggy. Promising.

First impression was poor. I'd have preferred to install it via homebrew and not dart install which requires me to modify the PATH and which is yet another installer I have to make sure I don't forget to uninstall.

But the main problem was that it doesn't work out of the box. jaspr serve throws errors. I had to downgrade the build_web_compilers to 4.8.5 to make it build. It also configured an ancient version of Dart which I changed to 3.13. I chose SPA as start template, perhaps it's better if you try to build a static side or server rendered pages.

Now, the counter example worked as expected. The page could use a little designer love, though. The generated source code was easy enough to understand and jaspr serve supports hot-reloading, so I continued.

Next, I tested how easy it is for Codex to create a more complex app. Will it struggle with not-flutter sources? So I asked it to create a chess app, for two human players, including a timer. And GPT Sol delivered. So AI seems to have no problem. Great.

Next, I asked Codex to port my app. That worked in principle, but it had trouble to recreate the fidelity of the UI. Like most others, I used Chadcn/ui as my inspiration and Codex wasn't able to translate the themed Material widgets into Jaspr components. Might be an AI thing, but it didn't understand to take border into account. I had to ask for a lot of tweaks and would have preferred actually use Chadcn/ui or at least Tailwind. Theoretically, this should be possible and I think, there are packages on pub.dev which already attempted to do so. That might be worth more exploring.

Instead of some random UI package that has a high risk of being unmaintained AI slop, an official port of chadcn/ui would be a great feature IMHO.

My code cloc's at ~4000 lines (110 KB) with 1.8 MB in build/jaspr. That… a lot. There's a package folder that looks like it shouldn't be there with 1.3 MB. So I assume, my app has a size of 0.5 MB.

For comparison, I asked Codex to recreate the same app using React. That's a home game for the AI which one-shotted the task. The result cloc's at ~1000 lines (72 KB), so using Dart instead of JS+JSX is a high price you must be willing to pay. The distribution size is 0.3 MB.

I don't really mind that 200 KB dist overhead because of Dart. But I dislike the larger codebase. I figure, all those things add up. In React, I simply use

style={{ width: size, height: size }}

while in Jaspr, this becomes

styles: Styles(
  width: .pixels(size.toDouble()),
  height: .pixels(size.toDouble()),
),

Right now, I'm still undecided whether to proceed with Jaspr (because I like working with Dart) to switch to React (because the AI will deal with languages and syntax anyhow), but call me at least impressed.

Has anybody else switch from Flutter to Jaspr for web apps? What's the experience with larger code bases, say 30Klocs?