ECMAScript 6/7 on the JVM with TypeScript and Vert.x
Following the latest releases of Vert.x 3.2 and vertx-lang-typescript 1.1.0 I figured it would be a good idea to give you a couple of examples how teaming Vert.x and TypeScript helps you use ECMAScript 6 and 7 features on the JVM today.
The vertx-lang-typescript library adds TypeScript support to Vert.x 3. TypeScript is a typed superset of JavaScript that compiles to plain JavaScript. It supports the ECMAScript 6 (ECMAScript 2015, ES6) standard and also a few parts of ECMAScript 7 (ES7) already.
The library automatically compiles Vert.x verticles written in TypeScript to JavaScript and executes them on the JVM. vertx-lang-typescript also provides type definitions for the Vert.x JavaScript API. Use them in your favourite TypeScript editor/IDE to get auto-completion, API documentation and meaningful error messages.
Vert.x is a reactive, microservices toolkit for the JVM, that provides an asynchronous, scalable, concurrent services development model. It supports polyglot language development with first class support for JavaScript, Ruby, Groovy, Scala, and of course Java.
InfoQ got a chance to catch up with Tim Fox, the creators of Vert.x and the Vert.x lead architect to get his thoughts on Vert.x in general and the upcoming Vert.x 3 release.
Tim explains how Vert.x compares to Java EE, Spring, Akka, and explains how Vert.x is a good fit for microservices, reactive development.
InfoQ: What is Vert.x and why would someone pick it instead of a traditional Java stacks like Servlets or Java EE or Spring?Tim: Vert.x is a toolkit for writing polyglot reactive applications on the JVM. Unlike the traditional stacks its been designed from day one with microservices in mind, and it's also been designed with scalability in mind so it's almost completely non blocking (OS threads).
This is critical for many modern applications that need to handle a lot of concurrency - e.g. process a lot of messages or events, or handle a lot of connections.
Also, unlike the traditional Java stacks, Vert.x supports other languages than Java - e.g. JS, Ruby and Groovy so we don't force you to always use Java and can use the best language for the job at hand or for the skill-set of your team.
Another important point is that Vert.x is toolkit, not a container or "framework". That means you can use it within your existing application to give it the Vert.x super powers. For example you can use it within your Spring application, and many users do.
InfoQ: What are your thoughts on Spring? Spring Reactor? Spring Boot? Node.js?Tim: I have a lot of respect for Spring. They have done an amazing job in creating a rich ecosystem, and there are components that do just about everything under the sun. For me though the main advantage of Vert.x, is many of the Spring APIs are blocking and that's going to limit scalability, also Spring is largely Java only, not polyglot like Vert.x.
But I'd rather not see Vert.x as a competitor to Spring. Vert.x is unlikely to ever contain as many bits and pieces as the Spring ecosystem. Let's not forget that Vert.x is just a library and you can use it along with Spring in the same application. What I hope to see over time is more components in the Spring ecosystem becoming non blocking so they can be more successfully used in scalable apps.
We're already seeing parts of the Spring ecosystem (like project reactor) taking a non blocking, event driven approach so this is promising.
Note: Project reactor from SpringSource/VMWare came out right after Tim Fox left VMwareand joined RedHat. Project Reactor is a competitor to Vert.x and is similar in focus and style.
InfoQ: What are your thoughts on Java EE? What are your thoughts on application servers?Tim: Java EE was originally designed with a very different development and deployment model to what is required for modern applications today. Java EE app servers were all about having a monolithic server which sat somewhere on the network and into which you deployed your application packaged as a jar or an ear. This is pretty much the opposite of a microservices model.
Moreover most Java EE APIs are inherently synchronous, so most Java EE app servers have to scale by adding thread pools as so many things are blocking on I/O (remote JDBC calls, JTA calls, JNDI look ups, even JMS has a lot of synchronous parts). As we know adding thread pools doesn't get you too far in terms of scalability. So really Java EE is crippled by design and is never going to be a good choice for applications that need a lot of concurrency.
Vert.x, in many ways, was a reaction against Java EE. To be fair, in the last few years there have been movements to make Java EE easier to use, and I see valiant efforts by some to repackage Java EE as a model that is suitable for reactive microservices. But to me this seems to be a hugely uphill struggle - Java EE was never designed with that model in mind and forcing it into that would require such deep changes in the Java EE APIs that you might as well throw it away and start again. Which is exactly what we did in creating Vert.x.
InfoQ: How does Vert.x performance compare to Node.js performance?Tim: Well, you can see that for yourself - TechEmpower BenchMarks
No comments:
Post a Comment