Question regarding kotlin-material-ui

[marvinbuff]

I am not sure if it is appropriate to ask this question over an issue. But I was wondering whether you are aware that there exists a second kotlin material UI wrapper which does fundamentally the same as this one. Of course, there are differences in maturity, popularity, and specific implementation. I think it would be very helpful if the Readme would have some information about the alternative and what the advantages and disadvantages are. As it stands now, I am unsure which one to use and it seems a lot of the effort developing a good material UI wrapper is duplicated. Might be worth it to investigate. If you want I can compile a small list of differences I experienced when working with either. Let me know what you think on the topic.

[cfnz]

Yes, some time ago I came across that wrapper (after I had completed mine :-(... ). I have had a brief look, but haven't gone too deeply into it.

So yes, if you have tried both and can compile a list of differences from an independent point of view, that would be interesting.

[marvinbuff]

As a disclaimer, I was learning Material UI, React, and Kotlin JS all at the same time. We first used Muirwik which was very nice to learn how to do things thanks to the great example app you build, but due to some gradle setup we needed to switch to the IR compiler which turned out to be very troublesome with Muirwik and was just supported by kotlin-material-ui out of the box. The biggest problems we encountered weren't also really your fault, but I think that having a local fork of murwik caused many problems with gradle, like failing hot-reloading and random compilation error.

I found the following points, some of course are subjective:

Pro Muirwik

• Extensive samples: very helpful for beginners, especially as not all examples from typescript translate 1:1 to KotlinJS
• Convenience functions: Reduce the code size tremendously but are in the end only simple functions
• Maintainer Activity: Looking at PRs and issues, I found you more engaged in the project

Pro Kotlin-material-ui

• Simple and clean feel: no special mTextfield which has a different API than the Material UI textfield, just access to the material UI textfield with typing. I really like this one as it makes it easier to convert typescript code into KotlinJS. You do lose the convenience of the wrapper functions though, which however can just be added for your use cases.
• Supported Components: Generally the library seems to be a bit more mature with all current components already supported.
• IR Compiler Support

Neutral Points

• Popularity: I would say both libraries are used and contributed to by a similar amount of people
• Missing icons support: Both libraries have similar feature request like for the material UI icons components

[marvinbuff]

I hope this small write up helps and thanks for your efforts in creating this library.

[cfnz]

Hi thanks for that.

In terms of the Pro Kotlin-material-ui, I actually kind of agree with the simple and clean thing... as mentioned in the Muirwik readme, I started Muirwik learning Kotlin, js and react... so there are probably better ways of doing things... sometimes using the library I think that prefixing everything was mThis and mThat was the wrong way to go and perhaps should have stuck to This and That.

But with simplicity you do loose some functionality. For example, there is no way to express required props. So you don't know until you run your app and get errors in the browser that you didn't supply something that should have been supplied. With function params you can make this requirement hard. Other than needing the required arguments, most if not all of the other props have the arguments as optional/with defaults and you can also use the attrs {} method of defining them instead.

From the small look I had at Kotlin-material-ui some time ago, I thought it wasn't typed as much as Muirwik, but I will have to have a better look and play with it at some stage (hopefully soon).

Re IR Compiler Support, there is a branch for that (which I believe is mostly from your work :-)). It all seems to work fine with the IR Compiler, at least with the test project, I have not had a look at kotlin-material-ui to see if it needed to do something similar. But I imagine that the IR Compiler branch will get merged into master soonish as there seems no further progress on it from the IR Compiler side of things (i.e. to make those changes not required).

Thanks for your comparison... maintaining Muirwik takes work, and if there are other options it makes sense to try and combine the effort into one better solution... I think that idea came up on a forum somewhere, but nothing much eventuated.

I am still committed to Muirwik and making it better, adding components when needed (mostly required for Lab components now-a-days as most of the core components are already present). But there might be a bit of work required to get online with Material UI 5 when it comes out, and maybe then it might be worth looking at Kotlin-material-ui (or whatever else) and seeing if a one better project will be a goer.

[marvinbuff]

In terms of the Pro Kotlin-material-ui, I actually kind of agree with the simple and clean thing... as mentioned in the Muirwik readme, I started Muirwik learning Kotlin, js and react... so there are probably better ways of doing things... sometimes using the library I think that prefixing everything was mThis and mThat was the wrong way to go and perhaps should have stuck to This and That.

No worries, ironically it was actually quite useful when I used both libraries at the same time as it cleared at what is coming from where.

But with simplicity you do loose some functionality. For example, there is no way to express required props. So you don't know until you run your app and get errors in the browser that you didn't supply something that should have been supplied. With function params you can make this requirement hard. Other than needing the required arguments, most if not all of the other props have the arguments as optional/with defaults and you can also use the attrs {} method of defining them instead.

I agree full with you there, also the attrs method is quite more verbose. I do see some definite value in function wrappers and actually, I could see a wrapper library around kotlin-material-ui which exactly provides those.

From the small look I had at Kotlin-material-ui some time ago, I thought it wasn't typed as much as Muirwik, but I will have to have a better look and play with it at some stage (hopefully soon).

I did have some type issues. It is certainly not perfect.

Re IR Compiler Support, there is a branch for that (which I believe is mostly from your work :-)). It all seems to work fine with the IR Compiler, at least with the test project, I have not had a look at kotlin-material-ui to see if it needed to do something similar. But I imagine that the IR Compiler branch will get merged into master soonish as there seems no further progress on it from the IR Compiler side of things (i.e. to make those changes not required).

Yes, I think that one should work out eventually :)

Thanks for your comparison... maintaining Muirwik takes work, and if there are other options it makes sense to try and combine the effort into one better solution... I think that idea came up on a forum somewhere, but nothing much eventuated.

I am still committed to Muirwik and making it better, adding components when needed (mostly required for Lab components now-a-days as most of the core components are already present). But there might be a bit of work required to get online with Material UI 5 when it comes out, and maybe then it might be worth looking at Kotlin-material-ui (or whatever else) and seeing if a one better project will be a goer.

Well, thank you as well. I think this is a reasonable plan. Let's see how it goes by then.

Thanks again for the discussion. I will close this ticket then as my question was answered.