[ovirt-devel] Tools for developing and building oVirt.js project

Tue Aug 26 11:58:15 UTC 2014

----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: "Mooli Tayer" <mtayer at redhat.com>
> Cc: devel at ovirt.org
> Sent: Tuesday, August 26, 2014 9:38:31 AM
> Subject: Re: [ovirt-devel] Tools for developing and building oVirt.js project
> 
> 
> 
> ----- Original Message -----
> > From: "Mooli Tayer" <mtayer at redhat.com>
> > To: "Greg Sheremeta" <gshereme at redhat.com>
> > Cc: devel at ovirt.org
> > Sent: Tuesday, August 26, 2014 9:17:20 AM
> > Subject: Re: [ovirt-devel] Tools for developing and building oVirt.js
> > project
> > 
> > Are we talking about using node as a development/test/packaging(minify etc
> > )
> > tool or having a runtime backend (site) on top of node?

As Tomas wrote below, Node.js only for devel/test/build process.

> 
> It is only devel environment (e.g. build dependency), not runtime.
> 
> I'd just like to point out that one thing is the development of the ovirt.js
> itself
> which is not going to be a big project and I can imagine also using less
> ideal (slower) tools for it's development.

That is true, however I'm trying to see things from higher perspective.

If/when we decide to modularize UI, having JavaScript as the lowest common
language to implement individual frontend modules, we might come to a point
when we'd like to implement some modules in JavaScript directly, rather than
in GWT. (For example, "base WebAdmin UI layout" module in AngularJS together
with PatternFly/Bootstrap.)

With modular UI, "need to know Java/GWT" barrier would be relaxed, developers
could implement new modules in anything that becomes JavaScript, GWT included.
Both core and community / 3rd party modules would share same module infra
(unlike today's UI plugins, which are not used for core frontend code).

UI modules would also give us a choice of technology for different parts of UI,
so we wouldn't have to implement all UI in GWT - parts could be implemented in
AngularJS, for example. This sounds a bit like polyglot approach for frontend
development.

The main idea is to break down build/devel-time GWT monolith, define logical
reusable modules communicating via clear API/interface, essentially reducing
code complexity [1], avoiding big GWT compile times and gigantic resource
consumption during big GWT compilation (basically any consequence that comes
from compiling big monolithic GWT application).

[1] feature implemented as separate module should be less complex
    than feature implemented within big monolithic codebase, less
    complexity also means better testability

> 
> A completely different story will be when (if) we decide to use ovirt.js to
> develop some parts of the webadmin/userportal
> in javascript instead of GWT (or even rewrite the whole FE to JS) which will
> be a big project (set of projects).

The initial idea with modularized UI is to break today's GWT codebase into
logical modules, I'll talk more about this tomorrow in "modular UI" session.

> 
> If we want to be effective in that effort, we will need good tools.

Exactly! We need good tools for JavaScript development, assuming we want to
utilize JavaScript as lowest common technology for frontend development in
the long term. This was my motivation when proposing Node.js, to me anything
other than Node.js (given its popularity and widespread) seems sub-optimal
for JavaScript development.

> 
> > 
> > From my perspective I can't stress enough how important is the separation
> > of ovirt UI part from the backend. I agree to everything Vojtech said about
> > developing to the browser with java.

Yes, separation of frontend vs. backend is very important, it should be done
by moving UI to work with REST API, which is the public interface to Engine.

UI modularization is idea for the long term, but still, in my opinion, very
important one.

> > 
> > Mooli.
> > 
> > ----- Original Message -----
> > > ----- Original Message -----
> > > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > > To: devel at ovirt.org
> > > > Sent: Monday, August 25, 2014 11:13:38 AM
> > > > Subject: [ovirt-devel] Tools for developing and building oVirt.js
> > > > project
> > > > 
> > > > Hi guys,
> > > > 
> > > > last week, we had "oVirt.js PoC" session and I mentioned the
> > > > possibility
> > > > of using Node.js and related tools like npm to develop & build oVirt.js
> > > > project.
> > > > 
> > > > I'd like to hear your opinion - what do you think about using Node.js
> > > > in
> > > > context of developing & building JavaScript projects? (oVirt.js etc.)
> > > > 
> > > > Obviously, I'm strongly biased towards Node.js because of its
> > > > popularity
> > > > and therefore availability of various tools (npm packages) for
> > > > JavaScript,
> > > > for example: grunt (task runner), jslint/hint (code analyzer), uglifyjs
> > > > (minify/compress), karma (both one-time & continuous test runner),
> > > > traceur
> > > > (es6 -> es5 compiler), etc.
> > > > 
> > > > My understanding is that any special-purpose JavaScript development
> > > > tool
> > > > is typically implemented as module for Node.js (due to its popularity),
> > > > so I think it makes sense to use Node.js as a platform for JavaScript
> > > > development.
> > > > 
> > > > There are also Java-based projects for JavaScript (post)processing like
> > > > wro4j, however these tend to be implemented by invoking JS tools (like
> > > > uglifyjs) from Java context via Rhino (JS engine for Java), for
> > > > example:
> > > > 
> > > >   https://code.google.com/p/wro4j/source/browse/wro4j-extensions/src/main/java/ro/isdc/wro/extensions/processor/support/uglify/UglifyJs.java
> > > > 
> > > > (To me, developing JavaScript project with Java-centric tooling sounds
> > > > quite strange in general.)
> > > > 
> > > > There's also webjars repository for hosting popular web resources for
> > > > use in Java applications (i.e. Maven artifact for uglifyjs etc.), but
> > > > this is just for easier dependency management from Java perspective
> > > > (JAR file as a distribution format for web resources):
> > > > 
> > > >   http://www.webjars.org/
> > > > 
> > > > Overall, I'm in favor of using Node.js to manage all tasks related to
> > > > JavaScript development and build process. If you have any objections
> > > > or suggestions, I'd like to hear them!
> > > > 
> > > > (I understand that Node.js essentially means new dependency with all
> > > > implications, but in this case, I think it's worth it. But this is
> > > > just me, so please share your opinions.)
> > > > 
> > > > Thanks,
> > > > Vojtech
> > > 
> > > I think most developers would agree that node.js is the tool of choice
> > > for
> > > JavaScript development.

If there are any other viable alternatives, I'd really love to hear them.

> > > 
> > > The thing we must carefully consider is that node.js uses its own package
> > > manager (npm -- much like maven), and unlike maven, tooling does not yet
> > > exist to deal with npm packages in an rpm environment.

Exactly, this is a big issue, we'd need to solve this.

npm doesn't support the concept of private/local repository like Maven does.
npm resolves Node.js packages via HTTP access. Some repository managers like
Artifactory [2] (typically used as proxy/caching Maven repos) already support
serving Node.js packages -> can be used as npm "private/local" repository.

[2] http://www.jfrog.com/open-source/

> > > 
> > > This isn't on the same level as adding a logging library or a collections
> > > library or something. I'd argue that dependencies don't get any heavier
> > > than this one. That is worrisome to me.

We already have CI infra to deal with Java dependencies (JARs etc.) so we
would need to come up with similar infra to deal with npm dependencies.

> > > 
> > > Run 'yum list available |grep nodejs' on your machine to see which
> > > node.js
> > > packages are available. Note that I don't see karma or uglify available
> > > in
> > > either Fedora or Red Hat SCL (Software Collections) [1].
> > > 
> > > [1]
> > > https://sochotni.fedorapeople.org/nodejs010-RHSCL-1-RHEL-6/Server/x86_64/os/Packages/

Correct, I didn't see those as well on my machine via yum search.

For uglify we could use some alternative. For karma, this can be considered
as devel/test-time dependency and therefore we wouldn't even need rpm for it.

> > > 
> > > Greg
> > > _______________________________________________
> > > Devel mailing list
> > > Devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/devel
> > > 
> > _______________________________________________
> > Devel mailing list
> > Devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> > 
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 