Comment by jillesvangurp | Hacker News Reader

Comment by jillesvangurp | Hacker News Reader

The new wasm support in Kotlin is pretty exciting. There's an experimental version of compose multiplatform that supports targeting browsers that will be using WASM. Compose multiplatform is basically Google's Jetpack Compose for Android with added support for other platforms.

As of a few days ago, IOS support in alpha and will hit beta next year. Android and desktop support are now stable. Once that stuff stabilizes, you can write UI applications that basically work on any platform.

The wasm compiler will roll out along with kotlin 2.0 which is the next major release for Kotlin and features a new compiler (k2). This looks like it should happen early next year. k2 is currently available in beta release and you can enable it in kotlin 1.9.x.

The nice thing with the Kotlin multiplatform ecosystem is that there are already a lot of libraries that work across the various platforms. So, the wasm compiler will rapidly become part of that and inherit a lot of nice libraries. Mostly all that takes is for builds to be reconfigured to target that ecosystem and implementing some platform specific behavior where that is missing.

Another interesting thing in this space is using and linking libraries written in different libraries. For example a lot of the platform specifics are probably going to be dependent on e.g. C or Rust libraries that are already available. In many cases these might be the same libraries that Kotlin native uses.

How does Compose Multiplatform on web work? Does it paint on Canvas like flutter?

Do you use the same widgets on Desktop, web, iOS and Android? I understand that on Android it's native. Does it emulate other styles on other platform? I guess, my question is mostly: How is the _feel_ of a Compose Multiplatform App on non-Android platforms.

Dart on web e.g. feels extremely janky to me, so does electron on Desktop. Dart on Desktop is ok, but all the applications tend to be very App-like with huge buttons and whitespace that just make it feel more like it was an Android App running in an emulator rather than an actual native app.

Would you recommend Kotlin as a language for new projects?

Compose web indeed uses a canvas and just like the Android and IOS versions it renders using low level graphics libraries such as cairo. I think the intention is indeed to have the same core components across all platforms and indeed emulate the look of the native platform. This is similar to what things like flutter do, which also depends on cairo if I'm not mistaken.

There is also compose web html which seems to be not getting a lot of attention lately. That depends on kotlin-js and works with the dom tree. But for obvious reasons it's a lot less easy to use the same components there.

I think it's too early to tell how it will perform, look, and feel on every platform. This is also a bit of a function of how much effort and design you put in. Using wasm in the browser should help with performance though. Dart might copy that trick as well. I think they currently cross compile to javascript.

Kotlin as a language is more than fine. Anything server related or Android related, it's a great language and I vastly prefer it to Java at this point (27 years of experience). I personally use it for web development (kotlin-js in the browser) and server development (spring-boot, ktor). IOS native development for libraries is also a popular option for sharing code across IOS and Android. That just got promoted to a stable release. There are some gotchas with interoperability with e.g. Swift and Flutter from what I understand. But it's basically very stable and workable at this point and fairly widely used.

Compose multiplatform is not quite ready yet. The Android and Desktop side work fine and are stable. But the rest is a work in progress. Compose web is going to be a while because even the compiler isn't ready yet. Compose IOS looks like it should get to a usable stage in the next six months or so. Stable is probably at least a year out for that.

How does this work in regards to accessibility? I think historically, canvas has not had a great track record as it's essentially a black box. While it might be okay for certain use cases (intranet, one-off tools, etc), I don't see how this would ever take off on platforms with a public user facing application.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ca...

Compose on android is native as in it takes full responsibility for its canvas, not native as in react native which tries to operate pre-existing controls as much as possible.

> Dart on web e.g. feels extremely janky to me

That's what this WasmGC is for :) Dart on web runs as dart2js whereas other platforms like Android/iOS/macOS/Linux/Windows runs as AOT arm64 or x86_64 code. Dart on wasm (as shown in demo in the article) will run better than transpiled JavaScript.

Every time I tried it my enthusiasm got curbed by the gradle mess.

Gradle is fine once you understand how it works. Admittedly, it takes a bit of time to get used to, but it's very customizable.

Gradle might be fine compared to other Java build tools, but when stepping outside the Java world it feels like a leftover from the 90's... and that's the same for pretty much anything else related to Android development, which is curious because Android didn't even exist yet in the 90's ;)

Which build tool is better? The language-specific ones are pretty much useless for a more involved build that is cross-platform, let alone uses multiple languages.

Gradle is generic, which does increase its surface area, but there is not many alternatives that are also fast and correct: there is bazel, and a new thing I very like: mill. But not much else is there.

Gradle is almost a language itself. I have never seen a project where teams didnt run into gradle hell and spend hours on every lib update to fix gradle issues. Its just too damn complex and most of the time nobody is really an expert in it.

Yes I believe Gradle is a DSL based on the Groovy programming language

Or more recently on Kotlin script (newer Gradle files often have s .it's suffix to indicate that)

Gradle is cancer. I would love to recommend an alternative that enjoys the admirable quality of "not being cancer", but I am instead left not developing on Android out of lack of any coherent alternatives (and especially examples or tuts showing how to make use of them if they do exist hidden out in the wild there somewhere)

EDIT: just to add some background, I am staunchly against any development platform that requires a developer to build a ridiculously complicated nest of file structures, libraries, bindings, etc out of dozens if not hundreds of disparate and usually incompatible projects yoinked from the internet that further makes broad and undocumented assumptions about the dev machine you're trying to install this all on.

Also bear in mind that package managers by themselves often make this process worse instead of better because they then proceed to proliferate into an entirely different level of the trashfire hierarchy. Get node/npm even though you're not coding in Javascript, then still have to get chocolaty or flatpack or fall back to trying to insulate everything into a docker container or use pip to install python packages but then drag out the venv when different projects want different versions of the packages and then further drag out conda when they want different versions of python as well.

Too much of the environment assumes that the developer is already steeped in all of the thousands of compromises existing developers have slowly gotten accustomed to over years of yielding and putting up with it. Another day, another fault line along which to fragment every tool you need just to create "hello world".

This is a good description of my problems with Python when it was first introduced to me. Although, "hello world" didn't require installation of anything (Python has been pre-installed in Ubuntu for a while now), the mess and confusion and incompatibilities and irreproducibilities were quickly run up against and each "solution" was more opaque and flippantly suggested that I couldn't figured that programming wasn't for me. I'm glad I persisted past it. The juxtaposition between hearing that "Python is so easy and wonderful" and my experience made me look for answers. And the answer, it seems, is that people don't care. The vast majority just keep installing everything until it works and don't mind that they initially don't know what's going on (and oftentimes never find out). The few that do mind are on opposite edges of a canyon of experience.

Thank you for letting me rant over this.

Right. The thing is that how it works changes all the time. A construct you used in gradle file suddenly gets deprecated or outright not working with new gradle versions. I heard those things happen during minor version upgrades as well. No thanks! Luckily I don't work on android apps.

Same. Also at least based on what I’ve seen on Android there’s a decent chance you’ll be stuck using some Java libs due to lack of native Kotlin counterparts, which makes it harder to fully leverage Kotlin’s features wherever you need to work with those libraries.

The syntactically similar language I’d rather have run everywhere is Swift. Swift Package Manager has problems too of course but in my experience has been less maddening, and the community has been more aggressive about writing native Swift replacements for Obj-C libraries.

> which makes it harder to fully leverage Kotlin’s features wherever you need to work with those libraries.

What does this even mean?

Just that Java libraries aren’t going to be taking advantage of Kotlin-specific language features, which in turn makes it harder to use those features in the parts of your application code that interact with those libraries unless you write wrappers that make these libraries fit in better with your Kotlin codebase.

There’s a similar issues with using Objective-C and C libraries in Swift, which makes Swift libraries more appealing where available despite Obj-C/C interop being good.

You didn’t answer my question, just rephrased your original message.

The only case I can think of is wrapping callbacks with coroutines, everything else will work in Kotlin out of the box.

Reply on news.ycombinator.com