Hi. I've been continuing with the HDA-style approach using Quarkus (with Renarde), Quinoa and Htmx. My initial opinion is that Quinoa is quite SPA-centered and very hard to use for MPA or HDA apps.
This is going to be quite long, so here's a TL;DR: Quinoa could use an option for specifing requests that's it's allowed to redirect or the ignoring option could be regexp-based, otherwise it's unusable for developing MPA/HDA-style apps.
Long version:
After resolving the CSS purge issue with templates being outside Quinoas graps (#61) by a workaround (disable purge in dev mode), I've been hitting other road blocks, but let's get the context straight first.
When creating an MPA (classic multipage application) or an HDA (hypermedia-driven application, specifically with Htmx returning ready parts of the HTML), one often uses a configuration where back-end code handles templates (Qute in this case) and also has an additional side-pipeline for handling assets (JS, CSS, images, fonts, etc.) which is Node-based - mostly the aftermath of SPAs going mainstream and focusing all of the attention. This pipeline is almost always on this - a asset processing pipeline, not a fully-fledged UI app.
It's not really that exotic: Laravel has a whole module just for that (Mix), likewise Symfony (Encore). Quinoa on the other hand is mostly SPA-focused which bascially makes it imposible for using with a asset processing pipeline. My experiences with this so far were:
- CSS purging problems due to templates being outside of the UI folder (#61 - worked around);
- unable to utilize the Quinoas dev server, due to the fact of lacking a fine-grained configuration - this is a longer issue, which I'm going to go into detail below;
- without the dev server, one is stuck with Quinoa running
npm build
all the time, which while being errorless, is very slow (imagine fine-tuning your UI code/CSS/whatever with small, rapid changes and being forced to wait a few seconds on every refresh - unusable in the long run).
Now, let's look at the dev server. It's a nice solution for an app that has all web resources (HTML, JS, CSS, other) on Quinoas side. Just redirect the requests to the UI dev server, ignore the REST API ones and done. This. This is very SPA-centric. It's basically unusable for a MPA-style development (hence HDA-style also, which is very similar, yet results in a hybrid SPA/MPA-like app).
A two problems here:
- Dev server requires, well, a UI dev server on the other side. For MPA/HDA it might not be the case. The whole process can be a simple pipeline for processing assets with a watcher triggering the build on change and outputing the resources in a target location. Quinoa goes either the "copy resources path" or "redirect requests path". Nothing in between, like: "watch the target dir and copy resources on change, because there's a second build pipeline building those assets".
- After working the first problem around by actually providing a simple web server for Quinoa to redirect to, there comes the second problem: no fine-grained request control. When the UI server is provided, Quinoa redirects the root request ("/") to the UI server. Not what one wants for the MPA/HDA, where the templates (and the root request) are being processed by the back-end. Of course there is an option for ignoring requests based on prefix, but try to use the root request ("/") here - you disable redirecting altogether. A simple regexp-based approach would solve the problem here. Either that or to provide options not only for ignoring requests, but for allowing also (e.g. allow prefixes like
/images
, /css
, /fonts
- for MPAs/HDAa you'll probably have only a few of those).
The above forces us to use the npm build
style, which with constant full rebuilds (Webpack already takes around 4-5s at this point, and we're getting started), makes us thinking of dropping Quinoa in favor of hand-feeding src/main/resources/META-INF/resources
by Webpack (which requires hand-crafted Gradle, Git and Webpack config and launching two dev mode tools separately). Resolving the second problem (by regexp or additional "allow requests" option) would make Quinoa fit for making MPA/HDA apps with only a bit of additional configuration.