Then you better fix the big banner on the Node-RED home page... https://nodered.org 
I find vuetify rather amusing :')
360 CSS classes only for the margin prop! (Itās even more, as Vuetify also provides variants for negative margins)
tailwind ftw, amazing framework.
1 Like
Sorry, the difference being?
The difference compared to tailwind is that flexdash needs to load about 1MB "worth" of css classes looking at this example (the "live demo" link on github does not seem to work), with tailwind this would be a fraction, as unused classes will be removed. Not sure if purgecss can work with vuetify, but that could reduce the css quite a bit.
1 Like
Well, it's not quite as bad as you make it:
so the entire CSS for flexdash is 730KB uncompressed and 112KB compressed.
But it's complicated... Vuetify is very good at being treeshakable, i.e., loading only what is needed, and that includes its CSS, except that I go out of my way to disable all that... So if you think it's worse than Tailwind in that respect I don't think that's fair.
Now, why would I disable all the tree shaking? The answer is custom nodes and custom widgets. Take a date picker as an example. If you write a node-red-fd-datepicker node+widget you'd probably want to use the Vuetify VDatePicker component (yes, you may want to use something else, but this is just an example). Well, either VDatePicker is loaded in FlexDash or it isn't. It's not really possible to dynamically add it. Similarly, if you want to use, say, the justify-center class in your node then either its definition is there or it isn't. (Or you drag in another whole copy of the base CSS for every contributed node.)
Right now there are 3 forms of loading/linking new widgets into FlexDash:
- you write a custom widget in the flow editor, that code is compiled to JS+CSS and then it is loaded dynamically into FD, supporting hot-reload when you edit your component
- you write a custom node with widget and run the dev server (Vite), then all of FlexDash including your widget are loaded using the dev server to give you the best debugging and hot-reload capability
- you build your custom node with widget into a bundled release package, this is loaded into the browser together with the bundled FlexDash.
In all these cases references to Vue, Vuetify, and uPlot in your widget need to be properly linked against what's in the bundled FlexDash.
Dunno how much experience you have dynamically loading and linking modules like that, but I would not characterize it as either easy or obvious. I think I have a better grip on some of it now and can simplify some of the stuff FD does, but it's all pretty tricky business regardless.
Coming back to the CSS front, maybe FD should have only the Vuetify CSS it needs and then dynamically loaded widgets should have their own slice of whatever CSS library they need. But given that the compressed CSS is only 112KB that seemed like premature optimization especially given all the stuff still in the air about dynamic loading & linking...
4 Likes
Oh, I completely forgot... A lot of FlexDash's CSS is font stuff. IIRC the material-design-icons all need some CSS to map the icon names to the appropriate glyphs. I believe that's actually the biggest chunk. Again, normally one ends up only with the set of icons used, but if your custom widget wants to use mdi-rocket then it has to be there, so I'm loading all the icons. I'd like to either rebuild the mdi lib to exclude all the outline icon variants or to find a way to dynamically load the CSS for newly used icons. Premature optimization at this stage...
Sorry this goes all completely off topic.
Summary
Note I have not installed/tried flexdash, but I get it, you cannot get rid of classes that are not known to be used yet (dynamic).
how much experience you have dynamically loading and linking modules like that
None, because I dislike any framework that requires whole load of toolchains/buildsteps (or a server for that matter). I want to be able to use a CDN for everything, it gives me flexibility, especially in node-red which I abuse as a webserver with http-in/response/template nodes where I can throw in raw javascript code (sourced from the cdn) and serve them locally.
I use Alpinejs for reactivity and tailwind for JIT also from CDN, depending on the needs/size I run the code through postcss for class purging (for the same reasons as you pointed out). Recently I found vimesh-ui (also cdn) that allows for component based inclusion within alpine.
Continued off-topic...
Off topic
If you ever want to reconsider the load of toolchains/buildsteps stuff give Vite a try: it does a very good job at streamlining things. But yeah, this stuff is one of Javascripts failings...
Funny: I'm allergic to CDNs 'cause I want stuff to keep working when the internet connection fails, which it does....
I have to look at vimesh-ui, haven't heard of it.
I believe I'm going to rip out all editing from FlexDash, that will remove 90% of the uses of Vuetify. I could then keep only the Vuetify components I use, remove the utility classes, and swap in TailwindCSS. Eventually the few Vuetify pieces left could be reimplemented, or not. There's something compelling about this path.
The question this raises though is where would pre-built UI components come from. E.g. say someone wants to build a date picker, or a data table. It mostly doesn't make sense to reinvent those wheels. If they pull it from some random UI toolkit they'll most likely pull in a ton of other junk and run high risk of creating conflicts. Then it probably would have been better to have Vuetify baked in for good&bad...
