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
frameworks seem to depend on
3. *Support our desire to create new code using a service-based SPA
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
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.
When I looked at React, it looked overwhelming, is/was using inline
much felt like our old code, but in JS instead of in Perl.
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
* 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
... and it's only 4pm right now! :-)
I've committed my code to
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.
-- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.