Are there plans to port Google's material design c...
# compose-web
a
Are there plans to port Google's material design components to the web at some point? I understand some of them work for desktop already?
๐Ÿ‘ 1
b
Yes, they'll use skiko to render on canvas. Note that this will come at a cost of bundle size and losing accessability.
Skiko js support was merged quite recently
f
There are ways to make accessibility work, as it does in android and very recently in flutter too. Bundle size is going to be a big problem. Might make compose for web unusable.
a
Thanks for the info, Martynas
It wonder if a tool similar to R8 in Android could cut down bundle size by removing unused functions
b
You mean DCE?
c
DCE is already in place for JS. Using the Google Closure Compiler the size can be reduced further (~25% in my experience) but it's still going to be multiple megabytes
d
...or maybe it's time for us to think beyond JavaScript? ๐Ÿค” https://developer.mozilla.org/en-US/docs/WebAssembly/Caching_modules
โ˜๏ธ Already smaller by virtue of binary format, better performance due to compilation, first-class support for caching of modules to reduce network load on repeat visits to your web-app; and a (renewed) Kotlin/WASM target is a current, active goal on the Kotlin Roadmap. I sense a strong synergy with Compose for Web with Canvas ๐Ÿ‘Œ โœ๏ธ K
f
How much smaller? Downloading 2MB of dependencies, even first time only, is still a problem.
d
Not necessarily - It depends on the use-case. If you're dealing with high-volume consumer facing webpage, it may be an issue. However if I have a business web-application for a more targeted audience, and it caches after the first 2MB download (which anyway is going to happen in <5s on modern 4G/5G connections) then it's still a viable solution IMO. It's easy to balk at the size some web-pages are becoming (I sometimes do); but honestly if it's just an up-front loading cost (showing progress bar) followed by the web-App effectively being 'installed' in the browser cache, then I don't see how this is much different to the Mobile App installation lifecycle - just in the browser. With the richer client-side capability then afforded by Kotlin + Compose, an App built & loaded in this way could end up offering a much better UX overall. That said, I'd hope JB put some thought into how we can structure a WebAssembly App for progressive loading where needed.
๐Ÿ‘ 1
c
Just to add to that, Skia already has a canvas API for WASM...
๐Ÿ‘Œ 1
k
Do you know when we can receive build with such support? It's days, weeks or rather months?
b
I'd guess months. Main focus right now seems to be DOM rendering
k
Ehh good and bad, I hoped it could be easy Android-desktop port to the web, but not having it means quite big amount of work and I cannot decide what to do :D however now I have at least hope to port my app at low cost in the future
b
Compose android+desktop+web still makes sense IMHO, you're able to share your business logic, networking, view models and even compose effects. The only bits remaining are actual UI layout and that's it.
๐Ÿ‘ 2
Plus there's that familiarity and best practices that you can reuse, even if you are not able to do it with exact same code
s
A 2MB web app is completely in the realm of acceptable I think. Even last year my web team was shipping an 8MB app due to polyfills and support for ie. Honestly, if I can provide a reasonable experience to a user and share code between web, android and desktop, Iโ€™m a pretty happy camper.
๐Ÿ’ฏ 2
d
I have a hunch that this is being worked on more actively than has been let on - probably via Kotlin/JS but perhaps even as a WASM tie-in. It makes too much sense. @Dominaezzz pass me the envelopes; I'm making a prediction that Canvas-rendered 'Material Compose' for Web will get a surprise mention during the 2021 Premier week.
๐Ÿ“ฉ 1
๐Ÿ”ฎ 1
๐Ÿ˜„ 1
d
Sealed!
๐Ÿ“จ 1
๐Ÿ‘ 1
๐Ÿ˜† 1
d
Ooh yeah ๐Ÿ˜Ž
The property setting
skiko.wasm.enabled=true
alone, from that PR, is enough to put me in a happy place.
f
I'm waiting for
skiko.ios.enabled=true
๐Ÿ‘ 1