I’ve been experimenting with the legacy Moqui UI (the JQuery/Bootstrap 3 version) and have successfully migrated it to a server-driven, Unpoly-first UI using Bootstrap 5.
Aesthetics aside, the UI now behaves like an SPA but with much better performance and a significantly smaller footprint to maintain.
If you’re interested, you can check out the fork here:
GitHub - moqui-automation/moqui-runtime: The default runtime directory for Moqui Framework · GitHub.
As part of this, I’ve also updated the SimpleScreens files for the fullcalendar component and refreshed the main dashboards for MarbleERP and PopCommerce.
Instead of maintaining the JQuery (JSTree, select2, etc.) and Bootstrap components, you could opt for a library of web components like IBM Carbon, SAP Fiori, Microsoft Fluent UI, etc.
Would this development direction be of interest to you for the UI?
Thanks.
Igor
This looks interesting. I’m not familiar with Unpoly, why did you choose this approach instead of using the vue/quasar screens?
I believe Moqui’s screen engine and screen artifacts are, by their very nature, a server-driven UI (SDUI). For an ERP system, I’m convinced the server-side approach is superior. Using Unpoly gives you that SPA feel without the burden of maintaining client-side components and complex JS stacks like Vue or Quasar. Unpoly’s fragment updates are actually faster, the code stays clean, and the maintenance is straightforward—similar to the jQuery/BS3 days (mostly just webroot-layout.css, navbar.html.ftl, and DefaultScreenMacros.html.ftl). I’ve kept jQuery specifically for things like jsTree and Select2, which I find to be a solid compromise. This aligns with jQuery’s recent resurgence; with version 4.0 and growing framework fatigue, it has reclaimed its niche as a lightweight tool for adding reactivity to SSR apps. Alternatively, you could go with web component libraries, but the clean structure of Bootstrap 5 has its own advantages. So far, I haven’t focused on a stylistic overhaul; I’ve simply performed a BS3-to-BS5 translation. Honestly, I doubt the end user will even notice the difference in performance.
Honestly, recently I’ve also started to appreciate simplicity more, so I actually like your proposal. I believe UI client libraries such as Vue would bring the best value if there would be a separate frontend component that interacts with Moqui via REST. For the screen engine I think your approach to keep things simple would be best. Regarding Moqui, I don’t think there needs to be an either/or decision. We could still keep Vue at /vapps and /qapps for who want to use those, and your component at /apps. And I think the /apps could use the upgrade to BS5, I’ll definitely test your repo when I have some time.
And what do you mean the end user won’t notice the difference in performance? Is BS5 slower than BS3? Or /apps slower than /qapps?
I don’t have numerical data to back this up, but my perception is that Unpoly is faster than Vue/Quasar. I’m not seeing any lag at all. We might need to spend some time giving the navbar a more modern look, or maybe find an open-source Bootstrap 5 theme to use. Right now, I’ve just enabled a CSS selector that pulls themes from Bootswatch.