Sure. Yes, my name is Jeff Brown. I work for SpringSource and my primary responsibility there is to work on the Grails framework. Of course, SpringSource is the company behind the Grails framework and Groovy programming language, and really, a whole bunch of other technologies in the Spring portfolio. But the Groovy and Grails stuff is what I spend all of my time working on.
2. Would you like to give us an overview about what Grails 2 is and what problem it tries to solve?
Yes. So Grails is a rapid application development framework for the JVM that is built on, largely built on top of the Spring framework, and in particular, a lot of it is built on top of Spring MVC, so it targets the JVM. So if you're building a web application that targets any other platform, Grails is not for you. Grails is specifically written as a framework for building JVM web applications.
There are lots of developer productivity gains that Grails has to offer. It's very, very easy to quickly get an application up and running on the Grails framework because of a lot of things that Grails does to help with things like a convention over configuration and the sensible defaults. Literally, in a couple of minutes you can have a Grails application, a simple Grails application up and running. And from there Grails offers a lot to simplify the process of building serious enterprise web applications.
Yes. So Grails has a lot of things in common with frameworks like Rails and Django but it also has some things in common with Spring MVC, but that's a little bit different relationship. Grails is really built on top of Spring MVC. In fact, a lot of Grails application developers don't realize this but your Grails application really is a Spring MVC app, although most Grails applications don't end up having to write any code that makes it evident that Spring MVC is under the covers, but a Grails application really is a Spring MVC app.
So because of that Grails has a lot in common with Spring MVC of course. Grails has different kinds of things in common with frameworks like Rails and Django. Django is a rapid application development framework for Python, and of course, Ruby on Rails is a similar framework with a Ruby programming language. So Grails is a rapid application development framework for the JVM.
So it turns out that most code in a Grails application will be written either in Groovy or Java and most of it will probably end up being written in Groovy. So Grails has a lot of things in common with frameworks like Rails and Django, probably more in common with Rails, so we'll talk a little bit about that.
So, Rails introduced a lot of really powerful and valuable ideas. When the Rails framework came out, that was really the first big popular framework that really leveraged the powerful idea of convention over configuration. The framework provided a scaffolding to make it very easy to get CRUD applications up and running, and Grails has a lot of things like that in common with Rails.
Some folks ask if Grails is a port of Rails to the JVM and that's really not the case. Grails is not a port of Rails. Certainly, the two frameworks have a lot in common and Grails took a whole lot of inspiration from Rails particularly in the beginning but they're really a separate framework. Certainly, Grails is not a port of Rails to the JVM.
4. What would be a typical workflow for Grails development?
Yes. A particular workflow for Grails application developer - so the framework is really pretty flexible with respect to that; so there's no one general workflow that all Grails application development teams follow. But there are lots of little things within the process that Grails does that relate to workflow.
For example, Grails has a really powerful reloading mechanism, so you can have your application running in development mode, and while your application is running you can make code changes to controllers and services and views, and really, just about anything in your Rails application. You can make code changes while the application is running and save those changes to the file system and then bounce over to the browser and almost immediately see the effects of those changes.
Yes, so you wouldn't normally be doing this across application serves because the reloading mechanism is turned off by default in production mode. So when your application is running you don't want, say, a cluster of application servers, you'd be running in production mode and reloading would be turned off. You can turn it on for production and there are reasons that folks do that. But by default it's turned off and for most applications that's the right thing.
In your development environment, when you're running your Grails application, it's not running on multiple application servers, it's running on one application server, by default that's Tomcat. So there's a command in Grails. So you can type "Grails run-app" and that will start up in instance of Tomcat and quickly deploy your Grails application through that instance of Tomcat. And that's the scenario that where reloading makes the most sense, while you're development.
Enabling reloading in production is problematic, potentially problematic for a couple of reasons. One is performance. The reloading mechanism has to pretty much constantly be watching for files to change and that's useful in your development environment so you're willing to pay that price. It's not a giant price but there is a performance penalty associated with that.
In your production environment where you're not going to be changing code while your application is running or you shouldn't be changing a code while your application is running. There's no good reason to pay that performance penalty. So when you deploy your Grails application to production, the reloading agent is not enabled by default.
Yes, there are some of both actually in Grails. So Grails is opinionated with respect to things like that. For example, in Grails 2, when you create a Grails application with Grails 2, the default JavaScript library in your application is jQuery. Prior to Grails 2, the default JavaScript library was Prototype. Both are really powerful frameworks. There are a lot of things that jQuery has to offer that I think make it preferable to Prototype at this point, but they're both really powerful libraries.
So when Grails 2 was being developed, what we did was we pulled the Prototype stuff out of Grails and turned it into a plugin, and did the same thing with jQuery, we built a jQuery plugin. So with Grails 2, you can use the Prototype plugin or you can use the jQuery plugin. But when you create a Grails application with Grails 2, the jQuery plugin is installed by default. So if that's not what you want, you can remove that and replace it with Prototype.
So, that I guess is an example of the framework being opinionated. So we installed jQuery by default but that's certainly not imposed on you. If you don't want to use jQuery, you can install any other, there are really a whole bunch of JavaScript plugins for Grails. And if you're not going to use JavaScript at all, you don't have to install any of those plugins.
Yes. So with respect to Polyglot programming, you really got a number of options in the Grails framework. So there's one kind of Polyglot. So if you're building any sort of web application with Grails or you're writing a Groovy code, you're probably writing Java code or might very well be writing Java code, but certainly there's going to be HTML in JavaScript, things like that involved.
So some folks will say that that's Polyglot programming, you're using JavaScript and Groovy, and that's true enough, but I think probably what we're talking about is writing a business logic, things that you might have written in Java, maybe you want to write them in Groovy or you want to write them in Scala or write them in Clojure and Grails supports that kind of Polyglot programming really pretty well.
There is a Scala plugin for the Grails framework. There is a Clojure plugin for the Grails framework and both of them allow you to write arbitrarily complex and sophisticated code in those programming languages. How that plays out in practice? Really, if you want to build a Scala, if you want to build a web application and write most of code in Scala, there are frameworks to do that. And I guess there are similar frameworks for Clojure.
My sense is that a lot of that is still evolving or at least not as sophisticated as the frameworks for languages like Groovy and Java. But there are frameworks out there for building web applications with those languages. But maybe you don't want to go that route, you don't really want to write a whole Clojure web app but you want to write a web application for the JVM and you want to write most of it in Groovy, but there's some component that you want to write in Clojure as an example.
There's a Clojure plugin, you can install the plugin into any Grails application and the plugin makes it very, very easy for you to drop arbitrary Clojure code into your Grails web application and easily access that Clojure code. And all that is really supported by Grails' plugin system. The plug in system is the answer. It's almost all the really, really cool stuff that Grails has to offer.
The Clojure plugin literal - so I wrote a Clojure plugin a few years ago myself and literally it was - at least the core parts of it, enough to get the thing functional, it took maybe a couple of hours to write. There wasn't a whole lot of work and part of that couple of hours was me learning the Clojure Runtime API to figure out how to call in the Clojure code.
The Grails part of it was very, very easy. The plugin system makes it easy to hook into all sorts of important parts of the framework and that's what made it easy to add support for Clojure. As I've said, there's a Scala plugin and it works very much the same way.
If you develop a programming language today that no one - so it's a brand new programming language and you write - you come up with some way to call that programming language from Java, then almost certainly we could build a plugin to support your programming language in Grails.
Dio: It seems these days, everybody is a language designer.
There are a lot of language designers out there, yes.
Yes. Groovy certainly is still evolving but don't confuse that with the idea that maybe it's not mature yet. Groovy really is a mature, sophisticated, ready for primetime real production app kind of programming language, so Groovy has been there for some time but certainly the language is still evolving. The Groovy development story works out very, very well. We've got a fantastic tooling in all three of the major IDEs, so the folks at IntelliJ have had great Groovy and Grails support from the very, very beginning before Groovy and Grails really were to a point where lots of serious enterprises wanted to use the framework and the language.
But before the technology really got to a point where it was being widely adopted, the guys at IntelliJ already had really sophisticated impressive support for the language and the framework. The same is true today for Netbeans and Eclipse; so the Netbeans guys who developed a fantastic support for the language and the framework, there is the Groovy Eclipse plugin that adds lots of sophisticated Groovy support to Eclipse, to support things like autocompletion and refactoring and ctrl-click, to drill in the methods, and all those kinds of things that Java developers are used to having in their IDE.
So the Spring Tool Suite is an IDE that we produced, that SpringSource produces and there's fantastic Groovy and Grails support in the Spring Tool Suite and just earlier this year. So right now, it's the fall of 2012 and just a month or two ago, we released GGTS which was Groovy/Grails Tool Suite which is the Spring Tool Suite which is built on top of Eclipse. It's the Spring Tool Suite with all of the Groovy and Grails stuff preconfigured and preinstalled and ready to go.
So if you want to build Groovy and/or Grails applications in an Eclipse kind of environment, GGTS is really the way that most developers are going to go today. But the tooling story is really, really good for Groovy. It's not the same as the tooling support that we get for Java. There are some things with dynamic languages that are just not as practical to support from a tooling perspective as the counterparts for statically typed language are.
But the tooling has come really, really quite a long way and is very, very sophisticated, and certainly isn't any sort of hindrance at this point for folks interested in adopting the language, and that wouldn't have been the case, at least not for all developers, that wasn't the case four or five years ago. The tooling support was an obstacle for a certain subset of folks who wanted to adopt the language. They felt like the IDE support just wasn't there and that was going to be a problem for them.
For other folks, even very early on, before there was tooling support, that wasn't an obstacle. Even today, lots of folks prefer to build a Groovy and Grails applications in a sophisticated text editor as opposed to an IDE. So you've got tooling options for whatever level of sophistication you like. If you want to write all of your code in TextMate, Vi, there are bundles and all sorts of cool stuff to aid with that.
Most folks doing serious development with Grails are going to do so in an IDE and all three of the big players have great support for the Groovy programming language and the Grails framework. And GGTS I think is quickly becoming really the de facto standard tool that folks are going to adopt if they want to build Groovy and Grails applications.
Yes, so certainly frameworks do need to evolve to support those kinds of things. So HTML5 for example, when we released Grails 2 earlier this year, we replaced or updated the scaffolding templates, the default views that are generated for you when you build simple CRUD interfaces under the Grails app.
We've evolved those to take advantage of some HTML5 capabilities and that's all cool. It looks better than the old scaffolding and it's more functional than the old scaffolding but sort of on a bigger scale than just updating the scaffolding templates to use HTML5.
We've got lots of support for things like writing RESTClients and exposing RES services from within a Grails application, that's all supported by a plugin, some that we've developed and some that the community has developed. We've got so really pretty sophisticated and impressive event-based plugins.
So if you want to build a web application that's, where events are an important part of your flow, you can very easily rig up things, like you might say anytime a particular domain class is persistent to the database, I want a message to be sent to the browser. And it turns out that's very, very easy to do with some of the plugins that we've got available for Grails 2.
So, I think it's important for frameworks to support all the new technologies like HTML5 and event-based systems and JSON and continue to support whatever it is that's going to emerge over the next year or two years, however long it might be. And I think Grails in particular does, so it does a really good job of that, again, because of the plugin system.
We don't have to necessarily change Grails' core to support some new WebSocket thing that might come along. We can write plugins to take advantage of all of that stuff and for applications that want to take advantage of those things, they use those plugins and for applications that don't want to take advantage of those things, they're not suffering any sort of bloat burden because the framework is not evolving in a way that it is the union or the super set of all the things that everyone might want to do.
Really, the core of Grails is really pretty, relatively small and we've got lots and lots of plugins so you take on which plugins make sense for your application and you're not burdened with the plugins that don't make sense for your application.
Yes, there is. So, if you were to point your browser at grails.org/plugins it's where the plugin portal is and you can search for plugins there. I think as of right now again, it's the fall of 2012 right now, and I think right now there are something like 850 plugins in our public portal and there are more almost every week. So, yes, there are lots and lots of plugins out there in our portal. There are plugins to solve pretty much any problem that is common across web applications. So there are plugins for authorization...
Dio: OpenID and stuff...
Yes, OpenID, Spring security. There are lots of security-based plugins out there. There are plugins for generating CAPTCHAs, there are plugins for logging, there are plugins for lots of JavaScript plugins, all of those kinds of things that show up in lots of web applications, there are plugins to solve those problems. And as an application developer, you want to take advantage of those things, right?
You don't want to spend a lot of time writing your own security solution, that problem has been solved by other folks already. You want to take advantage of the solutions that are out there by installing plugins in your Grails application that solve those problems and then spend more of your time solving your business problem.
Dio: Also, I suppose you can take advantage of some over components from the Spring portfolio like Spring Social and…
Yes, absolutely. So Grails supports really lots of the Spring portfolio out of the box, and for the Spring things that are not supported right out of the box, there are plugins for lots of those things. Spring Security is a good example.
There's really no security stuff in the core of Grails. Certainly, lots of serious web applications need some sort of security solution but the fact that none of that is in the core is really a good thing because you get the plugin whatever security solution you like. If you want to use JSecurity, there is a plugin for that, and if you want to use Spring Security, there's a plugin for that and so forth.
So the absence of those, of something like Spring Security being in the core of Grails is not a mistake and it's not a limitation, that's a good thing. That means you get the plugin whatever security solution makes the most sense for your enterprise.
Yes. One, it's good that there are new language features coming in Java that hasn't, as you've suggested that, hasn't always been the case. So the first version I guess was 1.02. It was the first version of Java and then 1.1 came out some relatively short amount of time later and I think anonymous inner classes were introduced in 1.1.
And then I think there were no language features until 1.4 came out and there was one new keyword introduced, "assert" and that was kind of a big deal. It was really the first big, the first language change since 1.1 had come out. And then Java 5 came out and there were like 10 or 12 new language features, annotations and static imports and enums and the enhanced for loop; that group of features that were introduced in Java 5.
And that was a really big deal because Java developers weren't used to getting new language features. It just didn't happen very often. There were lots of library changes, the collections API was introduced and lots of things changed in the core libraries but the language didn't change. So it was kind of a big deal when Java 5 came along and there were a bunch of language features introduced.
In Java 8, so I guess the big thing that the folks talk about is Lambda Expressions are coming in Java 8. Of course, Groovy already has support for Clojures but it's important that Java has support for something like that. So the Lambda Expression stuff that's coming in Java 8 is going to be relevant to Groovy even though we've already got really good and really sophisticated Clojure support.
One of the reasons that's important is things like the API on the standard collections, so things like Java, that you told that list and so forth. If the Java language provides standard support for - or provide support for Lambda Expressions then presumably there are going to be things in the library that will take advantage of those, things that make it easy to use Java 8 Lambda Expressions for iterating over collections and things like that.
So there will be standard APIs for doing that sort of thing and one of the things that we're going to need to do with Groovy is come up with ways to take advantage of those standard APIs from your Groovy code, right? And maybe that will be; so I don't know how that's going to shake out.
But certainly, we're going to have good - we'll end up with support for writing Clojures in Groovy or something like what we call Clojures today in Groovy and interacting with APIs that are written to deal with a more general - more generally the Java 8 Lambda Expressions that are coming.
Dio: Thank you very much, Jeff!
Certainly.