9 a.m.
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