58 thoughts on “Why learning JavaScript is more critical to XPage developers than Java”

1. You’ve convinced me. I’ll start refactoring my APIs to SSJS libraries right away.

   Reply

   • At least start with Nashorn as the target 😉

     Reply

2. Exactly Mark !!! JavaScript and Java are TOOLS in a developers toolbox. Developers need to learn how to use the RIGHT TOOL for the job. When teaching / transitioning Notes/Domino developers to XPages development I agree that the correct path is JavaScript and then Java when the need presents itself and they are ready to expand their toolbox.

   Anyone who is communicating “Java First and only Java” are doing the community a disservice. I suppose we should remind those folks that in order to call their Java code they have write some JavaScript 🙂

   Reply

   • Very eloquently put sir, thank you 🙂

     Reply

   • I’m curious who this person or persons is that’s communicating “only Java.” I’ve never seen that and it would be an interesting case to read about. Do their applications dynamically compile browser Applets or something? Do you have a URL?

     I’m also interested in the person or persons putting forth the argument that n-tier architecture is more important than user experience. Is there a URL for someone making that case?

     Reply

     • There are multiple blogs, Tim and Christian spring to mind who give a clear statement of why they believe XPages developers need to learn Java. While they do not state “only Java” the context is very clear that Java is the way to go. To a new developer it reads “only Java”.

       The n-tier architecture was a passing comment I have heard multiple times from various sources about web development in general. Not a specific XPage/Domino perso .

     • I would also vote Java is more important than JS. My first and foremost argument: it’s browser independant and it can be so smoothly debugged 🙂

       I agree that sometimes a good deal of JS knowledge is required. Comparing the few lines of JS code I wrote in my largest xPage application compared to the amount of Java code I wrote Java is way more important.
       Comparing CSJS against SSJS: the whole app uses less than 100 lines of CSJS. The SSJS is mostly used to call Java counterparts.

       I had so many situations when I started off with xPages where SSJS just didn’t do it cause I couldn’t debug it. On the client side I agree that it can come in handy, see my latest post (http://in-mood.blogspot.ch/2014/03/indip-how-to-figure-out-id-of-element.html), but eventually the solution wouldn’t work with Java at all.

       All “nice” stuff on the client side is supported by nice little gimmicks from the Extension library where you need not fiddle around.

       After all my experience to get a really nice xPages app going I would state the following hierarchy:
       1. Java
       2. CSS
       3. JS

       How to handle CSS properly I guess is still a mistery for most developers. After all the C stands for “cascading”, but how everything is built I don’t see no cascading no-where. Getting things look the way I want with the themes provided is WAY more difficult than to get the few lines of JS working. I spent, just guessing, a good 25% of the time on visuals!!!!

     • Michael, I would say that one ought to learn CSS before either if you’re going to work on the front end at all. It’s not very difficult and everything you do has an immediate visual impact on your application. If you do your CSS correctly, you spend 25% of your time on the first app getting the styles correct and then never have to monkey with it again.

3. Mark,

   It depends on your role in the development process. If you are involved mostly in the front end, then Javascript is critical. Since XPages is just a container for us, I wrote a number of SSJS library to handle the container and rarely touch them. The RESTful JSON services is all done in either Lotusscript, SSJS, or Java depend on what we need to do. The backend developer provides me the a RESTFul JSON service and I really don’t care how it was created. We are looking at creating more servlets in the future. Now if we switch to Nodejs then it is Javascript all the way.

   Reply

4. Great post Mark. I recently faced the decision and I chose to go back and learn javascript properly, from scratch, rather than learn java properly. A little bit of each gets you by, but I think bigger gains can be made for me by learning JS and getting serious about UI. I’ve been killing far too many kittens lately.

   Reply

5. Hmmm, Marky – I would venture to guess you’d be one to put me in the camp you describe. Just guessing, but thats where a lot of our conversations have (d)evolved to :). I too consider myself a web developer first. I’ve been developing web apps inside and outside of Notes/Domino/XPages forever. Before XPages, I too wrote UI and UX using backward hacks in Domino, used exciting UI frameworks like ext (and ext.nd) to deliver exceptional apps with exceptional UI and UX for many a years as well.

   That being said, I think maybe you put this too much in terms of absolutes. And I think maybe you might miss the viewpoint of the other side of the camp a little. Not trying to be confrontational, but, I’ve not seen (m)any(??) people espouse the “Beginning Developers must learn java” … Nor do I think that one should espouse that JavaScript is less or more critical than any other part of the platform. They are all important parts of the platform, and appropriate to learn at the right time in your place on the learning curve.

   I think what I have espoused in the past is that Java is a VERY powerful tool in your toolbox to do exactly what you are describing. In my opinion you can create a very sculpted and magnificent UX, that is very fast, very scalable – without java. Java allows you to take it to the next level. When you are ready, when you understand the platform, Javascript, general web development concepts, etc, its the right time to consider adding the next tool in toolbox, Java.

   So let me, for arguments sake, cede some arguments to you to get them out of the way ….

   1. Java is not required to write XPages (We all agree here)
   2. You can write magnificent applications with great user experience, and phenomenal functionality without writing a lick of Java
   3. Well designed UX and UI is critical to ANY application – regardless of whether you use Java or not (or XPages, or Dojo, or Mootools, or jQuery, or anything) – these are tools, not your app, not your UX, not your UI, not your functionality.
   4. Beginning XPages developers should start with the easy stuff, first, and then continually and eventually progress.

   Now, let me specifically address a few points from your article:

   “From that project forth I stopped putting the server first.” – this entire paragraph assumes the only thing that you can benefit from learning Java is server side performance. Honestly Marky, thats the LAST thing I use it for. I’ll get into what I use it for in a bit.

   “Speed” – Your entire argument about speed here relies on native direct access to data only. Using FTSearch to find docs, cached access to data, cached access to SSJS, etc. Yep. You’re right, If you restrict yourself to this being the only thing you do with java, the way you access data, then you are right. Why invent the wheel to re-access that data to save a few hundred milliseconds in data access on the server. What you are missing is things like being able to dramatically simplify data models, create and re-use components that can be optimized and shared amongst an application (much more compact and speedy than a even a custom control, etc). Other items like being able to customize and directly control the markup sent to the browser for custom complex UI and UX elements, and directly tying them to a data model. Something that can create LARGE amounts of code overhead when done strictly through something like a custom control. What you can do with Java to increase speed to the user is greatly reduce the overhead sent to the browser from a non-java enabled XPage App.

   “n-tier architecture / Separation of UI and business logic layers” – Ok, so I understand UI, I’ve written very UX friendly apps, and I’ve spent HUNDREDS if not THOUSANDS of hours specifically on developing and understanding UI/UX. So hopefully I qualify as someone that “can demonstrate to me(sic) that they understand the UI”. You might know or remember that I wrote an app that provides a pretty slick Workspace application that mimics the lotus notes workspace on the web. I ABSOLUTELY needed to abstract the UI and the business logic and data in that case. I reuse the concept of a “workspace tab” over and over again. I abstract the concept and re-use the concept of a database icon over and over again. The first time I built that, totally built without java. You know what. Performed like excrement. The markup in the page was BLOATED. There were hacks and tweaks to get it to do things i needed it to do. I documented a great deal of them on the XPages blog. I decided then and there I needed to learn java to make this work right and abstract a reusable model to cut the bloat, to increase performance, to dramatically reduce the code sent to the browser to increase speed. I did 2 things. First I wrote client side JavaScript libraries to abstract CLIENT SIDE things like event handlers, create smart UI objects, etc. Then I wrote backend Java classes to be the server side representation of those objects. Because of BOTH, performance became a non-issue. A very polished and complete UI/UX became VERY clean and spartan in my xpages’ markup. I can re-use those same components elsewhere in my app, and other apps, with a few clicks. All because I separated UI/UX from business logic. There is absolute benefit there.

   “It’s the future” – I would not venture to say “Java is the future” – I would venture to say its in your best interest and future as a developer to add tools to your toolbox, and to be able to draw on them at any time.

   “Java can do things SSJS can’t” – You are right here, but I think this is another case where you miss the point. Java can SIMPLIFY things that you do in SSJS. Java can make things you do in SSJS reusable. Your entire argument seems to be “Java is jackhammer when you need a sonic screwdriver” … I really think Java is your sonic screwdriver.

   “At this stage of the game anyone still resisting a move to XPages” – Straw-man argument? If they are resisting and moving to XPages, Java is not whats holding them back…

   “Because no customer ever said “This website looks like crap but the pages load so fast I am in love with it.”” – Again, your argument is that Java is for server performance only. I think you do not understand what Java allows you to do. Java is another tool to make your application rock. In terms of performance, yes, but also in terms of UI/UX.

   “End users are more forgiving of a beautiful website which is slightly slow, that a blazing fast, ugly, hard to use site” Over and over again – why does using java equate to a fast ugly site? It seems like your argument here is DAMNIT PEOPLE LEARN TO WRITE A UI/UX .. not “don’t learn java, it’ll make your site ugly” – and you know what people REALLY LOVE – a fast AND beautiful website.

   “Every time you use a 5 year old IBM XPages out of the box dojo control and tell a customer that it is a good interface, a kitten dies.” SOOOOO Wrong. We get it, you like jQuery. So do I. You don’t like Dojo (i’m guessing because its structured like Java) … but you can create excellent UI/UX with Dojo as well. To make such a statement like this really just shows bias. Its the developer that makes a bad UI/UX, not so much the components used.

   Now, to wrap up. Much like politics, this whole “argument” sort of plays out as ideology pitting Republican SSJS programmers against Democratic Java Programmers or whatever. The truth is really more in the middle; the truth is that you benefit from knowing and using both; the truth is if you are writing an XPage, you are writing a Java app; why not avail yourself of all the tools the platform offers so you know when and where to use them, rather than saying Its all A or its all B.’

   Marky – Finally, I think you are a great guy, I’ve spent some great times laughing with you, and I’ve loved every minute of it. I value your opinions, and I want to make sure you understand none of this is personal in any shape or form man. I think you rock, and I am a better developer for knowing you, so thank you, and thanks for sharing your opinions and knowledge here. You’re a gentleman and scholar Dr. Marky.

   Reply

   • Beautiful!!! Thank you.

     I guess my desire to write a post like this was that when I have developers coming to me who want to learn XPages but find posts only about using and writing Java in XPages I felt a need counter that.

     What you just wrote is the best explanation of the juxtaposition I have ever read.

     Wow!

     Brilliant

     Reply

     • Marky – I’ll have more to say to the post itself later… but let me respond to your comment here.

       “I have developers coming to me who want to learn XPages but find posts only about using and writing Java”

       This has always been a problem in a community. The Bloggers learn first. Then they move to more advanced topics and a learning gap gets generated for new people. It’s a problem learning via blogs. I don’t care the technology. There’s no index. No great way to go back in time and catch up. Google can’t do everything.

       Bridging this gap and keeping a focus on intro to intermediate material is part of why NotesIn9 exists and is part of the mission statement for the show.

       That does not make the Java posters “wrong” to post about Java though and I know that’s not what you said.

       If you think there’s too much Java or advanced stuff then post or create videos on the Javascript topics that you think are needed. Don’t get me wrong. I know you ARE doing this. How about a video or two to freshen it up? Even some of you’re jQuery posts were made a long time ago. Encourage others to post. Stop by the XPages Forum or StackOverFlow and help to spread the word there. Write an “XPages for Dummies” book so people don’t need to rely on blogs for learning.

       Of course I know you do a lot. You do a tremendous job giving back to the community and your blog and jQuery topics and demo site are a critical resource.

       I’ll make a couple quick comments on the article itself…

       I don’t know of anyone saying only use java. ok Maybe on Skype but I don’t count that. People misquote the movies alot also: http://www.totalfilm.com/features/the-20-most-misquoted-movie-lines

       Scott Good used to do a great Lotusphere session called “You can’t fix Ugly”. The point was if it’s ugly people won’t trust it. It can kill an app. That is absolutely true.

       If memory servers you prefer Android to iPhone. Why? The iPhone is beautiful. It’s extremely well made. It’s almost a work of art. Yet you choose Android? Why? Because of better capabilities on the BACKEND.

       Pretty means little if the functionality isn’t there.

       The UI code and the backend code deserve EQUAL importance.

     • Again then “only Java” comment was more of a reflection of how newbies read posts on learn Java and how they approach me.bit comes across as Java only

     • I’d also like to hear from people considering XPages development if they are reading this. What’s your take and what can *we* the community do to help you 🙂

       Of course this post has provoked discussion and that is great 🙂

       Thanks Dave 🙂

6. Marky, you seem to be confusing two separate arguments. The need to learn Java and the need to only learn Java. And by combining SSJS with ECMA Script into a single language you can easily make the case that JS is the one ring to rule them all because it’s the only client side option.

   As a Notes client developer I found it important to have a good knowledge of @formula and lotusScript. I preferred Ls but know some developers who still prefer @formula. I consider it personal preference as long as they know both and make informed decisions.

   With XPages I would suggest it is wise to know ssJs, Java, and EL. After that it becomes preference as to how much of each. I have observed that the longer people write XPages the more likely it is they write more of their code in Java. many of these people suggest learning java earlier based upon their own eperience. I would too. I use SSJS only when I have to. I just don’t like messy difficult to maintain code. but that’s my preference. I would urge everyone to make the effort to learn and use java. I would not suggest it wise to develop Xpages applications without having that in your toolkit in much the same way of developing HTML without CSS or Donino web development without XPages. sure it can be done, but why?

   Reply

7. Amen! Great post Marky!

   Reply

8. SSJS is the PHP of Domino development. It gets the job done and a master can do amazing things in it, but it is still an inappropriate tool for the task of building a good non-trivial app. Moreover, it teaches you bad habits that are hard to overcome.

   With SSJS, you’re effectively writing procedural instead of object-oriented code. That’ll get you by for a while, but as soon as your app moves beyond trivial complexity, you end up fighting your framework more than having it help you. Code reuse is harder, concerns are woefully intertwined (so that your UI code is half about back-end crap that is irrelevant to presenting a good experience), and the whole thing becomes more fragile. You can improve the situation by refactoring your code out to script libraries and JS pseudo-objects, but that’s akin to trying to shoehorn OO code into vanilla C.

   I also disgree with the common assertion that using SSJS means you’re writing in “the same language” for both server and client code. SSJS and client JS share many semantics (as does Java), but there’s no overlap between DOM manipulation and Domino database access, which make up the bulk of your actual work. In an environment like Meteor, the two sides are indeed blended, but XPages are not such a environment.

   Reply

   • Just like all other OO language, you should be able to write effective and reusable code with JavaScript. Yes, it is not a true OO language like Java, but at least on the front end with the use of Dojo, I create reuseable class all the time. Now it takes discipline, but you should be able to apply the same methodology for SSJS. What would be useful is have the dojo.declare equivalent for SSJS.

     Reply

     • Richard – I thought the same thing originally as well, but there is a fatal “flaw” … basically there is NO guaranteed persistence of SSJS objects between requests. The object must be recreated each time (or least expect that you will) … depending on the server settings and how it does persistence between sessions, this can get wiped out. You can’t even persist them in a map, because it hold pointers (if I remember correctly) … so then you need a way to serialize/deserialize the SSJS object. You also can’t persist domino objects that way either (cant really do that in java either) … anyway, you really start going down the rabbit hole when you start to do SSJS objects and realize, you might as well write them in java because all that infrastructure is already built for you. You just extend it.

     • Maybe I am wrong, but I though that SSJS prototypes were persistence between requests and someone blogged about that recently.

     • Unless changed very recently, Its not guaranteed. The items remain in memory after the page is completed, but are subject to be collected, and if your server is set to persist pages to disk inbetween requests instead of held in memory, they are collected. David Leedy had this very convo w/ high level XPage team members @ IBM and i what pushed him over the edge to start to learn Java.

     • Also – addressing specifically “SSJS prototype” persistence – even if thats the case, its such a minor capability without the ability reliably persist the state of an object. Prototype persistence is rather moot since the code to establish the prototype can be run to rebuild it at anytime, unlike the state of an object.

     • If your SSJS object contains no functions, it can be persisted. The instant you add a method (function) to the object, it becomes toxic to store, because IBM’s implementation of functions is not serializable. Remember, even if you choose not to write your own Java code, everything is running as Java. So every SSJS object is really a Java object, and every SSJS function is also a Java object, and the class that each SSJS function is an instance of is not serializable, so you can’t store functions (or objects that contain functions) in the view scope unless you force all pages to persist in memory, which is wasteful and negatively impacts scalability. If IBM ever adds true cluster support to XPages, you won’t be able to store functions in session or application scope either… which means if you currently do, all those apps suddenly break the instant you upgrade. So the only SSJS objects safe to persist are directly analogous to user-defined types in LotusScript: you can bundle multiple properties, or a hierarchy of properties, into a single variable, which is marginally more elegant than maintaining an entirely flat variable structure. But you can’t store any objects in memory that define their own behavior… all your logic must act from outside upon comparatively “dumb” objects instead of bundling process intelligence into the object itself like you can with Java or even client-side JavaScript. If you’re sticking to JavaScript on both the client and the server to avoid having to think in one language when targeting the browser and another for the server, this persistence limitation reduces that benefit, because you still have to structure your server code much differently to protect against the consequences of that limitation… or else “dumb down” your browser code to artificially apply the same limitation to a context where it’s not applicable.

     • Tim, thanks for the explanation.

     • Tim, I want to clarify something real quick … You say “If your SSJS object contains no functions, it can be persisted.” CAN and IS are “still” two different things correct? If, for example you create a global object in an SSJS library, once your session is done, your global object is up for collection … unless you specifically write a method to serialize the object to a scope map, and figure out a way to call that method, and then deserialize it back out again when you need it, Its not something done automatically for you … correct?

     • That’s an excellent point, Jeremy: I was specifically referring to the behavior of the scope maps, where it’s rather cut and dried: an object with no functions is safe to store in any of the four scopes; an object with any functions is already unsafe to store in the view scope, and is likely to be unsafe to store in the session and application scopes in future versions of the product. But the expiration of each scope’s contents follows very predictable rules.

       The behavior of objects defined in script libraries is far less predictable. On the one hand, functions are obviously “safe” to define in libraries, either as members of objects, or as “top-level” functions. Your pages aren’t going to suddenly explode when you adjust persistence settings to optimize performance and scalability just because you happen to have some functions defined in a script library. Behind the scenes, this is because automatic serialization by the platform is never a factor with libraries.

       On the other hand, that’s kind of the whole problem… state maintenance for libraries is far less clear-cut than it is for the scope maps, because library state doesn’t obey the persistence settings like the component tree and scope maps do. As you indicated, objects defined in a library can up and vanish from request to request (not to mention across sessions), which sort of undermines the whole “whee, Domino is a stateful web server now” celebration.

       Given how crucial the nature of closure is to what makes JavaScript a powerful language, this behavior also undermines the value of defining code that looks like JavaScript… in a context where it behaves sort of kind of like JavaScript, but all your closures can vanish out from under you based on rules that aren’t intuitively obvious, this again seems to me something that reduces the benefit of writing as much code as possible in a single language to reduce the amount of context-switching, because you still have to reserve neurons for which JavaScript patterns are appropriate in the context of the browser and which are appropriate in the context of the server.

       Some of those distinctions are fairly obvious: for example, the server won’t have direct access to the DOM, and the browser won’t have direct access to the persistent data store. But when the very nature of closure is suspect — both because you can’t store functions at all in scopes, and because your library objects can be garbage collected when you would expect them to persist — then you’ve lost one of the biggest reasons why JavaScript is an awesome language. So you’re left with a weak imitation of an awesome language, something that at first glance seems comparatively accessible but encourages all manner of bad coding habits and shifts all warnings and errors from compilation to runtime.

       So to anyone who I personally may have scared off by blogging and podcasting less about how I wrote code five years ago and more about how I write code now… I do want you to know that my intention behind that tendency is not to insult anyone who, for whatever reason, isn’t writing most of their code in Java. Your choice of language, on its own, does not and cannot make you a bad programmer. But if I offer occasional advice on how to spare yourself some of the pain I’ve personally experienced and witnessed over the course of those five years, and in response you lash out at me publicly, misquoting my advice, and implying that I have no regard for user experience, I WILL consider that rude. Just sayin’.

9. Very well written Mark

   Reply

10. As others have already commented I’m also a little confused by this blog. Nobody recommends writing Java applets these days. Of course you need JavaScript for the frontend. The discussion JavaScript vs Java doesn’t make sense.

    It’s fair to ask whether new developers should use SSJS or Java. IBM provides these different options to attract different types of developers with different skills and different preferences. Obviously you don’t have to use Java to build XPages apps, but Java provides options like the usage of the many available Java libraries.

    Reply

11. For me the decision is quite clear, I use Java server side to build XAgents / Rest APIs but do not use any markup or client side controls generated by Domino.

    I am just using Domino for its security, data storage and as a simple Java Application server. Everything else is separated and done using Javascript client side.

    Why this madness? Because I get the best of both Worlds, I can use my existing Domino knowledge in conjunction with the power of Java to build useful server side logic, I can protect my data at a granular level and I can even send an email 😉

    On the javascript side I can take advantage of a huge number of very powerful tools and frameworks to make my workflow fast and efficient like AngularJS, bower and Grunt and I can use an IDE dedicated to Web Development like Webstorm and I can host my front end on any web server – CDN anyone?

    Going forward I see my applications consuming services from REST endpoints not caring what the underlying technology is, want to send an email? Call this endpoint, want a PDF then call this endpoint. Check out https://www.dreamfactory.com/

    If at some point I decide that I wish to swap my server side technology to something like nodejs then at least I wouldn’t have to rewrite my front end, JSON is a wonderful thing and of course one of the advantages of nodejs is it uses javascript as well.

    Finally browsers and there associated technologies are only going to get faster and more powerful as companies like Google and Microsoft push the envelope. You might not have access to the latest browsers on the desktop in client situations right now but you will on Tablets and mobiles.

    From a personal career perspective, if you have a choice, I know which language / technology I would choose to concentrate on.

    Reply

    • Mark, This is also the approach that we have been using. We are using all RESTFul services between the server and the client. The client consumes the services and responses accordingly. Our thoughts are the same. At one point we can swap the back-end with something like Nodejs. But security security has prevent that.

      The front-end interface is more challenging then the back-end since it is changing so much so fast. Yet the front end has to support so many different clients and different versions that it is hard to keep up. No longer can one say that we will only support IE 8 or Firefox 3.6 and be okay.

      For back-end work, Java is the way to go for IBM Domino. But for developers who are focused on the front-end, JSF requires them to learn the back-end which many front-end developers will have trouble. The believe the concept of SSJS is to help them in the transition. However, I believe this will not work since the mindset of the front-end developer is not the same mindset of the back-end developer. We in the IBM community doing Domino are used to doing both and this mindset transitions to XPages, but for developers coming from other platform this is an issue.

      That is why we separate the process between the back-end and front end using RESTFul services. After we created our IAD tool for creating the front-end interfaces, rarely do I use Domino Designer. The tool allows a front-end developer to focus on the front-end. Occasionally, I use the Domino Designer to make code changes to the tool and modify the SSJS or Lotusscript. The back-end developers can focus on performance, data security, scalability and the RESTFul services that will be consumed by the client.

      On a side note, I was on an important Web site that said and required IE 8 and Firefox 3.6. Since IE compatibility mode is not compatible and who has Firefox 3.6, the site is totally worthless to me and could not use it. Can’t imagine user coming from tablets trying to use the site.

      Reply

      • Richard interesting you should mention security as well. One thing myself , Mark and Mark Leusink have been looking at is CORS and Domino security.

        I think we might have hit a limitation when doing Cross Domain PATCH Requests in that if you use Session based authentication and website rules you can only have 3 custom HTTP Headers, we need 4 for CORS to work correctly. Mark L has suggested using a broker XAgent and possibly sending Basic authentication headers and we are investigating but that’s not an ideal solution as its not seamless.

        The other issue is Domino returning a HTTP 200 and a form for session based authentication – even on failure. We ideally need a way to turn that off and handle authentication failures ourselves.

        I am currently converting the result into JSON (http://www.markbarton.com/?p=314) and then using HTTP interceptors in AngularJS to look for these errors as a way round it.

      • @Richard, @Mark, we do exactly the same thing, SPA application all data GET, POSTs are json (I’m using jackson to convert json to and from back end models). Since the back end and front end are completely decoupled, moving to a new back end (Domino to SQL) was pretty straight forward. I have been using Angular.js for the last 6 or so months, developing the front end used test driven development plus jasmine, and all the “services” were mocked, so didn’t even need a back end. We have a SPA app that’s been in production for a couple of years now: DOM manipulation and callback spaghetti. Ember, Angular, etc., really make the whole process pleasurable…and testable.

      • @Mark, @Nick. I have not looked into Angular.js too much. I created my own data-binding library using Dojo may look at it again. Can Angular.js control the existence of DOM elements on the page?

      • Richard, AngularJS has 2 way data binding between the Scope Model and the DOM elements often described in blogs as ‘magic’ 😉

        Doing things like repeats / hide whens are fully automatic – imagine you make HTTP Request, you get given the JSON data and then you assign it to the scope model,assuming your DOM elements are bound to the model which is done through declarative syntax, then it will automatically update the display. Its very clean and readable.

        So a controller function would look something like this:

        //Controllers
        demo.controller(“viewController”, function ($scope, $http) {

        //My model is here
        $scope.task={};

        //HTTP GET Method to get View Data
        $scope.getData=function(){
        $http({
        method: ‘GET’,
        url: “http://192.168.1.30/RESTTest.nsf/test.xsp”
        }).
        success(function (data, status) {
        //Update the model
        $scope.task=data;

        }).
        error(function (data, status) {
        //Error log it

        });
        }
        })

        Your front end could look like this – the ng- tags are AngularJS directives that come with the framework, you can create your own:

        Assuming your REST endpoint returns {“myTitle”:”TEST”,”myDataItem”:”TEST”}

        As its 2 way this works nicely the other way if you bind your form inputs to the scope model you can then just post the model as is (no collecting all the values and serialising the form etc).

        It gets even better when you start using realtime libraries in the client – suddenly you have Pub / Sub data being automatically updated in the browser without you having to do anything other than wire it up – checkout GoInstant / Firebase for an example.

      • @Richard. Angular.js, Ember etc are awesome. You never manipulate the DOM again. Everything is in the “controller”. I actually have a: service\ (my)controller\ (angular) controller.

        I could talk about this for a while, but I’ll let some much more qualified people do that, here are some starters…
        http://www.ng-newsletter.com/posts/how-to-learn-angular.html
        http://www.thinkster.io/pick/GtaQ0oMGIl/a-better-way-to-learn-angularjs

        I also have this book:
        http://www.packtpub.com/angularjs-web-application-development/book

        There are stacks of modules out there:
        http://ngmodules.org/
        angular-ui
        once.js (great for performance, one way binding)..
        calendars…everything.

        We have in production, what I like to think is a pretty complicated SPA app (it’s a health care app rolled out across the UK…running on Domino), but we started it a few years ago, before we knew of angular etc. and we hand cranked stacks of stuff oursleves…JS code bloat, ugh. So much DOM manipulation and sycning DOM and models. We could dramatically reduce code and increase testability using these frameworks. You can unit test just about everything: directives, filters, models, services, controllers, etc. Awesome.

      • I would also encourage people interested in front-end development to check out libraries like AngularJS and consider separating your front-end and back-end logic completely. IMHO this is where web development is heading – complete separation of front-end and back end. That way your front end can be html + css + javascript for browsers, or native app for android / iOS and they all talk to a common API on your server.

        I think the world of tightly coupled front & back end, of sever generated web pages, is going to become less common / more niche. I think this is true whether you are looking at classic Domino, X-Pages, PHP or .Net.

        Yes – a full stack app can have advantages but separation of duties can provide significantly easier testing and deployment, and the ability to consume and combine information from multiple sources as appropriate.

      • I agree. However, the separation of the front-end and backend brings a development process that many classical Notes developers are not used to. Since they are separate, they mostly likely will involve separate teams of developers. The mindset of a front-end developer is different than the mindset of a back-end developer. This requires better project management, organizational process, and planning during the development process.

12. “Beginner XPage developers need to learn Java / Everyone should learn Java”

    I’m not sure who’s saying that, but that’s the road to madness. If you know Java, great, go straight to beans and skip over SSJS. If you don’t, then trying to learn XPages and Java at the same time is suicide, because you won’t have the requisite knowledge to work out where your problems lie. It’s the advice I’ve always given when speaking to new XPages devs at conferences or mentoring. And as if you needed any evidence on that, look at the OpenNTF Domino API. Virtually everything is available from SSJS and in the demo application there are examples for SSJS directly alongside the Java ones. That’s also why I put a huge amount of effort into XPages OpenLog Logger, to ensure it’s specifically designed to work from SSJS as well as Java.

    But that’s also why I’ll agree learning JavaScript is critical to XPages development for anyone who doesn’t know Java: because the syntax of SSJS is based on the syntax of JavaScript. If you’re not comfortable with the latter, you’ll be banging your head on the desk for the former. As an example, see what happens if you forget to declare a variable with “var”: the code fails with no explanation.

    I’d recommend at least a year of XPages expertise and then comes the decision point and where the second part of your statement comes in. If the vast majority of your code is written as CSJS, if you enjoy your chosen CSJS editor, if you’re happy with a black box of XPages components and libraries, if you’re using so little of things like Apache POI that SSJS is fine, if you’re happy copying and pasting whatever custom server-side code you want from database to database, if you never need to debug what’s happening in which lifecycle phase on the server, you don’t need to learn Java. You’re basically a front-end developer who just consumes back-end resources via things like REST.

    If at that point the majority of your code is written as SSJS, you should definitely learn Java. SSJS is a stepping point, a familiar touchstone for a new world that’s not. You’re clearly a back-end developer, more comfortable with server-side than client-side. Separation is a good thing, but not a reason to learn Java. Performance is a bit better, but IBM have put considerable effort into improving performance of SSJS compared to Java with caching, so that’s not a reason to learn Java. The reasons to learn Java are quicker and easier development (the editor just makes things much more enjoyable), easier consuming of standard frameworks (including SBT), easier debugging, reusability by moving code beyond the NSF, and taking advantage of things like DOTS.

    The one thing no XPages developer should do is stay coding mainly in SSJS.

    On the order, personally I’d move XML virtually to the top of the list. You need to understand the basics of it to work in the source pane, and if you just stay in the Design pane, it’s making life difficult. I’d move the XSP package almost to the bottom of the list. Other than XSP.partialRefreshGet() and XSP.partialRefreshPost(), there’s not much I have ever used. I’d also move JSF lifecycle up quite a bit. I cover it in any basic training I run because, unless you’re coding solely in CSJS, sooner or later you’ll hit a problem that’s caused by your lack of understanding. Because you’ll see a partial refresh as a call where your server-side code runs rather than a series of events where server-side code runs, some of which may or may not be the server-side code you’ve written!

    Reply

13. I consider myself an experienced XPages developer and I do not use much Java. Its not that I don’t want to, but I don’t have the time to dive in and start incorporating it into my applications. I know I need to do it, but I am the only production support and on-staff developer for my organization. I have to solve problems as quickly as I can so I can move on to the next project or support issue. I am sure there are problems that would be easily solved with Java and I absolutely want to develop that skill, but the real work wins every time.

    New XPages developers may not be 100% dedicated to just development. If that’s the case, they need to be able to solve problems as quickly as possible and as best as they can with the skills they already have or can easily develop and build upon.

    I would agree with both Pauls that you need to pick the right tool for the job and develop it in a way that you or your colleagues can easily support it in the future.

    Reply

    • Great point, Abby… I’ve always been in smaller development environments where the people who might be available to touch an app (either Notes or SharePoint) could be counted on less than one hand. If there are two people on a team supporting (all) the applications, then it’s a good idea that both of them be at least semi-comfortable with maintaining each others’ code. If one person is relatively new or tends to use one tool set, then having someone else who can code elegant masterpieces using state-of-the-art language techniques that take advantage of a personally-built API that shields them from having to use three lines of code instead of one… not a great situation, in my opinion.

      Ultimately, it’s about building business solutions that can be maintained by more than one person or be maintained by someone with a “reasonable” level of experience (I realize that “reasonable” is open to interpretation). Letting a code guru or prima donna loose in your environment so they can build self-congratulatory technical masterpieces is nearly as bad as having someone try to use @formula to do everything (while actively avoiding LotusScript, JavaScript, Java, XPages, and anything else IBM or the community comes up with).

      Reply

14. I’ll give you this Marky: You sure know how to throw a party!

    Reply

15. […] week, after reading the tempest of comments generated by Marky Roden’s post, I changed the title of  LWOXP […]

    Reply

16. Nice article !
    As a seasoned Domino developer, I have limited experience twith XPages but seemed to get on with it quite well. My first project was a combination of Java (using managed beans) and SSJS. My thoughts were that each offer great functionality, some things being easier to access in one more than the other – eg @Functions in SSJS vs. something more wordy that does the same thing in Java. Saying that, doing these things in Java isn’t too hard.

    However one point where Java won hands down is the compiler and IDE. Immediate syntax and reference checking- it won’t let you get away with anything, and fills your code with warnings or errors if you’ve mistyped something or forgot to include a library, or generally got it wrong somewhere. It also makes you think about how you structure your code more by insisting that everythig is a class.
    Whereas SSJS just allows you to save pretty much any old code and you only find out whether it works with a massive and slightly unhelpful error dump as the SSJS runs.

    I ended up using SSJS for front-end things like testing @UserRoles to see whether people should see various buttons etc, and Java for the more backend stuff like getting/updating the relevant profile document.

    I’d utterly agree “you don’t have to learn java to use xpages” but that, for me, was one of the big advantages of usging Java.

    Reply

17. In case anyone is interested I responded to this post via NotesIn9: 141. “Java vs JavaScript Throwdown”. http://notesin9.com/index.php/2014/03/31/notesin9-141-java-vs-javascript-throwdown/

    Reply

    • Priceless! Thanks David

      Reply

18. I think you should ask the newbies what they want to do in the future. If they are commited to Domino, then do SSJS, but they won’t have a chance getting any real J2EE job in the future. If it is just their first job, and they wish to switch to J2EE in the future, at least give them a chance practicing Java?

    Reply

19. Great post Marky. I can understand many of you point, but I respectfully disagree. I posted a more detailed response about 18 months ago on learningXPages.com. 😉

    http://www.learningxpages.com/blog.nsf/dx/10112012091912AMDOLHML.htm

    Reply

    • Oh I remember that well 🙂

      And I respectfully disagreed with it *grins* thanks for the link reminder that is an excellent addition to the discussion 🙂

      Reply

20. Hey Mark
    I’ve been developing great xpage apps thus far WITHOUT Java.
    But I do believe that if I learn Java along the way (as I am trying), I will become even more competent as a developer.
    Hence, I think its a personal choice to learn java. I do not think that Java will greatly improve my applications at all, (at least not by a large margin).
    It will be good to know Java for the future as Java is not dead. There are many many many jobs/contracts for Java developers, not much for XPAges. (at least not at the moment)
    Java makes sense from a mobile development as well!
    My 2 cents worth 😉

    Reply

21. Marky, well done … who woulda thunk that it would be you to excite the community in this way … 😉

    Since I am a partner at TLCC and we do offer several XPages courses I did feel compelled to add my 2 cents to this discussion, so for anyone who cares, I share the opinion of the other two Paul’s ( does that make us the three Paul’s now? I’m clearly trading up for skills reputation 🙂

    Both Java and JavaScript are integral and critical to XPages development and “Developers need to learn how to use the RIGHT TOOL for the job” … I agree with many here that you should learn both … for me, its just a question of the order of developing these two skills. You should learn JavaScript first because you WILL be using this initially, and you CAN develop a great XPages application “without a stitch of Java”. In fact, if you are part of a development team and you have a Java-buddy you may never need to become a full-on Java developer, but you do still want to understand its strengths and to leverage those in your XPages applications.

    If you don’t have a Java-buddy you may want to add Java to your skills toolbox. And when you do that I also recommend you take a bit of time to add the Expression Language (EL) as well. You can learn and master EL in less than a day and its a really handy and efficient language for data binding, working with scoped variables, and setting and getting properties in JavaBeans and Managed Beans.

    (This next paragraph may read like an advertisement for our courses, so look away if that offends you, but I think it is relevant to this discussion and reflective of my opinions on what to learn and when).

    We have an XPages Skill Path at our site (http://tlcc.com/admin/tlccsite.nsf/pages/Xpagedev9skillpath) which maps our courses to the skills you want to develop. As pre-req skills we offer courses to learn Notes application development and the back-end Domino Object Model (via LotusScript or via Java agents). Prior to our first XPages Development 1 course we also recommend JavaScript as a pre-req, so yes, we recommend JavaScript first. We have two Java for XPages courses that are recommended later in the skills path. We cover EL in our Java 2 for XPages course.

    Reply

22. Nice article Mark.

    It’s Horses for Courses. You can run the same horse on very course but your chances of winning are not good. You are doing the horse and yourself no good. both are working harder than they should.

    Having multi horses ensures you have the best chance of winning on every course.

    Javascript and Java are two essential horses that every xpages (or should I say web developer) should have in their arsenal to ensure success with every client.

    I think both Java and javascript are equaly important, and all xpages developer should have a working knowledge or or at least a good apprecation of Java to ensure they are not making life too hard for themselves by restricting their development to soley javascript.

    It’s the same old argument of @formula vs LotusScript. As we both know sometimes one line of @formula is equivalent to hundred of lines of LotusScript. Same applies with java.

    Reply

    • Interesting perspective mate 🙂

      I don’t think it is a race though – to me is more analogous to building a store front.

      Unless someone walks through your door you will never sell anything 🙂

      Reply

    • I’ve been doing XPages development for about two years and I’ve rarely needed to use my Java knowledge. It may not be the fastest pages, but one can certainly get by without Java. On the other hand, if you can’t grok Javascript or CSS, you’re quite handicapped.

      By the way, I’d love to see a one-line formula and the 100 or hundreds lines of LotusScript that it replaces. I can imagine replacing a dozen lines of LotusScript with a single line of formula language, but since I know I could co-opt that by just using Evaluate, it loses a lot of its impact.

      Reply

23. I am not sure where I stand. I would say I prefer Javascript above Java, mainly because there is little study material on writing cool, rock solid apps with Java & XPages on developerWorks.

    Where are all the cool, heroic & exciting stories about using Domino REST api’s + Angular.js + XPages?

    Reply

    • Patience my friend 🙂

      Reply

      • Patience.. doesn’t work so well for me 🙂

24. […] again, let’s not kid ourselves, we all know Marky’s preferred language of choice (*coughs politely*). But I want to properly wrap my head around IBM Social Business Toolkit, and not just learn the […]

    Reply