Since 1.4 (released in september 2014), we have used Dojo Toolkit with its Claro theme for a professional (business) look-and-feel as well as providing users with more direct feedback on their actions (such as checking that required fields are correctly provided). Even today, we're using Dojo 1.16 to support our 1.8 development.
Although Dojo is serving us well, the world has moved on. Even the Dojo developers have moved to developing Dojo 2 - a toolkit which is technically completely incompatible with Dojo 1, although it is built on the same philosophy of what's required for professional-looking web applications.
For quite some time, it has been apparent that we need to switch to something other than Dojo 1, even if it is only because Dojo 1 drags lots of cruft with it. Switching to Dojo 2 is - due to its incompatible nature with Dojo 1 - a similar effort as switching to something completely different. For that reason, I have been evaluating a number of options, along the following list of requirements:
1. Separate framework, loader and widget library
With Dojo 1, Dojo and its Dijit library are all of the above. They are also very tightly integrated.
2. Support our Dijit widgets and declarative code
There is too much dijit-html in our code base to make a step to a different widget library at
this point: especially in 'old code' html is still being composed "inline", which means that we're
not ready to make templates for all our code yet - an assumption that most current
frameworks seem to depend on
3. Support our desire to create new code using a service-based SPA approach
In order to move forward, we are implementing services for our 1.8 rewrites. This means
we're investing in new technology and we should want to take advantage of the full
capabilities of the new framework we will be selecting.
In addition, I'd like to stick to developing our UI through some kind of templating as we have been doing so far using Dojo's declarative syntax -- Dojo also supports a programmatic syntax, but we have explicitly not gone there.
Over time, I have been looking at the following frameworks to replace our Dojo 1 setup:
* Dojo 2
And skimmed over a lot of others.
Going over the alternatives, I started with Dojo 2 -- this is several years ago, when Dojo 2 wasn't final yet. Back then, the developers were using a "build the application in code" (instead of templates) approach. When asked about it, they declared that templating can be bolted on, but it's not a concern of theirs.
I looked at Vue several times over the past years. Its templating system is relatively quickly understood. The first few times I went out to find widget libraries to go with it, however, each time I found that we still need to support Dijit widgets too -- and I'd hate to have mixed looks for newer and older code where older code would use Dijit widgets while new code would use Vuetify or similar.
Last week, based on recommendations from John, I looked at Svelte. It looks extremely appealing as it doesn't prefer one widget library over another and has as its focus to send as little code over the wire to the client as possible. It achieves that by precompiling templates into optimized/targetted JS functions. Remained the question on how to use our Dijits with it.
This morning, I decided to a proof-of-concept with one of these libraries. As I found instructions for Vue on how to create its renowned 2-way data bindings for non-native components, that's where I decided to start. Over the course of a single day, I was able to:
* Load Vue and Dojo into the same page (without conflicting, ready to be used)
* Create a Vue app out of the login page (no functionality yet)
* Tie a Vue action to the login form submission (which required it to stop being a Dojo widget)
* Create 2 Vue components encapsulating Dijit widgets to deal with 3 types of UI elements:
2. TextBox (for text and password)
* Find out how to propagate the content of the Vue button component to the Dijit Button widget
to be used as the button caption
* Set up two-way data binding between the Dijit TextBox widget and the Vue textbox component
... and it's only 4pm right now! :-)
Based on the experience above, I'm now quite happy with Vue as our main option to take the next step into expanding our SPA. In order to determine the right way forward for the application as a whole, though, further experimenting will be required: something as "simple" as our login page obviously is no match for the logged-in application which has a menu, error popup and main application section, each with its requirements to support this mixed setup.
Robust and Flexible. No vendor lock-in.