InfoQ caught up with Ubidreams founder Romain Pellerin for a deeper analysis of the platform.
INFOQ: Why would I use Nanoko instead of ember.js or angular.js for large client side applications?
Nanoko is not a MVC or MVVM framework. Unlike angular or ember, [Nanoko] proposes a build process ensuring the reproducibility of the build. It also integrates testing, aggregation, minification, and a bunch of web languages such as Less and CoffeeScript. Nanoko also proposes a framework to build and run modular applications. the main outcome of Nanoko comes from this combination: an industrial build process, and a modular runtime.
Nanoko does not focus on an UI-centric architecture style, but embraces service-orientation making the development more flexible, and the integration really easy.
INFOQ: Is Nanoko used in any production apps currently? If so, what examples are there?
Yes. Ubidreams has developed a cross-platform app named "Gourmandise" for Remy Cointreau. This application is a mobile catalog used by the sales department when meeting customers. In addition to the iPad application a web application (CMS) was developed using the Nanoko stack. This CMS runs on any browser (including IE8).
INFOQ: What application architecture is Nanoko a variant of? MVC, MVM, MVVM, or something else? I read the FAQ and see that Nanoko is complementary to existing MV* frameworks.
Nanoko eases the creation of any architecture-style. For instance, Ubidreams have implemented an MVC pattern where:
- Models are based on JSON data structure retrieved from a server
- Views are implemented using Enyo and Twitter Bootstrap components. These components are enabled or disabled according to the device / browser features.
- Controllers are just Nanoko's components (actually, h-ubu's component) managing links between the model and the views. It can also rely on services.
- Services are reusable functions (such as security, networking task and scheduling) also implemented as Nanoko's components and used by controllers.
INFOQ: If Nanoko is complimentary, then it is not so much a framework on its own, but a way to organize your apps into discrete modular parts. Is that a fair statement?
Yes it is a good vision of the Nanoko's benefits. It's more a platform than a framework like angular.js or backbone.js. Obviously such quote depends of your definition of "framework." Anyway, it's probably easier to see Nanoko as a platform to build modular / component-based applications.
INFOQ: Nanoko is not a framework. Do you agree or disagree? Please explain why.
Agreed. Nanoko let you bridge heterogeneous technologies. Behind this, Nanoko aims to improve the development industrialization and efficiency.
INFOQ: How does Maven interact with Nanoko? Why is Maven better than Grunt?
Maven is in the core of the industrial-strength continuous build/delivery chain of Nanoko. We can love or hate Maven. Facts are that Maven has drastically changed how Java software are built, in a good way. We think that the rigorousity and conventions of Maven paves the road to web development industrialization. Grunt gives a lot of freedom as Ant did a couple of years ago for Java. However, without a strictly defined lifecycle, a powerful dependency management, and enterprise artifacts repositories, such industrialization would be hard if not chaotic.
Using Maven also means using the very same build system for the backend and the web part of the application. This is a pretty important aspect to see. In addition dependencies between both would be very simple: just a Maven dependency.
It's not to mention release processes and documentation management placing Maven as a cornerstone of the Nanoko platform.
INFOQ: Please explain the interaction Nanoko has with J2EE app development. How is this server-side technology compatible with Nanoko?
Nanoko is not per-say bound to JavaEE or any backend technologies. But integrating the Nanoko stack with these technologies is straightforward. Nanoko promotes service-orientation, where features are available as ‘services'. Backend servers are just exposing Restful or web services.So reifying these services in Nanoko is simple as pie: a component exposing the very same service interface. Others components just rely on this component to access to the server features.
INFOQ: How is Nanoko different from node.js or require.js?
First, Nanoko is compatible with require.js and node.js. Actually, it recommends them. You can see Nanoko as a way to build and bind require's or node's modules.
Using the service-orientation, modules interact using pre-defined services (named contracts in Nanoko). This loose-coupling allow substituting a module by another one (even at runtime). You can quickly see the benefits of such pattern: having modules enabled / disabled according to the platforms and the execution context, asynchronous evolution of the modules, easier testing and so on.
INFOQ: What made you decide to open source Nanoko? Under what license?
Nanoko is a collaborative effort from several companies (Ubidreams, dynamis-technologies, Grenoble University...) having open-source as one of their core values. So opening the source of Nanoko was natural for us. After having discussed with the different founders, we selected the OW2 consortium, as we are pretty close to the OW2 philosophy.
The source code of Nanoko is licensed under the Apache License 2.0 to remove all barriers for business adoption. The full codebase is available on GitHub. Releases are published on Maven Central making using Nanoko's components very simple.
INFOQ: Where is this project headed?
The project is headed in France both in La Rochelle (Ubidreams HQ) and Grenoble (Dynamis technologies HQ) cities. Nanoko joined the OW2 open source consortium to reach an international visibility. With this strong & great support from OW2 and all its members, the future of Nanoko looks shiny.