https://kotlinlang.org logo
Join Slack
Powered by
I made a compose wasm app, it is not a pet project...
# random
o
I made a compose wasm app, it is not a pet project, but something serious. And I am about to launch it, but I am having second thought. It has a backend, AI and CRUD support. I have seen a wasm web app but not a wasm compose web app. I am thinking of converting the UI to react. I don't know much of JS. I usually build with compose multiplatform. 🙄 🙂
s
Why do you think React would be better? Compose Web Apps feel a bit different, because they are not manipulating the DOM, but drawing into a Canvas. That means you just can't select text and copy&paste, also scrolling feels a bit different.
https://stefan-oltmann.de/exif-viewer is my WASM Web App with DOM manipulation ... because Compose for Web wasn't stable enough at the point I made it.
If you're looking for examples of Compose Web Apps, I made some: https://stefan-oltmann.de/pixelsafe https://stefan-oltmann.de/mines https://seed-browser.stefan-oltmann.de All Open Source on GitHub, if you like to review the code.
In #C0BJ0GTE2 there are some more examples for Compose Web Apps others made. It can be used in production.
What kind of app did you make?
o
People visiting the might think it feels different. It an app that can help transcribe and manipulate media files
s
Yes, Compose Web apps feel more like Android apps running in your browser rather than real web apps. It's their nature.
You can feel how that is if you scroll in my seed browser above.
People will notice that scrolling feels different, that they can't select text or in general don't have a right-click menu. Okay, for the last part... you can disable that with JavaScript, too.
My ONI seed browser has a bigger community around it. Some people notice that, other's don't. A lot of them don't care at all.
I looked into making more native web apps with kobweb and others, but to be honest: I want a single codebase for Desktop, Android and the web. Not something special for the web.
It an app that can help transcribe and manipulate media files
In what parts do you think people will notice the difference and might not like it?
o
I am planning to launch it on android and ios later but my target is web first. That is why I am investing so much on it
s
Ok, but you won't have a Compose UI for Android & iOS then, or will you?
Webpages in Apps, where the app is usually just a wrapper around a webpage, don't feel that great to me.
If you don't want to make the UI twice, you need to choose your poison and either make an app that doesn't feel native on the web or an app that doesn't feel native on iOS & Android.
For Ashampoo Photo Organizer I spent a lot of time making the UI twice... in Compose & SwiftUI... you usually don't want to make the UI twice.
o
I think when they want to open in a new tab, or save an image to their 'that is right click to save they can't do that. It is a multiplatform app. The platform implementation for web is done but the ios and android is not yet complete
s
I think when they want to open in a new tab, or save an image to their 'that is right click to save they can't do that.
Yes, you don't get that out-of-the-box for Compose for Web apps. You need to implement it. It's possible though.
o
I don't really mind those drawbacks like open new tab or save image
s
https://stefan-oltmann.de/pixelsafe lets you download the file, too. You can look at the code how to do it.
New tabs are also possible using the LocalUriHandler
s
if web is your primary target then don't go for anything in a canvas
s
If you don't want to make the UI twice, you need to choose your poison and either make an app that doesn't feel native on the web or an app that doesn't feel native on iOS & Android.
As I said.
Maybe you don't need an Android app at all.
I'd like an option to generate a native Web App (DOM manipulation) from a normal Compose Multiplatform app, but that's unfortunately not on the menu. Kobweb and all the other alternatives I checked out offer their own syntax. Nothing is directly generating a native web app from regular Compose.
How much UI / screens do you have? If it's minimal you maybe can actually do the UI twice. Give us more info.
o
Should I check out kobweb? I have heard and watched a tutorial in it before
s
I'd do that rather than learning React I think.
But I don't know JS and I'd not vibe code something I can't maintain / fully understand.
o
My screens are less that 7, but I think as I improve it, it will increase
s
I'd advise to not do the UI twice. I'm fed up with that.
s
thing is, users won't care about how cool your tech is and that you only had to write UI once. user experience matters a lot more
👍 1
☝🏻 1
speaking for real products ofc
it's fine when web is a second class citizen as an alternative for installing apps. but imagine github as a canvas app, I'd quit
➕ 1
s
True. I'm talking about the effort and maintenance. As I said every solution has drawbacks: 1. Making the UI twice -> great for users, but takes a lot of time. 2. Making the UI native for web -> not so great mobile app experience 3. Making the UI native for Android -> Compose for Web doesn't feel native to the web
👍🏻 1
If you go for the web, make a native app there and make it an PWA instead of an Android app.
PWAs don't feel that great, but for iOS it safes you 99$/year
o
I have not heard of PWA before, thanks, I will check that out
✅ 1
s
In my case at least my ONI seed browser is a "real product" (at least with 1000+ real users / day), but I don't care that they don't have the best possible experience. My joy of making and maintaining it is more important. But it's also a free app, so I might care more if I had paying customers that write me they don't like the experience.
I have not heard of PWA before, thanks, I will check that out
Thanks to the one and only @אליהו הדס all my mentioned web apps above are PWAs. You can look up on my GitHub how to do it.
I hope JetBrains will give us the option to generate a DOM-based web app from regular Compose code. Would be awesome and solve a lot of problems.
But I believe it's a huge undertaking.
o
Kobweb is a PWA. I will check out kobweb. Thanks guys
s
Didn't know it comes with PWA support out of the box. That's helpful. Wishing you all the best.
P.S., small guidance: When it's ready and not open source, you can show it to us in #C01Q62JMKBP When it's open source, share GitHub link in #C0BJ0GTE2
👍 1
j
Compose WASM felt incredibly slow on Safari the last time I've tried. Not sure if this has changed. Just something to consider. Accessibility of the apps I tried also wasn't great - e.g. couldn't select text
s
Did you try other browsers in comparison?
j
Yep, Chrome was much faster.
m
@Stefan Oltmann Why do you say "you just can't select text and copy&paste"? You just have to wrap all your text in a SelectionContainer like this:
Copy code
SelectionContainer {
    Text("This text can be selected and copied by the user.")
}
Or did I misunderstand what you said?
s
Yes, you need to do that to every text. And still you don't get the usual context menu.
Compose Web apps just don't feel native to the web for multiple reasons.
m
That's true. The fact that you don't get a context menu is annoying and I think I have reported that already somewhere.
Who defines how a web app has to look and feel? For me web apps and especially PWAs should just behave like desktop apps, if they are running on a desktop, and mobile apps, if they are running on a mobile device. I am always unhappy with the appearance of web GUIs, so why should I try to replicate that? I only like the ease of deployment on different platforms avoiding all the installer building and app store issues.
👍 2
s
I completely agree. That’s why I’m fine with making all my apps Compose Web apps. It’s more enjoyable to build and easier to maintain. The only thing is, some users notice that Compose Web apps behave a bit differently when it comes to scrolling and other UI details. For example, you often need a custom scroll bar, and if it doesn’t match the browser’s default behavior, users will pick up on it. For me, it’s not a big deal, but for some users, it might stand out.
u
@Ohiorenua Aigboje Check out my gallery; it uses the latest alpha version of Compose, which greatly improves performance. My code isn't very optimized, and yet I find the performance very, very good. https://kdroidfilter.github.io/compose-macos-26-ui/
🚀 2
This gallery handles native browser navigation and resource preloading very well. The bundle itself isn't very large at 5.5 MB, which is really nothing in 2026. I think it's a very good alternative. I've also refined the UI for small screens. I think this app contains a lot of basic knowledge for learning how to build a Compose Web app. I haven't implemented the PWA yet, but that's something I'll do next.
I think the main thing is to know what's acceptable and what isn't on the platform you're building an application on. An Android developer doesn't become a desktop developer just because they know how to use Compose. There are good and not-so-good patterns. It's the same for the web; some things are acceptable and others less so. To sum it up, on the web you don't have title bars, bottom bars, bottom sheets, or animations at every transition. That's Android, not the web. The web is long pages, hamburger menus, etc. If you follow the patterns, your users won't notice anything.
👍 1
o
I will check it out. My app right now is 12mb which is not too large
u
12mb in release mode ?
o
No when I run it. I have not build a released yet
u
release is much lighter
s
one of the biggest differences is that web uses links and not buttons to navigate. so you can't open it in a new page, can't copy the address or preview it etc. it just kills the navigation flow of some users. That's more important to me than the UI
🤔 1
u
chech my gallery
s
yes I'm on it and it has the same problem
u
no it's work
s
it is navigating using buttons. well, to be fair, it's only changing the fragment anyway
u
I don't understand what difference that makes.
s
like I said. you cannot open anything in a new tab. you cannot copy the link address or see the preview (bottom left)
u
You can implement your own context menu for this, but yes, you won't be able to use the previews.
s
you also need to support any shortcuts like mouse-wheel click or ctrl click which opens the site in a new tab
also, I'm not sure if password autofill works yet
u
yes autofill is a big problem
s
and there's no fallback to system fonts. for a global audience you need to bundle big font assets like chinese
u
Yes, but personally, I'm not targeting the Chinese public, so I don't really see it as a problem.
I think it will be possible to detect the browser language and load only the correct font accordingly.
Even if it's not the case now, it's certain that it will happen.
Autofill too, I think that will be resolved. I think that, once again, it's meant to replace web apps and not websites.
👍🏻 1
👍 1
s
Chinese, Japanese and Korean fonts are really big. My seed browser supports them, but I had to strip the TTF files to only the used characters.
s
the issue is less translated content you provide, but that you have to support all these fonts as soon as there's any kind of user generated content or they won't be able to use their native language
s
You are right that JetBrains should enable us to use system fonts on the web somehow.
Aside text selection and native scrollabar feeling I would call this one of the things they should work on.
s
not possible because the api is not yet provided by browsers
👀 1
s
Ah. So it's only automatically loaded when you write in into the DOM, but not otherwise accessible?
Browsers don't seem to support WASM or HTML5 Canvases really well yet. 🤔
With Compose for Web we can't really build webpages. What we build is Android apps running in the browser. I guess you need to view this as the successor of Java Applets, just in better.
I don't know who here is old enough to to remember Java Applets 😅🙈
🧔‍♂️ 1
Knuddels used that when I was 15 🫣
29 Views
Open in Slack
PreviousNext
Powered by