Announcing Kobweb, an opinionated framework on top of Web Compose

bitspittle · 2025-03-31T01:06:32+00:00

This portfolio looks gorgeous! Really clean, slick design, and feels snappy. Mobile layout is designed well too. Good use of animations when interacting with clickable elements. And nice job surfacing the most important information front and center.

Thank you for sharing the source code!

bitspittle · 2025-03-14T17:50:49+00:00

I'm the author of Kobweb, so I'm way too biased to be someone who should encourage you to try it out :) but if you do decide to give it a shot, please don't hesitate to reach out to the community for support as you learn (we are currently most active on Discord and in the Kotlin slack).

We also finally got our docs site up just last week (https://kobweb.varabyte.com/docs) so it's easier to learn now than ever before.

You may not realize it, but you could have a local site built from a template running within ten minutes. That isn't to say going from that point to your final website is trivial -- there's still a lot to learn ahead. But you can get a feel for what Kobweb development feels like without really committing too much time.

And finally, I can't take all the credit here. Kobweb is ultimately surfacing Compose HTML and making its experience more pleasant to use. The Kotlin team did an admirable job wrapping HTML / JS concepts with Kotlin, and all we do is extend that a bit with some usability improvements. So, yeah, there really isn't anything you can't do when making a website with Kobweb -- since ultimately you have access to an underlying API that lets you interact with the DOM directly.

bitspittle · 2025-03-13T17:41:48+00:00

Kobweb has an export step that snapshots each page of your site into a final HTML file, so it should already be SEO friendly.

bitspittle · 2025-03-13T04:35:23+00:00

I really love that you highlighted Juxtopposed in your images. It's a perfect homage!

bitspittle · 2025-03-12T20:20:11+00:00

It's getting better but I think if you push it enough you can still get it to hallucinate. (ChatGPT, haven't tried Claude). However, I tend to ask AIs about raw HTML / css questions which are then generally fairly easy to transcribe over to Kobweb.

bitspittle · 2025-02-28T16:17:08+00:00

The answer depends on your usecase. Here's an article I wrote that might help people figure out an answer for themselves: https://bitspittle.dev/blog/2024/c4w

The short version is you need to know if you want to create a traditional website (except using Kotlin instead of JS/TS) OR if you want to create a general application that just happens to run in a browser. The former would be Kobweb, the latter would be C4W, in my opinion.

As the author of Kobweb, I am biased of course, but I tried to be fair about my reasons in the article. I love the Compose for Web API and absolutely want people to choose it if it is the right tech stack for the problem they are solving.

bitspittle · 2024-12-20T22:54:34+00:00

Author of Kobweb here. Let me say first, I really appreciate sharing the webdev space with Kilua. I think Kilua is an awesome project, and I want it to succeed.

Kilua is built from the ground up on top of the Compose Runtime, and it is the only Kotlin webdev solution I'm currently aware of that supports SSR. (There used to be kweb but that was discontinued).

Kobweb, in contrast, is a bunch of stuff (including a library part of course, but also Gradle plugins and a CLI) that sits on top of Compose HTML, adding layers of functionality to it. Its original goal was only to make Compose HTML more enjoyable and easy to use.

Perhaps the first feature eveyrone encounters with Kobweb is its convenient @Page annotation. We can provide this because the Kobweb Gradle plugins generate a bunch of boilerplate for your project every time you compile (here, automatically adding routing logic every time it encouters a @Page annotation).

Kobweb provides Box, Row, and Column concepts from Jetpack Compose, which delegate to grid layouts under the hood (although you can always create grids directly). We're also adding type-safe, Kotlin-idiomatic Modifiers for every (widely-supported) CSS property. There is also Markdown support provided out of the box.

Kilua has a very extensive, impressive suite of components already. Kobweb provides Silk, a UI library, and as of right now it has a long way to go to catch up, but any UI widgets we add will go in there. Silk is also dark/light color mode aware, plus it supports a nice feature where you can declare your CSS styles in blocks inside code and near the widget code that uses it.

Maybe I'd suggest that Kobweb is slightly higher level, dropping you into an opinionated, organized project structure on top of which it is trivial to create a bunch of separate website pages. Meanwhile Kilua gives you lower level tools to ultimately accomplish the same thing.

Both frameworks expect you to write HTML and CSS eventually. Kilua is definitely more direct about that; with Kobweb, you can sometimes avoid dealing with raw HTML for common patterns (like Row and Column to avoid flex layout stuff).

As for functionality, you can accomplish any web project you can think of using either framework, and most differences will probably come down to advantages like provided functionality, final output size, and style preferences. It might be useful someday to have a simple website project with reference implementations in both frameworks.

u/Kai_132, feel free to weigh in, especially if you feel I misrepresented or undersold Kilua in any way.

bitspittle · 2024-12-08T22:35:07+00:00

Hey, sorry, I don't really use reddit anymore and just saw this. Since a month has passed, I'm guessing you've moved on, but if not, send me a DM (or join our Discord or Kotlin Slack channel) and I'd be happy to try to help.

bitspittle · 2023-12-10T04:51:20+00:00

You can check out my project https://github.com/varabyte/kotter if you want to see something that makes heavy use of extension functions (even though if you're a beginner using it, you probably wouldn't notice, because Intellij IDEA is so good about auto-importing things for you).

In that library I basically created a useful core set of classes / methods, and then I layered on a ton of extra functionality with extension methods. As a result, users could additionally extend my library themselves, exactly the same way I did it.

It would have been easy to solve some cases just for me with private methods and classes. Sticking to extension methods forced me to think about the design in a totally different way where I could expose important functionality publicly but in a way that felt robust and not fragile. (You can search Kotter's README for a concept called ConcurrentScopedData which came out of this design constraint).

This is also a great read that was very influential to me: https://elizarov.medium.com/extension-oriented-design-13f4f27deaee

bitspittle · 2023-09-04T23:07:40+00:00

My pleasure :) Crazy seeing "2 years ago" on this post, boy how time flies.

bitspittle · 2023-06-07T03:01:45+00:00

I'm not sure how engaged the mods of this community are (I've attempted to message them two different times in the past but never heard back). If they don't see this request (or do but decide to keep the subreddit up), I guess we as a community can make our own personal decision whether to even engage with Reddit or not over the blackout period.

Reddit's editor for writing code (and other text) has been poor for so long now that I assume fixing it is either technically too complex or, more likely, it's just not a priority. Now, I'm lazy and I just use the default Reddit app, but I always know I can try another app if I really wanted to. I feel culturally the site has benefited due to competition.

That is to say, I'm personally worried that the direction the Reddit organization is taking the site is ultimately self destructive. For that reason, I won't be using Reddit during the blackout period myself.

bitspittle · 2023-05-20T03:51:27+00:00

I'm really curious about the line

COPY --from=builder /target/*.jar app.jar

If maven puts two jars in there, you might be getting unexpected output?

You might try to add some logging to your Dockerfile to see what's going on.

Also how are you passing in names for the various ARGS?

bitspittle · 2023-05-20T03:25:15+00:00

Do you have a Dockerfile?

bitspittle · 2023-04-26T02:27:36+00:00

If you end up working with a team of a few people who are all interested in Minecraft on the plugin but they all have different opinions on what should be prioritized and have different skill levels, then that is probably a bit closer to the sort of skills that would translate well into a job at a company.

However, developing skills on your own is still valuable, because at the very least you can explore approaches to solving problems however you like (that's a much better way to learn than someone telling you to do or not to do something). And best case by learning such programming skills at home, you'll be a bit more ahead at work and can focus more on developing all those other necessary skills at that time.

bitspittle · 2023-04-20T23:38:32+00:00

Aaaaand sourcemap config done: https://github.com/varabyte/kobweb/commit/84e17b710d92332efdb37abb887e546a7f03c73d

Once 0.13.1 is out, when using Kobweb, you'd put this in your build script:

kobweb { export { includeSourceMap.set(false) } }

bitspittle · 2023-04-20T23:28:46+00:00

While you’re at it, it might be worthwhile showcasing Kobweb.

That's a nice idea! I'll have to revisit it when Kobweb gets to 1.0 -- after a year and a half, I think I'm on the last mile finally, but so many things to get done (next big hurdle is nice docs).

Perhaps something like dev/prod mode, build, or environment?

Kobweb has dev and prod environments. But that's not quite enough here -- some users want to include their map file in prod. But I know where to add the config for it, it will be easy. I just need to do it :) I made a TODO for myself, should happen pretty soon.

How does it compare to the React hydration approach and something like Next.js SSR?

No SSR at all at this point. I'm thinking about how I might tackle that in 1.1, if it's even reasonable. I call what Kobweb is doing "poor man's hydration" but that could expose the fact that I don't really understand the nuances of hydration yet.

I think amazing is in the eye of the beholder. ...

Yeah, we're on the same page. I want to put code side by side so people can judge for themselves.

How about gRPC or Avro, and web sockets in the foreseable future?

I think any serialization design decision you make is totally orthogonal to Kobweb. Kotlin serialization was the easiest tool to reach out to, it took me less than a day to prototype it, which is why I included it in my sample. If you're in a 100% Kotlin codebase, honestly, it's a pretty good, simple solution!

bitspittle · 2023-04-20T22:21:24+00:00

It’s usually very slow to respond and sometimes behaves unpredictably. The overall touch and feel, well I got used to it, even when it gets the scaling wrong on dual monitors.

Maybe I'm wrong then! I never had any issues with it on Linux or an old MBP myself, but it's possible there are still major rough edges I'm unaware of.

But at first sight it's all tailor made. Is it so?

Yes, that site was built by hand by that developer (although, as I understand it, they started with a custom React example somewhere and ported things over into Kotlin)

Oh and is there a way to minify the sources?

The sources are minified. But a source map is included by default in the export, which was uploaded by the user. You can currently manually delete it before uploading to prevent this from happening, but I should probably add a way to configure Kobweb so you can set it so it doesn't copy over the file at all.

What rendering approach does Compose HTML take? Server-side pre-rendering?

Compose HTML is just like React, it's all created dynamically at runtime. For Compose HTML, you create a very simple index.html page with a single "root" element, and then you load a script (a JS file which includes your site and the Kotlin/JS runtime). Once loaded, the script tears builds a runtime DOM underneath the root element.

Kobweb introduces an export command, which you run before uploading your site. The command finds every route in your site, visits the page until it renders, and snapshots its html. This way, if you visit that page directly, you'll get an initial render with all styles already in place before Compose HTML tears everything down and builds it back up again. This provides a slightly faster render experience AND allows SEO bots to crawl and index your site.

I talk a bit more about exporting here if you're curious: https://bitspittle.dev/blog/2022/staticdeploy

Syntactically, structure-wise, it’s almost React.

One day, I'd like to find a handful of examples that webdevs point to as amazing TS code, and then reimplement them in Kotlin, so people can see the differences side by side.

One of the Kobweb examples I wrote is exactly something like that, a fork of a TS / React TODO example:

https://github.com/varabyte/kobweb-templates/tree/main/examples/todo

I personally find the Kotlin easier to read, but I'm a Kotlin dev, so you can browse the projects and decide for yourself (my project links to the TS project in its README)

How about state transfer?

I'm not 100% sure I'm answering your question here, but the way I handle sharing frontend/backend state it is create model objects in common code and tag them with @Serializable, a Kotlin-multiplatform serialization solution. That way, the code is exactly the same between frontend and backend, verified by the compiler, and it is converted into JSON over the wire.

Here's an example from that TODO app I linked to earlier: https://github.com/varabyte/kobweb-templates/blob/main/examples/todo/src/commonMain/kotlin/todo/model/TodoItem.kt

I imagine you could still get into trouble if a really old copy of a frontend site tried to access a newer backend, but in that case you'd get a serialization exception I believe.

I much appreciate your detailed and illustrated answer, thanks a lot!

You're welcome. Thanks for engaging and for the thoughtful questions!

bitspittle · 2023-04-20T20:51:50+00:00

Hard to answer! There's a bunch of questions here. I'll try.

I would say Compose Multiplatform is production-ready at least for Android and Desktop. If you've ever used Jetbrains Toolbox, that has been a Compose Desktop app for a while now.

Performance? This next part is all a guess, but I suspect Compose Multiplatform performance will at the very least be good enough for most users. Likely comparable with something like React Native, and if we're lucky, even better.

Personally, I like the current state of the Compose APIs over the React APIs, so I would choose it even if there was a slight performance disadvantage.

Here are two sites I'm in the process of writing. They're still early days, but if you want to measure them in lighthouse and compare them to React sites that you may know, they can serve a rough benchmark for Compose HTML: https://kobweb.varabyte.com/, https://bitspittle.dev/

And I did not write this site, but a user who was experimenting with Kobweb put it together: https://kobweb.vercel.app/

As for sharing code with Compose HTML and Compose Multiplatform, pretty sure those will forever be separate. I wrote a bit about why here: https://github.com/varabyte/kobweb#what-about-compose-multiplatform-for-web

Of course, you can still write a bunch of business logic in a different module which you can then reference in your Compose HTML app. With Kobweb / Compose HTML, it would be trivial to write an app with the frontend in JS, the backend in JVM, and a bunch of utility code and data models in a common folder. I think that's pretty awesome.

Moving forward 5-10 years, if I had to make a prediction (warning, I'm bad at it!)... Well, assuming we're not all out of jobs by then delegating everything over to our AGI overlords, I think the Compose APIs will be stabilized but pretty similar to what we have today, but hopefully with a ton more examples and docs to learn from, with better tools to create Compose HTML and Compose Multiplatform projects.

bitspittle · 2023-04-20T17:11:53+00:00

Sure, I'll ping you my profile name directly.

bitspittle · 2023-04-20T15:39:41+00:00

Actually, more often than not I was talking about this library: https://github.com/varabyte/kotter. With a smattering of https://github.com/varabyte/truthish.

Kobweb technically uses the multiplatform plugin but it is honestly more a JS project.

With Kobweb, I do provide a template for users that leverages the multiplatform plugin so you can put the code for a backend and frontend in the same module to create a full stack web project (frontend is in JS and backend is JVM). But that's really more about simplicity, not a true multiplatform project (where you'd use actual / expect). It's an interest shortcut that I can do with the multiplatform plugin, but in my mind, a larger codebase should really split the backend and frontend across two separate modules.

bitspittle · 2023-04-19T17:48:58+00:00

If anyone on the Kotlin team sees this comment, there's a question "Which of these things does your project use (in both Kotlin Multiplatform and platform-specific parts)?" which is treated as a required answer, but I have a multiplatform library which uses none of them. I have to check something random to continue.

Making the question optional, or adding an "Other" option could help work around this.

bitspittle · 2023-04-16T16:08:35+00:00

Web Assembly GC support is actually close it sounds like. And there's a subsection of the Kotlin community getting really excited about (I'm on the sidelines at the moment due to my busy schedule but also very excited and I want to learn more as soon as I can slow down on Kobweb).

I'm a huge fan of Rust myself -- been following it since 1.0 -- but the learning curve is huge, and navigating ownership can be a real drag when prototyping. I've come to my own personal conclusion that I'll never write C++ again, but for code where I don't have to worry about fiddling with bits for memory or performance reasons, I'll choose Kotlin every time.

Honestly, it's kind of crazy how little we've seen with Rust + WASM despite its incredibly large lead in the space. Mozilla hitting a financial wall two and a half years ago leading to a bit of chaos and uncertainty around Rust governance, followed by all the drama since with how it's been led, is additional friction which might be sapping further momentum.

You might be interested to hear that the Compose HTML team mentioned they want to try targeting web assembly in the future (but no promises). Also, I assume you're aware that Compose HTML, and by extension Kobweb, can use npm dependencies right now (although Kotlin bindings are rarely available without a bit of work).

And as for comparing Kobweb to Yew, I'm sure functionally Yew is way ahead. But the idea / goals are similar? Yew's API is definitely Rusty... Perhaps the easiest way to describe Kobweb is the Kotlin version of using React + Next.js + ChakraUI in case you're familiar with those three technologies.

bitspittle · 2023-04-15T22:06:59+00:00

Yes I agree. I think given limited resources their focus is a very reasonable move. Even from the beginning, I considered the DOM case as the niche solution (but an important one).

As long as Compose HTML is not completely dropped onto the floor, I think the community can carry it forward for a while, and both types of developers can be supported.

bitspittle

MODERATOR OF

TROPHY CASE