https://kotlinlang.org logo
Join Slack
Powered by
:sound:*Open Discussion* What do you think about ...
# javascript
t
🔉*Open Discussion* What do you think about Kotlin JS, do you feel JetBrains should: 🤔 1. Grow further 2. Pivot in some way 3. Maintain 4. Close My impression is that it should "*Growth Further*". Why? I feel WASM will take over JS someday but it'll probably take at least 5+ years. Luckily, Kotlin can do both so we can easily port everything from JS to WASM when it's ready. Therefore, I feel they should invest in JS as later on the switch to WASM would just re-use the concepts. 🙏 What do you think? I'm interested in opposing opinions. 🦠
1️⃣ 9
@corneil What do you think? 😁
e
WebAssembly and JavaScript currently solve a different set of problems. Plus, WebAssembly is in its infancy and even if it's pushed hard it's not something that will take off for the bigger and more conservative companies. Scala.js is the most prominent competitor to Kotlin/JS, and at this point Kotlin needs to catch up on its usability and its support for newer ES features. K2 definitely slowed down everything else, hopefully by 2.1 it will be easier to contribute new K/JS features.
d
Yeah, I would also definitely challenge "we can easily port JS to WASM when it's ready". But that's ok -- the technologies are still both really interesting for different reasons. Another competitor out there is Microsoft's Blazor. I found this comment insightful: https://kotlinlang.slack.com/archives/C04RTD72RQ8/p1722863896100829?thread_ts=1722352466.349419&cid=C04RTD72RQ8 I would love for the state of Kotlin/JS to improve where that user would have felt safe choosing Kotlin instead of C#
e
> we can easily port JS to WASM when it's ready It's going to be a challenge because most projects are not "greenfield", or have to adapt to the distribution platform. As a quick example, we ship K/JS code to VS Code extensions, which currently don't even support ES modules! Another pitfall of WebAssembly-on-web is its lack of accessibility options, which makes it a non-starter for companies that need ISO certifications. Drawing on a canvas is cool, making it usable is another story.
I'll also add that K/JS is considered stable in its new IR form since end of 2022. A mere year and a half. It's still a young project.
c
I use K/JS in production, I love it. It should definitely continue existing. But at this point, what's missing is mostly around the ecosystem, but the tech itself is there. IMO, JB should communicate more strongly about it, give visibility to library authors, publish experience reports. The same way they do with iOS. After that, the community will grow naturally, and library authors will add what's missing. As long as Compose HTML continues to work, and library authors stop fearing that the tech will be discontinued any day and their work will be for nothing then it will grow by itself. IMO that's the main reason not much is happening right now.
💯 3
t
Thanks, @Edoardo Luppi, @CLOVIS, and @David Herman for kick starting the discussion. I feel that the biggest issue currently is that I'm underestimating how difficult would be to port "everything" from JS to WASM. 👍 However, I feel that I'm lacking your perspective on what decision would you choose from the 4 options and "Why". Would you be open to sharing your thoughts so I better understand what would you prefer? 🤔
e
I think it's a "grow further" for everyone here
👍 2
t
@Edoardo Luppi However, why do you feel this would be the best option? I feel that my argument around WASP wasn't the one that you necessarily share as a group?
d
Everyone who will answer your question is probably a community member pretty invested in Kotlin/js or otherwise we probably wouldn't be here. I'm sure we all want Kotlin/JS to continue getting support
👍 2
c
There have now been 4 different people who asked me these exact questions just this week 🤣 at this rate I'll have to write a blog post
😂 5
j
Scala.js is not a real competitor. Basically no one is choosing Kotlin/JS or scala.js in isolation. They already know Kotlin or Scala and are adding a JS target. People choosing to target JS without prior Kotlin or Scala are choosing just JS or TS.
👆 3
gratitude thank you 2
👆🏻 1
s
@jw Exactly. Even with Kotlin experience, someone dipping their toes into web for the first time might have an easier time with vanilla JS or TypeScript due the abundant resources, from frameworks, libs, tutorials, etc...
h
So felt it was a bit to risky to consider an non release framework.
stop fearing that the tech will be discontinued any day and their work will be for nothing
This was also a huge contention point from my colleagues. They felt like there is no reassuring presence of KotlinJS and back then it was still not stable and the kotlin-wrappers are also not stable yet. So they pushed to make the frontend TS/JS.
😔 2
e
> no reassuring presence of KotlinJS I mean this channel has 44k members, it's the largest channel in this Slack workspace after Android basically, says something about K/JS 😄
🙂 2
🤯 4
h
Ultimately I was able to able to get the green light to do backend and frontend in KotlinJS. The senior dev (50+) and the backend lead (30) did a quick survey of KotlinJS and "there were almost no resources online" and having to wrap JS libraries that we want to use is time consuming and a maintenance burden.
e
there were almost no resources online
The difference in random tutorials online is noticeable. Online resources are in favor of the typical JS or TS stuff obviously, given they also attract more novice programmers. However, the average resource's quality is on the low end nowadays.
and having to wrap JS libraries that we want to use is time consuming and a maintenance burden
That's why Kotlin-only libraries needs to be pushed more. Wrapping platform's objects is ok, wrapping existing JS libraries can, indeed, be time consuming, especially around external declarations. Although, once you get the gist of it, development speed adjusts. For example, I had prototyped a full VS Code extension in K/JS with good results, and had to create externals for VS Code APIs and all the other dependencies we needed to use. We ultimately stabilized for a Kotlin core, and a lightweight amount of TypeScript for the basic interactions with VS Code APIs. In the screenshot you can see the language usage.
👍🏾 1
👍 2
A full K/JS extension is still on the radar tho. Sooner or later I'll convert one of them as a test.
to do backend and frontend in KotlinJS
Doing backend development and deploying on Node.js is definitely more approachable compared to developing SPAs, for example. I haven't encountered any true issue, even in interoping with JS (although, I'd have loved exportable unsigned arrays!) That's why for our webviews we opted for Angular: there is a decade of work from thousands of devs that K/JS is missing. But as I already wrote, this target is relatively new.
h
> Wrapping platform's objects is ok, wrapping existing JS libraries can, indeed, be time consuming, especially around external declarations. > Although, once you get the gist of it, development speed adjusts. Yeah the simpler side of wrapping is fast if you figure it out a little that's true, but there is a thread in here where I asked about wrapping the zustand library and iirc the type alias of the main zustand... var? function? was a jumble of brackets, anonymous classes and (higher order) functions that I just could not see through. > Doing backend development and deploying on Node.js is definitely more approachable compared to developing SPAs, for example. Yeah I can see that, though I already had one year of KotlinJS/React under my belt from implementing all the missing features into the legacy project. Combined with no JS knowledge I felt it was wiser for me to continue with KotlinJS instead of learning JS/TS while rebuilding the project. I don't think I could have even estimated the time for that. Meanwhile the project rebuild is coming along well. Maybe to add to the two questions from @Tomas Pinjušić, when I started with KotlinJS I was new to frontend development in general aside from some light ASP.NET with Razor. And I guess you will always have people that are new to multiple aspects. Be it Kotlin itself, KotlinJS, React, SPAs, JS/TS and for those it's important that the learning resources are not strongly linked/depended on knowledge in the other fields.
e
> zustand library and iirc the type alias of the main zustand... var? function? was a jumble of brackets I don't know that specific library, but JS libraries can be a big mess... But is it Kotlin's fault? Not really, it's just the sad state of JS we need to account for. > instead of learning JS/TS while rebuilding the project That's pretty much why our team went for Kotlin at the beginning. I had been using Kotlin for years already and once the opportunity of reimplementing a custom TCP protocol came up, I ended up prototyping it using KMP. The Java team, used to developing Eclipse PDE stuff, liked the Kotlin approach. Once the development of the VS Code extensions started I simply activated the 
js
target and filled the gaps (e.g. the TCP client implementation, logging, charset conversions).
Although, as much as I'd like to avoid dealing with JS, you still need to know what you're doing around it. There is always the necessity of having someone in the team that is polyglot and that can handle DevEx or DevOps issues. Setting up a mixed language development environment and getting it to be smooth is * hard *
➕ 1
h
Yes, definitely. Especially in smaller companies. We only have ~35 people total and need to cover android, ios, big data, kubernetes, hardware (iot), m2m, backend and frontend. So you need to wear multiple hats, by necessity.
✔️ 2
e
I'll also add that the Kotlin approach is pretty cool as you end building a set of internal reusable multiplatform libraries. We already use the protocol library in a Kotlin Native CLI, for example.
h
I know it's off topic for this thread, but a little anecdote. For our hardware we had major problems getting some module to run, so the hardware people hired a freelance linux driver developer. That dude was the absolute crack at what he did. He went in and fixed the driver of a rather big chip developer (MediaTek I think). He was crazy expensive as well I heard, but everything worked flawlessly after a few weeks. Sometimes I envy that absolute deep single field knowledge. He didn't do frontend or backend or http nothing, his world were interrupts and address spaces, C and assembler.
e
We deal with that kind of expertise often in the mainframe world. It's not something I like to do, but having people that can navigate 20 years old Assembler or C code is pretty cool. The green screen emulator experience feels like being in the Fallout videogame tho. There is some movement around bringing Kotlin to z/OS, by having LLVM target z/Architecture. Who knows, one day, maybe.
K 3
c
Setting up a mixed language development environment and getting it to be smooth is * hard *
Btw, if anyone of you has the kind of knowledge to do this please get in touch. I'm currently writing a Gradle plugin to use Vite/Rollup instead of Webpack, and it shows promising results (if anything, it's much faster), however as soon as someone is using a thing that's even slightly non-standard it all breaks down. I don't have the knowledge to actually understand what's going wrong. I see multiple here are working for companies that do KJS, it would help me enormously if you could ask your colleagues to help me investigate these cases so I can understand how to fix them 🙏
👍 1
e
Our workspace is driven by Nx. Nx keeps track of the dependencies between local projects, so for example when we want to start a VS Code development instance we might call
Copy code
nx run vsc-extension:build:watch
through a run configuration, which will build vsc-extension and its dependencies, including the correct Gradle projects, before opening up the extension host window. There is no bundling or minification going on during development, to have faster feedback and not screw up debuggability. The bundling is then handled at packaging time by esbuild (yet again via an Nx executor).
b
I'm currently using Kotlin JS to interface with a JS framework, I don't think WASM would really help here. Plus there is a well known performance issue in that regard with strings, since you need to copy strings from and to WASM when interfacing with JS APIs
c
Until Kotlin/WASM is mature and close to a drop-in replacement for Kotlin/JS I wouldn't suggest it be deprecated. There are enough people using it who will probably feel left behind. Ideally you do not want Kotlin/JS to lag behind other platform when it comes to language features. If there are plans for language features that will move the language forward significantly and is blocked by fundamental aspects of JavaScript support then I would suggest a clear statement and would support moving the language forward with Kotlin/JS
20 Views
Open in Slack
PreviousNext
Powered by