Alternate UI framework than Quasar, for speed and for beauty

[evnchn]

It all started, when I complained that the Quasar library had too much unused code. Short of code-splitting (not doable due to how Quasar was coded) or tree-shaking (not doable since NiceGUI does not use any webpack or rollup or esbuild or whatever), I was thinking of swapping out the UI framework altogether.

So, here are some lightweight Vue UI frameworks:

• Vue-material: 75.1KB gzip, 404KB raw
• Vant: 82.0KB gzip, 251KB raw
• Oruga-ui: 67.5KB gzip. 283KB raw
• Buefy: 74.5KB transferred, 330KB raw

But then, I realized that some of these UI frameworks may look worse than Quasar due to their lightweight nature. Then I further realized that Quasar isn't hot either. So, here are some Vue UI frameworks which looks more beautiful (at least as a default)

Screenshots taken with best effort to find a page which represents how the UI framework typically looks, if used by a (possibly noob) user who didn't try their best to style it*

• PrimeVue** (369KB gzip, 1.8MB raw, quite large IMO)

• Nuxt UI (No CDN build???)

• Vuestic (117KB gzip, 437KB raw)

• Vuetify (185KB gzip, 892KB raw)

*A typical Quasar website never looks as good as the Quasar documentation, IMO!

** Memorable since someone commented PrimeVue beneath a thread complaining how Quasar doesn't look good

Now, for these to work, we need:

• Those UI frameworks support being used in CDN / UMD / ESM mode
  • Is Nuxt UI out-of-the-question? I guess they would be disinterested towards a soluton that doesn't feed Nuxt, a full-stack framework...
• Someone to write compatibility layer for NiceGUI
  • Possibly, ui.buefy_button assuming developing for Buefy, same goes for other UI framework
  • Or, if done outside of NiceGUI, then buefy_ui.button

What do you think? Is this a good idea, or am I setting myself up for failure? Does anyone actually want this? Beyond nitpicking, is anyone actually unsatisfied with Quasar's look (it is pretty good already, if not a bit dated from the Material Design) / performance (it is pretty lightweight already, 159KB transferred, 514KB raw)

I have many questions, and I need your answers. Let's chat!

Note: On previous discussions:

#4056: discussion on potential deficiencies of Quasar, and how other frameworks don't suffer from it
#3818: was about this topic, but it was not quite done and was silent for 4 monthes, and I felt this topic needed a re-kickstart as well as a proper assessment, as any other feature deserves. Also you know very well I am terminally online, so if anything I'll get to doing it. Mentioning @alegue87 as a result.

Please 🚀 if you think this needs to be done, thanks!

[me21]

Regarding code style: you offer ui.buefy_button or buefy_ui.button. I would prefer

ui.set_framework(BUEFY)
...
ui.button

to ease framework switching if possible.

[evnchn]

Sorry for missing the message because I was in the middle of finishing the PR #4859

I think that, once we get sorted the frameworks and their compatibility with NiceGUI, implementing ui.set_framework(BUEFY) would be trivial. It would be a call to app.configure_vue_ui_framework, and setting some flag somewhere within the NiceGUI codebase to inform all elements to switch over to the tag name of the UI framework in use (aka q-btn -> el-button)

But yeah, API design is something we have to focus on, but probably not for #4859 to go through.

Note that any attempt to "change the functionality of NiceGUI elements to use another UI framework" may come with interesting edge cases such as:

• That the element not supported / doesn't behave the same from Quasar to another UI framework
• That there would be difficulty in adding some elements which exists in the other UI framework but not Quasar
• Any code which attempts to further configure the Quasar element using .props will totally break under the new UI framework

So I am not sure on that one. But we can kickstart the API design earlier because I can foresee it being quite a big argument (expecting 100+ messages back-and-forth)

[kleynjan]

Evan, I for one am guilty of stoking the enthousiasm for this while not being able to contribute anything meaningful. That said, I would still very much like to be able to use NiceGUI with non-Quasar options:

1. Quasar does look dated on the outside (although I hated Material to begin with).
2. I don't know about the alternatives, but the html/css produced by Quasar isn't exactly a beauty either. Tired of navigating this nested q- div stuff (lack of integration with Quasar SCSS sources doesn't help).
3. Other frameworks seem to have caught up and exceeded Quasar in functionality: available controls, styling.

But: I think it's a hell of a job to get this right. First step would be to separate out Quasar from the NiceGUI framework proper...

PS: For my type of (corporate / line-of-business) application, functionality, "looks" and performance (after initial load) are more important than "weight" in terms of size and load time. My preference for a framework would follow those priorities.

[evnchn]

You are not guilty for stoking up the enthusiasm, regardless of the contribution. Showing desire towards a feature, even without ability or time to develop it, still points the team and its (arguably limited) manpower towards the right direction - features in desire and in need.

First step would be to separate out Quasar from the NiceGUI framework proper...

I am doing this RIGHT NOW

Spoiler:

app.configure_vue_ui_framework('''
app.use(Vuetify.createVuetify());
''')

[evnchn]

@kleynjan Your stoking of my enthusiasm lead to #4859

[falkoschindler]

With PR #4859 being released in version 2.21.0, I'm closing this feature request as resolved.

[pycaw]

Not just for speed and beauty but to manage dependency risk as Quasar has 550 open issues and a single maintainer for all that.
Reassuring to see work is already started to support other frameworks.