Dealing with Kotlin as a front-end language and then mixing it with a lot of existing libraries from JS can be a problem if you intend to publish your library to others.
I'm not saying that Kotlin is a bad choice, but the contrary. Kotlin is an amazing language and it's very pleasant to code in it. But we already have a lot of good libraries written in JS today and most of these libraries can make your life a lot better if you are writing a web application. If you are a front-end developer you know what I mean. We have a lot of amazing libraries and frameworks like React, Aurelia, Angular, VueJS, Marko, RxJS etc.
Then what is the problem? Well, Kotlin compilation to JS is getting better and better, but it's not a language that comes from the Web environment but from the JVM (Java Virtual Machine). And because of that, while you can make a lot of good things with it, you still have to deal with not only the JS nightmare of tooling to bundle and distribute your transpiled library, but you will have to make choices of how you will distribute your own library to others too, so they can code in Kotlin as well.
Actually, I don't know if I can say that is the standard way, but the common practice is to publish a Jar package which contains some Kotlin's metadata (to be used by the IDE) and the generated JS. And actually, if you intend to code entirely in Kotlin that isn't a problem at all, but you if intend to use some existent JS library, then we have a problem here.
For example, let me say that you are writing an application and want to use React as your UI library. Then you will have to create bindings that link your Kotlin code with existing React library. Suppose then that you pretend to use the published library in NPM. You will only have to create the bindings by yourself using the Kotlin's JsModule annotation or use someone else bindings (like my kodando-react library). And because you don't have too much time, quickly you decide to use the kodando-react library. After putting the dependency into your Maven project, you are ready to go (
When you finished your application, then is time to merge your application generated JS, with the kodando-react's JS, with the React and all its dependencies into a bundle to use it on a browser. You can use a bundler like WebPack to help you with this task, but wait... where is the kodando-react's JS? You have a Jar, not a JS file.
At this point, you have two options:
1) Unpack the kodando-react library to extract from it the generated JS into a directory that WebPack can find;
2) Install the kodando-react library published into NPM.
Ok, what is better? Sincerely, I don't know and I expect that you give me your opinion after but first, let me put some points so you can analyze.
The first option will give you exactly the JS generated that match with the kodando-react library that you got from Maven. So, you don't have to worry about if the kodando-react definitions that you used to code are in sync with the kodando-react JS that you unpacked. The problem here is that you don't know which React version that library was written to, except if you check the documentation. Then you will have to keep in sync by yourself the extracted JS with the React downloaded from NPM.
The second option will give you a better integration with WebPack and not only that, the kodando-react library that you downloaded with NPM will download all its dependencies and the correct React version. Additionally, you don't need an extra step of compilation to unpack things. At another hand, you will have to keep in sync the current Jar's version with the current NPM module version to match each other.
I think that the best option would be the second, but if you have some tool to help you and make transparent to the programmer this sync problem, then that would be the best option and the previous options would be only a transparent step at the tool.
What do you think?
Comentários
Postar um comentário