So far, ProjExec has been a really good citizen in the IBM/ICS world as we tried to reuse the core Connections stack as much as can (Dojo, OneUI, ...). But these technologies start to age while the browser technologies evolved a lot in the past years: what required a whole bunch of JavaScript using Dojo/JQuery can now be squeezed in a few lines using new libraries! It is time to change gears.
We started to look at what technology would better fit our needs. The main requirements are:
We started to look at what technology would better fit our needs. The main requirements are:
- Make the developers productive - easy to integrate new developers
- Have a decent performance when the application grows - ProjExec is large!
- Can integrate with the existing code, and be used incrementally within ProjExec
- The tool chain should integrate well with what we currently use (Maven, Eclipse...)
- Can be debugged easily, with mean full logs
- Have a eco-system with ready to use libraries (bootstrap, mobile, ...)
The natural next move was to use Angular 2, as it fixes most of the issues found in 1.x. I would say this is true, but the learning curve grew significantly. That includes some technology choices (ex: Observable vs Promises), Typescript, the tool chain required to get an application properly packaged, and the heaviness of the resulting code... I spent time playing with it for Darwino (we'll release some examples), but I do not see the ProjExec developers being quickly productive with it. This has been further confirmed by one of my friend, a GDE (Google Developer Expert, the equivalent of IBM Champion): his one week training class is barely sufficient to get the developers comfortable. Also, getting it integrated in a venerable existing application raises some challenges.
Ok, we'll might use it later with Ionic 2 for a dedicated mobile UI, but for now, let's look if something easier can be used on the existing web application.
Ok, we'll might use it later with Ionic 2 for a dedicated mobile UI, but for now, let's look if something easier can be used on the existing web application.
The next candidate on the list is Facebook's ReactJS. Clearly, there is a buzz around this technology. It has very interesting concepts, it creates high performance applications. But the initial learning curve is even bigger than Angular's, particularly for Java developers. Moreover, it is pretty low level, which provides great flexibility but you then have to choose the proper companion libraries.
We'll keep this in the back burner, let's look is something else better suits our needs.
Finally, we discovered that another library got a lot of traction last year: it is called Vue.js (https://vuejs.org/). After a first look at it, it feels like what I hoped Angular 2 would be! Ok, I bought 2 books from Packt ($5 each), got the source code from Github and started my deep learning. It features exactly what we need:
We'll keep this in the back burner, let's look is something else better suits our needs.
Finally, we discovered that another library got a lot of traction last year: it is called Vue.js (https://vuejs.org/). After a first look at it, it feels like what I hoped Angular 2 would be! Ok, I bought 2 books from Packt ($5 each), got the source code from Github and started my deep learning. It features exactly what we need:
- Easy learning curve, particularly when you have some Angular 1 background. Anyway easier than Angular or React
- You don't need a whole set of tools/CLI to be in place up front. Just include the single JS file and you can get started. It happens that we'll finally use Webpack, but this was not a requirement from the beginning.
- It fixes many of the problems/inconsistencies found in Angular JS 1.x (bind vs values, separation of concerns, single file components...)
- It easily integrates within existing applications, regardless of what they already use (Dojo, JQuery, ...), even if they are not designed as SPAs
- It performs as good as ReactJS. Moreover, if you're a JSX fan, it is available as well
- It is very lightweight and non intrusive
- Developer's productivity feels superior to ReactJS
- A good set of tools/libraries/docs is available https://github.com/vuejs/awesome-vue
- See how it compares to the other libraries: https://vuejs.org/v2/guide/comparison.html
I'll be interested to hear anybody else experience. Please feel free to comment.
I have been experimenting with vue.js in Xpages for 2-3 months. It was love at first sight. It's very intuitive. Documentation is great. There's a very good and exhaustive course at udemy (Vue.js 2 the complete guide). What I really like is that it's up to the developer if he/she want to use vue.js for a couple of widgets on a page or write complete single-page applications. It's very flexible that way.
ReplyDeleteYep, this is exactly the reasons why we are using it. We are starting with a few components and we'll make it an SPA later.
DeleteThanks for sharing your experience!
I've been doing the same exact reasesrch and just recently discovered Vue.
ReplyDeleteIt's the next step in our testing but the fact you are liking it makes me accelerate it's study. Thank you for sharing
Eric McCormick is a big fan of Vue. We looked into Angular, React, and Vue, but we kept our Dojo-based MVC framework. Over the past year we have made major performance improvements. The upside is that it is easy for us to improve and enhance. Downside, we have to fix the bugs ourselves. Either way, we are extremely happy with our Dojo-based MVC framework that we created.
ReplyDeleteRichard Moy
It is good if you're happy with Dojo. We also have some Dojo components and we'll continue to have them coexist with the new stuff. Now the Dojo programming model feels a bit obsolete and not as productive as technologies like Vue. Moreover, when integrated into IBM Connections, we have to use IBM's version of Dojo, where they replaced the regular loader by the one coming from jazz, featuring a server side JS aggregator. Unfortunately, this is not compatible with regular client side aggregation, which forces us to load the modules one by one. This is a definite performance killer that we want to get rid of.
DeleteRichard's right, I am a big fan of vue.js. I've found the markup syntax to be highly familiar, coming from an AngularJS 1.x perspective, and the component-like nature and heavy use of ES6 abilities to be pretty refreshing. Additionally, some of Evan You's efforts in providing a pretty fantastic ecosystem, including a cli tool, which allows for different templated starters (such as webpack, browserify, etc.), has been phenomenal.
DeletePhilippe, that is because IBM's implementation is old and even when Dojo switched from synch to asynch AMD module it is still using the old methodology. We use Dojo the way Dojo was intent as asynch with AMD . Performance wise, I think our implementation is dare fast. Combine it with bootstrap, fontawesome, chartjs and other open source code, it is awesome. Of course I am bias.
DeleteUnderstand and agree. But we are forced to use their Dojo so far, so we have no choice. On the other hand, I'm not a big fan of AMD, I find it heavyweight. Getting the modules split using ES6 imports (or Node require) and then Webpack is much more convenient.
DeletePhilippe we have one single XPage HTML container with all views, widgets, and interactions are generated by JavaScript using AMD. So view ,widgets etc are generated when needed and destroyed when required. This keep the memory space clean. The next version of Dojo coming soon will support ES6 import.
DeleteJust started dabbling with vue.js 2, too. It looks very promising, and I'd be curious to see what others are doing with it.
ReplyDeleteOh yeah. We are experimenting with Vue and Xpages as well! So keep us informed, or maybe some articles would be very helpful!
ReplyDelete