HN Explorer

Show HN: Can we have Flutter-like portability without the bloated web binaries?

1 points by io_eric ↗ HN
I’ve been spending the last few months building Coi, a type-safe language that compiles to WebAssembly. The initial goal was just a fast, reactive web language, but as I refine the core, I’ve started mapping out how to take this multi-platform, mobile, desktop, and server, without falling into the traps that other frameworks have.

The plan is to use C++ as the intermediate layer. For desktop and mobile, I want to use Skia combined with a layout library to translate HTML/CSS sizing and transformations into something Skia can draw. This ensures the UI stays pixel-perfect across platforms.

However, the "Flutter approach" to the web has always bothered me. Shipping a 2MB+ Skia binary just to render a basic landing page feels redundant when the browser already has a world-class rendering engine. It results in massive bundles and a canvas-only UI that breaks basic browser expectations like SEO, text selection, and accessibility.

With Coi, I want to split the strategy: on the web, it stays lean by using the browser’s native HTML/CSS and JS glue. On native platforms, it uses the C++/Skia stack. You get the same codebase and the same visual output, but the web build doesn't suffer from "canvas bloat".

Right now, I’m still focused on the web target and refining the core language specs, but the server target is next on the roadmap. I'm curious if this "hybrid rendering" approach, native elements for web, Skia for desktop/mobile, is something others have found success with, or if I'm underestimating the difficulty of keeping the layout engines perfectly synced.

I'd love some feedback on the language design or the architectural plan.

https://github.com/coi

4 comments

[ 3.1 ms ] story [ 25.3 ms ] thread
ifh-hn
I'm not really qualified for useful feedback, but a while back when I was trying to decide on a truly cross platform development framework, I went with dart/flutter. The reason was, as a noob, I couldn't make any sense of the ridiculous, and ever growing, amount of web focused cross platform frameworks.

With all that said, since you mention flutter, which despite continuing rumours about it's demise, is established and extremely popular; what would make me drop flutter for this?

I'm not being flippant, it's a genuine question.

For me if it's smaller, faster, easily to learn (darts and excellent language, flutter is a lot more complicated), and quicker to write and deploy I'd use it.

io_eric
Honestly, the biggest difference is how they treat the web. Flutter brings its own entire rendering engine to the browser to draw pixels on a canvas, while Coi is designed to use the browser's native HTML and CSS.

If you’ve used Vue or React, Coi will feel much more familiar. It’s a component-based model where your logic, styles, and markup live together, but you get strict static typing and native-speed performance via WASM.

The goal is a true "write once, run everywhere" workflow. On the web, it stays light by using the browser's engine. For mobile and desktop, the plan is to map that same HTML/CSS styling and component logic to a native C++/Skia backend. You get a native app's performance without losing the web's layout flexibility.

matt_kn
Bundle size matters until it doesn't. Flutter is absolutely not suitable for web pages, but for web applications the situation is different. I was quite hesitant about Flutter web, up until around 3 years ago, the binary size being biggest concern. That was until I looked at Linear (which we used back then) and found out that the download is several times larger than whatever we were building with Flutter web, and nobody cared. I used to obsess about every kilobyte transferred, but I think at least when it comes to applications, that time might be over.
io_eric
Technically, it’s not just about the download pipe. A 2MB+ WASM blob or JS bundle imposes a heavy CPU parse/compile tax. On mid-tier mobile devices, this results in main-thread jank and a 'Time to Interactive' (TTI) that kills user retention before the first frame even renders.

Beyond that, the 'Canvas-only' approach is computationally expensive. You are effectively re-implementing a rendering engine (layout, hit-testing, paint) on top of a rendering engine. While the browser's native DOM/CSS engine is a highly optimized, hardware-accelerated C++ powerhouse, a Canvas-only app has to manually calculate every pixel and handle every event in the WASM/JS loop. This drains battery faster and runs hotter than letting the browser do what it was built for.