My project now supports exporting your Compose for Web project in a format that allows it to be serv...

# compose-web

[David Herman]

My project now supports exporting your Compose for Web project in a format that allows it to be served by static website hosting providers. If this is something you might be excited about, you can read more here: https://bitspittle.dev/blog/2022/staticdeploy

[hfhbd]

Sounds interesting, so you split the compose code into different single html files?

[David Herman]

Yes

[David Herman]

You pull the page down, it renders immediately, then the JavaScript gets downloaded and runs your Compose for Web code, which essentially replaces the DOM with itself.

[Robert Jaros]

Does it work somehow with dynamic routes?

[David Herman]

It does not, at the moment. Dynamic routes are excluded from exports: https://github.com/varabyte/kobweb/blob/68a0938cf401143cf3b99b9177792d3801350a98/g[…]om/varabyte/kobweb/gradle/application/tasks/KobwebExportTask.kt

[David Herman]

You can still use query parameters though

[AJ Alt]

I'm a little confused by this. I've been serving static GitHub Pages built with compose web for a while. The build artifact is a single js file, so static hosting works fine. What problem is this solving?

[David Herman]

How many pages do you have in your site?

[AJ Alt]

Multiple.

[David Herman]

So let's say you have page "a", "b", and "c" or whatever

[David Herman]

What happens if you type <https://io.whatever.github/github-project-pages/path/to/a> ?

[AJ Alt]

It loads that page, which has a js script tag that loads the js? Same as any html page?

[David Herman]

If you don't have something like "docs/path/to/a.html" in GHP, you get a 404, don't you?

[AJ Alt]

I don't. Here's an example: https://ajalt.github.io/colormath/converter/

[AJ Alt]

That's written with compose-web

[David Herman]

Thanks! Let me look at the project

[David Herman]

I'm probably looking in the wrong place? https://github.com/ajalt/colormath/tree/master/docs

[AJ Alt]

https://github.com/ajalt/colormath/tree/master/website/gradient

[David Herman]

So what happens when you compile that?

[David Herman]

(I hope I'm not coming across snide or defensive, I'm genuinely curious and asking questions here)

[AJ Alt]

I get a js file which I copy to /gradient.js, which is loaded from the html:
https://github.com/ajalt/colormath/blob/master/website/gradient/src/jsMain/resources/index.html

[hfhbd]

I understand: kobweb goal is to increase performance by storing the initial compose rendered page in a static html and reload changes dynamically with compose web after loading the (big) js file.
Currently, if you create different pages with an empty index file, the compose js file needs to be downloaded at start, which results into an empty page until js file is loaded.
correct me if I am wrong 😄

[David Herman]

That's definitely an advantage! But I was under the impression that a single "index.html" + "js" file was not compatible with most static website hosting services

[rocketraman]

@David Herman I think @AJ Alt has created index.htmls for each route on his site. See: https://github.com/ajalt/colormath/tree/gh-pages. For example, https://github.com/ajalt/colormath/tree/gh-pages/gradient.

@AJ Alt Correct me if I'm wrong but all the navigation and menus and stuff on your docs site are already static. Its just the applications that are compose-based and embedded.

[Robert Jaros]

Generally you need a configuration which redirects 404 to the same index.html. Most services can do that, because typical react apps need this as well.

[hfhbd]

It depends on the router: HashRouter supports SPA on static website hosting service via <http://foo.com/#/a|foo.com/#/a>. Otherwise, you need to configure the service to redirect 404 to the index file and use a BrowserRouter

[David Herman]

Ah, if you can configure a redirect that would work

[Robert Jaros]

Your idea is basically a pre-rendering for kotlin/js (https://create-react-app.dev/docs/pre-rendering-into-static-html-files/).

[David Herman]

But yeah, I'm still coming up to speed but if what @rocketraman is saying is correct, you had to do extra work to generate that layout

[David Herman]

Yeah, I'm pre-rendering

[David Herman]

Note that Kobweb doesn't exist to export static sites, that's not why I wrote it

[David Herman]

but quite a few people who tried it out wanted to then export it to a static site host, which is the feature I added here

[Robert Jaros]

It's made really nice and I want to try copy this this for my KVision (sorry 😉)

[David Herman]

I saw Google Cloud Storage had the ability to reroute 404s to any html file but I didn't see that on GitHub Pages or Netlify when I looked (although I could have missed it)

[David Herman]

@Robert Jaros ✌️ It's open source, good luck my friend!

[hfhbd]

Nope, GHP does not support any kind of configuration, but (again), you could use a HashRouter as alternative.

[Robert Jaros]

For github pages it is a long story: https://github.com/isaacs/github/issues/408

[David Herman]

@hfhbd I might be missing something but even with a hashrouter, if someone opens up say an incognito window and visits a subpage, you'll get a 404?

[David Herman]

Whereas Kobweb will actually generate the site with all files in their expected places

[rocketraman]

No because the hash part of the URL is ignored by the server when serving up resources.

[hfhbd]

Nope, https://routing.softwork.app/#/users/2?name=paul

[Robert Jaros]

hash routing always opens index.html, it's not processed by the server

[David Herman]

It's also possible, although I'm not 100% certain, that this will allow better SEO support, in case there are crawlers that run over text and don't run the javascript file.

[rocketraman]

@David Herman My use case is a bit different than the static non-hash URL routing problem. A user creates an "entity" in my application.

Normally this entity is rendered via Compose/Web, but dynamically I'd also like to create a static version of that for SEO reasons: something that loads extremely quickly and is easy to index by search engines. These SEO-friendly pages would essentially be entry-points to the main application. Is doing something like that possible? Can I use Kobweb via an API to generate these static pages?

[David Herman]

Is compile time OK?

[David Herman]

Will you know before you deploy?

[rocketraman]

Not really because these entities are created at runtime. I can always use Kotlin scripting or something to trigger the compiler at runtime though.

[David Herman]

At the moment then I'm not sure, I don't think so

[David Herman]

That sounds like server side rendering though? Except where you save the file on the server after you serve it?

[rocketraman]

It is server-side rendering, yes. Which compose/web doesn't really support. I know JW has done something in that area, but I recall him saying it wasn't easy and AFAIK he hasn't shared it.

[rocketraman]

So I was looking for work-arounds short of trying to implement it myself :-)

[David Herman]

By the way the chat flew by really quickly before so I didn't get to say thanks for explaining the idea of hash URLs

[David Herman]

although I do like URLs that look clean, whether that's a benefit or not may be a stylistic thing though

[rocketraman]

Its the "original" way of routing for SPAs, before people figured out how to make the URLs clean. I agree, I prefer them clean as well.

[David Herman]

@rocketraman I'm going to ping you later (I have to run in a bit), would love to chat about your usecase 1:1

[MrPowerGamerBR]

Kinda offtopic but still related to rendering HTML: I wonder how hard would it be to run the application JS file with GraalJS, letting it render the page for you instead of spinning up an entire web browser. This would be useful for SSR that has dynamic content.

I once played with this idea before, and while it could be possible, you would need to polyfill a lot of browser stuff (like the DOM).

On my personal project what I ended up doing was checking if the browser User-Agent is a Crawler bot and, if it is, load the page using Playwright and output the rendered page to the Crawler. It works, but it is veeery slow compared to just not doing that and you use way more resources.

[rocketraman]

I've been looking at Playwright as well. It'll probably work for my use case if I cache its output. AIUI Google heavily penalizes pages that crawl slowly, so you're probably better off letting their JavaScript crawler index your page then having a slow response to their normal crawler.