https://kotlinlang.org logo
Join Slack
Powered by
<@U0GCNKJF4> Indeed, catching up with Flutter is a...
# webassembly
s
@pabl0rg Indeed, catching up with Flutter is another reason for Kotlin to work seriously on WebAssembly. And I do think that only a Binaryen based toolchain will allow fast dev cycle able to compete with Flutter.
g
I didn't get point about Webassembly and Flutter. How those are related?
n
I think the point that @sdeleuze was trying to make is that Kotlin needs to diversify (be versatile) in order to continue to be relevant, no matter what happens (not every threat comes from technology). Although Flutter can be considered to be a threat, a much bigger threat is Apple blocking Kotlin Native apps in the App Store (can find more context here - http://talkingkotlin.com/catching-up-with-cedric-beust/ ).
j
Catching up to Flutter would be going backwards, no?
😂 4
g
Hah, it’s funny. But a lot of people still want to share UI, how they do with R/N and Flutter
n
Sharing UI is ok provided the UX (User Experience) isn't important. In most situations (with a GUI app - anything with a front-end ) the UX is important so sharing the UI causes enormous issues.
g
Nobody says that UI sharing is easy, both R/N and Flutter struggle with it a lot, but there are obvious advantages, just because mobile UI today are pretty similar on iOS and Android And of coure it’s always trade-off
j
Someone is free to write a shared UI but it's not something you want at a large scale and it's orthogonal to other code sharing efforts which are arguably more valuable anyway
💯 1
g
Sure, but it would be pretty hard to do
something you want at a large scale
Exactly, for a big projects you probably would choose native. Small and medium sized teams it’s just to hard to write such solution with shared UI themselves
j
Not having shared UI is a huge win for multiplatform architectures right now because it forces you into a strong view model that you then rasterize in the platform-specific widgets. Then if shared UI does come along, you just write that once instead of N times but retain the strong architecture. If we had shared UI, you'd see all kinds of layering violations as a result.
🤔 1
s
I won't argue if that's a good or bad idea, but WebAssembly seems a good platform for those who want to build portable web/mobile/desktop apps with builtin rendering capabilities (canvas or WebGL based) with fast dev cycle. That's seems to me much more appealing than Flutter which is essentially a try intended to recycle Dart language and VM.
g
But there are no solutions for WebAssembly on mobile/desktop except browsers, only plans, as I understand. And everyone hates non-native UI for mobile/desktop and still too slow and resource hungry browsers (which are required for now to use WebGL, with or without web assembly)
s
g
I don’t know, still sceptical about PWA on mobile, but who knows
But I agree, it can easily replace electron on some simple cases (Spotify, Slack)
s
electron is another proof that people only want to work on UI once
j
Because it only runs on desktop and still requires per-platform integrations? hmm...
p
Maybe MPP is now easy/straightforward in Kotlin (i last took a close look a few months ago and it was not for the faint of heart). But the dev cycle is surely less appealing than Flutter (hot code swapping). In small companies like mine (most companies), having to design UIs twice is just a pain. Non-US people here may know Glovo. Their app is awesome and looks nothing like a typical iOS or Android app.
Also Flutter’s React-style data flow is appealing. There was a React-style library for Android called Anvil but it seems abandoned.
s
Yeah short dev cycle is key, that's why paying the price of of full LLVM toolchain where Kotlin could use directly Binaryen to target WebAssembly in an optimized way would be an error for regular use case.
➕ 1
+ LLVM is not a good fit at all with upcoming Wasm GC as highlighted by Luke Wagner from Mozilla
❔ 1
n
Don't think it would be a good idea to "*throw out the baby with the bath water*", aka throw out the Kotlin Native part. Better to work around the LLVM limitations as they stand.
s
That's not the advice of the Luke Wagner which is likely the most relevant expert on that very question (WebAssembly GC lead)
In understand the issue given the investment on Kotlin/Native but WebAssembly is designed for linear memory while WebAssembly + GC is a different beast. IMO the goal is to build something competitive with other language, and I think this is possible to build that via a fast Kotlin -> Binaryen toolchain which will be much faster than LLVM. It is designed for Wasm, supports parallel codegen, will supports natively WASM GC, has a simple API, produces optimized bytecode.
Maybe some inspiration from https://github.com/AssemblyScript/assemblyscript/wiki/Architecture could be taken to add a Binaryen IR output to Kotlin/JS or fork it to create Kotlin/WebAssembly.
cc @bashor
n
Would be likely that JB would need to recognise WASM as a much lower risk target, and that it provides far more benefits (business/technological) than iOS (very high risk - at the mercy of Apple who can block Kotlin Native at any time), before they consider developing a new Kotlin platform (Kotlin WASM). At the end of the day Kotlin Native CAN continue without iOS. Kotlin Native is still a very important platform that opens up a lot of opportunities which were not available before, or were prohibitive to Kotliners (IoT, Embedded, Serverless, CLI etc).
s
On server side, I see a big move currently toward GraalVM native image which allows to be native while keeping Kotlin/JVM ecosystem. That will be pretty difficult for Kotlin/Native to fight against that. On the other side, I think first class support for WebAssembly is something where Kotlin can shine if the effort start now as a priority.
n
The JVM ecosystem isn't designed/well positioned for Serverless, however the C ecosystem is which is where Kotlin Native comes in. When it comes to other types of back-end development (Monolith and Micro Services) the JVM is a far better option simple smile. If Serverless performance benchmarks could be done then it would be very likely that Kotlin Native would outperform GraalVM (especially on memory usage and binary size). WASM wouldn't be a viable choice for any type of back-end development, but would be good for front-end web development.
s
GraalVM native images change the game. Spring Boot starts in 6 ms when compiled with GraalVM native image with low memory usage.
l
@napperley Apple can't block Kotlin/Native because it is compatible with LLVM, and blocking Kotlin/Native would mean blocking C/C++ and other LLVM compliant languages too, which includes Objective-C… and Swift.
➕ 1
n
I wouldn't be too sure of that if Kotlin Native programs (for iOS) have a unique signature that Apple can easily detect using one of their own systems.
l
@napperley They already allow Cordova apps, which are easily recognizable. Same for Flutter apps. iOS developers have already started to adopt Kotlin/Native, so they would hate Apple if they tried to make such a bad move, and this is not beneficial to them.
➕ 1
g
+ not clear status of React Native which allows swapping code on runtime and any other solutions like Xamarin or RoboVM and forks Of course K/N can be detected somehow, but it would be pretty strange move from Apple, K/N is not something different with C/C++ libraries Also agree that it is not clear why they would decide to do that
z
Someone is free to write a shared UI but it's not something you want at a large scale and it's orthogonal to other code sharing efforts which are arguably more valuable anyway
@jw are you specifically talking about mobile here or desktop apps as well?
n
This thread is getting long and is getting off topic. Would be better to move it to #random .
3 Views
Open in Slack
PreviousNext
Powered by