I have tried to write this article multiple times over the last 2 years, when I read it back to myself it always sounds like I am bitching. Honestly, I usually am and that is why it has not been published. This is a final attempt at a constructive argument against the insistence on many blogs that everyone should learn Java.
Many people think I hate Java; I really don’t. I can program Java (I am no expert admittedly) and have done so on multiple occasions. My concerns are always raised when community members are insistent that everyone should learn Java. I do not believe that to be the case.
Since R4.5 Domino has been a web server – and the client side user experience has always been independent of that. The only decision to make them “tightly coupled” was that of the developer who chose to not venture beyond the bounds of the out of the box capabilities.
Just because no-one was championing client side development does not mean that it did not exist. I used IE5 <XML> islands back in 2003, pre-ajax, to make dynamic data loading views. I used jQuery in 2010, long before I experienced XPages. I have always considered myself a web developer. I am sure there are many others who do the same.
Here’s why a long long time ago one of my biggest projects failed. While it exceeded expectations of the customer and absolutely rocked on the server, the end users were never asked if they liked how it looked. It failed because people didn’t like the way it looked and it wasn’t used. It hurt. It really, really hurt. From that project forth I stopped putting the server first.
“Beginner XPage developers need to learn Java / Everyone should learn Java”
I shake my head every time I see this. It is an all out, complete, and utter fallacy. Below are my thoughts on some of the reasons touted for using Java and not SSJS:
- On low to medium volume document processing the time saving still insignificant compared to network latency and browser rendering speed. I have no numbers on this but in over two years XPages developer and 4 major projects dealing with <50,000 documents in a database. Speed of response from the SSJS code on the server has never been a concern.
- I recently worked on a database with over 1,000,000 records in it. Accessing and displaying data via SSJS using FTSearch was in the matter of 100s of milliseconds.
- We have SSJS code getting view entries by key and returning results on 250,000 records in less than 0.5 seconds
- As has been pointed out in the past, the server caches a large amount of frequently used SSJS code making it no slower than any Java equivalent
- Java is faster – Yes it is. But in my experience SSJS seems perfectly fast enough.
- n-tier architecture / Separation of UI and business logic layers
- When someone can demonstrate to be that they understand the UI they can lecture me about how they need to separate themselves from it. From my perspective it makes a back end developer’s life easier to separate themselves from the UI they don’t understand.
- It’s the future
- I guess that depends on your perspective. If you want to spend the rest of your development career developing WebSphere applications it might be. Either way it absolutely is not necessary for XPages development in the next 2 years
- Java can do things SSJS can’t
- Yes I agree, things like Apache POI, custom REST services or Plugin development – absolutely agree.
- Complex data processing of significant amounts of data (not a normal use-case for a notes database)
- Use the right tool for the right job🙂
- At this stage of the game anyone still resisting a move to XPages is not going to be encouraged by being told they need to learn Java – So please quantify your statements when you tell other community members “they must learn Java”. I think this is more appropriate – “Those of you with a solid understanding of XPages and the JSF lifecycle, who are wishing to take their server side programming skills to the next level, learn Java”
Beginner XPage developers have enough to learn as it is
XPages web developers (using XPages) need to have a solid understanding of these technologies to be successful – *In this order*
- Lotus Notes Object Model (assumed)
- Basic Programming
- External Libraries (jQuery, dojo)
- Unique Browser deviations from the ECMA standards (looking at you old IE)
- Unique browser deviations from the standards
- JSF Lifecycle
- Other things I have forgetten
- Because no customer ever said “This website looks like crap but the pages load so fast I am in love with it.
I understand everyone has their talents in different areas, but (and I can’t stress this enough), end users don’t care about the technology that makes a website work. End users are more forgiving of a beautiful website which is slightly slow, that a blazing fast, ugly, hard to use site. Ideally it would be beautiful *and* blazing fast but that is a whole separate discussion.
I am not saying using Java is wrong. I just want to temper the expectation that everyone *needs* to learn Java. In my opinion they don’t.
Let the comments blaze on…..
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.
Many thanks to Brad Balassaitis for proof-reading and bitchiness reduction assistance🙂