Using XPages For Websites. Good Idea?
Recently I had a request for a quote from a company who (desperately) needed their Domino-based website pulling in to the 21st century. They needed somebody to re-design the front-end and build a back-end CMS for it.
One of the things they asked me was:
Would you be using XPages?
My reply was along the lines of:
If you really want me to I could, but whether I would or not is something I'll get back to you on.
Nothing came of the project but it got me thinking nonetheless. Is using XPages for a public-facing website a good idea?
I'm still yet to use XPages in any real way but, based on what I do know about XPages, I've formed my own opinions on when they should be used and when they shouldn't.
XPages are fine for use in web-based applications but they'd be overkill and detrimental to performance for a standard website.
Websites should be fast. Especially so if SEO is of any importance.
Now, let's take the OpenNTF website as an example. As a website it's fairly standard. Noting special going on. Nothing that can't be done with plain ol' HTML and a moderate sprinkling of JavaScript here and there. Yet the website is a real heavyweight.
Taking a look at the site with Firebug's Page Speed plugin:
As you can see, there's 28 JavaScript files! Woh there! That's just plain bad practice. No website should ever use that many files without just cause. Clear your browser cache and load OpenNTF's website afresh. Because of the reliance on so much JavaScript you'll see a blank page for way longer than you really ought to.
Same goes for IQJam.net's and the number of CSS files:
Again, there's nothing going on there that one reasonably-sized CSS couldn't handle.
Apologies to Bruce et al. I'm not picking fault in what you're doing. It's just that yours are the first two XPage-based websites I could think of! That's a good thing, right?
It might be "ok" to have so many JavaScript/CSS files on an internal web-based application, but for a public website? Surely not. If it is ok it's only because it's entirely necessary, which, as far as I can tell, it's not in either of the above cases.
So, my question is twofold -- is it ever a good idea to use XPages for a standard website that happens to be Domino-based and (if so) is there a way to use XPages but without the bloat?
I know I've asked a similar question in the past but I still have no idea whether XPages is a good fit for a website. Next time I get asked to re-design a Domino website and am asked to use XPages I want to be able to reply with more confidence in my convictions.
It all makes me wonder. If XPages is the future of Domino then does that mean Domino has no future as a platform for normal websites?
Skip to the 
You can subscribe to an individual
Jake, the OpenNTF infrastructure has grown for 10 years and implemented by many different people who mostly have done this in their freetime. So the design is certainly not optimal.
As far as the many JavaScript files we can certainly reduce them. With Dojo you can create custom builds to combine only the files you need in one or few files. We are always looking for people who help on OpenNTF. If you want please contact me.
With XPages you can disable to return the standard Dojo and you can disable to return any css files. So it's more how XPages are used, rather than what XPages provides. That having said it would be nice if XPages could combine multiple files into one/few ones dynamically at runtime.
XPages.info is much better. There are only four files: Dojo, xsp, analytics, counter.
Reply
Hi Niklas. I wish I had the time to help.
I didn't mean to single out OpenNTF. It's just the first one I thought of.
I understand what happens when you let numerous developers loose on a website over a period of years. Perhaps it needs one developer to take a fresh look over it.
You're right - Xpages.info is much better. Perhaps I was wrong to judge the Xpage technology on just a couple of websites.
Reply
Interesting... not that I would profess to know anything about development, of course!
I've just run the same analysis on uklug.info - which is XPages driven again. 4 Javascript files, but 42 CSS files. That's no judgement on the (very good) designer though!
As Niklas has said, with zero budget sites, it's a mix between optimising sites and adding new features. We've certainly concentrated on the latter!
Reply
Try creating an XPage in a new database and adding some basic HTML. By default it will include only 3 CSS files (based on the default "webstandard" theme) and 2 JS libraries (dojo.js and xspClientDojo.js). If you change the theme of the database to your own, no CSS files are send by default.
It all depends on what you add to the XPage. If you increase the complexity (e.g. by adding custom controls), the number of included files also increases, because most of the custom controls rely on additional (dojo) libraries/ CSS.
Reply
"Is using XPages for a public-facing website a good idea?"
My answer is, "It depends." If it involves user submitted data then there are just too many issues with security on XPages. I gave a talk last year at UKLUG on Security on Domino systems. It wasn't very well attended, but those who did attend received some shocking information as to the extend of security loopholes that many people leave in their websites. XPages is superb for developing rich, interactive websites. But developers who fail to understand the security aspects of what they develop in leaves themselves (and their companies, and their users) at the mercy of people who will try all sorts of nasty tricks to get at the data behind the scenes.
XPages has a few flaws in it which allows "issues" if it's not developed properly. But I just can't get people to listen to these and thereby avoid the pitfalls.
Reply
Dragon do you have a link to your presentation. Id' be interested in listening.
Reply
Nice fud there. How about backing it up with some facts?
Reply
Show the rest of this thread
I couldn't make it to UKLUG, but..."But I just can't get people to listen to these and thereby avoid the pitfalls."...
I am most definitely listening.
I'll do a web search, but if it is appropriate, can you share your knowledge\ experience of any specific risks? ...realising you probably wouldn't publish directly on the web.
Reply
Hi Dragon,
can you follow up with me on the security issues
jim dot quill at ie dot ibm dot com
I didn't get to attend the UKLUG, and would be interested, as I am sure others are, in hearing the inforamtion you presented.
We can't stop someone reading URL parameter data and writing it as HTML but I would like to see how many of the issues you have discovered/observed are flaws, vulnerabilities, bad default values, best/bad practice, knowledge, etc. to see what we can do out-of-the-box to prevent or minimise XPages developers doing anything which would be considered bad.
Thanks for your input/help,
Jim (Domino XPages Development)
Reply
That's nonsense: XPages are inherently no less secure than anything else in Domino. As a Domino developer, if you don't know your job, you will produce insecure applications, end of story.
Reply
Show the rest of this thread
We have recently build our corporate website with xpages.
It is possible to exclude dojo if not needed, by disable dojo in your Xpage.
Have look at http://www.e-office.com
Reply
Frank,
Nice site. You can even reduce the size of it by 2% if you remove all of the hardcoded "http://www.e-office.com" strings :o)
Reply
The problem is using functionality that is offered. Dojo and IBM offer something that should work for everyone.
If you create your own theme, and you're not using dojo and IBM xsp extention, xpages are a great option. You could keep it to a minimum of 1 js file and 1 css file if you want.
You only have to create your own theme and that takes time and some research.
Reply
Jake,
It is absolutely possible to create an xPages application which does not need most of the JS/CSS files you see in the source of the above web sites.
Most of the dojo JS files are needed for the "interactive" part of your application. If you want to do some cool things in the site using the built in functionality, xPages rely on dojo to do most of them.
If you create a theme of your own (which does not extend from the webstandard theme), it will only have the css you include in the theme.
-Baiju
Reply
Does that mean Domino has no future as a platform for normal websites? I guess that depends on what you define as a 'normal' web site.
While xPages opens up lots of new components and features which are oriented toward building a web applications, I think there are also lots of benefits for a more informational site with only the occasional interactive piece.
One of the advantage that xPages gives you over traditional Domino development is the ability to easily move away from the tight coupling of form with data which better suits a 'standard' web site model.
Another benifit is a better model of componenent reuse. xPage/ custom controls are easier than the form/ subform model, for example, because you can load a contol multiple times on a page, passing different parameters to each instance, and you don't have to worry about unique field names or any of the other similar issues.
You also get access to session / application scope variables and other such back-end features that simplify web site
Reply
XPages without the bloat is hard work. Start an XPage application and
use what Designer offers and you will automatically start in bloat mode.
There are several ways to switch off bloat mode. The most radical one is to use the so called "Ágent Mode" (credits to Stephan H Wissel). This is basically like agents with Print statements but much (with an emphasize on much) more powerful.
95%+ code control, little RAD capabilities.
As for the future of Domino for normal websites. Domino never was a platform for "normal" websites. Isn't this what made Codestore famous!? Working around all those limitations. At the end you normally switched off most of the Domino HTML rendering (not to speak of the applets or the Domino default view styles).
XPages really has some great concepts (for example the server side javascript part is great and well done).
By the way. When you design your XPage application keep in mind that recycle() is back. If you don't your http task will die a painful death and it just needs the Google crawler for this to happen.
I still think that you should try it yourself. There are people that really swear on XPages and some that are totally unimpressed.
Reply
This "Agent Mode" looks promising. We have standardized on jQuery (much easier to use, better documentation than dojo). Now we can consider xpages in "Agent Mode" with jQuery.
Reply
Show the rest of this thread
"...keep in mind that recycle() is back..."
All Domino objects instantiated in an XPages request are recycled when the response is sent back to the requesting client, at the end of the JSF lifecycle. This is done by recycling the original Session object, which the servlet manages for you.
Reply
Show the rest of this thread
Server version plays a lot into the XPages light-vs-heavy discussion. E.g. 8.5.0 didn't auto-flatten Dojo files. If you enabled the calendar control on a date field you'd end up with 50+ JS hits as it pulled in the various Dojo files. 8.5.1 auto-flattens the files, resulting in just a few. But it doesn't auto-flatten the CSS. Supposedly they tried to get that in to 8.5.2 but couldn't, so perhaps it'll be in 8.5.3.
Reply
Oh, I also forgot to mention the ridiculously obvious benefits of building a public-facing site on XPages: future improvements. E.g. Your client say they want a search box with full-text index -- Done. Basic CMS control capability? No problem to add. If a year later your customer wants to add on a discussion forum integrated with their public site, you're halfway there already.
Reply
Some Domino site (Blogsphere) render their output in an agent. A lot of sites have QueryOpenAgents. Using XPages "agent style" that can be MUCH faster especially when you add some caching logic. for "mostly read only" sites you don't need all the Ajax and Dojo goodness.
So the answer: Yes I would use XPages and yes I would think hard which of the features to use. And YES: the backend (CMS UI) would be XPages in any case so it runs in a client too
Reply
Jake,
XPages or other methods including using Dojo straight the way I do and traditional Domino Web development can all do the job with no problem. The more important question is to ask what tools are available or you can create that your users can use to maintain and update the information on the web site. If you can create it in XPages or Flex that is great. As long as your client can easily use the tools. Having the client create or update Web pages using XPages is mostly likely not going to happen.
Reply
Jake,
Consider that all of these implementations of XPages rely on RAD techniques, use the Dojo libraries, etc. which -- I will say -- is often overkill.
However, if you deep-dive and actually write XPages apps, you'll quickly realize that you can go "beyond RAD", disable the auto-inclusion of Dojo libraries, and -- and please pay attention here -- FINALLY have complete control over the content while keeping in-line with the vendor best practices for application development.
The last 3 XPage-based apps I've written don't load the Dojo libraries. One of them loads iWebkit.css as it's an iPhone port of a Lotus Notes Client NotesDatabase.
And before anyone says it, sure - I could have done the same with blank Navigators, Forms, and other hacks that we've relied on over the years...
But while that's comforting to developers who have relied on those techniques for the better part of a decade, it's not future-proofed and working with the direction of the platform.
Reply
Ok, ok. You've got my attention.
So, you're saying I can use XPages and have no JS and CSS files added for me (without using the "XPage as Agent" method mentioned above)?
Reply
Show the rest of this thread
My current beef with XPages is that it take fooorever to start if not in memory. Let's say you have a support app that isn't very frequently visited, but once a while you're hit by an angry client and as a "bonus" your XPage support application takes forever to respond.
To my, very limited, knowledge there's no way reliable workaround (love to be proven wrong though!).
Sure you could write a traditional Domino app for this part, but still - this may be a dealbraker in some cases.
/J
Reply
I do think that the speed of XPages in the Notes client is far too slow, even on local replicas.
I could be mistaken but it seems much faster in island disconnected mode than on network mode with a local replica - not sure why that should be.
I would be hesitant to recommend XPages in the client just at the moment.
Reply
The persistence settings might help out here... you can set persistence on an XPage to be aggressive and have the server always try to keep it in memory, or be memory-friendly at the expense of performance. The default if I recall is in between those two.
Also, a quick-and-dirty trick would just be to have a scheduled agent that opens your XPage every X minutes so it's always readily available.
Reply
The CSS and JS inefficiencies in the examples are quite common across platforms actually, it is not a xPages thing by itself. Typically it occurs when working with frameworks that componentize UI assets and behaviors. In combination with developers who are not aware of the performance penalty (or lack the time to optimize it), you get the result as seen, a very sub optimal speed.
The very good news is that often with very little effort, you can reach a performance gain of 500% for those websites. Use the tools like Google PageSpeed and Yahoo's Yslow on the site and they will tell you exactly what to do. Most often it is simply a matter of gzipping, combining files, spriting and caching.
I've found that few developers are aware of front-end performance, whilst I once heard that 80% of the time between requesting a page and the user actually seeing it loaded and fully rendered occurs at the front-end, not the back-end (can't remember the source, sorry).
I can't blame those developers. They are asked to be everybody at once: designer, database admin, programmer, security specialist, analist, support engineer. Until two years ago I had no idea either how some simple adjustments can dramatically speed up a website at allmost no cost.
Sorry that I cannot answer your original question as I have no xPages experience. I can tell you though that this is not an xPages specific issue, it is a general front-end engineering issue.
Reply
XPages can be a lot of things, and by looking at the source code for the openNTF project "XPages Extension Library", or as I like to call it, "The missing XPages documentation", you can see a lot of the stuff that is possible. However, it is not for the faint of heart.
As somebody who has a CMS system running with a presentation layer made with XPages, I feel I have something to add to this discussion. When we upgraded our old application (from v5 to v6), we created a presentation layer using traditonal WebQueryOpen agents and a custom templating engine, but had troubles scaling this. The solution for us was to go the "XPage as Agent" route with Freemarker as a templating engine. On top of Freemarker we have added our own freemarker-directives that speak Domino.
The reason we did this is the following:
1.) We had an existing application, and wanted more or less backwards compatibility with our templates
2.) Simple for our consultants to modify and reuse templates and subtemplates without modifying the design of the application
3.) The Web is text, not objects
This model gives us a few easy advantages, for example templates are stored as Notes documents (and some system templates resides in jar files), and we can also easilly use Memcached to cache complete or partial pages. XPages is actually a really fast processing environment, and typically gives us response times around 200ms for a cache miss, and 30-50ms for a cache hit.
While this solution works fine for us, we have had troubles with unstable servers, and after several PMR's we are still not sure if its us or XPages that crashes Domino on high load.
If we didn't have our own CMS already, I would not have considered using XPages for public websites, as I see it as too much work. I would have chosen an already existing CMS. We do however use XPages for internal sites and custom applications for clients, replacing "traditional" Domino web development.
Reply
I tend to associate xpages with applications and tend to think its overkill for a "normal website". Consider the following 2 sites in domino I recently made live:
http://weatherbarrier.com
http://banyan-llc.com
These sites are what I consider "normal websites" in that they have common content associated w/ a lot of companies: static pages (eg about us, services, etc.), executive/employee profiles, testimonials, case studies, news, maybe a document library/white papers, a few forms, etc. I have a solid process for creating a site w/ a robust web based cms that handles all the components above and of course since its domino you can easily customize it. I'd be happy to share it w/ you. I suppose you could use xpages for your cms/admin interface but I would still likely not have the "front end" in xpages for following reasons:
-while I am sure you can find some code bloat on the above sites they are fairly lightweight and leverage jquery for features you often want to give your users: dropdown menu, galleries, clean validation on forms, nab lookups for secure section and more. Plus the spiders crawling generally like clean css/xhtml. Can you easily have a cleanly coded front end using xpages?
-the above sites easily allow users to manage seo components such as window title, url, h1 tags, meta tags and of course the content using http://ckeditor.com/ which I believe xpages uses. no idea if you can easily control url conventions in xpages but thats a must have for most sites that want to do well in seo.
In my opinion Domino has never been marketed or pushed as a platform for normal websites. In my opinion its an ideal one as "normal" sites are document centric and it has a strong future as long as you take the best stuff going on in open source and use hacks to get it working in domino which is what you've been doing for some time.
Reply
Jake, I do agree with the basic point that there are too many files loading but for what its worth both of the xpage sites above score a higher ranking ( firebug page speed ) than codestore as does our new Xpage app http://www.deliverytoolkit.com/moc-demo
codestore = 71
openntf = 75
iqjam = 78
deliverytoolkit = 73
I know, numbers are not everything, your site definitely loads faster than mine for the first page, but it did make me smile.
Reply
Well the frontpage of Codestore currently loads 43 graphics (1302.5KB) but there are some heavy photos in there.
Reply
Show the rest of this thread
According to the Page Speed plugin on my Firefox this site's homepage gets 83/100. So, there! ;-)
Like Henning says though it has been quite a photo-heavy week or so on codestore, which can't help.
Reply
To be honest, same thing is in ASP.NET world. If you enable async postbacks, you suddenly get about 23 javascripts on your web site.
My guess would be that XPages and ASP.NET go by the policy that no matter how many javascript files you have, they will be cached after inital web site load anyway.
I never used XPages for web, but with ASP.NET, it never really got that performance. A site using async postback with all 22 javascript files took about 5 seconds more to load up. In the end, if it is something basic, you are better of writing your own ajax request.
My ruling would be that XPages are fine (much as ASP.NET), but some features are still not useable out of the box. Not for web sites anyway.
Reply
The JFS (which XPages is built on) does not have a large fan base. Search the internet and I my guess is you won't find many developers screaming of joy.
I don't think it is meant for standard websites, more for applications internally.
But most likely the main reason for not using XPages or Domino in general on a website would be license issues.
I did some searching last year to find a good Java based framework to build websites on.
My conclusion is: if you want a fast , easy to use, powerful framework with active developers and users backing it ->
Go for the Play Framework
http://playframework.org
Add a NOSQL database and you might even feel at home :-)
Reply
If you're going to search the internet, you should use the correct abbreviation, which is "JSF." Or JavaServer Faces.
Reply
Show the rest of this thread
Struturo is written in @formulas. Lean and mean.
Reply
If you are concerned about the number of requests on your sites I would be happy to help out. There is a lot of things you can do. Feel free to try out Domino Accelerator Pack: Automatic Dojo builds, server side and client side-caching, compression, JS-minify, combining, smart-cache.
http://www.dominoexperts.com/dapInfo
Reply