Kobweb in production Hi, Kobweb powers one of my ...
# kobweb
o
Kobweb in production Hi, Kobweb powers one of my for-profit projects. A private business management service for a medium-sized company. Some CRUD, several interactive forms, file uploads. No fancy animations. It has been running in production for the past 3 months and no issues were raised so far. Stack: Static export. The backend is written in Quarkus, the Kobweb application gets exported and served by the server as static resources. I chose Kobweb for the following reasons: • I already knew Compose from my Android career • I despise JavaScript • The website is not public and the scope is small • No need for localisation, theming, or accessibility • Don't have to care about optimization. Neither SEO nor bundle size. The Good • Layouts and modifiers from Compose UI are remarkably well ported to Compose/HTML. Layout bugs exist, but are few and far between. • If you come from Android, you are right at home. Boxes behave like Boxes. Rows behave like Rows. • Dev mode Hot Reload which actually works. OMFG it's so good. Shame on you, Android, for never making it work. The Bad • Massive bundle size. I wouldn't recommend using Kobweb for a public-facing website. • Lack of some common UI components in Silk. First party
date/time picker
.
(filterable) dropdown menu
. • Beware of
Modifier.weight
and Column/Row spacing attributes. Both are not-quite-right • Inconveniently placed KDoc. It is placed on Types. But in practice you use factory functions to instantiate those Types (e.g.
CssStyle.base {}
,
Color.rgb()
). And because of the way IntelliJ IDEA displays the quick-doc popup, the KDoc is hidden from you - the factory function has no KDoc to display and the receiver (
CssStyle
,
Color
) is resolved to the
companion object
of the Type, which also doesn't have any KDoc. Therefore, there are no symbols in your actual application code that would allow you to look up the KDoc of Kobweb components with a single shortcut. • A first party abstraction over XHR for file uploads with progress report would be a nice to have The Ugly • I don't know. So far I haven't encountered any unfixable ugliness. Would I recommend Kobweb to others? For lightweight use cases similar to mine, yes. But only under the condition that you have existing knowledge of both HTML + CSS and Compose. Kobweb is not a learning tool for web dev newbies. If you don't know HTML/CSS or Compose UI, you'll be confused by the mixing and matching of Kobweb-specific layouts + modifiers and Jetbrains Compose/HTML tags + attrs. For larger projects, projects with unclear vision of future development, no. Stick to well-understood JS frameworks.
👍🏻 1
thank you color 1
s
Hot reload is honestly such a game changer! Android unfortunately has some technical reasons that prevent it. HTML and JS are far simpler to hot reload, Compose on ART? Not so much. On a related but kobweb-unrelated note: if you use Compose Mutliplatform, you can get hot reload on desktop (with JetBrains Runtime). It's experimental, but works so well it changes the game. I never use Android during most of my development anymore because of it, until I'm dealing with Android-specific stuff or testing before a release.
o
HTML and JS are far simpler to hot reload, Compose on ART? Not so much.
Absolutely! But I am now forever spoiled and I simply... expect better. Google spends what - 15? 20? or more? million dollars per year on Android platform development. For that kind of money I'd expect Hot Reload to be a solved problem by now.
s
Sometimes no amount of money can solve architectural issues 😆 But yeah, Android could land changes in ART (Android Runtime, Android's "JVM") to enable something similar to enhanced class redefinition (DCEVM) on JetBrains Runtime on desktop. That would need to happen in an upcoming Android version (or mainline update to ART). DCEVM is what drives hot reload on Compose Desktop currently, and it'd be great to have something similar on Android! Edited: just realized DCEVM is very specific to OpenJDK / Hotspot. ART could implement something similar, not necessarily identical.
☝️ 1
(I'm not holding my breath for it though, unless Google shows interest in improving things this way).
d
@okarm just huge, huge thanks for posting this. Really, truly appreciate the detailed feedback. And I'm humbled you put your faith in our software for your project. Thank you for trusting us.
If you don't mind, I'll reach out to you directly to get a little more information I can turn into bugs in our issue tracker.
BTW if you wouldn't mind looking it up, I'd be very curious if you could visit your Kobweb site while having the network tab open in Chrome Dev Tools and let me know what you see there. The bundle size you see during an export might be misleading -- the output compresses remarkably well. I generally see about ~300K or so for what actually needs to get downloaded by a user.
As for UI components in Silk, I absolutely agree it's totally underbaked right now. We have plans to focus on filling those out extensively this year. Take a look at Chakra UI docs for something that is much closer to our final vision.
And also, yes, our docs are unfortunately not great, or at least not of uniform consistency. I'm a big believer in good docs (I did a much better job in Kotter ) and I do consider filling them out to be required before considering Kobweb "final". A lot of the comments in Kobweb would have to be copy/pasted across multiple copies of the slightly different versions of the same method, which means later if we change one, we'd have to change them all, so we've been postponing it. But it's good to hear feedback like this from users, to remind us that it will be very useful to get this right.
I'm really happy to hear the Android-inspired layout code worked so well for you! Thank you for sharing that with us.
It's also gratifying to hear that the live reloading experience worked so well for you. Honestly, I think what worked best here was that was a feature I worked on top of from the very beginning. A lot of projects try to add live reloading on after the fact. I don't want to take too much credit though! I owe a lot to Gradle here (
gradle --continuous
is an amazing feature), and beyond that, I just need to kick a "reload" request to the browser when I detect the build is done, so I have to send lots of appreciation to the browser as well.
And finally, you are right that this is a tricky framework for web dev newbies. There is A LOT going on here for people's first projects. After v1.0, I'm hoping to focus putting out a series of simple, official Kobweb video guides on YouTube. Perhaps that will help a bit to explain some of the concepts to people who are starting from scratch. But a lot to get done before that point....
🎉 2
Anyway, keep on not writing JavaScript ❤️ And thanks again for sharing this great feedback.
@Skaldebane it's been a while. Does Apply Changes not work well for you? The Studio team worked closely with the ART team to support it. I believe the ART team implemented a subset of the JVMTI spec to accommodate this feature.
s
Huh, interesting. I remember using it a long time ago (and it did kinda work) with Java/XML, but since the new UI rolled it's been gone from the UI by default (it could be added again from settings), so I never bothered trying. Not sure how well would that work with Compose though, but I'll try giving it a shot! I think Live Edit is built on similar tech (and maybe other ART features in Android 12+)? And Live Edit haven't worked for me in a long time (it just tells me to re-run). Even if it worked, it feels super limited compared to what we recently got on desktop. Live Edit of Literals was more reliable, but even Live Edit kinda worked a while ago. I haven't worked with a pure Android project in a long time now, so I'm not super sure if it's an issue with multiplatform projects or something else. Thanks for the pointers though!
🫡 1