A couple of things come to mind (as usual). IBM has set themselves a rather expensive bar. Keeping up with rapidly evolving internet standards in terms of the output generated by XPages is going to, in my opinion, reduce IBM's incentive to keep Domino up to date going into the future. I've thought about this in the past - what is the motive for IBM to keep Domino on the cutting edge if the tools are let go for free, the market is shifting and they've added so many developers to update the tool to where it is (presumably though many of those come and go, the balance being less than those needed for the 8 build?). And I'm no seer, I don't know all of what goes into this... just superficially, I can see where IBM in the near future see's the benefit of stopping updates to the Domino code. Which leaves XPages where legacy domino is, stuck... but worse in that it has so much baked in to it it rapidly loses pace with standards with a large technical debt for any developer tasked to update it.
It has often been noted by you, Jake, and others like us that IBM's decision to have Domino decide how to generate any HTML or JavaScript has been the biggest problem for Domino as a web platform. XPages and One UI + Dojo only doubles-down (or worse) on this same problem. If you have to update these to meet new standards, tweaks are probably not going to cut it. Rip and replace will be the order of the day.
The smart developer is going to keep his toolbox full of tips and tricks for how to do it the old way. Sooner or later, you will find yourself with some other platform and knowing a lot of how to do it from scratch and building your own way around a problem is going to serve you better as a developer than knowing how to wrangle XPages into giving you what you want.
I sat down last Friday to try a benign little XPage idea I had. I wanted to take a view with a simple document and create a repeating section for each document. Really, drop-dead simple. I added a repeat control, added a data source (view), and mapped the control to the data source and the first column. It all compiles fine with no indication of error. But to run it, I get a "error getting property 'columnname' from bean'. Issue: the designer let me easily make something that breaks right off. If I'm writing my own code, I expect this. But if the framework is tightly integrated with the IDE - - it should just work. Then I go to correct it and the 'bean' is apparently broke for good as the same error shows no matter what I do, including replacing the controls with simple text. No recompile option? Apparently not. So why such a struggle to get XPages to do something that would be drop-dead simple with a bit of LS or Java? There's the other reason I don't see XPages as as long term solution. The ROI is low for your efforts as a developer. The framework is so deep that anything you want to do in XPages is wholly dependent on XPages. You can't easily beg barrow and swap code between non-xpages stuff and you "have to" do it the XPages way to get it to work... and to top it off, that "way" is a bit esoteric and difficult to come to grips with when the IDE can't even guide you to creating functioning content without serious issues.
Now, no doubt, I'll once again be raked over the coals for breaking faith with IBM, ridiculed for being too stupid to see the beauty of XPgaes and accused of damaging reputations. But honesty demands it, and we owe it to ourselves and our customers to be honest about the short-comings and outlook for XPages. For me, the "old way" will always be the smart way while I acknowledge that XPages is the "cool" way, the shine will fade in time as browsers continue to move forward with new standards and features and XPages becomes more expensive for IBM to keep up to standard.
So, Jake, sorry to lay this here but your question brings the issue to the fore. I find most of what you share of value, but like you question the level of interest in doing it the old way. Personally, it's a post I would read with interest. It's the sort of adventure story I like. Worth your time? That's up to you. If you enjoy sharing and telling a good story, why cut yourself off from your joy?
A couple of things come to mind (as usual). IBM has set themselves a rather expensive bar. Keeping up with rapidly evolving internet standards in terms of the output generated by XPages is going to, in my opinion, reduce IBM's incentive to keep Domino up to date going into the future. I've thought about this in the past - what is the motive for IBM to keep Domino on the cutting edge if the tools are let go for free, the market is shifting and they've added so many developers to update the tool to where it is (presumably though many of those come and go, the balance being less than those needed for the 8 build?). And I'm no seer, I don't know all of what goes into this... just superficially, I can see where IBM in the near future see's the benefit of stopping updates to the Domino code. Which leaves XPages where legacy domino is, stuck... but worse in that it has so much baked in to it it rapidly loses pace with standards with a large technical debt for any developer tasked to update it.
It has often been noted by you, Jake, and others like us that IBM's decision to have Domino decide how to generate any HTML or JavaScript has been the biggest problem for Domino as a web platform. XPages and One UI + Dojo only doubles-down (or worse) on this same problem. If you have to update these to meet new standards, tweaks are probably not going to cut it. Rip and replace will be the order of the day.
The smart developer is going to keep his toolbox full of tips and tricks for how to do it the old way. Sooner or later, you will find yourself with some other platform and knowing a lot of how to do it from scratch and building your own way around a problem is going to serve you better as a developer than knowing how to wrangle XPages into giving you what you want.
I sat down last Friday to try a benign little XPage idea I had. I wanted to take a view with a simple document and create a repeating section for each document. Really, drop-dead simple. I added a repeat control, added a data source (view), and mapped the control to the data source and the first column. It all compiles fine with no indication of error. But to run it, I get a "error getting property 'columnname' from bean'. Issue: the designer let me easily make something that breaks right off. If I'm writing my own code, I expect this. But if the framework is tightly integrated with the IDE - - it should just work. Then I go to correct it and the 'bean' is apparently broke for good as the same error shows no matter what I do, including replacing the controls with simple text. No recompile option? Apparently not. So why such a struggle to get XPages to do something that would be drop-dead simple with a bit of LS or Java? There's the other reason I don't see XPages as as long term solution. The ROI is low for your efforts as a developer. The framework is so deep that anything you want to do in XPages is wholly dependent on XPages. You can't easily beg barrow and swap code between non-xpages stuff and you "have to" do it the XPages way to get it to work... and to top it off, that "way" is a bit esoteric and difficult to come to grips with when the IDE can't even guide you to creating functioning content without serious issues.
Now, no doubt, I'll once again be raked over the coals for breaking faith with IBM, ridiculed for being too stupid to see the beauty of XPgaes and accused of damaging reputations. But honesty demands it, and we owe it to ourselves and our customers to be honest about the short-comings and outlook for XPages. For me, the "old way" will always be the smart way while I acknowledge that XPages is the "cool" way, the shine will fade in time as browsers continue to move forward with new standards and features and XPages becomes more expensive for IBM to keep up to standard.
So, Jake, sorry to lay this here but your question brings the issue to the fore. I find most of what you share of value, but like you question the level of interest in doing it the old way. Personally, it's a post I would read with interest. It's the sort of adventure story I like. Worth your time? That's up to you. If you enjoy sharing and telling a good story, why cut yourself off from your joy?