Optmize the framework and the production website speed and remove unused code

[EchoEllet]

Optimize the framework and the production website speed and remove unused code

---

Hi, The Kotlin code compiles to js in the end, but that compiled code is not really optimized

for example, the HTML pages are not minified by default, there is a lot of unused javascript code

Font Awesome by default is outdated and the the dependency loads the whole font, when you use Font Awesome using the npm package manager it will use only the styles you used, and that is applied to a webpack-based project in js or ts

And I don't know if this Kotlin web issue but is there any possibility to fix this as well??

I really hope this framework gets better and better, in the future we might even see it as an alternative to Next js, and thank you for your time

[bitspittle]

Thanks for the report. Taking time to investigate like this shows that you care a lot about it!

How are you generating the JS you're testing? You need to export your site first and then run it with --env prod. That path goes through Compose HTML production compile / webpack DCE steps.

It's true that the font awesome approach is unoptimized, but that was a decision on purpose to balance simplicity of use vs disk size. If we want to use the npm solution, or some other piecemeal solution, users would have to manually specify what fonts they are using across their whole site as far as I can tell, because Compose HTML pages are created dynamically.

It's pretty likely the font awesome script gets cached so it's only downloaded once, and if many sites use it, your computer may already have it. If I recall, the file size is significantly smaller than most images you download these days.

A user can always opt to use npm dependency themselves and write wrappers for what they need and exclude the Silk library if the script file size is truly prohibitive. Also, Silk is even now working on providing kotlin-idiomatoc typesafe SVG element APIs (with a smattering of provided icons) as an alternative to font awesome icons (coming in 0.14.1). So I think that the user has multiple options here.

WDYT? And please let me know if you were already testing prod output in your earlier analysis.

[bitspittle]

PS the final screenshot you shared looks like a Kotlin stdlib thing so I can't do anything about that one I don't think.

[EchoEllet]

Thanks for the report. Taking time to investigate like this shows that you care a lot about it!

How are you generating the JS you're testing? You need to export your site first and then run it with --env prod. That path goes through Compose HTML production compile / webpack DCE steps.

It's true that the font awesome approach is unoptimized, but that was a decision on purpose to balance simplicity of use vs disk size. If we want to use the npm solution, or some other piecemeal solution, users would have to manually specify what fonts they are using across their whole site as far as I can tell, because Compose HTML pages are created dynamically.

It's pretty likely the font awesome script gets cached so it's only downloaded once, and if many sites use it, your computer may already have it. If I recall, the file size is significantly smaller than most images you download these days.

A user can always opt to use npm dependency themselves and write wrappers for what they need and exclude the Silk library if the script file size is truly prohibitive. Also, Silk is even now working on providing kotlin-idiomatoc typesafe SVG element APIs (with a smattering of provided icons) as an alternative to font awesome icons (coming in 0.14.1). So I think that the user has multiple options here.

WDYT? And please let me know if you were already testing prod output in your earlier analysis.

Hi, thank you for your time, I really appreciate that you really care about this framework

I just export the site using

kobweb export --layout static

I don't know what you mean by --env production

Can you explain in more detail?

I hope the documentation gets better as there are a lot of missing things

For example, how to use npm package?? How to register css class from some page

How to register 404 page

Even though I know how to do this as it is similar to next js

And there is more, but it's not on my mind

I also hope The hot reload gets improved, I know Kotlin code needs to be compiled first

But TypeScript also needs to be compiled first, but it has a development npm package that provides a solution to this without compiling everything

Thank you for your time again.

[bitspittle]

Yes the docs will get better. They're minimal for now. (Kobweb has kind of been exploding while I'm working on it.)

You can look at #134 and #133 which are tracking documentation improvements. The best recommendation is to join the Discord for now and ask questions there until we have time to improve the docs.

You can read more about exporting/ running Kobweb sites here:

https://github.com/varabyte/kobweb#exporting-and-running

Or in the README created by kobweb create app

(In your case, after exporting, you'll want to do is something like kobweb run --layout static --env prod)

[EchoEllet]

Yes the docs will get better. They're minimal for now. (Kobweb has kind of been exploding while I'm working on it.)

You can look at #134 and #133 which are tracking documentation improvements. The best recommendation is to join the Discord for now and ask questions there until we have time to improve the docs.

You can read more about exporting/ running Kobweb sites here:

https://github.com/varabyte/kobweb#exporting-and-running

Or in the README created by kobweb create app

(In your case, after exporting, you'll want to do is something like kobweb run --layout static --env prod)

Run it in the production environment

Doesn't change much about the unused imports of js and the huge file of it

I also hope there will be a built-in image component just like next js

[bitspittle]

Hey, I'm closing this issue because I think it's out of scope for Kobweb. I think issues about unused JS and file size issues will need to be handled by the core Compose HTML team.

If you'd like to file a bug about the Image component, please create a separate issue and add more information about what you want specifically, so we can understand the pain point and prioritize the issue. Thanks!

[EchoEllet]

Hey, I'm closing this issue because I think it's out of scope for Kobweb. I think issues about unused JS and file size issues will need to be handled by the core Compose HTML team.

If you'd like to file a bug about the Image component, please create a separate issue and add more information about what you want specifically, so we can understand the pain point and prioritize the issue. Thanks!

Sure, but what about minifing the html pages?? It will save at least 30% space

So we don't have to manually do this

Or create script that automate this

[bitspittle]

So you filed this issue really broadly, which makes it very hard to organize. If you want to convert it into a specific "HTML should be minimized by default" issue, we can do that, but you'll need to convince me it's worth it. I'm willing to listen, but I'll need more evidence to understand your position.

FWIW when I have inspected websites created by other frameworks, I never noticed any of their html being minified. Nextjs doesn't minify HTML by default.

Most HTML gets compressed before it gets sent over the wire, so your estimated savings of 30% is probably a lot less (since compression algorithms are probably pretty good at detecting and shrinking common whitespace patterns for example).

Can you compare the size of a minified HTML file of yours to that of its compressed non-minified version?

And finally, keep in mind that Kobweb is fundamentally a layer built on top of Compose HTML to make it easier to work with. The JetBrains Compose plugin is what has decided dev and prod defaults here (and they, in turn, delegate to Webpack for this). It seems like they have chosen to minify JS and not HTML in prod, and at the moment, that seems like a common and reasonable default decision to me. Happy to read things if you find that would try to convince me otherwise.