Today we continue the interview with Howard Lewis Ship from the Apache Tapestry team. In the second part Howard talks about his favourite stack of frameworks, the future of Tapestry and open-source in general. Enjoy!
Is it possible to use Tapestry as a REST backend for one-page-app in one of the hipster Javascript frameworks (e.g. Ember, Backbone.js or AngularJS)?
Howard is the creator and PMC chair of Tapestry Framework
I don't have direct experience with Ember or AngularJS (at least, not yet); I certainly like Backbone however. In my existing applications, where I have very complex user interactions, I started using Backbone about six months ago. For the moment, I'm using it in a somewhat bastardized way: the Backbone code communicates with the server via JSON data inside a hidden field, so as to integrate into an over-all form submission. Traditionally, Backbone wants to communicate directly to a RESTful endpoint. However, there's no reason why Tapestry pages and components can not be used as RESTful end points; it's actually exceptionally easy to have a Tapestry event handler return JSON data... just create a JSONObject instance inside an event handler method and return it; Tapestry takes care of the rest.
Can you describe your top-of-the-tops technology stack? On DevRates you reviewed Gradle, Spock and CoffeeScript, are these your favorites?
For any kind of build, Gradle should be your starting point, because it will be your ending point. I've used GNU Make, Ant, and many versions of Maven, and none of them hold a candle to Gradle, or leave you as much in the driver's seat. Gradle lets you get stuff done.
For testing, Spock is by far the best tool I've ever used. Everything I said above about simplicity, consistency, and feedback is fully present in Spock, and it's just a joy to use. Likewise, Geb, (a Groovy layer about Selenium 2), makes web testing ... well, not easy, but tractable and maintainable. Nothing makes web testing easy, especially once Ajax is in the mix.
I'm coding all the new JavaScript for Tapestry 5.4 in CoffeeScript, and when I venture out into the NodeJS space, I'm using CoffeeScript on the client and the server. I do love what my code looks like in CoffeeScript (aesthetics do matter for me, just look at my Java code!), but ever after several months, I'm not always sure if the CoffeeScript I write will generate the JavaScript I need. There's a bit of an ethic in CoffeeScript to avoid the use of curly braces and parenthesis at almost all costs. The CoffeeScript compiler can be amazingly clever about figuring out what you want, but even after a few months, I tend to second guess it a bit often, and a bit wastefully. I tend to wonder whether something better than JavaScript, but not quite so cranked up to eleven as CoffeeScript, might serve everyone better ... but I can assure you, I'm not going to be the one to take that on.
Lastly, I love to work in Clojure whenever I get the chance. Clojure's immutability is not a good fit for Tapestry pages and components (they are all about dealing with mutable data), but the services layer can certainly be well addressed using a functional language, and Clojure is by far my favorite functional language. I've even committed some code to 5.4 to simplify the interaction between Tapestry components and Clojure functions (by making the Clojure functions masquerade as Tapestry services that can be injected into components). When I get the chance to use Tapestry with Datomic, I want to be able to write all the relevant code inside Clojure, and not use their Java API.
What is the future roadmap for Tapestry?
It is pretty clear that the future belongs to HTML5, and JavaScript, running in the browser. That means jQuery, Bootstrap, Backbone, AngularJS, or what-have-you. What's important is that Tapestry evolve to continue to address the needs of traditional, page-oriented applications while also clearing the barriers related to using Tapestry for modern "single page" web applications. In fact, I think there's a great advantage to having a single framework that can address both styles well, and efficiently.
For example, when developing NodeJS, a server-side exception produces a very limited report in the console, and may be unreported in the browser. I hate that; if Tapestry was in the mix, a server-side exception would produce an popup window (really, an iframe) with the full, detailed, exception report. Once you have that, you can't go back to scratching your head, or setting breakpoints, or scavenging your log files.
So my future roadmap is pretty much to continue to embrace the SCEF goals outlined above, with an ever growing focus on the client, and providing infrastructure to support client applications. That could take any number of forms; it may mean having a different kind of template that can "execute" on the client or on the server; it may mean having a more fully-fleshed out REST story integrated into Tapestry. Still, I wouldn't want to sacrifice the really wonderful encapsulation provided by components, or the composability of the overall component model. Certainly, having real support for WebSockets is a must; that's long overdue.
I do think that, eventually, the idea of having a Form component and a TextField component will become pretty antiquated; all communication to the server after a page initially renders will be Ajax, without the compromises and half-measures of the HTML form design; just POSTed JSON data.
What are your thoughts about the future of open-source? More acquisitions like Spring to VMware? More and more small frameworks hosted on GitHub?
I think a big chunk of the future belongs to GitHub projects and NodeJS. I think the NodeJS guys got things very, very right by effectively saying "we're going to provide the barest minimum viable libraries bundled in our core, and everything else should be an add-on library provided by the community". Note "library", not "framework" ... they are very disdainful of frameworks because they've seen what they've done to the Java landscape and the Ruby landscape. I think in their minds, if its is "composable" its a library, and if locks you in, in any way, its a "framework" (I don't know precisely, in any language, where the transition point really is). The same ethic is present in the Clojure community, where Stuart Seirra has loudly declared "don't build frameworks!".
You can kind of see the point of the "libraries only!" mindset: The complexity of Java frameworks (even Tapestry!) can make many less-experienced developers into cargo-cultists; they can eventually get the right results, but don't understand exactly how or why it all works. The barely understand the layer they are working on, and strong developers always understand at least the layer of abstraction immediately under their main work (to truly understand Java, you should have a passing knowledge of bytecode perhaps; to understand web development, you should have some understanding of the DOM, HTTP, and how a browser operates). Working as a cargo-cultist, not really understanding your tools and your craft, is bad for individuals, and maybe for the industry as well.
I think it is great that Spring and JBoss and others have hit the jackpot in the acquisition lottery, but I don't know that I would draw any big conclusions from those pretty rare examples. Those acquisitions were not about code, or about technology; they were about customer lists, they were about support contracts, they were about key personnel. However, I think that once one of these organizations becomes so established, so too-big-to-fail, their ability to innovate, or to do something truly revolutionary, falters. What the world needs is more kids on GitHub doing crazy things because they don't know they are attempting the impossible, not more people sitting on specification committees.
What is your opinion on DevRates website?
I think it's a clever idea; as an open source project I don't really know as much as I'd like about my users, so seeing what projects are really used and by who can be really useful. I wonder what could be gained by drawing clear relationships between projects, or by analyzing what groups of projects are used together?