Category Archives: Javascript

UI Survey 2017: Java vs. JavaScript

Recently, I’ve seen a number of surveys covering the popularity of Java and Java UI frameworks. Most surveys show that either Spring or Java EE is more popular. However, they don’t answer two important questions: is Java becoming more or less important? Currently, I’m mostly interested in UI frameworks, so the next logical question is: what is the market share of Java UI frameworks compared to JavaScript UI frameworks?

To my disappointment, I didn’t find a clear answer, neither by researching the internet nor by asking the question on Twitter. So I’ve started to gather information myself. That wasn’t easy, so most of the article is based on indirect hints and educated guesses.


My first surprise was when I learned about ng2-bootstrap in December 2016. At the time, Angular2 itself was still brand-new. So it won’t surprise anyone that the third-party libraries had a hard time catching up. In other words: At the time, ng2-bootstrap was a promising library, but it still had a long way to go. Compared to BootsFaces, it’s still a tiny library. In early April 2017, it consists of merely 17 components, as opposed to the 74 components of BootsFaces.

Nonetheless, ng2-bootstrap had been downloaded 70.000 times in December, give or take a few. In early April 2017, the download counter even shows 204.000 downloads per month. Compare this to 2.000+ downloads of BootsFaces per month. Oops! Such an unfinished library is 100 times more popular than the fire-proven BootsFaces?

Of course, BootsFaces is one of the smaller JSF frameworks, but even the so, ng2-bootstrap seems to be more popular than all JSF component libraries together. My curiosity was piqued.


Another indicator of the popularity of a framework is Google Trends. I’ve compared the number of search requests of JSF and Spring MVC:

Comparing the Google Trends of JSF and Spring MVC
Datasource: Google Trends (

Both frameworks seem to be roughly equally popular. JSF used to be much more popular in the past, but it has lost a lot of popularity in recent years.

Actually, the dwindling number of search requests may have a different reason. In 2004, there were three times as many search requests to JavaScript than today. But it’s unlikely JavaScript is used less today. It’s much more likely that developers ask other questions today. Or maybe they simply ask less question because they’ve learned how to work with JavaScript. The same may hold true for JSF. I’m even told JSF is gaining traction again.

Adding Angular and React to the equation

However, adding AngularJS and React.js to the trends analysis changes the image radically. There are 10 times as many search requests for React.js and 20 times as many search requests for AngularJS:

Comparing the Google Trends of Angular, React.js, JSF, and Spring MVC
Datasource: Google Trends (

Again, that might simply mean that there are twenty times as many problems with Angular than with JSF. Plus, the search may be biased by my selection of search keywords. For instance, both Angular and JSF are “topics” of Google Trends, while React.js is categorized as a “JavaScript library”. Spring MVC is merely a search term. So it’s hard to say whether “Spring” or “Spring MVC” is the better keyword to find out about the UI framework of Spring.

Be that as it may, the trends are impressive. Plus, I’m working with Angular2+ on a daily basis. It’s a good framework, not a source of problems. Still, the huge quantity of Google searches may simply mean the developers are still learning how to use Angular. But I believe the trend also indicates that Angular and React.js are more popular than Spring MVC and JSF.

What about other frameworks?

I know that there are countless other UI frameworks, both in the Java realm and the JavaScript universe. I’ve limited my research to these four frameworks because they seem to be the most popular ones. I’ve entered quite a few other frameworks in the search bar. That didn’t change the results significantly, so I didn’t include them in the charts.

Trends of programming languages

Another indicator is the popularity of JavaScript and TypeScript. In many rankings, JavaScript, Java, and C are the most popular languages. Even if the Tiobe index indicates that JavaScript and TypeScript are much less popular than Java: Java is a general purpose language, while JavaScript and TypeScript are still being used almost exclusively in the browser. It’s possible to write server or desktop applications using JavaScript, but if I’m not mistaken, that’s still a small niche.

The last indicator is the strategy of PrimeFaces. Recently, they spend a lot of time developing the JavaScript offsprings of their JSF framework. I gather that has something to do with market shares.

Wrapping it up

For some reason, it’s hard to find information about the market share of Java and JavaScript UI libraries. Such surveys are sparse, and most of them concentrate either on Java or JavaScript. So much of this article is speculation. Nonetheless, I’m under the impression that the JavaScript UI market is five to ten times larger than the Java UI market.

Come to think of it, that’s not surprising. Java UIs are almost always used with Java back-ends. Client-side web application can be used with any back-end. That includes .NET, SAP, databases with REST APIs and even PHP. Plus, JavaScript is the language of choice for web designers.

However, I’m surprised that Angular seems to be so popular in the JavaScript world. Angular specifically targets enterprise applications, and that’s only a small fraction of the JavaScript applications. I reckon much of the rise of Angular and – to a lesser extent – React.js is at the expense of traditional server-side web frameworks.

By the way, that doesn’t affect my commitment for BootsFaces. Even if the estimated community of roughly 10.000 developers is small in comparison, that’s still the population of the village I’m living in. And it’s a lot of fun to help so many developers!

Dig deeper

Java Web Frameworks Index February 2017 by RebelLabs
Spring MVC vs. JSF
Spring MVC vs. JSF vs. Angular vs. React
License of the Google Trends screenshots

Date Patterns Cheatsheet: Moment.js and Java’s SimpleDateFormatter

More and more projects seem to abandon Java as a front-end programming language in favor of JavaScript. Usually, they keep with Java as the backend programming language. Most of the time, both ecosystems exist peacefully. But there are sources of confusion. One of them being dates and times.

Does this sound familiar? Yes, you’re right. Dates and times are a pain point of Java since day one. JavaScript just adds another layer of complexity to this.

Moment.js is a very popular library to deal with dates and times in JavaScript. So I’ve assembled an interactive cheatsheet helping you to convert the formats into each other.
Continue reading

Newsflash: Saving HTML Pages or Snippets as an Image

There’s a nice JavaScript project allowing you to save HTML snippets as an image. I didn’t test it yet, but the Fiddles look nice (for instance, this one).

Basically, the library traverses the DOM, using an HTML5 canvas to draw the elements it finds. In other words, it’s an HTLM rendering engine written in JavaScript. Most likely, that means that the library only supports a small fraction of the giant set of HTML attributes and elements. But still, it seems to support many common use cases.

Another approach is putting foreign objects into an SVG and to draw that SVG image into an HTML5 canvas. The foreignObject is currently only partially supported by most browsers, but even so it seems to do the trick for many common usecases.

How to Connect HTML Elements With an Arrow Using SVG

The other day, had a list of items on the left-hand side, and another list of items on the right-hand side. Some of these items are connected, some of them are not. Wouldn’t it be nice to show this by connecting the item with an arrow?

At first, there’s nothing new here. We’ve been drawing and connecting boxes, circles and arbitrary shapes in the IT business for ages. Just think of flow charts or organigrams. There’s even a nice PrimeFaces component for that.

The problem is that my application was an Angular2 application, not a JSF application. Plus, the PrimeFaces component, which is really nice, didn’t match my requirements. I didn’t want to display a flow chart. The boxes I wanted to connect contain live data and even images. So the task is to connect arbitrary <div /> elements with an arrow.

At first, the task seems a bit intimidating, but once I’ve started to delve into it, it became surprisingly simple. Simple enough I can even provide the source code at the end of the post.
Continue reading

Electron Brings JavaScript to the Desktop

Let’s continue my “Java on the desktop” series with something that’s not Java, but interesting nonetheless. Electron is a framework wrapping your HTML5 application in a native window of your operation system. Other than most projects in the JavaScript universe, Electron does not follow a “mobile first” approach. Quite the contrary, it’s fairly opinionated in that it supports only three platforms: Windows, OSX, and Linux. This includes access to your computers file system and access to the Windows registry via third-party NPM modules. If I’ve got it right, it even allows you to install your application as a Windows service, which is kind of scary. You know, not too long ago every security expert recommended deactivating JavaScript in the browser because of alleged security risks. Obviously, we’ve come a long way.
Continue reading

Let’s Make JavaScript Development Simple Again!

Recently, I’ve grown increasingly uneasy about the current state of JavaScript development. I’m a full-time Java developer who tries to get familiar with JavaScript. Over the years, JavaScript has become a really nifty programming language. There’s hardly anything you can’t do with JavaScript. It’s one of the most exciting areas of development in 2016.

Only… each time I start to read a tutorial about JavaScript, I feel stupid. I know I’m not stupid – at least if it comes to programming – so the explanation must be something different. I freely admit I’m lazy. That’s a valid explanation why I don’t cope with most tutorials.
Continue reading

Getting Started with TypeScript

The other day I showed a TypeScript program to our architect. He doesn’t like JavaScript, but when he saw my TypeScript program, he was pleasantly surprised. TypeScript looks pretty familiar to Java programmers, making it a good language to get started with client-side programming. Plus, the core feature of TypeScript is types, making development much more fun. I know fans of dynamic types disagree, but wait until you’ve seen the autocompletion and refactoring features of your editor before you judge. Be that as it may: TypeScript comes with powerful type inference, too, so most of the time you can use it as a dynamically typed language and still benefit from types. If you’re still sceptical: hard-core JavaScript may be relieved to learn types are optional.

After a couple of works I’d say that TypeScript is the language of choice for me. In earlier times, I’ve propagated Dart, which is an even nicer choice as a language. Unfortunately, Dart suffered from needing a virtual machine of its own, and the lacking interoperability with existing JavaScript code. So, it didn’t make a bit impact on the market yet, so I prefer a language that compiles natively to JavaScript.

So, I’ve decided to write a tiny tutorial on TypeScript. It’s not an exhaustive step-by-step tutorial. I can’t beat the official TypeScript manual, so I won’t even try. Instead, I’ll give you a short tour-de-force from a Java programmers perspective.
Continue reading

Comparing JavaScript to ECMAScript 6

Not long ago, the specification ECMAScript 6 – the successor of (guess what) ECMAScript 5, more commonly know as current JavaScript – has been finalized. Already browser developers are busily implementing ECMAScript 6 features into their browsers. So it’s interesting to compare the two versions of the language. As to my impression, ES6 is much more concise, legible and accessible to developers coming from classical object oriented languages.

Ralf Engelschall compiled a nice comparison of typical snippets of the two languages.

There’s also a comprehensive compatibility matrix. It’s interesting that at the time of writing even the best transpilers don’t exceed 59% (Traceur) or 71% (Babel+core.js) compatiblity (according to the compatibility matrix). On the other hand, the most popular desktop browsers – which are targeted at the mass market and can’t afford to implement features speculatively, only to remove them later – support ES6 already remarkably well, most of them exceeding the 50% mark.

An Alternative API to JSF AJAX

As BootsFaces gains traction, people start to ask for AJAX capabilities. We’ve implemented some rudimentary AJAX support, but obviously that’s not enough. Developers need the full power of JSF 2.2 AJAX.

Funny thing is they demand it precisely the way JSF 2.0 defines it. It was a really clever approach when it was introduced. But I think in 2015 we can do better. I was always puzzled by the slightly counter-intuitive approach of JSF AJAX. Why do we have to use a facet to activate AJAX? Why do we need so many ids? And what does the attribute name execute mean, for that matter? For execute doesn’t execute anything. Instead, it defines which data to send.

The tradional JSF approach to AJAX

   <h:inputText id="name" value="#{}">
   <h:commandButton value="Welcome Me">
      <f:ajax execute="name" render="output" />
   <h:outputText id="output" value="#{helloBean.sayWelcome}" />	

The PrimeFaces approach

PrimeFaces shows us how to do thing better and more concise. Actually, AJAX and the superior search expressions are the two top reasons why I’m so fond of PrimeFaces. PrimeFaces allows for a very compact definition of AJAXified command buttons:

   <h:inputText value="#{}" />
   <p:commandButton value="Welcome Me" 
                    process="@previous" update="@next" >
   <h:outputText value="#{helloBean.sayWelcome}" />

We’ve got rid of the facet, we’ve got a powerful expression language allowing us to get rid of the ids and we’ve got much more intuitive keywords to define which inputs fields to send and which region of the DOM is to be updated.

Unfortunately, even PrimeFaces uses verbose event facets for almost every other AJAX event:

<p:inputText value="#{userBean.firstname}">
     <p:ajax event="keyup" 
             update="@next" listener="#{userBean.onKeyUp}"  />
<h:outputText value="#{userBean.firstname}" />
<p:inputText value="#{userBean.lastname}">
     <p:ajax event="blur" 
             update="@next" listener="#{userBean.onBlur}"   />
<h:outputText value="#{userView.lastname}"/>

The BootsFaces approach: a proposal

Now, let’s go one step further. Most interactive BootsFaces components already have quite a few JavaScript callbacks: onclick, onchange, onblur and so on. Why don’t we use precisely these callback attributes to define AJAX behaviour?

<b:inputText value="#{userBean.firstname}" 
             onkeyup="#{userBean.onKeyUp}" update="@next" />
<b:outputText value="#{userBean.firstname}" />

<b:inputText value="#{userBean.lastname}" 
             onblur="#{userBean.onBlur}" update="@next" />
<b:outputText value="#{userView.lastname}"/>

Note there’s a double use of the JavaScript callbacks. The general idea is to act differently according to the type of the onblur and onkeyup methods. If it evaluates to a string, it’s a Javascript method. If it evaluates to a method, it’s a JSF method.

This way, you’ve got a simple, intuitive API allowing for very concise code. Using the callbacks you even veto (i.e. prevent) the default action from taking place – a feature that’s lacking in the JSF world for some reason, but has always been possible in the Javascript world by simply returning false.

Update April 9, 2016

In the meantime I’ve implemented my proposal. Now it’s part of the current BootsFaces releases. But my proposal didn’t make it into the productive code without changes. Using the EL syntax for JSF calls is a nice idea, but it simply doesn’t work. For one, this approach would prevent you from defining the JavaScript code in the bean. No matter how unusual this use case may seem: it’s a valid use case, so BootsFaces should support it. Second, there’s simply no way to distinguish between a simple string and an EL expression. So I’ve decided to modify the syntax of my proposal. In the early days, developers used to prefix their JavaScript code with “javascript:”. So why don’t we follow this tradition and prefix our AJAX code with “ajax:”? Hence, the current syntax looks like so:

<b:inputText value="#{userBean.firstname}" 
             onkeyup="console.log('before the AJAX call');
                      javascript:console.log('after the AJAX call');" 
                      update="@next" />

Note that the second log is called after submitting the AJAX request, but it is executed almost always before the AJAX response is processed. That’s the nature of AJAX: it’s asynchronous.

What about you?

If the majority of you, dear readers, doesn’t feel comfortable with the double use of the callback methods, we could also introduce additional callback methods. For instance, we could call the callback methods onClickJava, onBlurJava, onChangeJava, onDragStartJava and onDropJava. Personally, I don’t think that’s necessary, but it’s you who count, so I’d like to hear from you. How do you like the idea? Which implementation would you like to see in implementation? Do you prefer the standard JSF way using event facets? If so, why? Or why not, for that matter?

Using Grunt in Mixed Java and JavaScript Maven Projects

In recent years, JavaScript is becoming more and more popular – even in Java programs. It’s hard to evade the temptation to pimp up your Java program with a bit of JavaScript here and there. Or a jQuery plugin. Before long, you’ve got a lot of JavaScript code. Now, you’ve got Maven to manage your Java builds. What about the JavaScript part of your application?

Why should I use Grunt?

Grunt is one of the most popular JavaScript build tools. It’s really powerful. Even the plain vanilla tasks are interesting enough: combine and minify both JavaScript and CSS files. But Grunt doesn’t stop there. It can also minify images, or compile LESS and SASS files to CSS. Another interesting option is to run JSHint, a tool detecting potential errors in your JavaScript code (following the Lint tradition).

By the way, I expect this article to grow over time as I gather experience with Grunt. Feel free to leave comments to foster this growth :).
Continue reading

Newsflash: Compiling Java to Javascript

These days I stumbled upon Dukescript, which is a very innovative and ambitious approach to bring Java to various client platforms: traditional desktop applications, iOs devices, Android devices and the browser. Two of these target platforms – the desktop and Android – run Java natively (at least after installing a JRE in the case of desktops). Running Java on iOS is a brain-twister, but RoboVM takes the scare out of it, I’m told. Which leaves the browser, and that piqued my curiosity: Dukescript uses Bck2Brwsr to compile Java to Javascript.
Continue reading


When I heard about Scala.js a couple of years ago, I thought to myself: “Well, that’s an interesting project, but sure it’s bound to fail”. Only it didn’t. The other day I’ve stumbled over an impressive technology demo. You can write a ray tracer in object-oriented and functional Scala, compile it to Javascript an run it in the browser. Ray tracers are power-hungry, so the good performance shows that Scala.js generates surprisingly good code. I didn’t run benchmarks, but judging from what I’ve seen I believe Scala.js is “good enough” on a modern browser. Native Javascript may be faster, but in many cases you won’t notice the difference.
Continue reading

Newsflash: Google to Support AngularJS 1.x Longer, Dropping AtScript

According to Jaxenter, the AngularJS team reacted to the harsh reaction of the Javascript community on Google’s AngularJS 2.0 plans.

As a consequence, they decided to support AngularJS 1.x longer, giving companies who’ve already invested in AngularJS applications more time to migrate to AngularJS 2.0. Plus, they decided to drop AtScript. Instead, the team decided to merge AtScript with Microsoft’s TypeScript. That’s a pity because AtScript seemed to be an interesting language, but at the same time it’s good news since alternative browser languages start to cannibalize each other’s market share.

Read the full story at Jaxenter.

By the way, the original AngularJS 2.0 plans reported about have changed considerably in the meantime. The AngularJS team listened to the feedback of the community and adapted their former, much more radical ideas in order to align better with existing editors, existing tools and older browsers. Read the current state of the discussion at the AngularJS design documents folder.

Newsflash: AngularJS 1.3 Released

Oct 15, 2014. AngularJS 1.3 aka “superluminal-nudge” has been released two days ago. AngularFaces will support AngularJS 1.3 starting with the next version (AngularFaces 2.1).

According to the AngularJS blog, AngularJS 1.3 contains 400 bug fixes, a lot of performance improvements – both concerning speed and memory consumption – better support for users with a handicap and much more. An improvement I particularly like is ng-messages, a directive that simplifies the tedious chore of adding error messages (even if it’s still a far cry from the ease of use of <pui-message /> of AngularFaces):

<form name="myForm">
<input type="text" ng-model="field" name="myField" required minlength="5" />
<div ng-messages="myForm.myField.$error" ng-messages-multiple>
  <div ng-message="required">You did not enter a field</div>
  <div ng-message="minlength">The value entered is too short</div>

Code cited from the documentation of ng-messages

AngularJS also contains an improved model binding engine. For instance, AngularJS 1.3 supports one-time binding, a feature that’s already familiar from AngularDart. If you don’t want to update a value once the page has been loaded, one-time binding improves performance considerably. Another nice feature ng-model-options, which allows you to fine-tune the model updates. For instance, you can restrict model updates to certain events, such as leaving the field:

<input type="text" 
       ng-model-options="{ updateOn: 'blur' }" />

This feature comes in handy if you’ve got a circular dependency of fields containing calculated values that can be modified by the user (just think of three input fields, displaying a simple equation such as a = b + c).

According to the blog, using a short-hand dependency syntax often blocks minification. To notice such errors during development time, AngularJS 1.3 introduces an optional strict DI mode.

Dig deeper:

Announcement on the AngularJS blog

Newsflash: React Speeds Up AngularJS Rendering

Today I’ve read about a small but interesting framework called React.js that convinced me to start a new series on this blog. Newsflashes are small articles, just two or three sentences, describing an interesting idea and providing a link to read on. They are less thoroughly researched than the full-fledged articles of Instead I’ll go with my guts to choose interesting bits of information.

React is a lightweight Javascript framework focusing on the UI. According to the project page, using a virtual DOM difference algorithm makes it very fast. Thierry Nicola decribes in his article how to combine AngularJS and React to make your AngularJS application faster.

While the effect is impressive, chances are you’re going to benefit from React without having to use it yourself. My bet is many frameworks, possible even browsers, are going to use virtual DOM by default.

What About TypeScript? A Java Programmers Perspective

Is it a déjà-vu, or did I accidentally enter a time machine this morning? A couple of minutes ago I saw a video introducing two brand new features: Intellisense (aka auto-completion) and refactoring. It wasn’t even a particularly fancy refactoring – just “rename variable”.

And it felt just great!

Believe it or not, even in 2014 there’s still a wide range of popular programming languages that simply aren’t suited for autocompletion, let alone complex refactorings. One of them isn’t merely popular, it’s ubiquitous: Javascript.

So today I’m going to introduce you to TypeScript, a language trying to adress some of the issue of current Javascript while trying to keep the spirit of the language alive.

Continue reading

Google Adds Asm.js Test To Its Octane Benchmark

Google enhances its Octance Benchmark measuring Javascript performance in an interesting way. It adds two benchmarks measuring technologies developed by Google’s competitors: Typescript has been developed by Microsoft, while asm.js is a Mozilla project aiming at speeding up a subset of Javascript. Google does not support the asm.js. According to them it’s better to optimize the entire Javascript runtime instead of focusing on a subset of it. In my eyes this is a convincing argument: asm.js code is designed to be generated by compilers, not by humans. As for now Javascript compilers like Dart, Ceylon, Kotlin or Typescript haven’t had that much of an impact. The majority of Javascript code is written by humans.
Continue reading

AngularFaces: Synchronize Angular Models With JSF Beans

Fork me on GitHubThis component is different.

Thus far every AngularFaces component was essentially a JSF component with some AngularJS sugar on top of it. <a:sync> works the other way round. It enables a pure AngularJS application to benefit from the JSF engine. Every time a JSF request is submitted, <a:sync> moves parts of the AngularJS model to the JSF bean’s attributes. A little later, when the response is send to the client, <a:sync> injects JSF bean attributes into the model of AngularJS.

Strictly speaking, the “a” prefix of the library makes <a:sync> sort of a misnomer. It’s not about doing thing in an asynchronous way. It’s about synchronizing AngularJS models with JSF beans.

Update Sept 16, 2014
AngularFaces 2.0 takes a different – and better – approach to adding fuctionality to JSF. This article describes the older version AngularFaces 1.0. However, <a:sync> is also part of the new version. Now it’s called <ngsync>, and synchronizing data from the client back to the server has been postponed to version 2.1 of AngularFaces. Have a look at the tutorial at if you’re interested in AngularFaces 2.0 and above.

Continue reading

AngularFaces: Comboboxes, Checkboxes, Sliders and 3D-Graphics

Fork me on GitHubWhen I learned about threejs two weeks ago, I immediately knew the next AngularFaces demo would look fancy. Threejs makes it easy to explore the third perspective in the browser. I even daresay threejs makes Javascript is the language of choice to do fast 3-D graphics.

Most people agree number crunching isn’t the natural domain of Javascript. So I hope to convince you it’s sensible to do the calculation of a Mandelbrot set on the server and to do the 3-D magic on the client1.

Along the way, I added three components to AngularFaces: Comboboxes, checkboxes and sliders are new kids in town, while <a:commandButton> and a couple of other components and tools learned some new clever tricks.

Let’s have a look at the details.

Update Sept 16, 2014
AngularFaces 2.0 takes a different – and better – approach to adding fuctionality to JSF. This article describes the older version AngularFaces 1.0. Have a look at the tutorial at if you’re interested in AngularFaces 2.0 and above.

Continue reading

  1. Frankly, I suspect my demo ran faster and smoother if I wrote it entirely in Javascript. But then, I wanted to write an AngularFaces demo, not a pure AngularJS demo, so I opted for the second best solution. But then, I could also improve the demo by using Aparapi – a Java framework capable of rending several dozens of Mandelbrot images per second. Funny thing is both three.js and Aparapi run on the graphics accellerator card.

AngularFaces: Calling AngularJS Controllers via a:angularButton

Fork me on GitHubThis article concentrates on the AngularJS side of an AngularFaces application.

The standard AngularJS approach to calling a controller function is adding an ng-submit attribute to the <form> tag. In a JSF application, this isn’t a good idea. It might make Angular intercept button clicks intended to be send to the server.

To avoid the problem, AngularFaces offers the <a:angularButton> tag.

Update Sept 16, 2014
AngularFaces 2.0 takes a different – and better – approach to adding fuctionality to JSF. This article describes the older version AngularFaces 1.0. Have a look at the tutorial at if you’re interested in AngularFaces 2.0 and above.

Continue reading