Hey Folks, Is there anything that can be done for ...

# compose-web

[Moe]

Hey Folks,
Is there anything that can be done for web apps using wasm regarding SEO ?

[Robert Jaros]

It depends what do you want to use. There is nothing you can do with Compose Web, but there are alternatives - Compose HTML, #C04RTD72RQ8, #C06UAH52PA7

[Moe]

@Robert Jaros thanks for your response
would that mean something like this should work ?
Build the html parts with Compose HTML and create a canvas for Compose Web ?

[Robert Jaros]

Not really. I mean you don't need to use Compose Web at all if you want to build web app with good SEO in Kotlin.

[Moe]

So basically since The JS is client executed no search engine will register this, at this point combining both wouldn't work If i understand you correctly

[S.]

in fact, some crawlers also do run the js, if something is important for SEO you just shouldn't rely on it + make sure to have good loading times.

the compose for web issue isn't the js at all, it's that it's painted onto a canvas which is basically opaque to crawlers

[S.]

however, one of the only reasons to combine compose for web and compose html is, if you have some complex UI elements which have to be rendered on a canvas and can't be displayed with normal html elements. other than that pick one of those, unless you have a good reason

[Moe]

So wouldn't pre rendering with something like Ktor help here ? Say if I was forced to stick with compose web

[S.]

prerendering a canvas might be difficult due to screensizes. but in the end, it's still a canvas, which is like a blank sheet for crawlers or accessibility tools alike

[Moe]

that sounds fair, so Ktor might help for some sites, and might not for others.
the one im working on has a fixed width at 1440, and its mostly an informative site with a bunch of text.
think this could be a good move here ?

[S.]

No, you don't get the point. It's still a canvas which crawlers can't index. Ssr only really helps for compose html

[Moe]

i see what you mean now, thanks!

[Casey Brooks]

To throw in my two cents, which many traditional “web devs” will probably disagree with: if you need enough interactivity on a page that you would want to adopt Compose Web/HTML (or React, or any other heavy client-side framework), then you’re building an App that probably requires users to log in, and thus SEO isn’t really applicable to you. It’s much closer to an Android or iOS app, and no one asks why web crawlers ignore those, because SEO marketing simply is not their purpose.

If you’re concerned about SEO, then you’re focused on the static content of a page, and thus wouldn’t expect to have much interactivity on it, and don’t need a heavy framework. Basic HTML and browser JS APIs are all you want here, since the goal is a very lightweight page.

JS frameworks with SSR, static outputs, etc. do blur the lines here a bit, but I think it’s safe to say that Kotlin’s Web offering is well outside of that use-case. Kotlin is optimized for highly-interactive Web Apps, and simply has too much overhead to be competitive for lightweight SEO-focused websites.

[Skaldebane]

@Casey Brooks This. Build your landing page etc... with HTML (whether using Kotlin or not isn't very relevant, but make sure whatever you use generates static HTML), and the product itself can be Compose/Web.

Though note that Compose Web has some other usability issues for the moment, but these will hopefully be resolved as it stabilizes, hopefully matching Flutter Web's usability, which is in a pretty great state given the limitations of the web platform in general.

[David Herman]

@Casey Brooks

I can only speak for Kobweb here, but we're spending a lot of effort wrapping all CSS properties with type-safe Kotlin APIs (significantly extending an initial, incomplete set provided by the Compose HTML library). This has nothing to do with being optimized for interactivity, but it can still be a major benefit to help some decide to reach for it as a solution.

Also, if you're writing a fullstack site, getting to use Kotlin for the whole codebase is a pretty sweet deal. Multiplatform is great.

And finally -- many of us love the Kotlin language. Having access to powerful concepts like suspend, var/val, a consistent "this" concept, sealed classes, and much more, can be valid reasons to reach for a Kotlin API for even a relatively static website.

> Kotlin is optimized for highly-interactive Web Apps, and simply has too much overhead to be competitive for lightweight SEO-focused websites.
I'm not really sure what "competitive for lightweight SEO-focused websites" means to each person, but in practice, users have been able to get strong lighthouse scores for their Kobweb sites. The compressed size of many Kobweb sites is 200-300K or even less, which, sure, can't compete with a JS site (where the runtime is already bundled into the browser), but it is still plenty fast in practice and often no larger a download than any one of multiple image assets often found on the same page.

[Skaldebane]

I think they meant "Compose Web" by "Kotlin" here. Otherwise, Kotlin/JS is freaking awesome.
And hopefully Kobweb allows a Kotlin/Wasm option in the future!

[David Herman]

If that's the case, then I would probably agree. Compose Web is solving a different problem.

[David Herman]

As for Wasm support in Kobweb, it is not planned for a 1.0 release but feel free to share any desired use-cases you have at this representative issue.