Tapestry is simple because it is focused. It does HTML apps (yes, it has support for XML, WML, FooML, or whatever, but the deepest groove runs through the HTML code). It creates the minimum abstraction away from HTML and HTML markup. It automates that mechanical aspects of developing a web application, particularily server-side state management. It starts you at the place where, if you started from scratch, you would eventually reach (through much pain, effort and trial and error). And it's always meant to be useable with no special tools (or, off-the-shelf tools, such as standard WYSIWYG HTML editors).
JSF pretty much begs for tool support. Although Kitto Man claims that tools are not so necessary, the development story from Sun and the JCP is that we'll have Microsoft-style tools that write our code for us, based on what we drag and drop.
Additionally, Andrew has recast the Tapestry vs. JSF discussion into the larger context of imposed standards versus simple, effective solutions. JSF is a big, proprietary, complex specification that arose out of private discussions by a "group of experts". As with EJBs (especially entity EJBs), the Java community is expected to accept JSF as the single, definitive approach based on an unearned level of trust. Can we wait another 3 - 5 years for Sun and the JCP to straighten out this mess? We don't know how JSF was designed, how decisions were made, what deals were cut or who the whole thing is supposed to serve. This kind of secrecy of course leads to paranoid theories ("JSF exists to support tool vendors"). Personally, I think the JCP and the JSF is Sun's best attempt to do things properly ... but I think they are quite misguided.
My own personal level of irritation with this endless raft of imposed specifications from Sun and the JCP is running out. JCP specifications are anonymous, a team of experts throws a specification over the wall and loudly proclaims: this is how you will now work. Tapestry and other major open source projects are personal --- they are backed by known individuals whose reputations are on the line in terms of the code they provide, but also in all the ancilliary aspects such as documentation, online support, and speaking engagements.
Futher, if the name of the game is beat Microsoft then Sun's strategy is way off. From my point of view, Sun hopes to win the war by providing the better technology and more options. Unfortunately, you can't win that war without winning the tools battle. The JCP doesn't provide tools, it attempts to create a market where others create the tools. But the tools are proprietary, and the properitary JSF tools (vaporware, but likely coming) will lock users into proprietary implementations of JSF. BEA may allow drag-and-drop development of JSF apps inside BEA Workshop, but those dragged-and-dropped components are going to be proprietary to BEA so what have you gained vs. using Microsoft's cohesive, integrated, properitary approach? Nothing I can see.
So what is Sun supposed to do? I don't think the JCP can continue to exist as both an incubator and a standards body: choose one --- standards body. Allow the industry and/or open source movement to come forward to provide completed specifications for new technologies, based on existing art. Allow submitting groups to form their own process prior to submission. Set the guidelines for accepting specifications based on public review, and a transparent process leading up to the submission of the specification.
But I don't have a good solution for Sun itself. They need a more compelling hardware story if they aren't going to be consumed by vast clusters of linux boxes (if Google can run on cheap hardware, anyone can!). They've never made money on software, and only lost money on Java. Meanwhile, IBM has been coming around and embracing Linux, Java and open-source. If IBM can do for Java in general what they've done for IDEs (with Eclipse, as an independent open-source software project) then more power to them .. IBM should buy Java, or buy Sun itself to get it.
No comments:
Post a Comment