https://kotlinlang.org logo
Join Slack
Powered by
Hey folks, I'm evaluating Kotlin and Compose Multi...
# compose-web
i
Hey folks, I'm evaluating Kotlin and Compose Multiplatform for building a POC of a niche website that I'd like to rank well on search engines. Are there any SEO concerns?
s
Yes, even if JB is trying to hide/ignore it, but compose for web cannot be indexed, so you will not get any SEO out of it.
➕ 6
You will have to opt for Compose Html (bottom of the page)
thank you color 1
i
Got it. Thanks for clarifying! 🙌 I love Kotlin and the Compose APIs but w/o SEO using it for testing startup ideas won't work
s
There are libraries like Kobweb or Kilua which you could check out - both using compose html. kobweb sort of "mimics" familiar compose APIs (it's like the next.js for kotlin). kilua offers built in SSR which might be a requirement as well
thank you color 2
i
Compose HTML seems like a solution but we won't be able to re-use our mobile UI and we'll have to write HTML + CSS 😬 Are there any plans by JB to fix the Compose Multiplatform indexing issues?
👆 1
🚫 2
s
compose for web draws the entire UI onto a single canvas (opposed to html + css), which is inherently not indexable. I doubt we will see any improvements on this front for the foreseeable future
👍 3
a
if you want to reuse components from your app you can still have your landing page written in html + css and then the rest of your app will be in CMP. your mobile app doesn't have a landing page so that's web specific code, right?
the web only technology counter part of this is having your marketing site (landing page) separate to your app (dashboard) landing pages are usually static (html) apps are interactive (react)
🙌🏽 1
🙌 2
s
other concerns are bad accessibility, huge download sizes, international language support, apart from all kinds of unexpected behaviours. until recently you couldn't even use wasm on safari. to be honest, compose for web is a toy, but not much more for now. I have successfully used #kobweb to build some websites which also rank on search engines. you cannot reuse your mobile UI but you can reuse and share the entire app logic
thank you color 1
i
Thanks for sharing folks! I like the marketing website (HTML + CSS or Compose HTML) and product (Compose Multiplatform) strategy. I was hoping if JB can build some tool/way to convert Compose landing pages into indeaxble HTML. Our landing pages are usually simple and minimalistic - value prop. + some fancy animations / interactive experiences. P.S. I'm an Android dev and I prefer not to spend hours to "center a div" and grt familiar with CSS to do nice animations/transitions
In an ideal world, as an Android dev I'd like just to scale our mobile/tablet UI on desktop and call it a day 😄
💯 1
a
@Iliyan Germanov better start a different thread for sharing links, otherwise this will get messy 🙂
👌 1
@S.. does have very valid concerns. it really depends on your use case right now whether Compose web makes sense or not
a
How does Compose HTML help with SEO? This only works when using a server side framework like Kobweb
s
not necessarily server side (kobweb isn't SSR either), but compose html gives you an html Dom, which kobweb uses for SSG and kilua for SSR. but yes, you need something built on top of it, since compose html itself is pretty barebones. both libraries actually supplement quite a lot that's lacking
☝️ 1
here's an article diving a bit deeper into issues and concerns about compose for web and a comparison with compose html https://bitspittle.dev/blog/2024/c4w not to badmouth compose for web but it's approach of using a canvas has some implications which JB does not communicate about. so for requirements like SEO, the hidden compose html library (with the necessary frameworks on top) are probably the better choice if you want to stick to kotlin
c
but compose html gives you an html Dom
But that will not help with SEO. As far as I know, I.e google, will only index the html site and not execute JavaScript so your page is pretty empty.
s
yes, but kobweb has an export process which spins up a local server, visits each page and snapshots it to a static html file. I imagine kilua does something similar on the server
👍 1
p
What about making landing page on pure html with all seo stuff with redirecting to complicated business logic to web page made with compose?
s
if your web app (c4w) does not need to be indexed this could work (ecommerce likely wants the products to be on google etc) but as pointed out in the article above, compose for web still has other concerns apart from SEO which should be evaluated
👍 2
i
#kobweb looks intriguing! I'll definitely dig deeper and give it a shot 👍 Thanks for sharing the blog post for C4W!
r
And just a note - Kilua is not based on Compose HTML. It's based on Compose Runtime but the rendering engine is implemented from scratch to support SSR and Wasm target (I'm the author).
s
oh apologies, I wasn't aware
e
I know pretty much 0 about SEO, but is there a way to differentiate between regular requests and indexing requests and have the server return just the information needed for SEO? Unless what it needs is an actual HTML representation of your content?
r
As far as I know returning different content for google bot and different for users is considered a bad practice and can make your site be banned from google at all.
👍 1
👍🏻 1
☝️ 1
e
I guess I have some learning to do. I guess there's more to it than just meta tags?
👍 1
r
c
Initially Google (PageRank algorithm) was based on links from and to your page and give them weights.
e
Maybe they'll just start rendering your page and having AI "look" at it 😆
a
no way to tell 🙂 better to build for what needs there are today with the tech that exists right now. otherwise you might end up waiting forever
but yeah the way google works with indexing your site is much more complex (it seems at least) than just the contents of your page. it scans for links in the page, anchors, images etc. so you can't just share 'here are the important stuff for seo'. ui performance is measured as well too
👌 1
d
> P.S. I'm an Android dev and I prefer not to spend hours to "center a div" and get familiar with CSS to do nice animations/transitions > Author of Kobweb here. I used to work on Android Studio so I get where you're coming from. If it's any consolation, I've come to really appreciate CSS since working on this project. Of course I'm biased, but I think having a Kotlin type-safe layer on top of CSS helps a lot. And Kobweb, by providing Box, Row, and Colun primitives, renders many "centering a div" concerns moot. https://github.com/varabyte/kobweb#learning-css-through-kobweb
🙌 2
i
And Kobweb, by providing Box, Row, and Colun primitives, renders many "centering a div" concerns moot.
That's what won me in the first place! Thanks for working on this awesome project 👏 I'll give it a try^
Of course I'm biased, but I think having a Kotlin type-safe layer on top of CSS helps a lot.
Definitely!
🙇 1
@David Herman I haven't read the docs fully yet but do Kobweb support packaing and deploying an SEO optimized sites to GitHub pages? I'm evaluating giving a shot for a landing page of a startup idea that we want to test in our local market P.S. It's nice to see that you've also thought about navigation 💯
d
f
Some recommandation from the Kotlin Website https://kotlinlang.org/docs/js-overview.html#kotlin-js-frameworks
d
Some recommandation from the Kotlin Website https://kotlinlang.org/docs/js-overview.html#kotlin-js-frameworks
How do these compare to Kobweb and Kilua?
r
Kilua is KVision's "younger brother". The API is quite similar, many modules, components and their properties are almost the same. Unlike KVision, Kilua is based on Compose Runtime and utilizes full power of Compose for state management (
remember
, 
mutableStateOf
, 
collectAsState
etc.). Kilua's unique feature is full support for true SSR (with HTML code generated on the sever dynamically).
a
how come all these compose related web frameworks don't reuse jetpack compose's api but for the web (ie hide any sort of Div, tags, css etc and use Rows/Columns and modifiers) is the target users people who know how to use web technologies and want to use kotlin instead? found it odd
f
Kotlin/JS was started somewhere like 2017, it's older than compose. It's an alternative like any other web framework (rubyonrails/Django/…).
Compose for web use WASM technology and not javascript directly
s
hide any sort of Div, tags, css etc and use Rows/Columns and modifiers
it's not really feasible because the underlying concepts are fundamentally different. in fact, kobweb provides Row/Column and Modifiers, which offer a lot of convenience and typesafety but still map to CSS.
I think if you try to completely hide the web speciality it would become very confusing. how would you go about debugging it with browser devtools when your code reflects a completely abstracted api?
a
Not sure what you mean by debugging. I wouldn't want to debug the framework/library that does the mapping to html/css. That's like debugging that jetpack compose renders the right pixels no?
But if that is the reason why such frameworks don't do a 1 to 1 map of jetpack compose, it's totally fair point and I got my answer
s
you don't debug the mapping but for example the layout you create. figure out why your hover effects don't work because you applied them to the wrong element etc. or try out different css properties. check responsiveness..
👍 1
r
Having a framework that use jetpack compose api but render to plain html/css is a dream which will probably never come true. If it was possible, JB would do this by extending Compose HTML instead of taking the canvas way.
d
I wouldn't rule it out completely. I think eventually might actually happen.
a
Canvas voor web does not make sense at all to me. Flutter went down that road and after all those years it is still terrible. I really don’t understand this strategy by JB. They could make a React killer. But instead they focus on reimplementing the whole browser experience in Canvas. It’s Java applets all over again
d
I think Kobweb and Kilua are very beneficial though, in order to look at things from a different perspective. Solutions are destined to only get better, thanks to the experiments of everyone in the open source community.
s
the canvas solution is the only one where it's possible to keep the "share your UI on all platforms" marketing pitch, whether it's good or bad 🤷🏻
e
I haven't tried Flutter so I can't comment on it (but I have no trouble believing that it's terrible 🧌 ) but so far my experience with Compose Web has been great. The biggest issues I keep hearing about are SEO and accessibility. I believe they're working on accessibility (or maybe already finished working on it), and SEO hasn't been, and probably never will be an issue for what I build. I suspect the same is true for most Kotlin developers. If you're making an internal tool, or SaaS webapp, or just a web version of your mobile app, then you don't need SEO. I guess if you do need it, then the answer is to either not use Compose Web or find a way to have a hybrid approach if possible.
➕ 3
Also let's not forget that it's still in the experimental stage (unless they bumped it to alpha at KotlinConf), so there's a lot of room to grow here. But what's already there is great from my perspective.
s
the big problem isn't really it's alpha version but that it's based on a canvas. so some problems are pretty much engraved into it's foundation
e
What are those problems? Aside from SEO
d
Size, having to ship the big Skia library
s
performance in some cases, size, accessibility, missing out on a huge js ecosystem for html dom, browser devtools, and one big concern for me as well: languages like chinese, korean, japanese, russian.. don't work out of the box without providing huge font files
d
Yes, accessibility is definitely another important issue
e
Size is probably going to not be a big issue for many because of the same reasons I listed for SEO. And that's probably a more solvable problem considering they're not really focusing on things like that at the moment (alpha)
s
you are still doomed to have bigger download sizes, because you simply need way more code to make all of this work
e
@S. Size and performance (and I haven't seen many performance issues) are products of this being an early stage product, and they're not unsolvable problems either. I personally don't consider not having the js/dom ecosystem an issue. Devtools is a bit of a pain, but again it's something that can get better.
And if it's always going to be a little bigger that's fine by me if I never need to touch standard web dev 😅
r
You would be great java applet dev, if applets were still here with us 😉😛
😄 1
e
I started off working with applets 😂
s
always comes down to the use case but it's a LOT bigger than conventional websites. especially considering serving millions of users and paying for the bandwith. and the problem that comes with this is the time to render which is also quite bad compared
d
As it is now, compose web makes sense for internal applications (with a limited number of users, for specialized tasks), but not for public consumers
But I am confident, within 3 years, compose web will be much better than now and will be feasible for a larger number of use cases
r
With Kobweb, is it not possible to use expect/actual to build multiplatform components? I.e. is it possible to have a UI composable in common code, which uses Jetbrains Compose primitives for some platform, and Kobweb primitives for JS?
r
There is a project which tries to do this https://gitlab.com/opensavvy/ui/decouple (#C04QPSCQ39T)
👍 1
💯 1
👍🏻 1
d
> @Alex Styl how come all these compose related web frameworks don't reuse jetpack compose's api but for the web (ie hide any sort of Div, tags, css etc and use Rows/Columns and modifiers) My very early first prototypes of Kobweb attempted to do this, but very quickly, I found it felt like paddling a kayak against a tsunami. I quickly came to a fork in the road, one path where I could just build usability on top of Compose HTML and the other where I could try to recreate the Jetpack Compose API instead, delegating to (non-
canvas
) web elements behind the scenes in a way that was opaque to the developer. I'm not 100% sure, but I doubt you can create Jetpack Compose entirely backed by (non-
canvas
) web elements. I bet it would be a real challenge to port the various powerful Jetpack Compose animation APIs over, as a concrete example. My current opinion: If users really want to use Jetpack Compose, and they truly understand the pros and cons of that decision (thanks to @S. for linking to my blog post earlier which goes into that!) then they should just use Compose Multiplatform for Web. On the flip side, if you're going to embrace the web, I think devs should bite the bullet and start learning about HTML / CSS but wrapped in a Kotlin-y blanket.
🙏 1
❤️ 2
👆 1
a
I see. Thanks!
a
Ps, modern state of web is much better then before. With import maps, es modules and http2 you don’t need any build tools. Just make your websites, sprinkle some simple JS over it (with a minimal framework like Stimulus or something) and deliver SEO and fast sites. Google NoBuildJS for some inspiration.
d
@Arjan van Wieringen pure JS for your website is certainly a common and very feasible option that people should definitely consider! It's hard to beat the advantage they get since the JS runtime is included in the browser already and doesn't have to be redownloaded per site. Kotlin may be preferred if you want to leverage multiplatform, which is a powerful use-case if it applies to you (e.g. teams that are already all in on Kotlin). For example, it's a really nice experience writing both your web frontend and server backend in Kotlin, with data objects and business logic declared in common code that can be shared across both codebases.
287 Views
Open in Slack
PreviousNext
Powered by