I have been in the backend for most of my life. Re...

# compose-web

[Draget]

I have been in the backend for most of my life. Reading about developments in the JS community, the struggles of Frameworks like Angular with following the 'lean trend' with treeshaking and minifying etc. to streamline the compliation and delivery of apps.

As an enduser, I tend towards being one of those yelling old bearded people who immediatly nag around when a website loads a megabye of JS and does display NOTHING without JS enabled. I do appreciate the different developments for SSR (ServerSideRenderig) in the different frameworks.
Recently started playing with Svelte and Snapper that basically gives me a nice, clean static website with mostly just the JS I want, while allowing declative and clean component description and logic.

That all being said, I find it interesting to integrate the web frontends into my whole Kotlin ecosystem using compose-web. How does it compare if I am the kind of person that would like to use static-site-generators for everything? Could I declare components that have zero logic and end up with a lean, small website that is basically static when using compose-web?

[Norbi]

Considering your goals you should choose another technology/stack.
Compose/Web is inherently Javascript-heavy (when deployed).

[Draget]

I see, thanks. 🙂

[darkmoon_uk]

If you want to use Kotlin to build wholly server-rendered web applications, then Ktor + Kotlinx HTML library fits the bill.

[rocketraman]

SSR (note, not SSG) is useful for performance reasons and SEO. It's not about avoiding JS on the front-end, it's about optimizing the page loading experience. I don't see any fundamental reason why SSR couldn't be supported by compose web.

[ESchouten]

BTW, is you're going to use Svelte, don't use Sapper, it's successor is called SvelteKit

[rnett]

@rocketraman I suspect it will be eventually, it's just not a priority at the moment