The Angular Mini-Book is a
guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and
deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.
Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with
Spring Boot and use security best practices like HTTPS and a content security policy.
This book shows you how to build an app with JHipster, and guides you through the
plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks
so you understand the underpinnings of your great application.
I've been to JavaOne many times in my life, starting in 2004 and continuing in 2005, 2006 and 2008. I have fond memories of the first couple years, meeting all the Java open source guys and having a lot of fun.
You might notice that the aforementioned blog posts no longer show pictures. That's because they were originally hosted on Apple's HomePage, which they shut down years ago. I haven't bothered to republish the photos and fix the links, but I do still have them. For those looking for a blast from the past, checkout Mike, Howard and James or Bruce and Marc. I also have a set of photos from our Geronimo Live party in 2006.
As many of you know, JavaOne used to be a huge conference, attracting 15,000 attendees back in the day. Numbers have dwindled a lot since Oracle bought Sun and I've heard recent years are more around 1500. Since I've spoken at a lot of conferences, but never JavaOne, I figured I'd try this year. The good news is I got accepted and I'll be there next week!
10 years ago yesterday, I released the first version of AppFuse. It started with XDoclet generating ActionForms from POJOs and became very popular for Struts developers that wanted to use Hibernate. The project's popularity peaked in 2006, as you can see from the mailing list traffic below.
It's possible the decrease in traffic is because we re-wrote everything to be based on Maven. It's also possible it was because of more attractive full-stack frameworks like Grails and Rails. However, the real reason is likely that I stopped working on it all the time due to getting a divorcebecoming an awesome dad.
Below is a timeline of how the project evolved over its first 4 years.
AppFuse has been a great project for me to work on and it's been a large source of my knowledge about Java, Web Frameworks, Spring, Hibernate - as well as build systems like Ant and Maven. We started with CVS, moved to SVN and now we're on GitHub. We've experienced migrating from Tapestry 4 to Tapestry 5 (thanks Serge Eby!), upgrading to JSF 2 and enjoyed the backwards compatibility of Spring and Struts 2 throughout the years. We've also added REST support, a Web Services archetype and kept up with the latest Spring and Hibernate releases.
Last year, we added Bootstrap and jQuery as foundational front-end frameworks. For our next release, we're switching to PrimeFaces, adding Wicket and changing from jMock to Mockito. Most of these changes are already in source control, we just need to polish them up a bit and add AMP support. I hope to release 3.0 before the bus is done.
Thanks to all the enthusiastic users of and contributors to AppFuse over the years. It's been a great ride!
This week, my lovely fiancé and I traveled to the City of Light. Our journey was designed around some speaking engagements at Devoxx France. Devoxx is one of my favorite conference franchises and Devoxx France has been special to me ever since the Devoxx (Belgium) I spoke at in 2011.
2011 was the year I spoke about my experience with Play, Scala, CoffeeScript and Jade. I wrote the presentation on my flight over, composed the demo video the night before and made it all happen in the nick of time. Of course, this was after 120 hours of research and preparation, so the presentation composition process had all the data I needed. You can imagine my sense of relief after pulling off that talk and getting an enthusiastic applause from the audience for my efforts.
One of the first audience questions I received was from Nicolas Martignole, asking if I'd speak at Devoxx France the following year. I whole-heartedly agreed to do it and was excited for the opportunity. It was with great disappointment that I later found out I couldn't attend Devoxx France in 2012. My client didn't like me taking so much time off and I agreed to scale my two week vacation back to 1 week. This year, I was determined to go, so I submitted some of my favorite talks: Comparing JVM Web Frameworks and The Play vs. Grails Smackdown with James Ward. I was extremely pleased when they both got accepted.
Side Story: I met Martin Odersky shortly when he sat down next to me for the Java Posse presentation in Belgium in 2011. After shaking his hand and introducing myself, I had to politely ask him to leave because it was Trish's seat. Talk about awkward; but Martin was very gracious and promptly found a new seat close by.
Comparing JVM Web Frameworks
Both talks required a bit of updating. For Comparing JVM Web Frameworks, I started reading The Paradox of Choice and found many parallels to the agony that developers experience with choosing a web framework. I described how I didn't think good framework decisions were based on the many, many features that frameworks have, but often on pre-defined constraints. There's those lucky developers that get to choose a Full Stack Framework because they're doing greenfield development. Then there's those that want a better Pure Web Framework that replaces something (e.g. Struts) that's not satisfying their needs. And lastly, there's those that've found it possible to leverage a SOFEA and use a JavaScript MVC framework with an API Framework on the backend. I don't think it makes sense to compare all web frameworks and I tried to use these pre-defined constraints (language, platform and application type) argument to separate into categories and help make choosing easier.
I took out the parts of the presentation that've pissed people off in the past - particular the JSF bashing by James Gosling, the Rails gushing from Craig McClanahan and the Pros and Cons sections of each framework. I added the history of web frameworks and research from InfoQ and devrates.com.
The best part of the JVM Web Frameworks talk was the audience's reaction and enthusiasm. Devoxx always seems to attract passionate developers and Devoxx France was no different. Developers packing the room, clapping after your intro, laughing at your jokes, signifying that they agree with you about JSF. As a speaker, it's an unbelievable experience.
You can view my Comparing JVM Web Frameworks presentation below or on Slideshare.net.
Play Frameworks vs. Grails Smackdown
To prepare for James Ward and my Play vs. Grails Smackdown, we had a number of goals. First of all, we wanted to update our apps to use the latest versions of each framework. I documented what it took for Grails, James just checked in his code to GitHub. It was interesting to see that Grails 2.0.3 -> 2.2.1 caused a number of issues with testing, while Play 2.0.3 -> Play 2.1.0 required API changes, but nothing for tests. Secondly, we updated all the stats for our pretty graphs and ran load tests again.
This is where the fun started. On Tuesday evening, I decided to challenge the notion that Play was twice as fast as Grails. James had proven this with Apache Bench tests. With Play 2.0 and Grails 2.0 (last summer), we clocked Play at 251/requests per second and 198 for Grails. After upgrading each app to the latest releases, we found the numbers to be 233/second for Play and 118 for Grails.
However, Apache Bench only tests until the first byte is received. Since I've done a lot of browser optimizations recently, I fired up whichloadsfaster.com, captured a screenshot and added it to our presentation. The next day, James added a CDN and a bunch of caching to his app and re-ran his AB tests.
Now he was smoking Grails, so I added a CDN and caching as well. However, the best I could do was just over 1000/requests per second, while he was around 2200/second. When he ran live tests during our talk, Play was around 2800/sec and Grails was around 900.
It was great to see how much better performance we could get with caching and a CDN. The best part is this should be available to most applications, not just these frameworks. By adding a CDN (we used Amazon CloudFront) and caching, we were both able to 10x the performance of our apps. You can find our presentation here or view it below.
Summary
This was a very enjoyable conference to attend as a speaker. First of all, it was in one of the most beautiful cities in the world, but it's also a very special place for Trish and I. We got engaged just outside of Paris in Versailles after the last Devoxx conference I spoke at. Trish has some amazing photos from that trip. Secondly, the Devoxx conference attracts a special kind of developer - one that is passionate about and eager for knowledge. Lastly, speaking with my good friend James, in an exotic city about something we love - that was special. Asking for beers and having them brought to us at the start of our Smackdown. That was magical (thanks Nicolas!).
To all the Devoxx organizers and crew - well done on a great show!
In preparation for my Grails vs. Play Smackdown at Devoxx France next week, I recently upgraded my Grails version of Happy Trails from Grails 2.0.3 to Grails 2.2.1. I ran into a few issues along the way and figured I'd document them here to help others out.
Fixing the source The first issue I ran into was Spock and Groovy 2 incompatibilities.
| Resolving plugin JAR dependencies
| Error WARNING: Dependencies cannot be resolved for plugin [mail] due to error: startup failed:
Could not instantiate global transform class org.spockframework.compiler.SpockTransform specified at jar:file:/Users/mraible/.grails/ivy-cache/org.spockframework/spock-core/jars/spock-core-0.7-groovy-1.8.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation because of exception org.spockframework.util.IncompatibleGroovyVersionException: The Spock compiler plugin cannot execute because Spock 0.7.0-groovy-1.8 is not compatible with Groovy 2.0.7. For more information, see http://versioninfo.spockframework.org
I posted the problem to StackOverflow and got a response almost immediately. While this pull request helped me quite a bit, it was ultimately caused by my vision: I had two "geb-spock" dependencies listed in BuildConfig.groovy with different groupIds.
At this point, I also moved all my plugin dependencies from application.properties to BuildConfig.groovy.
The next problem I ran into was a unit test and functional tests failing. The unit testing issue was caused by my Direction model not being in the tests @Mock annotation. After I added it, validation kicked and I recognized my test was invalid. I added @Ignore and continued.
The functional test seemed to be seemed to be caused by Geb and it trying to use the Chrome Driver. One of my tests didn't work with the default HtmlUnitDriver, so I used the ChromeDriver for the one test.
| Running 11 spock tests... 6 of 11
| Failure: signup as a new user(happytrails.AuthenticatedUserSpec)
| org.openqa.selenium.WebDriverException: Unable to either launch or connect to Chrome. Please check that ChromeDriver is up-to-date. Using Chrome binary at: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome (WARNING: The server did not provide any stacktrace information)
Command duration or timeout: 45.66 seconds
Build info: version: '2.27.0', revision: '18259', time: '2012-12-05 11:30:53'
System info: os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.8.2', java.version: '1.7.0_04'
Driver info: org.openqa.selenium.chrome.ChromeDriver
at org.openqa.selenium.remote.ErrorHandler.createThrowable(ErrorHandler.java:187)
at org.openqa.selenium.remote.ErrorHandler.throwIfResponseFailed(ErrorHandler.java:145)
at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:533)
at org.openqa.selenium.remote.RemoteWebDriver.startSession(RemoteWebDriver.java:216)
at org.openqa.selenium.remote.RemoteWebDriver.(RemoteWebDriver.java:111)
at org.openqa.selenium.remote.RemoteWebDriver.(RemoteWebDriver.java:115)
at org.openqa.selenium.chrome.ChromeDriver.(ChromeDriver.java:161)
at org.openqa.selenium.chrome.ChromeDriver.(ChromeDriver.java:107)
at happytrails.AuthenticatedUserSpec.signup as a new user(AuthenticatedUserSpec.groovy:25)
Even when running "grails -Dgeb.env=chrome test-app", this still happened. This was caused by the fact that I had GebConfig.groovy in test/functional/happytrails. Move it to test/functional solved the problem. I also discovered that I know longer needed Chrome to get this test to pass. Apparently, the HtmlUnitDriver has issues with Grails 2.2, but it seems to work for me.
After getting the Geb configuration fixed, I ran into a functional test failure:
| Running 11 spock tests... 5 of 11
| Failure: click signup link(happytrails.AuthenticatedUserSpec)
| org.openqa.selenium.ElementNotVisibleException: Element must be displayed to click (WARNING: The server did not provide any stacktrace information)
Even though I could see the "signup" link when I ran "grails run-app", I could see that it didn't show up when running tests in Chrome. This turned out to be caused by an extraneous <div class="nav-collapse"> I had in my main.gsp. Removing it solved the problem. It's strange that this never showed up with Grails 2.0. My only guess is that Geb someone didn't look at the visibility of the element.
The last testing-related issue I ran into was a InvalidElementStateException:
| Running 11 spock tests... 7 of 11
| Failure: add new route to region(happytrails.AuthenticatedUserSpec)
| org.openqa.selenium.InvalidElementStateException: Element must be user-editable in order to clear it. (WARNING: The server did not provide any stacktrace information)
I was able to fix this by changing AddRoutePage.groovy from:
And then referencing name, distance and location accordingly (form.name, etc.) in AuthenticatedUserSpec.groovy.
CloudBees
After I had everything working locally, I logged into Jenkins on CloudBees. Since I hadn't used it in a while, I had to wait a bit while my Jenkins server was re-commissioned. Once it was up, I tried to select Grails 2.2.1 to build with, but found it wasn't available. After a tweeting this, I learned about Grails Wrapper, found that the latest Grails Jenkins plugin supported it and got everything working. I later discovered that CloudBees does support Grails 2.2.1, I just needed to setup another Grails installation to automatically download and install 2.2.1.
Heroku
The last two issues I ran into were with Heroku. Since I was upgrading everything, I wanted Grails to build/run under Java 7 and use Servlet 3. I changed the appropriate properties in BuildConfig.groovy, configured Heroku and deployed. No dice.
Error Compilation error: startup failed:
Invalid commandline usage for javac.
javac: invalid source release: 1.7
Usage: javac
use -help for a list of possible options
Sidenote: I tried building with Java 8 on CloudBees, but discovered the searchable plugin doesn't support it.
Compile error during compilation with javac.
/scratch/jenkins/workspace/Happy Trails - Grails 2/work/plugins/searchable-0.6.4/src/java/grails/plugin/searchable/internal/compass/index/DefaultUnindexMethod.java:94: error: reference to delete is ambiguous
session.delete(query);
^
both method delete(CompassQuery) in CompassOperations and method delete(CompassQuery) in CompassIndexSession match
As far as Servlet 3, it was pretty obvious that the Jetty version Heroku uses for Grails doesn't support it. Therefore, I reverted back to Servlet 2.5.
java.lang.NoClassDefFoundError: javax/servlet/AsyncContext
at org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:46)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2444)
I sent the Java 7 issue to Heroku Support a few days ago but haven't heard back yet.
Summary
While upgrading Grails from 2.0 to 2.2 wasn't as easy as expected, it is understandable. After all, Grails 2.2 ships with Groovy 2.0, which has a bunch of new features itself. All the issues I ran into were fairly easy to solve, except for Java 7 on Heroku. But hey, what do you expect from a free hosting service?
If you're at Devoxx France next week, I look forward to sharing our research on Grails 2.2.1 vs. Play 2.1.0.
David Díaz Clavijo sent me an email a couple weeks ago asking me about comparing web frameworks.
David is a computer engineering student at the University of Las Palmas de Gran Canaria (ULPGC) in the Canary Islands, Spain. His FYP (Final Year Project) is a web frameworks comparison focused on high productivity frameworks. He's started a blog to help facilitate his work and has been writing some interesting posts.
Four frameworks will be compared. The comparison test is composed by four fixed time tasks for each framework:
Learning the programming language: 5 hours
Making exercises in the programming language: 15 hours
Learning the framework: 25 hours
Developing the website: 50 hours
After all process is done, it can be seen which framework presented a higher productivity and smaller learning curve.
We have decided a cross-language set of frameworks which are: Ruby on Rails, Grails, Django and Code Igniter.
Sorry it took me so long to respond. I think your approach as far as learning the language, making exercises, learning the framework and developing the website is good. As you know, the last one you develop with will likely do well because you're repeated the steps so much with the other ones.
However, there's one thing I think you're doing wrong. In the real world, I don't believe that an architect would look at *all* the available web frameworks and choose one. I believe most of them already have a language bias or there's a target platform (e.g. LAMP, JVM, etc.).
I believe the majority of development happens today where a platform is already in place. Even moreso, the backend may already be in place and the company is simply trying to find a more productive front-end framework. In the first instance, where the platform is already chosen, the chooser's options are immediately limited. For example, if it's the JVM, Django might be eliminated because JPython isn't that up-to-snuff or widely used (this could be changing). However, it could be said that all the frameworks you've chosen (including Code Igniter) can run on the JVM.
I just don't see people identifying web frameworks across such a wide variety of languages. I think folks generally choose a platform, then a language, then a framework. It's possible that startups will do it differently by choosing a language first. However, I imagine most startups have a technical founder that already has some preference towards a particular language.
Now it's your turn, dear readers. Have you ever been in a situation where you've been able to pick a web framework across all languages? Did any of your biases enter into the equation?
How would you recommend David go about choosing web framework candidates?
I've been interested in integrating GWT into AppFuse ever since I blogged about it 4 years ago. A few months after that post, I wrote about Enhancing Evite.com with GWT and Grails. After Evite, I had a gig near Boston where I developed with GXT for the remainder of the year. When all was said and done, I ended up spending a year with GWT and really enjoyed my experience. I haven't used it much since.
It needs a lot of testing yet but it's getting quite there
As you can imagine, I was very excited to hear about Iván's work. So I cloned his repo, built gwt-bootstrap locally and checked it out. Functionality wise, it was great! However, when I dug into the source code, I found a whole lotta code.
To see how the GWT flavor compared to the other implementations in AppFuse, I created a cloc report on the various web frameworks in AppFuse. I'm sure these reports could be adjusted to be more accurate, but I believe they give a good general overview. I posted some graphs that displays my findings in visual form.
When I sent this to the mailing list, Ivan responded that it was a lot of code and estimated 12 new files would be needed to CRUD an entity. This sure seems like a lot to me, but he defended this yesterday and noted that his implementation follows many of GWT's latest best
practices: MVP pattern, Activities and Places, EventBus, Gin and Guice. He also shared a wiki page with explanations and diagrams of how things work.
The reason I'm writing this post is to get more feedback on this implementation. First of all, does GWT really require this much code? Secondly, are there other GWT implementations that reduce a lot of the boilerplate? SmartGWT, Vaadin* and Errai come to mind.
If you were starting a new GWT project and using AppFuse, how would you want it implemented?
I've been comparing web frameworks ever since 2004. It was the first time I'd ever proposed a talk for a conference. ApacheCon was in Vegas that year and my buddy Bruce suggested I speak at it. I submitted the talk, got accepted and went to work learning the frameworks I was talking about. At the time, I had a lot of Struts experience and I'd made a good living learning it, consulting on it and blogging about it. However, there was a new kid on the block (Spring MVC) that was garnishing attention and some other frameworks (WebWork and Tapestry) that had a lot of high praise from developers. I was inspired to learn why so many people hated Struts.
Fast forward 8 years and I'm still comparing web frameworks. Why? Because there still seems to be a large audience that's interested in the topic. Witness InfoQ's Top 20 JVM Web Frameworks, which was one of their most-read articles for two months in a row. One of the beauties of the Java Community is that it's very diverse. There's tons of folks that are part of this community and, like it or not, several folks that are former Java Developers. However, these developers still seem to maintain an interest in the community and it's still one of the largest pools of talent out there. Java is still quite viable and only seems to be getting better with age.
So the topic of web frameworks on the JVM is still hot, and I still like to write about it. For those of you still enthusiastic about the topic, you're in luck. The two best websites for the Java Community, InfoQ and DZone (formerly Javalobby) are still very interested in the topic too!
After finishing Core HTML5 Canvas, I dived into the next book on my list: The Well-Grounded Java Developer by Ben Evans and Martijn Verburg. I've known about this book since April of last year when I received an email from Martijn. He wanted to use some of my graphs and research on JVM Web Frameworks as evidence that many frameworks aren't meeting developer's needs and to support their coverage of Grails in the book.
I agreed and also did a quick review on Chapter 13, Rapid Web Development. In June of this year, I received another email saying the book was done and they'd send me a free copy. I received the book in early August, but didn't start reading it until mid September.
The book is broken up into 4 separate parts:
Developing with Java 7
Vital techniques
Polyglot programming on the JVM
Crafting the polyglot project
Developing with Java 7
The first two chapters on Java 7 and NIO.2 (aka JSR-203) were great in that I started learning new things immediately. While I knew about most of the changes (strings in switch statements, improved exception handling, try-with-resources, diamond syntax, etc.), it was a nice refresher and motivated me to install Java 7 and start using it on a daily basis. The NIO.2 chapter covers the new filesystem support with Path, the Files helper class and Asynchronous I/O.
It was around this same time that I started on Coursera'sFunctional Programming Principles in Scala. I quickly realized the course was going to take quite a bit of my free time (5-7 hours per week). It was a good challenge to try and read for 30 minutes a day as well as stay on top of my Scala homework. However, it was also highly rewarding in all the knowledge I received in the last two months.
Vital techniques
This section covers Dependency Injection, Concurrency, Class files, and Bytecode and Performance Tuning. I skimmed through the DI chapter but slowed down to try and get my head around concurrency. Then I thanked my lucky stars I haven't had to deal with it much. I found the class files and bytecode chapter mildly interesting but perked up again to learn more about how to do performance tuning, VisualVM, and the new G1 garbage collector.
Polyglot programming on the JVM
The polyglot programming section was largely a reinforcement of my existing knowledge since I've used Groovy and Scala quite a bit. The chapter on Clojure was an eye-opener since I hadn't used Clojure before. I wasn't quite convinced of its merits, but I did learn enough to read and understand its syntax. Reading the Scala chapter while doing the Coursera course made me realize that Ben and Martijn really packed a lot into each language's chapter. This section is really a great intro to all these languages, especially if you've never worked with them before.
Crafting the polyglot project
While the final section was good, I learned the least in this section. While the concepts discussed in this section are important, they're also things I've been using for years: TDD, CI, and Rapid Web Development (with Grails). This section touched on Hibernate when discussing TDD and I thought to myself - it's strange they don't have cover Hibernate (or JPA) as part of being a well-grounded Java developer. My guess is the authors assumed most Java devs already know it.
The final chapter had a lot of tips on staying well-grounded (what's coming in Java 8, how the JVM is supporting polyglot programming, future concurrency trends, and new directions in the JVM).
I really enjoyed this book and feel I became a more knowledgeable Java developer by reading it. It contained a lot of high-level concepts as well as nitty-gritty details. In my opinion, the sign of a great book is one that you feel you'll refer back to as a reference guide. The first half of this book definitely feels like something I'll refer back to. The second half I'll recommend to Java developers wanted to get caught up with the latest trends.
There is one little thing that does bother me in those presentations, and that's your fairly obvious bias against JSF. ...
If you are presenting yourself as, more or less, an authority on comparing web frameworks, then having a fairly obvious biased against one of them is just peculiar. I, all of my team, and various clients distrust your ranking of JSF. We do look at your data if the choice is between other frameworks, but as soon as JSF comes into the picture we just look elsewhere.
I'm not really sure where this bias comes from. Yes, JSF 1.0 sucked and 1.2 was only marginally better, but 2.0 is really cool and productive and there are SUPERB component and utility libraries now like PrimeFaces and OmniFaces. As a researcher of this topic I think you should keep up the date and not stick to some old grudge.
This is true, I am biased against JSF. It all started with my first JSF experience back in August 2004. If you remember correctly, 2004 was a big year: JSF 1.0, Spring 1.0 and Flex 1.0 were all released. The "AJAX" term was coined in early 2005.
Most of my issues with JSF come from having maintained an application built with it since 2004. If I were to start a new application without any legacy migration issues, I imagine it wouldn't be as difficult. However, if you compare it to Struts 2 and Spring MVC, I've had little-to-no issues upgrading those applications over the years.
Also, I'm not just biased against JSF, but most component-based web frameworks. Just ask the Tapestry and Wicket folks. They've felt my criticisms over the years. My reason for preferring request-based frameworks like Struts 2/Spring MVC and Grails/Play has been because I've never seen the appeal in component-based frameworks. Often I've found that their components are just widgets that you can get from any decent JavaScript framework. And chances are that JavaScript framework can work with any web framework. Also, I've worked on a lot of high-traffic web applications that require statelessness for scalability.
I see the value in component-based frameworks, I just don't think components should be authored on the server-side. Most of the Java-based component frameworks require 2+ files for components (one for the component, one for the view, possibly one for the config). I love GWT's component concept in that you can just extract a class and re-use it. With JS frameworks, you can often just include a script. These days, when I think of good component-based frameworks, I think of jQuery UI and Twitter Bootstrap.
All that being said, there's a lot of folks praising JSF 2 (and PrimeFaces moreso). That's why I'll be integrating it (or merging your pull request) into the 2.3 release of AppFuse. Since PrimeFaces contains a Bootstrap theme, I hope this is a pleasant experience and my overall opinion of JSF improves.
In other component-based frameworks in AppFuse news, Tapestry 5 has gotten really fast in the last year. I imagine this is because we have a Tapestry expert, Serge Eby, working on it. And we're planning on adding Wicket in the 2.3 release.
So even though I prefer request-based frameworks with REST support and Bootstrap, that doesn't mean everyone does. I'll do my best to be less-biased in the future. However, please remember that my view on web frameworks is as a developer, not an analyst. And aren't developers supposed to be opinionated?
Back in early October, InfoQ.com published a community research article titled Top 20 Web Frameworks for the JVM. Their goal seemed to be fairly simple:
Using the new community research tool, we at InfoQ want to get YOUR opinions on the relative importance and maturity of a variety of web frameworks that are targeted for the JVM. Please vote by dragging each practice across two dimensions – how important is the framework relative to the other frameworks, and how much is it actually used in real teams and projects.
When I first saw this article, I noticed some strange web frameworks listed. Namely, Netty, SiteMesh and Spark. I haven't heard of many folks using Netty for a web framework, but I'm sure it's possible. SiteMesh is certainly not a web framework and I've never even heard of Spark. And where is GWT and Vaadin? Regardless of the choices, I went ahead and voted.
Last week, InfoQ posted their top content for October on Facebook.
First of all, it's interesting to see that JVM Web Frameworks is still a hot topic for developers. Whenever I do my Comparing JVM Web Frameworks talk at conferences, I always see a few jabs about "he's still doing that talk!?" Yes, it seems strange that a talk I first did in 2004 is still in high demand.
Secondly, I think InfoQ does good in showing how the frameworks ranked and showing their heatmaps. Below are their rankings from 1109 participants.
According to this research, the top 5 web frameworks for the JVM are Spring MVC, Play, Grails, JSF and Struts (I hope those surveyed meant Struts 2, not Struts 1).
In my research from last February (slide 21), I ranked them (with no particular weightings) as Grails, GWT, JRuby on Rails, Spring MVC and Vaadin. So I guess you could say I got 2 out of 5 right (Grails and Spring MVC). Not bad considering InfoQ didn't even consider GWT and Vaadin.
Another intriguing data point in this study is each frameworks' heatmap. For example, below are heatmaps for the top 4 frameworks.
Notice how Grails and Spring MVC are both hotter in the bottom right corner? It seems the community's overall opinions of these two frameworks are more aligned than JSF and Play, which a fair amount of folks rank as hyped and unimportant.
What I really like about this research is it's the community's opinions, visualized. It also confirms that some of my favorite frameworks are still on top. I don't know if JSF belongs as a top framework, however it seems a lot of folks do. I recently thought about removing it from AppFuse, but decided to keep it (at least for the next release). I hope InfoQ does more research projects like this, especially if they get their list of web frameworks right.
