Hi team,
After the open
discussion session on our last scrum meeting regarding Wok
as an UI framework / library, I decided to list some
alternatives and technologies that we could use on the next
releases or Wok 3.*.
The idea is to provide a
solution that allowed developers to create panels, tabs or
even full plugins with minimal or no knowledge on HTML and
CSS or even DOM manipulation with jQuery.
Instead of using default
HTML tags, the developer could write something like this for
Kimchi network tab for example:
<wok-panel
collapse="false" title="Networks">
<wok-datatable
filter="network.name, network.interfaces, network.address,
network.type" model="kimchi.networks" sort="true"
sort-by="network.name" actions="network.actions">
</wok-panel>
<wok-window
model="network.add">
...
// Network modal
window contents
...
</wok-window>
<wok-window
model="network.edit">
...
// Network modal
window contents
...
</wok-window>
This might seem too
ahead of time but in fact it looks like any current MVV
JavaScript framework. So here are the current alternatives
with pros and cons:
1 – Custom elements API:
https://developer.mozilla.org/en-US/docs/Web/Web_Components/Custom_Elements
Current support:
http://caniuse.com/#search=custom-elements
Status: Draft
Effort: minimal
In my opinion based on
current structure this would be the least difficult
alternative to adapt current code into a library but browser
support is an obstacle.
2 – Google Polymer
https://www.polymer-project.org/1.0/docs/devguide/feature-overview
Current support: https://www.polymer-project.org/1.0/docs/browsers
Status: Stable
Effort: medium
To work like the example
above it would require some time to develop and I think it
would create something bigger than an UI library, check an
example source code and you will see what I mean. For some
native components such as form controls it would redundant.
It could be developed at the same time we maintain the
current code.
3 – AngularJS
https://angularjs.org/
Current support:
https://docs.angularjs.org/guide/ie
Status: 1.5.x Stable,
2.0 in development
Effort: medium to high
This would definitively
work like the example above and make Wok and all its plugins
work like a seamless single page application (no more
problems with global variables / tasks when switching tabs
from different plugins) but the effort would be medium to
high. Legacy code would be incompatible, we would have to
drop or move almost everything that we have done with jQuery
and rewrite ALL tabs, widgets and API calls and all
libraries that we currently use would have to be updated to
an AngularJS-like compatible version (or some could go away
as Angular provides native mechanisms that we could use).
The advantage here is that there’s a library that uses
Bootstrap SCSS so our UI assets wouldn’t discarded and the
users wouldn’t notice anything. The negative factor is that
we would have to rewrite our code to meet “AngularJS way”:
creating services or factories for the REST calls,
directives for the UI and the logic would go to the
controllers. It wouldn’t make the developers lives any
easier, in fact it would require a narrow and specific
skillset. For example: to make Wok load plugins, we would
have to write a mechanism to lazy load our plugins
dynamically based on the files installed in the plugins
folder.
We could also benefit
from some NodeJS plugins for unit, performance and UI tests,
even mock objects when developing new UI when we don’t have
the exact system environment, not having to worry about
messing with host or VM settings.
3 – Facebook React
https://facebook.github.io/react/
Current support: https://facebook.github.io/react/docs/working-with-the-browser.html
Status: Stable
Effort: maximum
We would exchange HTML
to JSX and JavaScript. I think based on our project
structure it brings the worst points from Google Polymer and
AngularJS analysis.
Regards,
Samuel