https://kotlinlang.org logo
Join Slack
Powered by
Silly question for the channel. And I don’t mean t...
# javascript
a
Silly question for the channel. And I don’t mean this as some sort of troll bait question, so let me preface this with the fact that I am a complete Kotlin evangelist. I’ve been using it since before 1.0, and I have mandated that all new JVM code in our server-side software be written in Kotlin. My question is “Is it worth it using Kotlin for React and/or JS?“. Has it helped mitigate problems? Problems such as: Readability, maintainability, “correctness” (getting rid of those annoying JS hacks that I cannot stand to find), scoping issues, removing ambiguity, etc. What does is provide that makes it the better choice? What about bundlers and all that fun? External code imports and dealing with those types. If you have a link to a good write-up of this, that would be enough. I don’t want you to waste your time. I’m just trying to make an educated decision on where we are going next within our company. Side note: I am considering diving into using Kotlin for more than just server-side code. We are currently using React native (huge mistake, IMHO) on the mobile side, React in the browser. As for the mobile side, I am considering Kotlin Multiplatform Mobile, and tossing React Native for native UIs.
👍 4
b
My personal opinion on this is to only use Kotlin/JS if you want to share code with your server or other platforms, otherwise I'd recomment sticking with TypeScript. Don't get me wrong, though, KotlinReact is not bad, it's just that it still requires quite some tinkering sometimes, whereas TypeScript is fully supported by React team themselves
a
Thanks. That is one route of a “mandate” that I am considering. Our software is basically all closed (healthcare), so we don’t have any major components we can share with the world. So, in this case, do you forgo the whole “PropType” definitions and just allow TS definitions to provide these types? I know that is a supposed issue if you want to share your TS code with other non-TS react projects. But, I am willing to get rid of that boilerplate and annoyance if I get TS. I do wish the React team would just give it up and dump Flow. Man that thing is just so ridiculously unnecessary. Nobody else uses that thing, the docs are really awful to read, and well, TS won that battle.
b
I didn't mean sharing components with the world. Main benefot of Kotlin/React is that it allows you to share code (not components) with your backends and mobile/desktop clients. Think of your server, desktop app, web UI and mobile apps all using the same source file containing your domain objects, interfaces, validators and busines logic
a
I am quite happy with Kotlin-JS right now. I think that Kotlin React bindings is just a stepping stone and it will be possible to use much more robust Kotlin-first solutions. I think that if you have dedicated JS/TS developers, it will be quite hard to convince them to move to Kotlin, but if you want to write somethin from scratch - Kotlin Js is a good solution.
👍 1
b
I should probably say Kotlin/JS instead of Kotlin/React as using Kotlin/Js indirectly forces you to use Kotlin/React (or any other kotlin web framework)
m
I guess you mean the other way round
b
There are also other kotlin-first web frameworks out there. Check out #kvision and #fritz2
👍 1
💯 1
➕ 1
@Marc Knaup don't think so. Kotlin/JS enables code sharing, not Kotlin/React 😄
m
Kotlin/React depends on Kotlin/Js, not the other way round. Or maybe you mean something completely different 😄
a
I had some issues with Kotlin/React. But all my problems are with React itself, not with kotlin bindings. I think that Kotlin-first solution is a way to go.
👍 1
m
I haven’t used it a lot yet but here are some major points I’ve seen so far: • A solid standard library makes you so much more productive than the crutches you have in JS. • Awesome coroutines & Flows. • You don’t have to constantly learn and jump between two languages which is a huge mental burden. • You can easily reuse code across projects, esp. back-end/front-end. • Same IDE, same tools, almost same everything. Much smooth. Such fun. but • It’s still very immature. Random issues everywhere. • Tooling ain’t too good either (e.g. debugging issues, slow hot reloads). • Still some type safety issues (e.g. randomly getting problems with 
undefined
because 
RProps
are based on an 
external interface
) • Random scoping issues (a Kotlin problem in general) b/c of excessive nesting with different receivers. • It feels boilderplate-y sometimes. • You won’t find many developers and esp. not good ones. Difficult to outsource or hire. • Very little documentation. I have no experience yet with integrating other libraries. I use it for hobby projects but probably won’t use it in proper products yet. Unless I have time, money and energy to get it going and have someone learn & implement.
a
I mostly agree with @Marc Knaup’s assesment. But most of negative points go away as soon as you stop using React. Actually, I was really disapointed in it. I've taken React because there are millions of component libraries for it. And guess what? Most of them are of terrible quality, I've ended up re-implementing all require components myself in pure Kitlin-JS or in Kotlin-React. As Mark mentioned, Kotlin stdlib makes most of JS ecosystem obsolete.
m
a
@Marc Knaup I do not think it is a huge secret, there are fully working prototypes already. They are closed for now, but at least for the desktop there was a call for pre-alpha testers.
m
I just hope that we get it for the web soon 🙂
With webassembly 😁
a
Well, maybe @Dmitry Romanov [JB] can share some insights on that.
s
Hopping in here as well – I think Marc and Alexander have already said most things which currently hold true about the ecosystem. We love to see the community and number of frameworks around Kotlin/JS grow, but for now you’ll have to expect some pains – that is unfortunately the price to pay for being a somewhat early adopter 🙂. On the flip-side, we do our best to listen to your voice and concerns, and are really invested in making K/JS viable and most importantly fun/productive to work with. As for the future of WebAssembly or Compose for other platforms – Until something gets announced, there’s nothing to announce 😉
💯 1
☝️ 1
d
@Marc Knaup Right now we are actively working on a new Kotlin-to-WebAssembly compiler backend. You can see the details and track our progress here https://youtrack.jetbrains.com/issue/KT-42292 And please also join our #webassembly channel 😉
🎉 1
m
Sounds fantastic, thank you @Dmitry Romanov [JB] 🙏
b
@Dmitry Romanov [JB] any ETA for alpha by any chance? Not looking for anything specific. Just broadly in months/years.
d
@Big Chungus We are not ready to promise any deadlines, cause for now the main team focus is on the new IR backend (KT-42289). Once we’ve finished preparing for Beta, we will begin to spend more resources on WASM.
b
Understandable, thanks!
🤝 1
Does anyone know if there's ban ETA on wasm GC proposal?
8 Views
Open in Slack
PreviousNext
Powered by