[Kimchi-devel] [RFC] Wok widgets as custom HTML elements or UI library

[Aline Manera]

Hi Samuel,

First of all, I could not check all links you shared here. Sorry about 
that. But I rather to get back to you sooner than wait until get more 
time to read all them =)

My only concerned about that is how much gain a Web developer will have 
with this Wok framework/library comparing to Bootstrap or other existing 
technologies.
Wouldn't we attract more people if we use existing technologies on which 
Web developers are already familiar with?
What are the benefits of having our own UI framework/library? Would it 
be simple enough to be an entry point for Web development?

Regards,
Aline Manera

On 06/03/2016 11:00 AM, Samuel Henrique De Oliveira Guimaraes wrote:
>
> 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 
> <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 
> <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
>
>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20160608/f7ae6897/attachment.html>