In recent years, new trends like mobile clients and social networks forced web applications to handle more and more concurrent connections. This resulted in new server architectures based on eventing and asynchronicity which you can find in nginx or Node.js. In 2011, Tim Fox started development on Vert.x, a polyglot JVM variation of this architecture. Vert.x allows developers to build their systems with JavaScript, Groovy, Java, and other languages - mixed within one application.
Recently, Tim released version 2.0 of Vert.x. InfoQ got in touch with him to find out, what's new in Vert.x:
InfoQ: Could you please tell us about the key features of the Vert.x update?
Tim Fox: We have a lot of new and improved stuff in Vert.x 2.0, but I'll highlight a few of the major areas:
Firstly we've done an extensive general review and cleanup of the core APIs, including the addition of many new features that have been requested by the community. The end result is a better, more consistent, and more useful set of APIs.
Secondly, we've created a more modular, extendible Vert.x. We have introduced a powerful new module system and much functionality in Vert.x is now provided in the form of modules, this includes all language support - the main Vert.x project now only understands Java, and all the other language implementations are provided in the form of modules - so you only install what you need.
Vert.x is now much slimmer and more streamlined - the distribution is only 4.5 MB in size. The idea with the module system is we want to encourage an ecosystem of Vert.x modules created by the community in a decentralised way. We've also spent quite a lot of time in streamlining the class-loader system to make it more efficient and allow you to share resources between applications more easily.
Thirdly, we've concentrated on ease of development with Vert.x 2.0. We have a new Maven archetype which allows you to easily create and get going with a Vert.x Maven project. We have a Gradle template project if you're a Gradle user. We have a test framework which allows you to write Vert.x tests as JUnit tests but have them automagically run in the Vert.x container.
We've also concentrated on making the IDE experience as seamless as possible - you can now run, debug and test Vert.x modules in your favourite IDE without any special configuration or setup. Another nice feature we've added is auto-redeploy of Vert.x applications when running in your IDE (or text editor) - so now you can make changes to your Vert.x code or other files and they will automatically cause redeployment of your running application without any build step or manual restart required.
InfoQ: Do we have support for new languages? Is it possible for language designers to make their language compatible for Vert.x?
Tim: A part of making Vert.x more modular has meant that all language implementations in Vert.x other than Java are not part of the core project, and are instead provided as modules. Any user can create new language support easily in Vert.x by just creating a new module without having to change core Vert.x at all. There is some more information on how to do this. Doing it this way allows us to decentralise all language development in Vert.x. Currently there are teams working on providing Scala and Clojure support - this development is well advanced.
InfoQ: Can you observe a "favourite" language within Vert.x?
Tim: Many of our users in Vert.x seem to come from current JVM users fed-up with the current application platforms and who wish to try a different approach. We see a lot of interest in using Java and JavaScript with Vert.x, but we also have a lot of interest in using Vert.x with other languages such as Groovy and Ruby.
Java 8 will be a good thing for Java users of Vert.x as it introduces lambdas which make working with asynchronous APIs much easier. I'm also looking forward very much to Scala and Clojure support as this will allow us to have a solution for those Java developers currently leaving Java for Scala/Clojure with other application platforms.
InfoQ: Let's talk about the module system behind Vert.x. How many modules are there right now? Do I have the possibility to use JavaScript packages from npm? How hard is it for a developer to contribute a module?
Tim: The module system is still very new (only one week old), so we don't expect to have nearly as many modules as npm yet! But the Vert.x module system works differently from npm - we do not provide a centralised module repository, instead we let developers use other well known module repositories, e.g. Maven Central and Bintray, and Vert.x just understands those.
The idea behind the module system is to empower the Vert.x community to create and share their modules without having any centralised bottleneck through which everything is controlled.
We also provide a module registry where users can register their modules, this allows others to look them up, but we do not store the actual modules there. There is no requirement that users register their modules in the registry - it just makes them easier to look them up by other users if they do.
We don't currently support npm repositories but we could consider adding support for them. There is a team working on providing drop-in support (i.e. API compatibility) for Node.js - this will be a huge feature and will let users run Node.js apps on Vert.x without any changes to them, and provide an on-ramp to the better polyglot world of Vert.x. Perhaps when that is released it would make sense for Vert.x to understand npm repositories.
InfoQ: One simple question ... Why would I chose vert.x over Node.js?
Tim: There are many reasons, and often it's a no-brainer. Vert.x can do pretty much anything Node.js can do, and more. So if you're thinking of developing an application for Node.js then it's definitely worth looking at Vert.x. I'll pinpoint a couple of areas where Vert.x really excels over Node.js:
One area is performance - for many applications, Vert.x beats Node.js hands down in terms of performance. Vert.x 2.0 has many performance improvements over Vert.x 1.x (which was already faster than Node.js in many benchmarks), plus we're leveraging the power of the JVM which is truly an unrivaled virtual machine. We also work very closely with the Netty team - in fact Norman Maurer, who is a core developer on Vert.x is also a core developer on Netty. Norman has made some truly impressive performance gains in Netty 4.0 which is used in Vert.x 2.0.
Another area is in choice of language. Node.js is JavaScript only. That's great if you want to do everything in JavaScript, but not so great if you don't. Vert.x supports Java, JavaScript, Ruby, Groovy and Python. There are also teams working on Scala and Clojure support.
Superficial comparisons of Vert.x and Node.js are valid, but really Vert.x is much more than just a "Node.js for the JVM", it's a lot bigger than that - it's a polyglot, distributed application platform. In some ways you can think of what Node.js does as a subset of what Vert.x does, but the goal of Vert.x is much broader.
InfoQ: It's not only the release of version 2.0, it's about Vert.x' first birthday, too. How grown up is software after one year? How large is the user base? What are the big references?
Tim: Vert.x is a community project and we don't provide any paid support, so I don't have companies on the books that I keep a register of, however I do know there are many people who are currently using Vert.x in production, including some big names.
InfoQ: Please describe the sweet spot for Vert.x. Or the other way round - what types of applications are not suited for Vert.x?
Tim: Vert.x is very much a general purpose application platform, and is suited to most types of application. We have a broad aim with Vert.x and are targeting mobile, web and enterprise applications. As the number of modules providing new functionality increases in the Vert.x ecosystem we hope Vert.x will become an even more popular choice for people writing applications and who are otherwise considering more traditional platforms (e.g. JavaEE or Rails).
We're currently seeing a lot of people considering Vert.x for web applications - in particular server-push type applications that require a lot of connections to be supported with great performance - Vert.x really excels in this area due to it's great non blocking support.
InfoQ: Often, when I have discussions about Vert.x (or Node.js), people ask me, how much benefit there really is compared to an ordinary JEE stack. Given that sweet spot application from above, how much hardware can be saved, or how much more traffic can be handled?
Tim: It's very hard to give an answer to that, the numbers depends very much on the particular application. But for very high throughput applications, e.g. those very heavy on connections - social networking apps are a good example - a non blocking approach is essential and traditional application platforms just don't deliver there.
But it's not all about performance and scalability. It's true that many apps just don't need that level of scalability. For these other apps, Vert.x still provides an advantage in it's lighter, fresher approach to application development. Vert.x is very lightweight and easy to get going with, with the minimal of configuration - it's a totally different approach to the JavaEE approach, and this is very attractive to developers, and seems to be the way the market is moving. Vert.x is also embeddable in existing Java applications.
InfoQ: Do I need special OS support to leverage the concept of asynchronicity?
Tim: No special OS support is required.
InfoQ: At the beginning of 2013, there was some discussion on the future of Vert.x. Could you tell us a little bit about this and the final results?
Tim: Everything has been resolved really well. The main Vert.x project is moving to a neutral entity - the Eclipse Foundation, and is not controlled by any one company - we have developers from both Red Hat and VMware as core developers of the Eclipse project.
The trademarks have been transferred to Eclipse, and Eclipse is trying to make the transition as painless as possible, for example we can continue to run the project on github. So most day to day activities will continue as normal. We expect the move to Eclipse to be completed over the next few weeks.
Tim Fox started Vert.x in 2011 while working for VMWare. He is still leading the Vert.x project, now being senior principal software engineer at Red Hat.
