Sitebricks is a new web application development framework from Google that is built on top of Google Guice, and focuses on early error detection, low-footprint code, and fast development. InfoQ had a Q&A with the creator and Google Wave Core Engineer Dhanji Prasanna.
InfoQ: What was the motivation behind building a new web framework? Why weren’t you satisfied with the existing ones?
Dhanji: Well, I have been working on this for a very long time (since Java 5 pretty much). I identified several pain points after using popular frameworks like Struts1/2, JSF, etc., and started on a long experiment to make web programming fun and pain-free for myself. Pretty much everyone I have shown it to has been seriously excited by the features. They all start out with the same cynical "yet another one?", but always ends with a positive reaction, happily. This is what has kept me excited myself, and going with it for so long.
I also believe there is a lot of room for innovation. Although I don't like to use the marketing buzzword "REST", Sitebricks embraces core HTTP idioms in its design, and there is a serious lack of existing solutions that do this. If we labeled it a "RESTful web framework" it may make people more excited, but we are confident the features will excite people as it stands.
InfoQ: How do you think that Sitebricks measures against the traditional Java frameworks and technologies like JSF, Wicket, etc.?
Dhanji: It's rather different from those. JSF and Wicket both approach web UI design using the abstraction of a desktop UI: Events, components and widgets interacting with user clicks and actions. Sitebricks abstracts directly over HTTP. In that sense, it is more sensible to compare it with JAX-RS (The Java API for RESTful web services), which I also helped design. Though JAX-RS does not do templating, or provide a client API, currently.
My primary complaint with existing MVC frameworks was that they magicked away too much, and tried to hide the HTTP layer. This led to grotesque practices like automagically injecting javascript that trapped clicks and converted them into state-gathering POSTs. These frameworks are also fairly verbose, which makes prototyping tedious. Sitebricks, on the other hand, is extremely concise, embraces HTTP, loves HTTP, and is very much about fetching and exchanging resources and messages.
On top of this, the templating layer is built like a functional language, which allows you to compose pages with one other (using folds and projections) in a simple and concise fashion. This is largely inspired by functional languages like Scheme and Haskell, and also from principles in Terrence Parr's excellent paper on Model/View separation (http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf).
InfoQ: Would you like to describe the basic principles and technological choices behind Sitebricks?
Dhanji: Sure, the primary principles are conciseness and type-safety, just like Guice. From navigation, to mapping URLs, writing template expressions, everything is supported with an extra layer of error-checking and static analysis. Expressions in Sitebricks templates are just as concise as JSP, but are statically type-checked using a type-inference algorithm. It even honors duck typing, with static guarantees.
Another core principle is speed: not just performance, but developer productivity. The Sitebricks lifecycle is no different than HTTP's, and each page is a normal Java POJO with an HTML template in front. "Custom" components in other frameworks often require plenty of additional configuration and support classes. In Sitebricks, because of the nature of the templating system, custom reusable page fragments are no different from regular pages.
Finally, Sitebricks is built directly on top of Guice. This was a core design principle from the beginning, so Sitebricks is tightly integrated with a complete DI system, and does not jump through hoops to take advantage of DI like other frameworks have had to.
InfoQ: What would be the process, tools and libraries for developing a web app with Sitebricks?
Dhanji: The idea that you can simply bring up an HTML page in a browser and hack away at it is essential in Sitebricks. You should not need any fancy tools to design pages or components. You can bring it up in any servlet container and iterate over fragments of a page (bricks) or a larger composited page.
Like Guice, Sitebricks takes the approach that type-safety and early error-detection can make a world of difference to an engineer's workday. Not only are your objects validated for DI dependencies (with Guice and Guice Servlet built-in), but expressions inside pages are statically type-checked against their corresponding page classes. With ace Red Hat engineer Mike Brock's help, I extended the wonderful MVEL expression language (http://mvel.codehaus.org) to use a type-inference algorithm, that maintains the conciseness of JSP-style expressions but gives you all the rich error checking of a Java compiler.
This keeps with our goal that you should be able to get the most out of it without any specialized tools (or even an IDE for that matter!). MVEL is also an order of magnitude faster than JSP EL, and several times faster than most other ELs out there.
Additionally, Sitebricks also performs loads of static analysis on HTML templates, ensuring that form parameters match bind targets, action URLs and a whole host of other inspections. And that's just the tip of the iceberg. We have a lot more in the works.
InfoQ: How does Sitebricks integrate with other popular web technologies like GWT and JavaScript toolkits for the client side or Hibernate and other persistence mechanisms?
Dhanji: Currently, you can use any javascript framework in a Sitebricks page and embed this into any other Sitebricks page as a composable fragment or "brick". Sitebricks does the right thing and ensures that CSS, Javascript and other resources are rewritten in the <head> tag as appropriate, meaning that you can embed into any other with a simple annotation. This allows you to wrap and reuse any web page as a composable bit of functionality, in any other web page, which is a useful feature. You can also use Sitebricks to deliver XML and Json to GWT applications, just like you would to any other client service.
We are working on a deeper comet-style integration with GWT that will allow Sitebricks to become a drop-in backend for long-running, bidirectional GWT apps.
Since Sitebricks is built on top of Guice, users can take advantage of all the existing integrations we already have with various frameworks and libraries. For JPA, Hibernate and db4objects, warp-persist (http://www.wideplay.com) is a thin, simple integration layer that makes persistence and transactions easy to set up in any Guice application. It also has extensive type-safety and query-automation features. Warp-persist is being used by many organizations and individuals, including some projects inside Google.
Guice's servlet module is also built in to Sitebricks allowing you to pretty much completely eliminate buggy web.xml configuration entirely from your apps.
InfoQ: It seems that there is a reference to Sitebricks within the Google Wave Federation Prototype Server. Is it used in this server? Are you planning to use it in more Google projects?
Dhanji: Good catch! Actually it is not used in Google Wave Reference Implementation. When I set up the Federation project's build configuration I used Sitebricks' ant script as a template, so some of the example commented code remains. However, I have discussed using it in other systems in Google Wave with the specific teams and am confident we'll use it there when it is more stable.
I have spoken to a few people around Google and they are all fairly excited about Sitebricks, but it is early days yet, so we will have to see how adoption proceeds as the codebase matures.
InfoQ: Since there is no such thing as the best framework for any job, what type of web apps do you think might benefit more from using Sitebricks and what requirements might make it not seem as an attractive solution??
Dhanji: This is a great question. Sitebricks works great for most of today's sites that have HTML pages that have a lot of textual content and some components that are inserted or modified by Javascript interactively.
At first blush, you might argue that A page-heavy, modern ajax app like Google Wave may not benefit much from Sitebricks, however when you begin to consider the RPC layer, then Sitebricks's RESTful web services API becomes very attractive for delivering Json or XML directly to the GWT application. Furthermore, we have found that fragments of pre-rendered HTML can provide huge performance gains compared to conversion from JSON or GWT-RPC. Sitebricks fits naturally in this area.
Finally, we have also been working on a robust HTTP (RESTful) web services provision within Sitebricks using fast serialization. We also bundle a simple HTTP client API, which means the same Sitebricks jar can be used for both sides of a web services remoting setup. We build on the MVBus extension to MVEL for this, which has shown an order of magnitude performance difference with traditional libraries like XStream.
InfoQ: What is a rough roadmap for releasing Sitebricks and what about licensing?
Dhanji: Sitebricks is currently open to the public under the Apache Software License 2.0. It is currently in an alpha stage, and is accessible at http://code.google.com/p/google-sitebricks
You can also message me directly on twitter with Sitebricks questions or comments at: http://twitter.com/dhanji
You can find more information on the Google Sitebricks project page, on the mailing list or on Dhanji’s presentation slides from this year’s JavaOne.
Also Dhanji is the author of the Dependency Injection book, which was recently featured on InfoQ and its last chapter is a case study on how to build a complete web application with Google Sitebricks.
Furthermore InfoQ has several articles available on Frameworks, Google Guice and Google Wave.