Hey, my team is looking into Kobweb. I saw that Ko...

# kobweb

[spierce7]

Hey, my team is looking into Kobweb. I saw that Kobweb is has silk, which seems to be applying styles through JS. I was looking to see if maybe it exported a css file, so that it could be optimized, or even just split up into different chunks. This doesn't seem to be the case.

Is there anything I should be worried about here in terms of performance, or application bloat?

[David Herman]

Performance? Not that I've seen. Application bloat? Possibly a concern! Although I'd worry more about the generated JS size from the rest of your code far far more than the CSS.

[David Herman]

Note that what Kobweb is doing is really Compose HTML's approach (with respect to creating styles in the code)

[David Herman]

You can do a static export if you want to see roughly how large the CSS styles are, and use that for an estimate of how much that will affect your final JS output size.

[David Herman]

It's an interesting question that I haven't thought much about (since I believe lots of other frameworks import large stylesheets without really thinking about it), but I'll try to remember to keep an eye on it!

[David Herman]

Feel free to file a feature request to allow exporting css styles into a file / generally optimize styles like removing things you don't use, or I'll do it later today. That said, it will be at least a few months before I can even look into it.

[spierce7]

is it generating a css class per usage?

[David Herman]

There's a global StyleSheet value (lives in Silk) which gets appended to

[spierce7]

so for each usage a new class is created?

[David Herman]

A new class?

[spierce7]

css class

[spierce7]

I assume not

[David Herman]

Every new widget that gets added to Silk will add an entry to the StyleSheet

[spierce7]

I see

[spierce7]

that makes sense

[David Herman]

At the moment, I'm planning on including a core set of useful widgets that many people will want. Later, as widgets get more exotic, they can be added to non-core libraries, so people might only import them if they want

[David Herman]

OK, rough estimate incoming...

$ kobweb create app/empty
... accept all default answers ...
$ cd empty/site
$ kobweb export --layout static

The empty app template is basically a minimal skeleton that just imports dependencies and has a stubbed root index page.

When you do a static layout export, Kobweb takes a snapshot of each page in your app, which we can use to see how large the style section is.

So, I opened empty/site/.kobweb/site/index.html inside IJ and highlighted the <style> sections, and it says that that's 10721 characters. So, roughly 1 byte per character, you can estimate that 11K of the download size is probably attributed to styles.

The full JS output for the empty site, after dead code elimination? 417K. So 2-3% of your JS output is styles.

[David Herman]

I can see that size going up to maybe 15K, or even let's go crazy and say 20K, when Silk's core widget set is "finished"

[David Herman]

Also, as you develop, the size of your site will almost certainly increase far faster than the block taken up by styles.

[spierce7]

yeah

[spierce7]

I'm a bit nervous about that

[spierce7]

our website is very large

[spierce7]

I'm thinking that maybe we'll need to split it up

[spierce7]

so that the js payload isn't so large

[David Herman]

I do have the seed of a plan to allow splitting up Kobweb sites into multiple subdomains

[spierce7]

maybe each feature will be treated as a separate build target on web

[David Herman]

If you're willing to generate pages dynamically, you can also look into dynamic routes, where one page handler can handle a wide range of URL values.

[spierce7]

I have a feeling that with compose web, getting a 10+MB page is pretty easy

[David Herman]

(Compose Web, which is WASM? Or Compose HTML?)

[spierce7]

compose html. sorry

[David Herman]

No worries, it's confusing

[spierce7]

I imagine the same is true on compose web

[David Herman]

I think you'd have to work pretty hard to get to 10+ MB

[David Herman]

but it is worth understanding with Compose HTML approaches that you can't really just download parts of a site

[David Herman]

You get the whole darn thing

[spierce7]

yeah, I get that

[David Herman]

So when you visit https://bitspittle.dev, you are downloading all blog posts even if you never read any of them

[David Herman]

(which I'll definitely want to fix at some point, right now it's OK because I only have 4 posts)

[spierce7]

We've recently done a bunch of research into next.js, astro, vite. We are taking a step back in terms of deployment tech with compose-html. I get that.

But we get the ability to target multiplatform... That's the goal here

[David Herman]

Text is cheap. The whole site + JS is easily eclipsed by a hi-res header photo.

[David Herman]

Yeah, I can appreciate the hesitancy.

[spierce7]

A slightly worse experience on each platform, but a more cohesive experience as a whole, with a much cheaper dev cost.

[spierce7]

It's less about the JS download size. It's more that the JS has to be interpreted and JITed. That makes things slow when you have several MB.

I'm guessing here. I'm not a JS expert.

[David Herman]

Fair enough. I haven't seen anything to be worried about yet, and lighthouse performance reports seem to be fine so far. But not sure what happens to larger projects.

[David Herman]

More like the performance issues I've seen are when you try to do too many fancy animating effects on the screen

[spierce7]

i imagine css animations would still do very well

[David Herman]

Yeah, they're fine

[David Herman]

I mean more like, if you do multiple layers with transparency effects

[David Herman]

Not Kobweb/Compose HTML issues, but pure issues with forcing the CSS engine to do crazy things

[spierce7]

sure