Apologies if I've misinterpreted, but a couple of the above comments seemed slightly tinged with derision for developers who have spent time with XPages and found reason to be excited about them. Naturally, your clients' needs drive your business, and if those needs have not yet provided a mandate to take advantage of the capabilities of XPages, it makes sense that you'd be focusing instead on platforms or technologies that seem a better fit. But to simply write off the excitement others have displayed (and, by extension, them for having displayed that excitement) for what is, arguably, the biggest evolution of the Domino platform in a decade as a misguided bandwagon before thorough exploration seems to me to be a bit premature.
I can only speak for myself, of course: like John, all of my development (except a couple days of LotusScriptery last month) since late last year has involved XPages. Of course they're not a panacea - it's not a perfect fit for every web development project. In fact, everything they do can probably be done with another approach... and therein lies the biggest barrier to adoption: if you're waiting for a project where XPages are the only technology that allow you to accomplish what your client has requested, it's probably not going to arrive. But I've been developing features all year for our clients that I could have written another way, but thanks to XPages I delivered in less time (and, therefore, at a lower cost to them) a working product that is more scalable and maintainable than the alternatives we'd explored.
Another phenomenon John alluded to that I've witnessed as well is an adoption rate of 8.5 that far outpaces what I've seen for any version since 4.6 - in one case, a client chose to pursue a significant development project in XPages less than a month after 8.5 went gold. In contrast, I've long been accustomed to having to talk employers/clients into upgrading to a supported (not just current) version of the product by enticing them with features that could now be enabled by clicking a checkbox that, in the version they were mired in, had instead to be tediously constructed from scratch. Suddenly we have clients coming to us who are aware of the platform's new capabilities and want to take advantage of them. It's not just developers who are excited... our customers see the potential as well. But it's much too soon to know whether our experience is isolated or if the overall trend will be similar.
In any case, I'm not surprised that you're impressed with Flex; I played with it a while back and liked what I saw. However, with one exception, I haven't had a need for it since. Personally, I found its user interface limiting: sure, it looks sharp, but aside from changing background colors, fonts, and the like, in the end anything I developed came out looking rather similar to any other Flex app. I can make an XPage look like whatever I want it to. On the other hand, I've noticed numerous similarities between XPages and Flex... for instance:
- The interface is designed either by manipulating visual controls or by editing the source XML directly, and then compiled into the file the user will access.
- The scripting language is a descendant of ECMAScript.
- Controls are bound to each other and to back-end data sources, so changes to a single control or dataset get pipelined automatically throughout the binding hierarchy (i.e. bind a repeat control displaying view data to the value of a combobox, and a pager to the repeat; selecting a different value in the combo changes what records display in the repeat, which changes how many page links the pager displays... and that's just one of the easiest examples. Sidebar: remember how arduous it used to be to create a decent pager for Domino? Now we just drag a pager control onto the canvas and select which data container it's associated with. Done. Sure, I could go back to manual URL parsing and link rendering in a LotusScript WQO agent, but why? I get the same functionality in, like, 3 mouse clicks now. And the result renders much faster...).
It's true, Flex Builder is a much cleaner IDE than DDE. But when I reflect upon the ability I now have to mix Formula, JavaScript and Java fluidly in a single line of code if that appears to be the best and easiest way to achieve the intended functionality (and it quite often is), I'd rather stick with a slightly buggy IDE (which may well get a bit less buggy when 8.5.1 arrives later this year) than restrict my toolbox to ActionScript alone. But that's my personal preference... to each his own. Or hers, for that matter.
Apologies if I've misinterpreted, but a couple of the above comments seemed slightly tinged with derision for developers who have spent time with XPages and found reason to be excited about them. Naturally, your clients' needs drive your business, and if those needs have not yet provided a mandate to take advantage of the capabilities of XPages, it makes sense that you'd be focusing instead on platforms or technologies that seem a better fit. But to simply write off the excitement others have displayed (and, by extension, them for having displayed that excitement) for what is, arguably, the biggest evolution of the Domino platform in a decade as a misguided bandwagon before thorough exploration seems to me to be a bit premature.
I can only speak for myself, of course: like John, all of my development (except a couple days of LotusScriptery last month) since late last year has involved XPages. Of course they're not a panacea - it's not a perfect fit for every web development project. In fact, everything they do can probably be done with another approach... and therein lies the biggest barrier to adoption: if you're waiting for a project where XPages are the only technology that allow you to accomplish what your client has requested, it's probably not going to arrive. But I've been developing features all year for our clients that I could have written another way, but thanks to XPages I delivered in less time (and, therefore, at a lower cost to them) a working product that is more scalable and maintainable than the alternatives we'd explored.
Another phenomenon John alluded to that I've witnessed as well is an adoption rate of 8.5 that far outpaces what I've seen for any version since 4.6 - in one case, a client chose to pursue a significant development project in XPages less than a month after 8.5 went gold. In contrast, I've long been accustomed to having to talk employers/clients into upgrading to a supported (not just current) version of the product by enticing them with features that could now be enabled by clicking a checkbox that, in the version they were mired in, had instead to be tediously constructed from scratch. Suddenly we have clients coming to us who are aware of the platform's new capabilities and want to take advantage of them. It's not just developers who are excited... our customers see the potential as well. But it's much too soon to know whether our experience is isolated or if the overall trend will be similar.
In any case, I'm not surprised that you're impressed with Flex; I played with it a while back and liked what I saw. However, with one exception, I haven't had a need for it since. Personally, I found its user interface limiting: sure, it looks sharp, but aside from changing background colors, fonts, and the like, in the end anything I developed came out looking rather similar to any other Flex app. I can make an XPage look like whatever I want it to. On the other hand, I've noticed numerous similarities between XPages and Flex... for instance:
- The interface is designed either by manipulating visual controls or by editing the source XML directly, and then compiled into the file the user will access.
- The scripting language is a descendant of ECMAScript.
- Controls are bound to each other and to back-end data sources, so changes to a single control or dataset get pipelined automatically throughout the binding hierarchy (i.e. bind a repeat control displaying view data to the value of a combobox, and a pager to the repeat; selecting a different value in the combo changes what records display in the repeat, which changes how many page links the pager displays... and that's just one of the easiest examples. Sidebar: remember how arduous it used to be to create a decent pager for Domino? Now we just drag a pager control onto the canvas and select which data container it's associated with. Done. Sure, I could go back to manual URL parsing and link rendering in a LotusScript WQO agent, but why? I get the same functionality in, like, 3 mouse clicks now. And the result renders much faster...).
It's true, Flex Builder is a much cleaner IDE than DDE. But when I reflect upon the ability I now have to mix Formula, JavaScript and Java fluidly in a single line of code if that appears to be the best and easiest way to achieve the intended functionality (and it quite often is), I'd rather stick with a slightly buggy IDE (which may well get a bit less buggy when 8.5.1 arrives later this year) than restrict my toolbox to ActionScript alone. But that's my personal preference... to each his own. Or hers, for that matter.