<https://twitter.com/sdeleuze/status/1639588268151...

# webassembly

[sdeleuze]

https://twitter.com/sdeleuze/status/1639588268151910401

[bashor]

Thanks, Seb for the such quick publishing 🚀

[Daniele B]

thanks @sdeleuze for the transcription!
Can you say something more about Compose?
Here it seems you are discouraging Canvas-based Compose/Wasm, which is something I am actually very interesting in, because it would allow you to share the same UI with Android (and potentially iOS too).
How heavier do you expect a Canvas-based Wasm Compose application to be w.r.t. HTML/DOM Wasm Compose?

Compose for Web provides in a nutshell 2 ways of drawing the GUI:

• Canvas-based pixel-perfect rendering

• HTML with DOM based rendering

While the first one is ok for let’s say build backoffices, for public websites, I tend to think we should keep using HTML lightweight rendering.

[sdeleuze]

Canvas rendering looks ok to me for backoffices or use cases where you want to share the same pixel perfect rendering between mobile/desktop/web backoffice.

But for public website, mobile website, ecommerce, SEO, accessibility, canvas rendering with 1 to 2 Mb of JS/Wasm as the minimum footprint is not ok. But yeah you loose pixel perfect and capability to share same components than on desktop/mobile.

So different tradeoffs, JetBrains/Google focus on Canvas but provide basic HTML/DOM building blocks. Some solution can probably be built on top of those basic buildings blocks to propose alternatives to Next.js/Qwik/Astro/Svletekit.

With Wasm I am ok to say goodbye to JS but I think there are a lot of use cases where a real web solution with server side initial rendering and « differential frontend rendering » make sense.

Something where customers would say « wahou, this web site built with Compose is super fast and footprint is so low! » and we keep a nice Compose DevXP.

[sdeleuze]

It is not just Canvas versus Dom, it helps to not have to ship the rendering engine but Compose is generally not yet super optimized for low web footprint yet, and you can gain also by moving most of the initial rendering on server side and keeping the notion of page and some constraints on what can be dynamic in a page.

[sdeleuze]

I will share some prototypes later, but I want to target less than 100K for the Wasm file sent on the frontend max.

[sdeleuze]

And if nothing is dynamic, should be zero.

[Daniele B]

In case of a desktop webapp, I think waiting for 2-3 seconds the first time the app loads it shouldn't be a big issue, if the benefit is to be able to reuse the same Android composables

[Daniele B]

So are we talking about 2MB size footprint for anything Compose?

[sdeleuze]

I need to check the exact size, but should be this ball park yes. For application this can be ok yeah, for public website not ok IMO.

[sdeleuze]

And it not just about the size (SEO, etc.)

[sdeleuze]

I have nothing against Compose for Web with Canvas rendering, I am just saying it misses very important use cases I am very interested about (public website, static site generator, e-commerce).

[Daniele B]

I understand your point. I agree Canvas is not suitable for websites where each screen needs to be SEOd. But I would expect (size allowing) Canvas to be a good solution for multiplatform compose applications.

[Suser]

would things like size / SEO eventually become a solved problem? or is there no hope of that

[sdeleuze]

Could you please elaborate?