If you're in Bangalore in India or Brno in Czech Republic over the next few weeks, you have an opportunity to see Errai getting talked up by myself (Mike Brock) and Christian Sadilek.
I'll be giving two talks at JUDCon India on January 24th. And if you come out for that, we've got a full schedule of other cool things for you to check out while you're there. See the JUDCon website for details and schedules.
On February 17th, Christian Sadilek will be giving a talk at the Fedora Developer Conference in Brno. Check out the details here.
Errai: The browser as a platform
Tuesday, January 17, 2012
Saturday, December 17, 2011
Thoughts on HTML5 and Development Methodologies
Over the past few months the Errai team has been busy at work preparing the next version of the Errai Framework, Errai 2.0.
It is a significant update that leverages all the best ideas that Errai 1.x had, while retiring some ideas and approaches that didn’t quite work out the way we’d planned.
Errai has developed a philosophy about rich application development in the browser. That philosophy might be summed up as: Your Application. Everywhere. Literally.
However, there’s been some people who’ve criticized this methodology. I’d like to respond to some of this now.
We have eschewed much of the conventional wisdom about how you should architect a web application by focusing on not just rich user experience, but rich developer experience. We believe that the latter ultimately leads to a better former.
We reject the need for polyglot applications as necessary -- the idea that the best way to build an application is to arrange a constellation of disparate languages and frameworks into a coherent single application is simply the “best approach” is something we don’t agree with.
You’re building your application in Java on the server. Why do you build the other part of it in JavaScript? The common response to this is, well, “that’s just the best way to do it”. But is it?
We don’t think it is. At the end of the day, the whole HTML5 group of technologies is just a specification that tells us how to make a browser do things.
Whether we write HTML and JavaScript directly or not, whether it’s translated from CoffeeScript, Dart, or in the case of Errai -- Java -- is immaterial. And it’s wrong to even suggest that Errai, with its use of the GWT compiler, sandboxes you into a world that proscribes any of these things. It doesn’t.
With Errai, your application can contain no JavaScript, or be almost all JavaScript.
The important part is how Errai helps you share not just model between the client and the server, but functionality. Without the need to write it twice, or write marshalling code, or worry about setting up your own comet or websockets. The communication model is central to the application development model.
Being able to share functionality, using the same code, with the same functionality is a good thing. You get all the benefits of type checking, code reuse, and productivity.
The implication that some make that, this sort of thing “hides the true nature of the web” is always one that puzzled me among those who advocate for a pure JavaScript approach.
I’ve always been of the opinion that such essentialist notions of pretty much anything are probably notions you should be suspicious of. I mean, the Java compiler hides bytecode. The C++ and C that the JVM is written in hides machine code.
It goes without saying that JavaScript itself is hiding all of this.
Moreover, JavaScript isn’t a terribly good language for large applications. And it surprises me that some of the very same people who trumpet the advantages of Java over other languages, will so willingly jettison their arguments in favor Java when it comes to JavaScript. There’s no immutability, side effects are hard to control, the object model is a mess, there’s nothing resembling a threading model, etc.
To which, counterarguments often include techniques about how JavaScript prototypes can be used in ways that simulate classes and inheritance, unit testing can guard against unintended side effects in large codebase, concurrency concerns do not apply in the world of the future, etc -- as if any of this somehow redeems JavaScript in any way in the eyes of someone who buys into these notions as being intrinsically good parts of a language.
JavaScript isn’t a bad language. Don’t get me wrong. It is mature and well understood. It does what its supposed to do. But the problem is, it was never designed with large application development in mind. Its designers did not envision a world where there’d be codebases of 100,000 lines of JavaScript code.
Yet, this is the world we’re quickly moving into. And the reality is, that technologies like GWT are extremely good solutions to manage these sorts of projects.
Over the next few weeks we’re going to show you why. Watch this space.
It is a significant update that leverages all the best ideas that Errai 1.x had, while retiring some ideas and approaches that didn’t quite work out the way we’d planned.
Errai has developed a philosophy about rich application development in the browser. That philosophy might be summed up as: Your Application. Everywhere. Literally.
However, there’s been some people who’ve criticized this methodology. I’d like to respond to some of this now.
We have eschewed much of the conventional wisdom about how you should architect a web application by focusing on not just rich user experience, but rich developer experience. We believe that the latter ultimately leads to a better former.
We reject the need for polyglot applications as necessary -- the idea that the best way to build an application is to arrange a constellation of disparate languages and frameworks into a coherent single application is simply the “best approach” is something we don’t agree with.
You’re building your application in Java on the server. Why do you build the other part of it in JavaScript? The common response to this is, well, “that’s just the best way to do it”. But is it?
We don’t think it is. At the end of the day, the whole HTML5 group of technologies is just a specification that tells us how to make a browser do things.
Whether we write HTML and JavaScript directly or not, whether it’s translated from CoffeeScript, Dart, or in the case of Errai -- Java -- is immaterial. And it’s wrong to even suggest that Errai, with its use of the GWT compiler, sandboxes you into a world that proscribes any of these things. It doesn’t.
With Errai, your application can contain no JavaScript, or be almost all JavaScript.
The important part is how Errai helps you share not just model between the client and the server, but functionality. Without the need to write it twice, or write marshalling code, or worry about setting up your own comet or websockets. The communication model is central to the application development model.
Being able to share functionality, using the same code, with the same functionality is a good thing. You get all the benefits of type checking, code reuse, and productivity.
The implication that some make that, this sort of thing “hides the true nature of the web” is always one that puzzled me among those who advocate for a pure JavaScript approach.
I’ve always been of the opinion that such essentialist notions of pretty much anything are probably notions you should be suspicious of. I mean, the Java compiler hides bytecode. The C++ and C that the JVM is written in hides machine code.
It goes without saying that JavaScript itself is hiding all of this.
Moreover, JavaScript isn’t a terribly good language for large applications. And it surprises me that some of the very same people who trumpet the advantages of Java over other languages, will so willingly jettison their arguments in favor Java when it comes to JavaScript. There’s no immutability, side effects are hard to control, the object model is a mess, there’s nothing resembling a threading model, etc.
To which, counterarguments often include techniques about how JavaScript prototypes can be used in ways that simulate classes and inheritance, unit testing can guard against unintended side effects in large codebase, concurrency concerns do not apply in the world of the future, etc -- as if any of this somehow redeems JavaScript in any way in the eyes of someone who buys into these notions as being intrinsically good parts of a language.
JavaScript isn’t a bad language. Don’t get me wrong. It is mature and well understood. It does what its supposed to do. But the problem is, it was never designed with large application development in mind. Its designers did not envision a world where there’d be codebases of 100,000 lines of JavaScript code.
Yet, this is the world we’re quickly moving into. And the reality is, that technologies like GWT are extremely good solutions to manage these sorts of projects.
Over the next few weeks we’re going to show you why. Watch this space.
Wednesday, November 23, 2011
Setting the Record Straight on GWT
Since joining the Errai team, I've been telling lots of people about our project. Every time I do this, I find myself dispelling some common misconceptions about what GWT is and how it can be used. I also find people are surprised that GWT code has easy access to the browser's native environment: although GWT smooths out implementation details between browsers, it is not a firewall that cuts you off from the underlying environment.
So what is GWT?
If my GWT app just boils down to JavaScript and HTML, why bother with all this?
So what is GWT?
- A Java-to-JavaScript compiler
- A class library providing:
- a subset of the Java SE 5 standard library (most notably java.lang and java.util)
- A programmatic UI framework (somewhat like Swing)
- Java wrappers for native browser functionality such as JSON and XML manipulation, XMLHttpRequest (AJAX and Comet), and HTML 5 features like Canvas, Local storage, Audio and Video.
- An RPC mechanism you can use if your application's backend happens to be written in Java (GWT RPC can't easily be retrofitted on an existing object model, but you can use it to build a server-side RPC layer)
- GWT Designer, a visual UI layout tool that generates code for the Swing-like UI framework
- UiBinder, a system for declarative UI (you define layout in files that are essentially XHTML interspersed with GWT widgets, with named elements automatically bound to fields in a companion Java class)
- Plugins for Eclipse, Maven, and Ant that help with creating, building, testing, and debugging GWT applications
The compiler itself is fundamental to any usage of GWT. Everything that follows is optional: you can take it or leave it, mix and match, use third-party alternatives, or invent your own replacements.
And what isn't GWT?
Now that we've listed off the highlights of what is included in GWT, it's important to address what it's not:
- GWT doesn't mandate a single, prescribed way of creating user interfaces. In particular, you don't have to create UIs in a "Swing for the browser" mindset unless you want to.
- GWT is not a server-centric system like JSF. Your GWT application compiles down to a collection of static files: HTML, CSS, images, and JavaScript. The application runs autonomously in the browser, communicating with the server only when it wants to. If you're not using GWT RPC, your apps need not be hosted on a Java web server.
- GWT does not require any browser plugins. Your compiled app is just one or more standards-based web pages.
- GWT does not prevent you from writing JavaScript directly. You can write inline JavaScript in your Java classes using JSNI, you can expose your Java APIs to JavaScript, and you can call JavaScript APIs from Java.
- GWT is not a dead project. Rumours of its demise are greatly exaggerated.
That's a great question. Thanks for asking. There are many compelling reasons to use GWT over raw HTML and JavaScript. I will address my favourite reasons in a future post, along with another question that I hope is burning in your mind: if GWT does all this, what does Errai add to the mix?
Monday, October 17, 2011
Errai 1.3.0.GA released!
The Errai team is proud to announce the release of 1.3.0.GA. This is the final 1.3.0 release and includes improvements and fixes based on community feedback. We would like to thank the Errai community for raising questions, suggesting improvements and reporting problems. Please stay tuned, there's a lot more to come in the near future.
Furthermore, Mike Brock's hard work and epic late-night battle with the Maven Release Plugin (which he demonstrably won) deserves a big thank you from the rest of the Errai team (Jonathan Fuerth and myself).
Furthermore, Mike Brock's hard work and epic late-night battle with the Maven Release Plugin (which he demonstrably won) deserves a big thank you from the rest of the Errai team (Jonathan Fuerth and myself).
Tuesday, October 4, 2011
JAX-RS in GWT with Errai
The JAX-RS integration module is our latest extension to the Errai Framework. It brings another enterprise standard to the browser and simplifies the integration of REST-based services in GWT client applications.
How does it work?
To jump right in, let's assume we have the following JAX-RS interface which we want our clients to send requests to:
We simply put this interface somewhere in our client packages (e.g. client.shared) where the GWT compiler can find it. To create a request all that needs to be done is to invoke RestClient.create(), thereby providing the JAX-RS interface, a response callback and to invoke the corresponding interface method.
Error Handling
For handling errors, the existing error callback mechanism can be reused and the error callback can be passed to the RestClient.create() call. The ResponseException provides access to the Response object containing all details of the underlying HTTP response.
What does this buy you?
Errai will take care of generating the HTTP request logic for you and will automatically serialize/deserialize your method parameters. This helps alleviating boilerplate code for creating the URL, setting the HTTP headers, parsing the response, etc. By default, Errai's wire format will be used, but don't be dissuaded by that fact. Errai's wire format really is just simple JSON.
Future work
We are currently improving Errai's marshalling capabilities. One outcome of this will be a mechanism for pluggable custom serializers. So in the near future you will have the flexibility to choose your serialization format.
Interested and want to give it a try?
We have prepared a maven archetype, which generates a working JAX-RS CRUD application: https://docs.jboss.org/author/display/ERRAI/JAX-RS+Quickstart+Guide This should help getting you started quickly.
As always, feedback is welcome and appreciated!
How does it work?
To jump right in, let's assume we have the following JAX-RS interface which we want our clients to send requests to:
We simply put this interface somewhere in our client packages (e.g. client.shared) where the GWT compiler can find it. To create a request all that needs to be done is to invoke RestClient.create(), thereby providing the JAX-RS interface, a response callback and to invoke the corresponding interface method.
Error Handling
For handling errors, the existing error callback mechanism can be reused and the error callback can be passed to the RestClient.create() call. The ResponseException provides access to the Response object containing all details of the underlying HTTP response.
What does this buy you?
Errai will take care of generating the HTTP request logic for you and will automatically serialize/deserialize your method parameters. This helps alleviating boilerplate code for creating the URL, setting the HTTP headers, parsing the response, etc. By default, Errai's wire format will be used, but don't be dissuaded by that fact. Errai's wire format really is just simple JSON.
Future work
We are currently improving Errai's marshalling capabilities. One outcome of this will be a mechanism for pluggable custom serializers. So in the near future you will have the flexibility to choose your serialization format.
Interested and want to give it a try?
We have prepared a maven archetype, which generates a working JAX-RS CRUD application: https://docs.jboss.org/author/display/ERRAI/JAX-RS+Quickstart+Guide This should help getting you started quickly.
As always, feedback is welcome and appreciated!
