Introduction
Angular.js is an Open Source (MIT) JavaScript framework created and maintained by Google. It is designed to help web developers create quick and functional applications, while reducing the overhead of data binding and state management.
If you want to find out more about Angular then look at some of the myriad of great resources around the web.
Angular Developer Tutorial
New To Angular? Start Learning Here
https://www.ng-book.com/
Angular.js the awesome parts (Video)
Front end / Back end
Angular.js is all front-end, 100%, JavaScript based. But as in any useful application there needs to be a back end to provide and manipulate the data. In the XPages case this would be Java.
The ExtLib REST services and the Domino Data Services are written in Java and when we are talking about a world where there are no XPages controls Java is the right way to go. Even if you don’t need full CRUD REST, you need a data source and that’s Domino data serviced by Java. There is of course no reason why you can’t create and pump out data in SSJS, but there is also no compelling reason to do so either.
In the following article series I am going to demonstrate how many of the techniques we use in XPages have analogies in the Angular.js world.
I know there are a number of people already using these techniques with Domino acting primarily as a data stores: Mark Barton, Karsten Lehman, Richard Moy and others. Unfortunately there is very little discussion and/or resource information for the community. I and others are looking to help ease that.
A new Paradigm
What using Angular.js (or Backbone.js or Ember.js or other JS frameworks) really does is change the paradigm of “Domino” development to be potentially much more in line with modern Rails, MEAN stack, and dare I say BlueMix development.
In time I hope to be able to discuss *how* Angular or *why* Angular but before then I just want to learn more about it, demonstrate the possibilities and broaden the discussion.
More to come soon 🙂
Xomino 
Mark,
It is interesting to see more and more XPages developers moving a direction that we have been taking for a while.
I know you use dojo a lot but do you use backbone or angular?
Not yet. I was investigating backbone to bind the DOM objects, but did not have the time test. I would like to. I am interested in your experience with angular.js. I am using Dojo at this time to bind the DOM objects with the RESTful API. Wrote something similar to Backbone.js.
Makes me think of a comment by Douglas Crockford about the ‘pendulum of death’ where we are constantly oscillating between a pure client-server model (the browser is dumb and the server does all the thinking) and the ‘server is just delivering data’ model. I’m still not sure which is the better, and we’re probably going to be oscillating for a long time.
The main problem for web based applications is still the “security”: You can not trust the data sent by by the client. So you have to validate the data from the client on the server, and maybe the validation depends on the “last state” of the user session. That’s why you have to store the state on the server too.
In the the next 12 monthes (until 2015) it is fresh-n–funky to do everything on the client, then, in 2015 the frameworks will get extended to fix the problems on the server side. In 2016, these frameworks will be critizised to become too complex, and everyone has to switch to the next framework/Language, because *the new one* is sooo hip and fixes all the problems.
“Same procedure as every year”:
When doing all your stuff in the client, you still have to do the same on the server. This is the price you have to pay for using a stateless protocol.
I am so tried…
I see no point at the moment in using angular with xsp (angular on an xsp I mean), but for mobile apps, working with Notes data I see use cases. Ofcourse the xsp could provide the data (e.f xpagent, rest service control). Some angular stuff you could do with partial refresh, “vanilla” XPages, but I am not full updated on angular. would be nice to learn from real world examples, preferably in an app form.
Astute observation.
“XPages” is a loose enough term that it doesn’t just mean using an xsp page but can be more inclusive of Domino’s >= 8.5 capabilities
Using an actual XPage is actually rather restrictive in this scenario – more to come on that.later
Mark interesting times ahead.
Yes I will pull my finger out and contribute my tuppence.
@Patrick I am sure I don’t have to tell you there are many reasons for diversifying the technology stack, from Risk reduction (both personally and from a business perspective) to cost reduction which can be subjective.
My take on AngularJS is it powers the front end and I don’t really care what drives the backend. My experience is with Domino so I am happy for it to generate JSON data using the techniques we all know as well as leverage some of its services – Mail routing & security particularly but I don’t want any of the UI stuff.
The important thing is I have found AngularJS does provide added value and benefit when combined with the Domino stack.
Mr. Barton, how you do pull the domino data in order to use with angular.js? Are you using xAgents, DDS ?
Luis,
Its a combination of things – where I can I will use the simplest solution which is DDS, this doesn’t always meet my needs though so I also use XAgents where we need more control and business logic.
I also do still use things like createdocument for posting where its appropriate and even pages with computed values. One thing to watch is Angular by default expects everything to be JSON when posting and things like createdocument use the older POST method of named pairs. Theres a simple HTTP interceptor module you can drop in for those cases. Either me or Mark will blog about it.
The ideal situation would be a full Java REST framework which we could easily leverage – something like https://jersey.java.net/
I don’t want to take Marks thunder away when talking about CORS and authentication but I think Mark might have a few words to talk about here when dealing with Domino REST API calls cross Domain.
Mr. Barton:
Thanks you very much for taking your time for answer me!! And thanks to Mr. Roden too for this great series (I read the first post of the series this morning and I was so anxious that I forgot to say thanks to Mr. Roden, sorry for that, and thanks you Mr. Roden).
Currently I am developing an xpage application using bootstrap, jquery, datatables.net plugin and other plugins too.
In order to pull domino data for the plugins I use Rest Service Control, and it’s ok so far, but currently i am investigating the ember.js framework for use with domino data.
I saw another post talking about backbone.js implementation in lotus domino using xAgents for pull/push the data, and I think that is the easy way, but i wanted to know if exist another way from xAgents and DDS, like the one you refer in the ideal situation.
In order to make it easy, I will try with the xAgents first, waiting for a solution like you refer in https://jersey.java.net.
I will be following this series !!!!
Thanks you very very much, sincerely.
Luis
Mark,
Can you elaborate on what you feel are the added value and benefits on AngularJS and how does that differe from backbone.js
I can – good idea, but this is not the place for that – future post. I want to show capabilities first before launching into the conversation about what is better when and why 🙂
Sorry Mark I was actually responding to Mark Barton
Richard – I do not know backbone that well but from what I can tell backbone is far more limited and lightweight.
I was trying to find a recent blog post that someone converted the standard Angular tutorial https://docs.angularjs.org/tutorial to backbone. They basically had to write x3 more code in backbone.
AngularJS is moving fast and to a certain degree that can be a problem and if you need to support IE8 then the current version will be the last officially supported version. 1.3 will no longer be tested for IE8, they will not remove any IE8 fixes but nor will they test for it, 1.3 is in beta at the moment.
v2 of Angular which is also in development is a step change – its based on ES6 and will not support a browser which doesn’t automatically update (IE11+, Chrome & Firefox) – the payoff is near native performance on things like mobiles. Still that’s no different to v2 of JQuery.
It is slightly surprising until you remember AngularJS is supported by Google who only support the current and last release for each browser in there products (IE11 / 10)
I still believe its the better framework and stands you in good stead for the future developments like Web Components.
Mark thanks for the comments. Another thing that I have to learn. I think my head is going explode.
Mark great topic! I often thought that the Domino REST Services were underused in this manner (pure data store). I personally prefer the model where the server is just used to provide and store the data and let the client (browser) handle the UI. I think this model opens up a wide variety of possibilities. For example you could build a native mobile app that uses the same REST APIs. Also it opens up the possibility of extensibility. Having APIs for your application today is a MUST! And that almost always means REST APIs.
I do not have much experience with Angular, one of the frameworks I want to look into. I have played around wtih Backbone a bit and I enjoyed working with it. It is a true MVC framework and it forces great coding habits. Can’t wait to see the rest of your posts on this.
Thanks Ryan – nothing like putting myself out there for scrutiny 🙂
Angular to me seems like it is Backbone+. I started with backbone but quickly realizes there was *more* to Angular and WAY MORE information on it online….
Learning 🙂
The fact that you are not afraid of being scrutinized is what makes you a good blogger/developer 🙂 You should check out Yoeman and the Yoeman Angular generator (https://github.com/yeoman/generator-angular). Really helps scaffold up your client side projects.
Thanks mate – will do in time 🙂
I totally agree with a couple of the other comments: building applications with a clientside JavaScript UI talking to a REST service is the way forward, especially in the mobile area, and is something that every (front-end) developer should look into. It’s all about keeping current with what the rest of the world is doing and not restricting your growth by keep doing what you know.
The learning curve to move away from what we did in the past (let the server render everything) is pretty steep and requires lots of new skills to learn, but I als find it a very refreshing and intuitive way to develop applications. One of the harder parts is choosing what technology/ products to put your efforts into. The amount of new stuff being released is overwhelming.
The latest framework I looked into is Ember (comes with great documentation), but I’m also very interested in Angular and look forward to what you come up with. Angular seems to be the cool kid at the moment.
(Oh and I’m actually only commenting to confuse people more on all the Mark’s in this thread 😉 )
In my eyes it is not a way forward, it is the same thing what happend during the last years over and over again. First do everything server side, the do it client side, then do it again on the server, and then change it back to client side… This happens every two or three years.
What does the rest of the world? Twitter for example has choosen in 2012 to switch back to server side generation because of better performance (Twitter’s server-side rendering takes 1/5 the time as client-side rendering): https://blog.twitter.com/2012/improving-performance-on-twittercom
When I have millions of concurrent users I will have better things to worry about than render speed.
I really appreciate the feedback and discussion but before we beat this to death, shall we take a look at some of the things Angular can do?
Right now, to me it looks cool, looks like a much better fit for my skill set and I am going to learn more about it 🙂
Sure we can.
But you said that angular.js will change the paradigm of Domino development. And my point is, that this does not change anything.
The advantage of client-side JavaScript UI/RESTful is that the transition between desktop and mobile is minimal, and with responsive design non-existent. I will demonstrate this in a up and coming blog. If your design your RESTful API correctly, the data validation is not be even a talking point. If you are a developer and rely on client-side validation then you are in trouble. Client-side JavaScript UI/RESTful provides the same analogy as responsive design for the interface, platform independence. By having all the your RESTful services created in Java all you need is an abstraction layer that talks directly to your specific web server. So when you change your server platform, all you need is to rebuild your abstraction layer.
As one who have created a number of applications with Javascript UI/REST, yes I agree that having the server creating the page has its advantages and has better performance, but the flexibility of Javascript UI/REST and the form vs data isolation overrides that. It is extremely important to carefully plan your REST services and follow a consistent pattern to minimize the number of required RESTful services.
I did this first time eight or nine years ago with WebServices & Ajax.
Great topic. I have wanted to look into angular.js for a while since that seems to be one of the frameworks making its way to the top – at least right now….
Andrew and Sven touched on the real problem – validation (and your business logic) HAS to be on the server. Otherwise, you risk poluting the data. I am working on a rather large XPages application at the moment. The browser version has gone into test. I have tried to implement an MVC model with all validation and business logic in the “Model” layer (lots of Java – 20000+ lines in total).
I have just started development of a mobile app (native) that will talk to the same application via REST APIs (through the same Model layer – validation and business logic). I suppose this setup (with several types of clients for the same application) is something that we will be developing more and more. And in doing so we already have to do the server side validation and logic – so why not use the opportunity to use a client focused framework (like angular.js) to use the same services as we will for the other clients (mobile web app or native app)? That makes sense…. Although, I still need to find a good way to implement a validation mechanism on the client side without having to duplicate all the validation rules for each client platform…
Looking forward to seeing more about angular.js 🙂
/John
Great Topic! I am an Xpages Developer & have been exploring MEAN stack for over a year now. It will great to use Angular with Xpages. Looking forward to this serious!
[…] better programming practice for Angular.js than was demonstrated in the previous articles within this series. I have mentioned before, part of the purpose this blog is very much a “learning in […]
An intriguing discussion is worth comment.
I believe that you should write more about this issue, it might not be a taboo matter but usually people do not discuss these topics.
To the next! Many thanks!!
[…] by a serie of blogposts from Marky Roden and popularity in the web dev community I decided to step (once again) from the XPages path (a […]
[…] The pursuit tracking application that this series is based on is a Front end driven application which uses Domino for the authentication and data storage. The “Front end” part is provided by Angular.js which is one of those cool “toys” that I refereed to above. I absolutely love it and it has wide support in the industry and is therefore a good choice to invest in. If you would like more information on getting started with Angular.js please refer to Marky Roden’s excellent series. […]