Making `index.html.gz` smaller

Software
1

Finally got back to poking around some of the code (focussing on front end, i.e. the index.html.gz) and wondering how to reduce its size.

It’s built using gulp which is waaaaaaaaaaaaaaaaaay past its ‘use-by-date’, but changing that is something to talk about with the Fluid-NC team.

It still sorta supports IE, so we could rip out that little bit of code and save a few bytes.

But it also supports lots of languages - all at once.

Here’s the supported language codes - note that this is Fluid NC’s list, I think Maslow’s bit of the code is just English? (can someone else correct me here)
en, fr, es, de, it, ja, hu, pl, ptbr, ru, tr, uk, zh_cn
There’s also 3 special language codes:
fl gets you ‘fluid_nc’ language, whatever that is
grbl gets you all of the above languages, excluding ja and zh_cn
No language code (what build.bat does) or the code all gets you all languages

However, there’s an alternate build command buildLanguagePacks.bat, which builds each language on its own. This seems way more convenient, although there was some weird behaviour for me where it deleted each file after making it. Using source control in VSCode though I just restored all of them.
Special language codes:
‘multi’ (AKA ‘all’) 157KB
‘grbl’ (no ‘ja’ or ‘zh_cn’) 114KB
Individual language codes:
‘ru’, ‘uk’, ‘zh_cn’ 114KB
‘hu’, ‘pl’, ‘ptbr’, ‘tr’ 113KB
‘it’ 111KB
‘de’, ‘es’ 110KB
‘en’, ‘fr’, ‘jp’ 107KB

I reckon running that buildLanguagePacks.bat (maybe restoring everything it deletes as it goes …) and then through all of the languages folder into the releases and say, ‘pick your language’ might be a good start.

3 Likes
2

how much space does that save us?

David Lang

3

@dlang 157KB - 114KB = 43KB of compressed file size saved at least

Uncompressed (i.e. in use on the machine) the ‘multi’ version is 776KB,
whereas ‘en’ (for example) is 559KB and ‘grbl’ is 584KB

The best compromise is probably to use the ‘grbl’ version as the ‘multi’, and have separate versions for ‘ja’ and ‘zh_cn’

1 Like
4

I agree that gulp would never be my choice today for a build tool. I’d probably use vite.

gulp package -en is how I build the index.html.gz with just english. I also changed this in our fork/branch to put index.html.gz in dist, so I don’t think the bat file would work anyway unless we were to change it to copy index.html.gz from dist (I didn’t see that when I made that change). We don’t have any multi-language support in the maslow UI, so this does save a few bytes. We could remove support for old things like IE, sure. I think too some more modern tools like esbuild rollup, webpack would probably outperform gulp’s code in terms of size

If you have python (And who doesn’t these days :slight_smile: ) you can use this to build and serve on localhost any changes without installing index.html.gz:

gulp package -en && python fluidnc-web-sim.py maslow.local - (well, whatever the windows command line equivalent is of &&) and this will launch on a localhost and proxy calls/websocket to your maslow (you can also use the IP instead of maslow.local)

Also, I know from your logo that you are on windows and prefer it, but “bat” files are not useful to those of us on linux or mac, so if you do script anything I’d really prefer python or bash, both of which run on all the major OSs. Heck .bat is well past its use by date even on windows :slight_smile:

4 Likes
5

Another thought I’ve had is to develop a standalone UI that just has the maslow stuff (with replacements for the few fluid things we still need/use in it and maybe uses a bit more modern stack, at least typescript and vite to build an index.html.gz that is leaner and a single maslow unified UI. Just “shower thoughts”, have not tried to do such a thing yet. I imagine it would take more time than I’m probably willing to give… but with me you never know :joy:

3 Likes
6

Compared to gulp, yes they are more modern, but still both past their respective use-by-dates. But I’d go all-in on bun, it lets you throw all of that away. One year ago I would have said that ‘bun’ was not ready, it is now, although it is still a work in progress.

If you have ‘bun’ you can also do this, and you don’t have to faff around with python versions and venvs.

Ooooh, so true. It’s just mummified remains now.

Or powershell, it absolutely runs on everything, although it’s power does tend to scare the :poop: out of me. Next thing you’re going to tell me is that all of this should be in a Jupyter notebook.

But yeah - I prefer developing on Linux

1 Like
7

Sure, but I’m saying in the current codebase, if you want to do a BIT better dev experience, the python proxy is “ok”… I’d prefer live reload and all the goodies I have in a better codebase, but yea, this at least makes it not fully painful to test changes. The alternative with the current code is to upload the index.html.gz.

:nauseated_face: sure, but please no :slight_smile: - seriously though that would work for me as long as I don’t have to touch it :joy:

Same, although my office computer is a mac mini, and I love/hate it, but I don’t do much development on it. The dang cmd key drives me nuts. Most of my dev envs are remote linux boxes I remote into.

2 Likes