https://kotlinlang.org logo
Join Slack
Powered by
<https://twitter.com/sdeleuze/status/1052160036749...
# feed
s
g
Great read Sebastien, very inspiring
s
Thanks
p
I honestly hope you get to convince whoever needs to be convinced; it all sounds like a hellish amount of work, but completely worth it. Good luck!
s
Kotlin/Native contains a good basis for that with the WebAssembly support, what I describe is not small work indeed but I am not sure it is unrealistic. The main challenge come from the fact that currently Kotlin/JS and Kotlin/Native seems to be 2 distinct teams with little interactions. What I describe is more a Kotlin/frontend initiative that would leverage Kotlin/Native WebAssembly support and leverage Kotlin/JS knowledge to make Kotlin a real frontend language.
p
You stated that very clearly in the gist, yes; and as I said, it doesn't look easy but it also looks like the best path to take as it comes to kotlin+frontend. The question is, how do we make it be the safest path as well? I would be all in, but not everyone is the personification of YOLO I am.
s
I think one of the key strength of Kotlin team is to listen feedback from the community, and I think the core stuff of what I described need to happen on JetBrains side. After that, we as a community will be able to build a strong Kotlin/frontend ecosystem. But for now I would say the ball is in JetBrains court.
So any +1 on what I wrote could help if you think my proposal make sense
m
Frontend is not the same thing as web, mind you. The most Kotlin-ish way to write frontends with Kotlin is still JavaFX/TornadoFX, as that uses the original language that supports things such as multi-threading.
p
yes, maybe @sdeleuze should change the wording from 
frontend
to 
web
, as 
frontend
also includes desktop and mobile, but his point is only about 
web
and he was very clear about it
s
I indeed mean frontend web development
Web is confusing because server versus client
👍 1
I will update to be more specific if that's not clear
o
I'm not a frontend developer but it sounds convincing. There are few small typos like 'general general'
k
Client side Web development means Angular and React to most people though. In that perspective, Kotlin/JS as a replacement for Typescript does seem to be the right thing to do..
s
As explained in my post, Kotlin/JS doesn't offer a good Web and DOM API right now because it is not generated from the right Web IDL, and I think you can't beat TS by generating JS. If we want a first class web client support, Kotlin should provide first class WebAssembly support and build its own frontend ecosystem not based on JS (while still providing JS interrop). TS is designed for JS era, Kotkin needs to be designed for the WebAssembly era which open the web to non-JS languages. Otherwise it will never feel "web native" for frontend developers.
👍 1
o
I think it will help (for me at least) if you will give an example
j
I've been waiting for usable WebASM for ages, would be nice to be able to write it in Kotlin. Custom HTML components using Unity or something similar for example is something that would be great, you can have something look exactly the same in all browsers with no extra effort, it'll be much more performant when having to display lots of data (JavaScript + HTML suffers when you want to display enormous data tables)
s
@oshai What kind of example would you need ? About the limitation of current Web & DOM API in Kotlin/JS ? About building frontend web applications without JavaScript leveraging WebAssembly ?
o
About the dom limitations and idl
s
That's just an example, there are many others
To be compared with the documentd API generated in this talk

https://www.youtube.com/watch?v=QaPMKZay_Ig▾

Also WebAssembly Web and DOM API is super basic, we need something more solid, hence my proposal to use a better Web IDL from Firefox source code to build a MP Web API usable from Kotlin/JS and Kotlin/Native WebAssembly backend
k
How would WebASM fit into the Angular and React ecosystem?
g
It will not, and this is the point of Sebastien, as I understand That WebAsm is new platform for web and all existing JS frameworks not relevant anymore, so it gives some room for Kotlin
k
That gives more Kotlin a better chance in a new space but that also is something that is not currently mainstream. If you ask a web dev what they would use for client side apps, I'd wager WebASM is pretty low on their list unfortunately 😔
s
As said by @gildor, my point is that there is a need for frameworks like Angular or React but natively developed in Kotlin, not wrappers on top of JS based frameworks which will always lag in term of feature, will always be seen as not first-class solutions and will combine the drawbacks of the 2 worlds: you need to use a non-JS language and have to pay the price of using a JS ecosystem and toolchain.
WebASM is not super interesting for existing JavaScript or TypeScript developer, except for niche features like crypto and CPU intensive features.
But for Go, Swift, Kotlin, C#, Rust developers who want to do web frontend programming while keep using there favorite language and toolchain, WebASM is super high in their priority list.
The thing that make some web dev not excited about WASM is that some many developers think that Web = JavaScript, with WASM this is not true anymore.
You can do web in a native way, with DOM and Web API written in the language you want (with some constraint on GC and other features).
Without plugin, just using the same browser features. That changes everything, and that's the only chance for Kotlin to be a major frontend language.
m
my understanding is that with WASM the DOM and JS APIs are still not really available
has that changed recently? they don't really have good GC integration, so it's not clear what the memory management semantics of using the DOM from C++ would be. at least that's historically been painful when working with rendering engines in C++
s
As said in my blog post:
m
ah, sorry 🙂
i forgot. you're proposing using JS interop first and direct binding later
s
yes + a native mode using reference types is already available in Firefox via 
javascript.options.wasm_gc preference
See https://github.com/WebAssembly/proposals for the status and content of the proposals
Reference types is pretty advanced https://github.com/WebAssembly/reference-types
GC and host bindings will take more time
But Rust web-sys crate (https://rustwasm.github.io/2018/09/26/announcing-web-sys.html) and .NET Blazor shows that we can move forward already today with this progressive "JS binding for now and native capabilities later" approach
s
I'm hopeful that this gains some traction. I think you made a lot of good points.
5 Views
Open in Slack
PreviousNext
Powered by