SSJS is a crutch
Category
There's another style of question that, quite frankly, concerns me. With apologies to those who I'm calling out here, what inspired me to finally publish this post is that lately I've noticed quite a few with a similar theme:
What I consider to be common about all of these is an understandable, but limiting, mindset: "I want to do new things, but somehow keep doing them the way I did the old things." If you happen to believe this is an effective approach, I recommend a personal experiment: surround yourself entirely with people you've known since childhood, and then try to grow as an individual.
While I don't have direct, personal knowledge of why @Transform was added to Notes just over a decade ago, it's probably safe to assume that it's because somebody at IBM acknowledged that what it does was already trivial to accomplish in languages in common use outside of the Notes and Domino world. I want to stress that a bit: list manipulation was already trivial in most languages more than a decade ago. Formula was lacking because achieving the same result had always required comparative hacks. Many of us were aware of this difficulty, but weren't aware that it was atypical, because we weren't using those other languages. So now that our beloved platform has evolved to center around some of those other languages, it's quite natural to want to continue using @Transform, because we didn't know everyone else already had a better way. The same is true of @For, @While, and several other bolt-ons that seemed magical to us when they arrived in Notes, but in actuality were bastardizations of patterns that everyone else just takes for granted.
Continuing to use Formula language within SSJS, therefore, is a crutch. I don't even mean that in a pejorative sense; it's a direct metaphor. We have muscles that are aching to do the work they're designed to do, but those muscles will never become strong if we cling to a tool that essentially performs the same function, but in a comparatively clumsy manner.
Another example of this, however, is when we either try to convince SSJS to be LotusScript, or punt entirely and spin up Agent Manager on every document save in order to keep using outdated code... or, worse, continue to write new code in a language that is, syntactically, nearly identical to Visual Basic 3 (circa 1993) and unlikely to ever again receive significant updates. I can sympathize with the argument that it can be difficult to justify manually refactoring large amounts of LotusScript in Java, especially if the existing code already "works", but only because I've made that argument myself in the past. I only hear that argument now from those who haven't actually done it yet. In my direct, personal experience, those who have made this investment have all had two common experiences: it's not as time consuming as they anticipated, and once they've made the switch, they don't want to go back. Buyer's remorse simply does not occur; at least, again, not in my experience.
How is this possible? Because if your destination language is Java, there's nothing in LotusScript -- or Formula, for that matter -- to miss.
Yes, if you port all your LotusScript to SSJS, of course you're going to be frequently annoyed that JavaScript's error management is sorely lacking compared to LotusScript's. But compared to LotusScript, Java's error management is magnificent.
You're bound to be occasionally annoyed that SSJS is a language primarily devoid of type safety executed in an environment where it tries to maintain type safety anyway. Java does not have this problem.
The SSJS editor can't reliably warn you that you misspelled a variable or function name, so you won't find out until runtime. Java does not have this problem.
I have a theory. I believe that IBM implemented SSJS as a transitional language. I don't believe they did this consciously, although it honestly wouldn't surprise me if that were the case. The evolution of the platform, the projects shared by IBM on OpenNTF, and the conference sessions I've recently attended all point to an increase in the significance of the role of Java within XPages itself as well as the broader IBM software portfolio. This actually mirrors what I've witnessed in my own development and that of the developers I know who have been developing XPages the longest: more and more code that would have been, or used to be, SSJS is instead now being written in Java. Anyone who is now writing the bulk of their code in SSJS is transitioning to Java, even if they don't yet realize it. The trouble with deploying transitional code, of course, is that you must support it. This is why SSJS is also a crutch: if you've ever dreaded converting your LotusScript, but then convert it to SSJS, you'll dread converting it to Java. That's simply inevitable.
So skip SSJS. Just learn Java.
Sure, you'll occasionally write quick SSJS evaluations in isolated component attributes because it doesn't make sense to spin up an entire Java class just to handle that simple expression. But complex business logic? Just tear off the Band-Aid. At some point, you will eventually want to refactor that code in Java. So do it now. Save yourself pain and your employer money.
I have a decent comfort level in about a half dozen programming languages, but I only speak one. So, having never learned a foreign language, I literally cannot speak from experience. But I always hear that there is no substitute for immersion. When learning a new programming language, I've certainly found that to be true. And I can vividly remember being not only hesitant, but terrified, of making the switch to Java. If you look hard enough, you can find evidence of that terror on this very blog. What removed that terror was, plain and simple, immersion. I chose a project (well, okay, Nathan chose it for me), bit the bullet, and just dove right in. That was over four years ago, so I frequently now forget that Java wasn't always my favorite language. I don't miss LotusScript at all. And I certainly don't miss relying on SSJS to define my business logic. I set that crutch aside long ago... and I hope, in the coming months, to provide those of you with a similar career focus both inspiration and assistance in doing the same.
<disclaimer>
I've been debating for quite a while whether I should write this post. It obviously makes a potentially controversial statement. A fellow developer who knew I was drafting it put my hesitance into perspective: "you really want to be that guy?" This was my response:
I want to be the guy who saves people pain. But sometimes to do that, you have to tell your friend if she wants to stop being punched in the face, she needs to leave the guy who keeps punching her in the face.
This post is just about making short-term programming decisions that have long-term benefits, so obviously the above is hyperbole. But that's where I'm coming from: a lot of you won't want to hear what's coming, but to the best of my knowledge this is the truth, awkward or unpleasant as it might perhaps seem. I'm making this statement only because I firmly believe that any Domino developer who takes it to heart will at some point be relieved in retrospect.
</disclaimer>
As I've occasionally mentioned, I spend a bit of time each week on stackoverflow. This is partly selfless: I enjoy helping people. It's partly selfish: the more successful we all are at developing XPage applications, the more the market realizes the platform's potential, which makes it easier for me to keep a job without having to drastically alter my career path. The bulk of the questions I notice on the site are indicative of someone embracing the platform but struggling with a specific aspect of it. That's a natural part of the learning curve, and it's great that they have a place to go for assistance with overcoming those obstacles.There's another style of question that, quite frankly, concerns me. With apologies to those who I'm calling out here, what inspired me to finally publish this post is that lately I've noticed quite a few with a similar theme:
- Lotus Notes - @Transform - Workaround available for XPages?
- SSJS equivalent of LSI_Info from LotusScript
- agent.runWithDocumentContext(document) retrieve document “body” field
- Calling Java agent from LotusScript in XPages upload
- How to use IBM SBT in background LotusScript code
What I consider to be common about all of these is an understandable, but limiting, mindset: "I want to do new things, but somehow keep doing them the way I did the old things." If you happen to believe this is an effective approach, I recommend a personal experiment: surround yourself entirely with people you've known since childhood, and then try to grow as an individual.
While I don't have direct, personal knowledge of why @Transform was added to Notes just over a decade ago, it's probably safe to assume that it's because somebody at IBM acknowledged that what it does was already trivial to accomplish in languages in common use outside of the Notes and Domino world. I want to stress that a bit: list manipulation was already trivial in most languages more than a decade ago. Formula was lacking because achieving the same result had always required comparative hacks. Many of us were aware of this difficulty, but weren't aware that it was atypical, because we weren't using those other languages. So now that our beloved platform has evolved to center around some of those other languages, it's quite natural to want to continue using @Transform, because we didn't know everyone else already had a better way. The same is true of @For, @While, and several other bolt-ons that seemed magical to us when they arrived in Notes, but in actuality were bastardizations of patterns that everyone else just takes for granted.
Continuing to use Formula language within SSJS, therefore, is a crutch. I don't even mean that in a pejorative sense; it's a direct metaphor. We have muscles that are aching to do the work they're designed to do, but those muscles will never become strong if we cling to a tool that essentially performs the same function, but in a comparatively clumsy manner.
Another example of this, however, is when we either try to convince SSJS to be LotusScript, or punt entirely and spin up Agent Manager on every document save in order to keep using outdated code... or, worse, continue to write new code in a language that is, syntactically, nearly identical to Visual Basic 3 (circa 1993) and unlikely to ever again receive significant updates. I can sympathize with the argument that it can be difficult to justify manually refactoring large amounts of LotusScript in Java, especially if the existing code already "works", but only because I've made that argument myself in the past. I only hear that argument now from those who haven't actually done it yet. In my direct, personal experience, those who have made this investment have all had two common experiences: it's not as time consuming as they anticipated, and once they've made the switch, they don't want to go back. Buyer's remorse simply does not occur; at least, again, not in my experience.
How is this possible? Because if your destination language is Java, there's nothing in LotusScript -- or Formula, for that matter -- to miss.
Yes, if you port all your LotusScript to SSJS, of course you're going to be frequently annoyed that JavaScript's error management is sorely lacking compared to LotusScript's. But compared to LotusScript, Java's error management is magnificent.
You're bound to be occasionally annoyed that SSJS is a language primarily devoid of type safety executed in an environment where it tries to maintain type safety anyway. Java does not have this problem.
The SSJS editor can't reliably warn you that you misspelled a variable or function name, so you won't find out until runtime. Java does not have this problem.
I have a theory. I believe that IBM implemented SSJS as a transitional language. I don't believe they did this consciously, although it honestly wouldn't surprise me if that were the case. The evolution of the platform, the projects shared by IBM on OpenNTF, and the conference sessions I've recently attended all point to an increase in the significance of the role of Java within XPages itself as well as the broader IBM software portfolio. This actually mirrors what I've witnessed in my own development and that of the developers I know who have been developing XPages the longest: more and more code that would have been, or used to be, SSJS is instead now being written in Java. Anyone who is now writing the bulk of their code in SSJS is transitioning to Java, even if they don't yet realize it. The trouble with deploying transitional code, of course, is that you must support it. This is why SSJS is also a crutch: if you've ever dreaded converting your LotusScript, but then convert it to SSJS, you'll dread converting it to Java. That's simply inevitable.
So skip SSJS. Just learn Java.
Sure, you'll occasionally write quick SSJS evaluations in isolated component attributes because it doesn't make sense to spin up an entire Java class just to handle that simple expression. But complex business logic? Just tear off the Band-Aid. At some point, you will eventually want to refactor that code in Java. So do it now. Save yourself pain and your employer money.
I have a decent comfort level in about a half dozen programming languages, but I only speak one. So, having never learned a foreign language, I literally cannot speak from experience. But I always hear that there is no substitute for immersion. When learning a new programming language, I've certainly found that to be true. And I can vividly remember being not only hesitant, but terrified, of making the switch to Java. If you look hard enough, you can find evidence of that terror on this very blog. What removed that terror was, plain and simple, immersion. I chose a project (well, okay, Nathan chose it for me), bit the bullet, and just dove right in. That was over four years ago, so I frequently now forget that Java wasn't always my favorite language. I don't miss LotusScript at all. And I certainly don't miss relying on SSJS to define my business logic. I set that crutch aside long ago... and I hope, in the coming months, to provide those of you with a similar career focus both inspiration and assistance in doing the same.
Comments
Where I tried using it, I soon got issues calling Java code from SSJS, for example because there are Java strings and JavaScript strings and the automatic conversion does not always work as expected.
We have agent.runOnDocumentContext() in some areas of our frameworks as an optional feature, for cases where apps should be run in parallel on the Notes Client and the web. I'm always telling the customers and partners to convert their code from LS to Java and not to use that agent call, but not everybody listens to me
As discussed recently on David Leedy's blog ( { Link } ), I also have left classic XPages development behind for many apps and only use XAgent to generate the UI and provide REST services (or write the whole app as a set of OSGi plugins). Using REST services feels just so much better in order to separate UI and backend logic, but that's a topic for another post.
Posted by Karsten Lehmann At 01:59:01 AM On 02/23/2013 | - Website - |
Posted by Roy Rumaner At 02:04:28 AM On 02/23/2013 | - Website - |
I try to avoid as many SSJS as possible. From the start of XPages I couldn't get SSJS. It is NOT CSJS or Java or Formula language. Just, to me, a weird mixed language I could not get a hold on.
So to Java is for the calculation and other tasks in XPages. I managed that by using controller java classes attached to an XPage.
I noticed that some co-workers has some troubles to get the concept of Java and the seperation of logic and presentation. They always try to calculate everything in computed text.
I keep telling them what you stated at your UKLUG session last year. SSJS is plain text and it will be tried to rendered to Java. So why not write it in Java from the start. Its faster and better controlable in my opinion.
So keep on going with evangelise the Java in stead of SSJS message.
I will do it also. So I planned a Java introduction and Java Deep Dive session for all my IBM Devs in my company.
I also created a XPages Kickstart Framework, my co-workers can check out of Source Control in their database to get a head start and an example how to use Java in XPages development
Posted by Frank van der Linden At 02:05:51 AM On 02/23/2013 | - Website - |
Now I'm a happy camper as I can write only in Java. It gives me so much more power and flexibility than LS/Formula. For sure, there is still a rest of those languages used in UI operations for forms, views, buttons, but that never was a place for us to place business logic in.
Having the maturity of Domino with all it's benefits (security, robustness, flexibility etc.) combined with the power of Java gives me a _real_ comfortable level for saying that Domino is a platform with future.
The switch has only one "caveat" for me (well, depends on the personal point of view): I'm using Domino Designer quite rarely. Only when I have to make changes to UI elements. Sometimes I miss it. And then I'm back in Eclipse. We'll hopefully see DD as a plug-in for vanilla Eclipse in the future - bringing my old home into my new home.
Posted by René Winkelmeyer At 02:26:04 AM On 02/23/2013 | - Website - |
Also thank you IBM for reaching out for us with educational material.
NOT
Posted by Patrick Kwinten At 04:09:01 AM On 02/23/2013 | - Website - |
Posted by Thimo Jansen At 05:08:57 AM On 02/23/2013 | - Website - |
Posted by Martin Jinoch At 05:10:33 AM On 02/23/2013 | - Website - |
re the "blur" - IBM was in a tough spot. Many will remember the fuss there was a few years ago about the impression that IBM was going to push developers towards using Java.
Many developers are realising that Java is the way forward for much of their xpages code but to have imposed Java from day 1 would have killed XPages.
There are those ( many ? it is hard to tell ) that would love to seperate XPages out from Notes. Things like the old version of Eclipse in DDE are an issue - maybe not now but can you imagine still having the same version of eclipe in 5 years time and missing the newest source control plug-ins etc.
IBMs backward compatability over 20 years has been its biggest strength IMHO but it is also a huge impediment to progress.
I am not offering a solution - I don't know what the right answer would be.
Posted by Sean Cull At 07:40:49 AM On 02/23/2013 | - Website - |
Great post. I couldn't agree with you more. In fact this topic was pretty much my presentation at IBM Connect. XPages Development: Modernize Yourself!
1 of my goals there was to try and convince people that not only is Java the destination, but it's also nothing to be afraid of. This is not to say you can't build XPages applications with SSJS alone, but if you stop there it's like building a notes client app with only formula and not using LotusScript. Your just limiting yourself from what you can do.
If anyone is interested I recorded my Connect session for NotesIn9. It ran a little long but it's available here: { Link }
Posted by David Leedy At 08:28:56 AM On 02/23/2013 | - Website - |
But I must disagree on one point. Your comment that there's nothing in LotusScript or Formula Language to miss. There are two big things I miss.
The first is decent recycling or checking, so identifying if a Domino object has been recycled is an absolute mess. I wish IBM would address that.
The other is @Right or strRight or even basic string comparisons. The base Java classes are a beta implementation with no way to get what's right of a string within another string and the need to test for both null and empty strings. StringUtils class in apache.commons.lang are a blessed relief, but the Java policy in Domino that doesn't allow these to work if they use the standard ClassLoader frustrates me.
These are frustrations, but are outweighed by the benefits of Java. When I was looking at importing from CSV, I searched the web and found a Java class for it. Basically, if you want to do something in Java and it's not specifically Domino, someone's probably done it. Those resources will *never* be available in SSJS. So learn Java because sooner or later you will do. So it's better to do it sooner.
Posted by Paul Withers At 09:14:36 AM On 02/23/2013 | - Website - |
Java is a pretty mediocre language in an absolute sense (though the JVM transcends it), but it's far and away the best choice for Domino development currently. There's no question that all Domino developers should be aiming to use Java for almost all of their server-side programming (the rest should be XSP/EL and pure formula language). It's the natural language of the XPages environment and using it makes you understand much more why it works the way it does - and, as a bonus, you'll end up much more productive writing significant code in it than in LS or SSJS.
PS - I actually really love @Transform (but not @For and @While - they feel wrong). I think it's because, if you squint really, really hard, it makes formula language start looking a little like Lisp.
Posted by Jesse Gallagher At 10:02:24 AM On 02/23/2013 | - Website - |
The problem I have with this stance (and all the good folks who commented on it in whole hearted agreement) is the message it sends to developers who have NOT started with XPages ( and from my experience there is still quite a few).
So now all of the "established" and revered folks in the community such as yourself are advocating trying to learn to develop in XPages without first learning the basics of SSJS and STARTING with JAVA.
This quite frankly intimidates the holy heck out of developers. They already know they have to learn something new and now all the people they have come to trust and respect are telling them best way to do something that is simply going cause significant frustration as it doesn't make sense to build anything and IGNORE one of the tools in your toolbox.
So if the ONLY tool in your toolbox is a Hammer, then every solution looks like a nail !!!!
So if the ONLY tool you use in your toolbox is JAVA, then everything becomes a JAVA solution regardless if that is best or not.
SSJS has it's place. It's a tool in your toolbox. And if you don't learn how to use that tool when building XPages applications then you are doing yourself, your customers and your employers a disservice.
Finally a reminder. You Tim as well as everyone who commented (with the exception of Karsten ) used SSJS in all of their FIRST XPage development projects. So were all of those applications CRAP ?? No. They met the needs of the folks that paid you to develop them, and they performed adequately enough that they made their way into production.
After coding with XPages and SSJS for a while did you learn better techniques and find opportunities for using Java instead? Yes. But what you learned during that process was invaluable. And as much as we would like too, we as existing XPage developers can not and should not take that experience away from those coming along behind us by advocating that SSJS is not worth taking some of their time and effort to figure out. So from my perspective SSJS is a BRIDGE and not a crutch. If we advocate blowing up the bridge it will just be that much harder to get folks over to where we already are.
Finally, based upon my stance here, one could assume I am NOT an advocate of learning Java. So let me just say that I have been SCREAMING INTO THE ABYSS for over 15 years for Domino developers to learn Java. It's a VERY IMPORTANT TOOL in their toolbox. It's just not the ONLY tool.
So existing Domino developers have a LOT to learn in transitioning to XPages. Lets not scare them off even getting started
Posted by Paul T. Calhoun At 10:14:38 AM On 02/23/2013 | - Website - |
I agree with what Sean mentioned; ssjs is absolutely necessary for the platform. There are a certain amount of users who have no intention of learning java. Had xpages not supported some form of server side scripting capabilities it would have been DOA as a technology.
Great post Tim, very interesting topic and points!
Posted by Dan O'Connor At 10:24:47 AM On 02/23/2013 | - Website - |
SSJS is really kind of neat, and I would argue that it's a low-hanging tempting fruit for new devs "oh, it's just JS? I can do JS...."
For any significant new development however, yes, you should just bite the bullet and go Java.
Though I am definitely not going to push people to rewrite large LS backend logic libraries in Java due to the .recycle() mess. There's business cases to do it, and business cases not to.
Posted by Erik Brooks At 10:47:21 AM On 02/23/2013 | - Website - |
Tools in the toolbox.
Posted by Erik Brooks At 10:55:02 AM On 02/23/2013 | - Website - |
I think one of the things that it comes down to is that there are two approaches one may take to writing XPages apps.
One route, which unfortunately is the majority of cases, is "I have a big pile of old Notes code and my job is to do it in XPages now." When coming from this direction, SSJS may indeed be invaluable. The syntax is sort of familiar for client-JS developers, the aliased class names are pretty much like LS product classes, SSJS script libraries are analogous to function-based LS script libraries, and the mapping of UI to executable code is easy to understand in a Visual-Basic kind of way. Plus, Java looks difficult and the business about recycling (though it plays much the same role in SSJS) ironically makes people think you have to do memory management. It feels more comfortable, a bit more like classic Form-based development - as Dan mentioned, having a language in that niche was almost definitely required for XPages to go anywhere.
However, from the other route - "what is the best way to write an XPages application?" - SSJS doesn't fit. From this perspective, the best analogy is a PHP developer switching to Rails (or Node.JS, whatever framework Python uses now, etc.). They'll wonder how you just drop a script on the filesystem, "require_once" shared snippets of HTML/PHP, use mysql_query, and so forth, and the answer there is "you don't." You CAN do those things in one way or another, but you'll be fighting the platform and the result will be a mess. Similarly, the best way to write XPages apps is to structure your code into JVM classes and reference them via EL method and property bindings. Those classes won't always have to be written in Java, but SSJS is not a language that can do that (at least currently), and so it's disqualified.
Posted by Jesse Gallagher At 11:13:42 AM On 02/23/2013 | - Website - |
Posted by Steve Zavocki At 11:16:07 AM On 02/23/2013 | - Website - |
For some situations SSJS is enough, much like @formula can be enough. It fulfills its role as an introduction to Xpages very well.
For some developers, this is the learning method best suited to their style.
I suspect that many developers will not graduate far beyond SSJS simply because the situation doesn't arise for them, and SSJS can handle most if not all of their issues.
The upside is that they can go further with Java then they could have with Lotus script.
Posted by Wayne At 11:16:53 AM On 02/23/2013 | - Website - |
Posted by Thomas Duff At 11:26:16 AM On 02/23/2013 | - Website - |
Posted by At 12:00:24 PM On 02/23/2013 | - Website - |
You absolutely can use SSJS to make very good applications. And there's nothing wrong with that at all. I said in my session and I like to say that java should be your destination. Java is not the first stop though. Build your apps with SSJS but realize that in SSJS you are already using java objects. That's what scoped variables are. So I feel that the old notes developers stopped learning with lotusscript. They didn't learn java. And why should they? Just for agents? Not worth the effort. The big thing with XPages is to not stop learning with SSJS. You want to learn java and add that tool to your toolbox. And unlike client dev there's a huge payoff for you as you can use java in so many more places.
So I'd just summarize to anyone reading this... SSJS works. Use it. Learn it. But then start learning how to integrate java in. There are resources available and there are more on the way. It's worth your while to integrate it in to XPages and its worth knowing from a professional development standpoint as well. It's not that hard and nothing to be afraid off.
Posted by Davi Leedy At 12:59:47 PM On 02/23/2013 | - Website - |
Why do they do that? They're not lazy (mostly) and they're not stupid (mostly). I think, in most cases, Paul is completely right: they're intimidated. I think SSJS was deliberately included specifically to act as that BRIDGE he mentions. IBM had been trying to get Notes developers to move to Java for several years already, and for the most part they had failed miserably. When XPages came along, IBM was determined to keep as many of those traditional Notes developers as they could, while simultaneously opening up the platform to Java developers.
So while I take your point, Tim, about ripping off the bandaid (can't tell you how many times I've had that conversation with my daughter, to no avail by the way...), I would suggest that there are groups of developers for whom that makes sense and groups for whom it does not. If you've EVER written code in ANY language other than @Formula/LotusScript/JavaScript, then I think Tim's approach is dead on. If you've only EVER been a Notes developer (and are still not comfortable with object orientation), I think it makes more sense to use SSJS where it works well and reserve your stressful, scary Java exploration for those places where it is needed (in other words, don't kill yourself building incredibly complex workarounds, because that's just silly). The exposure to Java will come - it's ultimately a necessity - but it can come gradually. Some people need that. And I think IBM was smart to build that bridge for them. Sooner or later, they'll get off the bridge and immerse themselves.
Posted by Rob McDonagh At 01:38:11 PM On 02/23/2013 | - Website - |
My first xx apps used it exclusively but then I grew more comfortable with Lotuscript and was able to achieve more. After a while 80% of my code was in Lotuscript.
Formula still had its place but the most efficient and powerful option was Lotuscript.
Posted by Sean Cull At 01:39:07 PM On 02/23/2013 | - Website - |
But when I have a team of notes client developers and I have them starting to learn XPages they are struggling to understand CSS, JavaScript and web technologies. Asking them to learn Java as well would be suicidal.
If you are in this boat and you want to be a developer still in 10 years you will need to learn Java or perish on the pile of forgotten coders. Right now you do not need to learn Java though. You should focus on being a better web developer because your clients could not give a rats ass what the underlying code is - as long as it looks good and is easy to use.
Posted by mark roden At 02:32:16 PM On 02/23/2013 | - Website - |
As for SSJS itself, I tried to like it. The problem I have is that it is a really bad JS. It is not compliant with the current (or previous?) standard. Javascript is a living language. There is a next standard that all implementors must move toward to be relevant in the browser and on the server. Is XPages SSJS a dead implementation of a living language? Is that really better than a dead implementation of a dead language like Lotusscript?
I'm hoping that someone who likes to bring other JVM languages into XPages (JG?) looks at Nashorn. That would at least be a modern, compliant, fast (for JS) implementation.
It's good to know Java even if you later choose to use another JVM language. SSJS can be a stepping stone if you want to immerse yourself in XPages before immersing yourself in Java. I just wish the stepping stone wasn't already old, cracked and perhaps irreparable.
Posted by Dan Sickles At 03:01:41 PM On 02/23/2013 | - Website - |
If they have a JSF-223-compliant version that runs on Domino's JVM, then that's already done! { Link }
Posted by Jesse Gallagher At 03:17:37 PM On 02/23/2013 | - Website - |
{ Link }
Now, hack the parser to allow identifiers to start with '@'.
Posted by Dan Sickles At 03:25:37 PM On 02/23/2013 | - Website - |
So still writing a lot of Domino JSP markup that calls COM APIs to process data in NSFDB2, are we?
SSJS is like using a Leatherman to do auto repair. Java is like using a Snap-on US Set 6, except it's free instead of $36,000.
Posted by Nathan T. Freeman At 05:36:27 PM On 02/23/2013 | - Website - |
You say:
"Right now you do not need to learn Java though. You should focus on being a better web developer because your clients could not give a rats ass what the underlying code is - as long as it looks good and is easy to use."
I suggest that if you have the prettiest site that looks good but the backend data is unreliable then no one will give a Ferrets ass!
Web development is a 2 sided coin. Front end and back end. Yes you can write your backend in SSJS. But there are numerous advantages from performance, to debugging, to capability in using Java. Learning any new language makes you a better developer.
My only point in all this, is you should never ever stop learning. If you're working with XPages then you should have Java on your radar at some point. Don't just think SSJS is good enough. But that's not to say you shouldn't also learn more about Dojo and jQuery and CSS Framewords as the front end as of course extremely important.
Posted by David Leedy At 06:36:53 PM On 02/23/2013 | - Website - |
yeah he did :)
Posted by Mark Roden At 10:22:18 PM On 02/23/2013 | - Website - |
SSJS isn't JavaScript in the sense that most developers reasonably expect. If you're used to writing JavaScript, it's because you're used to writing for browsers, and you expect to have access to frameworks and persistent closure between operations. The nuances of SSJS make it a leaky abstraction.
Even if SSJS worked just liked JavaScript in V8, it wouldn't change the fact that as a loosely typed language with overly forgiving syntax rules, it's a lousy language. It's very easy to write bad code even in good engines for the language. Semicolons at the ends of lines are optional for Pete's sake!
BUT most Domino developers are coming from a LotusScript background, which means they only know BASIC. So moving to a quirky implementation of a crappy language spec is... well, exactly what they are already used to.
Perhaps it's daring and controversial to propose that instead of moving from one proprietary, finicky, novice language to a different proprietary, finicky, novice language for the business logic the runs your enterprise, you should instead move to a standardized, common, expert language. If you find that a questionable position, then maybe you should take a serious look at how you formulate priorities for your business or your customers.
SSJS isn't a crutch. It's a guy that breaks your kneecaps and then hands you crutches and says "ain't I great?"
Posted by Nathan T. Freeman At 11:43:54 PM On 02/23/2013 | - Website - |
... node.js is becoming rapidly a contender for a server platform champion and I wouldn't be surprised if a future version of Websphere supports it at execution option.
There are 3 parts to SSJS:
1) shortcomings in the editor (which is a shame) & debugging process
2) upgrade to support the latest language specifications for JS
3) the use of it per se
If 1 & 2 are resolved (I'm not implying they will be - not my call to make) then looking at #3 would be different than it is now. Until then BEANS are not only good for your caffeinated hot beverage.
Posted by Stephan H. Wissel At 10:36:32 PM On 02/24/2013 | - Website - |
Good post and a lot of valuable points in the comments too... As many people have mentioned here, SSJS is a good starting point for a typical Domino developer with LotusScript/Formula/Web experience to try the switching to XPages. Once you start some serious development, you will realize that, to get the full potential out of XPages, you need to switch to java and to some extend it comes naturally. When you first make the switch to XPages,the thought that we can write all our code including formula in "JavaScript" is very comforting. The pattern I have noticed is, the first XPages application will have heavy SSJS libraries with all your business logic written in it.. as you gain more experience, you realize that it is much easier to swicth some of this code to java and eventually move most of your code to java. But to write simple expressions and quick property computations, SSJS is an invaluable tool for the XPages developer. So it definitely has a place in the XPages application development.
Posted by Baiju Thomas At 08:55:03 AM On 02/25/2013 | - Website - |
@Paul, I'm going to have to correct you on one point: the first XPage projects I developed relied almost exclusively on Java, using SSJS only as an entry point for that Java. So most events looked something like this:
#{javascript:return com.acme.xsp.project.SomeBean.someMethodName();}
And that's only because I hadn't yet learned that this syntax can be replaced entirely with:
#{SomeBean.someMethodName}
...as long as SomeBean is previously defined, either as a managed bean or as a data context (or data source).
So that was the pattern for quite a few of my early apps. It was only later that I allowed more of my business logic to live in SSJS... and that was primarily due to customer feedback indicating that they were concerned they'd be able to support the code if it all lived in Java.
Which brings me to my second point. Yes, XPage developers absolutely need to grasp SSJS, for the same reasons that the most skilled LotusScript developers still need to know Formula language: because there are valid uses for it, but also because other developers will use it. Just as there have been times when I haven't been able to use Java because the developers I was writing with / for feared they would not be able to maintain that code, I would struggle to work with others' SSJS code if I didn't understand that language.
But I do feel that starting with Java, and then exploring SSJS is the best way to go. JavaScript as a language is extremely encouraging of bad programming habits. If you try to use JavaScript as a bridge to get to Java, you will struggle more when you get to Java. If you learn Java first, you will write better JavaScript when you shift your focus to that language.
But the point I want to emphasize as vehemently as I possibly can is that Java is only scary before you dive in. Sure, you'll have pet peeves with it. No language is perfect. But it's not scary. Yet you're exactly right: so many Notes / Domino developers are still frightened of it. Why? Because people keep telling them they should be.
Forgive the analogy, but if every time American consumers tune in to a news source they respect, they keep hearing how awful the economy is, a significant percentage of them are going to think they should cling to every dollar just in case. So they avoid buying anything they don't believe they absolutely need. So the companies they would otherwise be buying stuff from aren't making money. So they cut jobs. So now there are more people who can't buy stuff. So other companies start making less money. Vicious cycle.
So if every time someone encourages Domino developers to learn Java, they hear someone they respect jump in and say "don't tell them that, Java is scary", especially if it's someone that they know has Java experience, then of course they will continue to believe that there's something valid to be scared of. They'll continue to postpone learning. Which keeps the platform in a state where there is very little good Java code to learn from.
When I was originally learning LotusScript, I found that the examples in Designer Help were occasionally useful, but what made it far easier to learn the language was the availability of code already in use in real apps. I could reverse engineer it, to some extent: compare the code I saw to the behavior, and detect patterns. It was easy for me to learn that language because LotusScript already had critical mass. There was enough of it out there in the wild that I could just grab something that already worked, and tweak it until it did what I needed it to. After a few months of that, I could finally just start writing code from scratch, because I had gotten to a point where I was thinking in that language.
We're never going to hit critical mass with Java in Domino if we keep telling developers that Java is scary. Those of us who already know that it's not scary need to do whatever we can to provide digestible examples of how Java can actually make Domino development easier than attempting to accomplish the equivalent operations in inferior languages. That's one of my key goals for this year... I don't make New Year's resolutions, but if I did, this would probably be right at the top of the list.
Posted by Tim Tripcony At 10:38:05 AM On 02/25/2013 | - Website - |
Now forgive me while I reminisce... I started using Java with Domino a long time back, with agents. Not that I'm a brilliant programmer, but mainly because it allowed me to use somebody else's brilliant code to accomplish things not possible in LS.
Back in 2001, my customer was an advertising company that needed a website where their creatives could post their work in a secure way for their clients to view over the web, and they wanted the views to display thumbnail images of the full-sized graphics they had uploaded. Rose Kelliher's book on Domino Web Development had an example that used an open-source, Java image processing library (anyone ever heard of an image processing library in LS?), that I used to automatically re-size the images to thumbnails for this and wrapped in an HTML-based view. One of their biggest clients wanted the web site to have a left menu look like the expandable folders in Windows Explorer (which I likewise, borrowed from some DHTML I found on the web, and then I built it into a Domino view to make it dynamic). The cool thing was that their 'big client' was Microsoft. So, it always gave me much pleasure to know that Microsoft execs were looking at their ad mockups on a Domino server. Since then, I've used Java for a number of agent-based tasks, but it never comprised more than a small percentage of what I did.
Fast forward to the last few years where I've been learning and developing in XPages... Since the preponderance of XPages tutorials, books, and examples are in SSJS, that is what I have been using (even though I'm comfortable, although a bit rusty, with using Java).
Fortunately, a few souls have been raising the 'use Java for XPages' banner and more examples are appearing (like David L., Russ M., Jesse G., ...). Keep 'em coming. Even people like me, who aren't scared of Java, need to see more ideas, examples, and encouragement.
Posted by Don Mottolo At 02:31:27 PM On 02/25/2013 | - Website - |
Until there's a good tutorial for Domino Developers on Java in XPages, it's still a steep learning curve with a lot of things that *should* be easy and *are* easy in formula language or LS just plain obfuscated in Java. If you're trying to get your front-end XPage to even work and try to get your back-end Java work, and work out how to get a handle on scoped variables, especially if you don't have ExtLibUtils package available, it's a huge issue. And I still consider JavaDocs an abomination designed to keep Java developers in a job and disempower - they are abysmal when compared to LotusScript help. So your method expects a String, but is that "1", "Fred", "componentId", WHAT?! (rant over)
Having said all that, let's point out one *huge* strength of XPages, which Tim's covered before on his blog (I think): none of your business logic has to be on your XPage or Custom Control. It doesn't have to be coded by the same person. A Java developer or experienced XPages developer could write the Java, in managed beans or POJOs, and a new XPages developer just create the XPages using the relevant APIs provided by the Java developer. And it provides a good learning resource, because the new XPages developer knows what it should do from a business point-of-view and can work out what it's doing in the code. That method could considerably ease the learning curve.
Posted by Paul Withers At 07:54:36 AM On 02/26/2013 | - Website - |
It seems an old school design replace of the application results in the Java code not taking properly - in fact it normally needs a clean and rebuild on the production server.
We face a worse problem on a particularly busy Domino server which is serving a high traffic site. We have got to the point where we are considering a standalone bean server.
This can't be normal - so what are other people doing? As an aside is it possible to restart an OSGI plugin without restarting HTTP?
Posted by Mark Barton At 08:23:14 AM On 02/26/2013 | - Website - |
Yes, but it's a fairly obtuse set of osgi commands. I can't seem to get the install syntax just right, but it's something along the lines of...
tell http osgi stop com.yourcompany.yourpluginid
tell http osgi uninstall com.yourcompany.yourpluginid
tell http osgi install URL:com.yourcompany.yourpluginid.new.jar
tell http osgi start com.yourcompany.yourpluginid
I have no idea what this would do to currently running applications, though.
Posted by Nathan T. Freeman At 09:07:25 AM On 02/26/2013 | - Website - |
I agree with MOST of this article but firstly the title is wrong. SSJS is not really a crutch. IBM injecting Formula into SSJS is the crutch (and you do state this).
You can pretty much do the same thing in any language it's just that some are better at some things than others. There are some great SSJS engines out there (Node.js, Rhino etc) and the number of folks jumping from say, PHP, to these is reportedly high. The documentation and examples are also very good.
Java has it's place (and I'm a big advocate of that language) but there is definitely a place for SSJS (and other commenters make very good arguments for this).
I think a more pertinent point is the quality and maintainability of the code written, regardless of language. It really doesn't matter what language you use, if the code is not maintainable then eventually you will need to refactor/rewrite and this is where people start blaming languages rather than the author (In my opinion). Although, as I said at the start, having a mix of Formula doesn't help the situation as developers will fall back to it [or have I just blamed the language and not the author
Posted by Rich Sharpe At 12:15:06 PM On 02/26/2013 | - Website - |