Category Archives: web design

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

UI Roundup 2017: Polymer

Two years ago, Polymer looked like an equal competitor to AngularJS. At the time, it wasn’t clear which one would win the race. Truth to tell, it’s not clear today. The JavaScript world is incredibly volatile and capricious. But the numbers I collected clearly indicate Angular (nowadays without JS) is much more important. At the same time, they indicate that Polymer is here to stay.

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.

Charts with Angular: ngx-charts (Formerly: ng2d3)

Originally, I wanted to write an article about ng2d3. That’s a fine library bringing the power of D3.js charts to the Angular2 world without the price. D3 requires you to adopt a special programming style. You have to learn and use a new programming paradigm, the data-driven programming style. ng2d3 doesn’t require such a thing. You just pass it the data, and it’ll draw the diagram for you.

The only problem with ng2d3 is that it doesn’t exist anymore. More precisely, when I started writing, the team published a new major version (including a couple of breaking changes) and changed the name of the project. Now it’s called ngx-charts. In the view of the new semantic versioning strategy of Angular, the name makes a lot of sense. Calling a framework “ng2-something” won’t work when Angular4 will have been published, skipping Angular3 altogether.
Continue reading

What’s New in BootsFaces 1.0?

BootsFaces 1.0 has been released. Actually, we’ve already published the first bugfix release, BootsFaces 1.0.1. I was a bit shy to proudly announce the 1.0.0 version because we had so many obstacles to overcome. Apart from the usual obstacles like exhausting projects at work (and they were exhausting this time!), there were also the earthquakes in Italy, which kept at least one of our team members busy, although they didn’t suffer any physical harm.

Be that as it may, BootsFaces 1.0 (and 1.0.1 in particular) is a great step to maturity. It’s the first version we officially call “production-ready”. Truth to tell, we were always convinced you can safely use BootsFaces in production. But most versions we’ve published in the past focused on features. This time we tried to focus on stability instead of new features when we prepared the 1.0 version. I counted 26 bugfixes that were important enough to open a bug ticket. Plus, almost twenty minor enhancements and three new components. However, we also added one or two major improvements, such as adding support for both horizontal and inline forms.

Download coordinates

Before starting the long list of details, let me provide you with the download coordinates:

Add these lines to your project’s pom.xml:


Add this line to your project’s .gradle build file:

compile 'net.bootsfaces:bootsfaces:1.0.1'

The BootsFaces project comes with both a Gradle build file and a Maven build file. The Maven pom.xml is the easy way to get started and should suffice for most purposes. Only if you want to tweak and optimize BootsFaces, you need the Gradle build. In particular, the Maven build doesn’t generate the CSS and JS files itself, but relies on the output of the Gradle build. By the way, that’s the reason why we keep the generated file in GitHub.

In any case, the URL of the repository is

Update Dec 27, 2016: Bugs

During the last couple of days, we’ve found and fixed a couple of bugs. If you happen to run into a bug, check our bug tracker if we’ve already solved the bug, and check out the sneak preview version of BootsFaces 1.1.0-SNAPSHOT. Strictly speaking, this version is not intended to use productively. Use at own risk. Of course, BootsFaces is published under an Apache V2 license, so every version of BootsFaces is published on an “as-is” basis, without any warranties. The difference between the snapshot and the final version is that we’ve tested the final version more intensively.

Continue reading

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

How to Wrap BootsFaces (or JSF in General) as a Native Desktop Application

When I showed the draft of my last post (the “Java on the Desktop” survey article), my friends surprised me by saying that nowadays desktop applications are sort of exotic. Everybody’s doing mobile or at least web applications. But the good old desktop has fallen into oblivion. That’s pretty strange, given that most of us do most of their daily work at desktop PCs or decent-sized laptops.
Continue reading

Java on the Desktop

For some reason, the vast majority of developers has accepted the browser as the operation system for their applications. While there are some good reasons for this, I never really bought into it. HTML5 has eliminated most of the pain point of web applications, but I still insist that most customers don’t really want to use a web application. We’ve taught them to accept to open the browser to do their daily work, but there are still quite a few disadvantages to this approach. The “old stagers” among you know how many obstacles we had to overcome before the browser became a really useful operation system for writing applications. Just for the fun of it, let’s start this article summarizing some of them:

  • How to deal with the “back” and “forward” buttons in a web application?
  • How to print a document from a web application? Most developers export documents to be printed as PDF files, but wouldn’t it be nice to be able to print documents without this detour?
  • How to import an Excel file into your application?
  • More generally speaking, web applications run in a sandbox preventing access to low-level resources such as your computer’s file system.

Continue reading

HTML5: Optional HTML Tags

The other day Marco Rinck tweeted something that’s very confusing, almost disturbing. Google’s HTML style guide suggests to omit optional HTML tags. Taking in mind that the page rank of your website is influenced (among other things) by whether your page has a clear layout and a good coding quality, following these guidelines is almost mandatory. Granted, I didn’t check whether this particular style guide is linked to the results shown in the webmaster tools, but you get the idea: if Google publishes a style guide on HTML and CSS, it’s going to have an impact on the market. So let’s have a close look at it.

What are optional HTML tags?

At first glance, the idea of declaring certain HTML tags “optional” and suggesting to omit them makes a lot of sense. Putting it in a nutshell, the idea is to make the code more human-readable. More to the point, the suggestion is to write HTML code the way the average human would write it if they didn’t happen to be a developer. Developers have learned to love clear structures, but that’s not the way most people think. A particularly fascinating property of the human mind is its ability to recognize patterns. Even better, it’s able to infer patterns where there are none.

Basically, that’s the idea of optional HTML tags: you don’t have to write an HTML tag if you can easily infer it from the context.

For instance, there’s no point in writing the <html> tag. The document is shown in the browser, so we already know it’s an HTML document. Similarly, there’s no point in wrapping the <head> tag around the <title> tag, and the <body> around the <for> or <p> tag. Both forms and paragraphs make only sense in the body of an HTML document, so it’s easy to infer the <body> tag.

Cool! But…

Being a human being – and a particularly lazy one – Google’s style guide fills my heart with joy. Mind you: having to end each and every paragraph with a </p> tag before starting a new paragraph is really silly. Actually, it’s the number one mistake when I add a new page to our BootsFaces showcase.

On the other hand, the new style guide is exactly the opposite of what web designers have been taught during the last couple of years. I’m not entirely sure about the version numbers, but as far as I remember, starting with HTML4, XHTML was promoted as the new way to go. Former versions of HTML – or rather, the browser rendering engines – tended to be very sloppy. Or, putting it positively, they mapped the pattern inference capabilities of the human brain. The (then) new standard was to get rid of inference. The idea was to define everything in a clear, concise manner.

What about parsers?

I don’t know why this clean coding style was propagated, but my theory (hey, that’s pattern inference at it’s best!) is that the idea was to make HTML machine-readable. Clean XHTML code can be parsed by an XML parser. In fact, that was what allowed me to write BabbageFaces. JSF usually generates very clean XML code which can be read and analyzed by an XML parser. That’s what I did to reduce the size of the HTML code sent to the browser.

However, I consider BabbageFaces a nice but failed project, basically because hardly any JSF page fulfills the strict requirements of XML. The average JSF page renders code that can almost, but not quite be read by an XML parser. Almost always optional HTML tags are used. Browser vendors always knew that HTML pages are written by human beings, so they introduced pattern inference from day one. So browsers don’t have trouble displaying the HTML code generated by JSF pages. The XML parser of BabbageFaces quickly ran into trouble with the same pages. Which is sort of remarkable, given that the HTML code generated by JSF frameworks usually is a lot cleaner than HTML code written by humans.

We need new parsers!

Far be it from me to resist the new guidelines. Quite the contrary. In recent years, compiler manufacturers have learned a lot. The semicolon that’s required at the end of each Java statement originally was introduced to make it easier to implement parsers analyzing the source code. It took compiler manufacturers a couple of years to recognize that the semicolon can be induced from context.

There are many programs out there analyzing HTML code. I don’t know whether they cope with tag inference or not. Thing is, HTML4 made it official that they don’t have to, while HTML5 officially makes tag inference part of the HTML language. As a consequence, you can’t simply use an XML parser to parse HTML pages. You need a full-blown HTML parser. A short investigation showed that Jsoup may be such a parser, but please don’t take my word for it: neither did I try it, nor did I compare it with other parsers.

Wrapping it up

Actually, the Google HTML and CSS style guide give the best summary itself:

This approach may require a grace period to be established as a wider guideline as it’s significantly different from what web developers are typically taught.

As a human being, I welcome the new standard because it makes both reading and writing HTML pages easier. As someone who sometimes writes programs to analyze HTML pages, I’m not so sure. At least, the idea to simply use an XML parser to analyze an HTML page is doomed.

Dig deeper

HTML5 specification of optional tags
Google’s HTML styleguide on optional HTML tags

Blisk – a Browser to Make Web Programming Easier

Mobile first! Seriously? Do you really optimize your application for mobile usage?

Actually, you can’t. The current state-of-the-art makes it difficult to adopt the “mobile first!” approach seriously. Mind you: that would require you to program your application on the phone instead of using your desktop browser. Until today, I’ve seen such an approach only with iOS programming and with UWP/Xamarin. The application is developed on the desktop, but run and tested on the cell phone or the tablet.

The other day a friend of mine, Dario D´Urzo, showed me another option for web developers. What started as a small JavaScript plugin two years ago has evolved to a full-blown browser in 2016. More precisely, it’s a browser based on Chromium which adds a number of tools dedicated to web designers and web programmers.

Targeting multiple devices

When you open a URL in Blisk you’ll see the web page twice. On the right-hand side, there’s the desktop view you expect. On the left-hand side, you see the same page in a simulated smartphone. As you can see in the screenshot, both views are remarkably different. It’s great to be able to seem both views at a glance. This enables you to truly adopt the “mobile first!” slogan. Even better: if you scroll one of the windows, the other windows scrolls simultaneously. Thus you can compare both the look and the feel of both displays.

Blisk supports a number of devices out of the box. It doesn’t cover every smartphone and every tablet available on the market, but the number of devices seems to cover almost every use case.

Multiple inspect views

Seeing multiple devices at a glance is just a start. You can also open device-specific developer tools and keep them open simultaneously. That, in turn, allows you to find differences between devices a lot faster than with the traditional single window.


Being a browser based on Chromium, I’m pretty sure Blisk has an annoying limitation: it doesn’t simulate the device completely. It only modifies the screen estate the replaces the mouse pointer by a large finger touch point. What it does not do is to simulate the rendering engine. If there’s an incompatibility because – say – Safari implements a feature differently than Chrome does, you’ll still miss it with Blisk. You still need to test your application with the real device.

Automatic reload

That’s another feature I’m told to be very useful. You can configure Blisk to watch certain files or folders. When you edit and save a file, Blisk automatically reloads the page. I suspect that’s one of the features that are useful to some and annoying to others, so probably it’s good news you can also switch it off. However, if your application supports reloading, I imagine that’s a tool boosting productivity.

Code analysis

Currently, that’s only a promise. The module providing static code analysis is still under development. I’m looking forward to it. Integrating code analysis into your browser (i.e. your runtime environment) might make you aware of problems much earlier than with traditional approaches such as SonarQube.

Screen shots

Another feature that’s still under development. However, I doubt that’s a killer feature to me. Tools like Greenshot integrate so nicely into my PC I never considered taking screenshots awkward. So I’m curious – maybe the developers have a clever idea I missed?

Integration with other tools

That’s something offering more potential to boost productivity. Blisk offers to provide integration with third-party tools, such as bug trackers and project management tools. Unfortunately, this is another module still under development.


Blisk has a long licence agreement, but basically it’s free both for commercial use and for personal use as long as you don’t modify it.

Wrapping it up

As long as you are aware on the limitations, Blisk is a great tool for every web designer and web developer targeting multiple devices. At the time of writing, many interesting features are still missing. However, what’s already there looks interesting enough to adopt Blick for development.

Dig deeper

Blick project page
Blick license agreement

Progressive Web Apps

The other day, we had a discussion in the office. Is HTML5 the solution to every problem, or are native apps the way to go?

For a long time, I was very reluctant to force our users to use the browser to do their work. At the time, we had a nice Java applet running in the browser, which seemed to be a nice compromise to me. We could offer a rich user interface, and every user who had access to the internet could install our application. But installing the applet soon turned out to be above the skill and will of the average user, causing a lot of hotline calls. Plus, developing simple HTML pages was cheaper. That tipped the scales. We kissed Swing goodbye and never looked back.
Continue reading

HTML Includes

Almost every programming language offers you an option to use the content of another file in the file at hand. Basically, it’s a very old idea. Sooner or later programs become large and larger, so developers started to split the files into smaller building blocks. First, they invented subroutines, later procedures, and functions. Later they invented higher-level building blocks like modules, classes, and packages. One of the early ideas was to include the content of another file. To a certain extent, that’s always been possible in HTML. You can include CSS files by writing <link rel="stylesheet" href="myFavoriteCSSFile.css">. Similarly, you can add JavaScript code stored in an external file by writing <script src="myFavoriteScript.js">.

Funny thing is there’s no way to include the content of an HTML file into another HTML file.

That’s very strange because it’s such a useful feature. Server-side languages like PHP fix the problem by providing server-side includes. Probably that’s why the HTML standardization team didn’t add HTML import prior to HTML5. Even so, a quick glance at is a bit disappointing. You can use the official W3C standard on Chrome, Opera and Android. A second closer look reveals that this particular HTML5 standard is still in the “draft” stadium at the time of writing (June 2016).

What may be in store for you

Let’s start with the current W3C draft which may or may not see the light of the world. To my surprise, it’s not a simple HTML include, but requires some JavaScript code. So, the recommended way to use HTML includes seems to add the include statement – which turns out to be a <link /> – in the header of your HTML page:

  <link rel="import" href="myFavoriteInclude.html">

The next step is to define a div in your HTML page which is going to contain the include file:

     <div class="put-include-here">
        This message is going to be replaced by the include file.

Finally, you put the content of the include file into that div:

    var link = document.querySelector('link[rel="import"]');
    var content = link.import;
    var el = content.querySelector('.put-include-here');

This is a bit cumbersome, but of course, it’s much more flexible than a simple HTML include. You can do anything with the file loaded by the import link. When I tried this feature, I was even able to load different files by changing the href of the <link /> tag from JavaScript. A write access to the href was enough to make the browser load the file.

Still, this version is a bit disappointing because I’d prefer a simple way to include HTML code. Fiddling with JavaScript is a nuisance. It’s nice to have the option, but it’s annoying you can’t do without. But then, modern HTML5 is flexible enough to write a simple polyfill providing the feature I’m looking for:

     <include-polyfill href="myFavoriteIncludeFile.html" />


AngularJS comes close to my ideal solution:

<body ng-app="someApp">
   <div ng-include="myFavoriteIncludeFile.html"></div>

There are only two drawbacks. First, you have to use AngularJS. That’s fine if you want to use it anyway, but it’s a no-go otherwise. Second, AngularJS cares about security. It goes without saying that security is a good thing, but in this case, it means many tags are ignored by <ng-include />. In particular, you can’t include JavaScript code. If you want to do such a thing, you have to write some additional code to make AngularJS forget about security.


I didn’t try this one, so I can say little about it, but it appeared on the front page of my search result, it looks nice, and it comes from a source I consider trustworthy, so chances are that w3IncludeHTML is a good alternative for you. Using it seems to be pretty straightforward:

<!DOCTYPE html>
    <script src=""></script>
    <div w3-include-html="myFavoriteIncludeFile.html"></div> 


I take it most of you use jQuery, so using jQuery to load the include file is little to no overhead. As usual, jQuery isn’t activated by an HTML directive like <w3-include-html />, but it’s activated by a single line of JavaScript code:


Wrapping it up

When I started this article, I wanted to rave about the simplicity of the new HTML5 standard. Along the way, I learned that the new HTML5 standard isn’t as simple as I expected it to be: it requires a little help from JavaScript. Adding insult to injury, it’s not exactly a standard. It’s supported by Google Chrome, which may be a very popular browser, but which isn’t the most popular browser in the enterprise world, at least not in every country. So a substantial fraction of readers needs an alternative. Luckily, there’s an abundance of alternatives. Searching for “HTML include” reveals no less than 650 million search results on Google. So I’ve picked three arbitrary solutions: AngularJS, jQuery or a W3Schools library for those who don’t want to use nor Angular nor jQuery.

Still, I wonder why such a simple feature hasn’t made it into the HTML standard yet. Probably that’s due to the “good enough” principle. Most web designer and web developers can use another solution, such as PHP server-side includes, so they don’t need HTML includes.

Newsflash: Material Design with Materialize.css

This morning I became aware of a nice CSS library: Materialize.css. In many respects, it reminds me of Bootstrap. Among other things, there’s a similar grid system, which is even slightly simpler and more logical than its Bootstrap counterpart. The class names are shorter, there are only three screen sizes, and my first impression it’s easier to learn “s, m, l” than “xs, sm, md, lg”.

Community support (speculative until confirmed by further research)

What caught my attention was the ambitious translation of the huge showcase. The German translation is pretty good, and my quick survey showed that the Spanish and French translations aren’t bad, either. Granted, the major part of the showcase is yet to be translated. But some time ago, I’ve started to translate the AngularFaces showcase to German. I didn’t manage to finish it because I ran out of time. So offering a large part of the Material.css showcase in ten (!) languages is no small feat. To me, that’s a good sign: I don’t think the four team members speak ten languages, so I render it likely that there’s a broad community support for Materialize.css.

Virtually every component you’ll ever need

The other thing that caught my eye is the large list of components. At first glance, everything you need to write a business application seems to be there: input fields, combo boxes, radio buttons, and checkboxes, just to name a few. Check boxes come with a nice twist: they optionally have an “indeterminate” style, which looks very intuitive to me. This makes Materialize.css one of the few UI libraries offering a convincing approach to three-state checkboxes. Another nice twist is the labels of input fields, which may optionally be displayed as watermarks until you enter your input. That’s one of the things difficult to explain but easy to show, so I recommend you follow this link to have a look yourself.

Wrapping it up

I’m big into Bootstrap, but even I have to admit that Google’s material design already has a big impact on the UI market. My crystal ball is currently slightly undecided, but chances are that Material Design is going to be one of the big things in the future of UI. Materialize.css isn’t the only Material Design implementation, but it’s clearly an interesting one.

Single-Page Applications With BootsFaces

Singe-page applications have become tremendously popular in the last couple of years. They are fast, they are responsive and they can save network bandwidth. The first SPAs that caught the attention of the community were based on JavaScript. So nowadays everybody seems to believe you can’t write an SPA with JSF.

But you can. It’s not even difficult. And it pays: the application becomes much more responsive. This article shows two approaches how to do it with BootsFaces. I’m sure you can do the same with other JSF frameworks like PrimeFaces, too, but I didn’t test it yet.

Currently, there are at least two approaches. You can exploit BootsFaces AJAX to do your navigation, or you can add AngularJS to the equation. The latter approach requires you to learn both Angular and JSF, but it may be useful because it allows you to use client-side AngularJS components.
Continue reading


My previous article focused on what the MV* paradigms are. But it didn’t answer the question whether using one of the MV* patterns is worth the pain. One thing is for sure: none of the MV* paradigms comes for free. It depends on your project whether using an MV* patterns is a wise investment or a waste of time and money.

Dissecting a chess application

For instance, consider my AngularJS 2.0 chess program (see the source code at GitHib or play it at It doesn’t follow any particular architectural pattern. Or rather, it doesn’t follow one of the established MVW patterns. To begin with, there’s no model. I simply didn’t need it. The program’s data are stored in the controller component of the program. I don’t know all the subtleties of the MV* theory, but I guess it’s OK to say the chess demo stores its data in the viewmodel layer.

Actually, the chess demo doesn’t consist of many layers. There’s the HTML code, there’s the chess engine and there’s some glue code.

My previous post (and the majority of tutorials) claims that AngularJS favors the MVVM pattern. Let’s stick to this fiction for a moment. It’s easy to identify the view layer: that’s the HMTL pages and the CSS stylesheets. The glue code is the viewmodel. I already said that there’s no need for a model layer.
Continue reading

First Alpha Version of Bootstrap 4 Released – What’s New?

On August 19, the Bootstrap Team has released the first alpha version of the fourth major release of their widely adopted front-end framework. Roughly two weeks later, August 31, they published their second alpha version.

State of the art

Please take this article with a grain of salt: the release post lists many highlights, many changes this version is going to bring out, but currently we are still talking of the first alpha version, so some things might change until we reach the final release.
Continue reading

OmniFaces CombinedResourceHandler Gives Your Application a Boost

OmniFaces 2.1 is soon to be released. Time to present a useful OmniFaces component which has been improved in version 2.1: the CombinedResourceHandler.

The CombinedResourceHandler reduces page load times significantly by combining the countless resource files of a JSF page into one or two larger files, which can be loaded and processed much more efficiently. Since version 2.1, these files can optionally be cached on the server side, giving the application another boost. Server side caching reduces the time needed to display the BootsFaces showcase by a second. If that doesn’t sound much: believe me, your customers will notice the difference. It’s a difference if the page takes one or two seconds to display.
Continue reading

Getting Started with BootsFaces: Responsive Design

BootsFaces is a JSF framework adding Bootstrap to JSF pages. One of the more attractive traits of Bootstrap is its built-in responsive design. Probably you already know the idea: screen elements are resized to fit on smaller screens. If everything else fails, Bootstrap starts to stack screen elements over each other if they can’t be displayed side-by-side. Usually, that doesn’t look as good as the original design aimed at larger screen estates, but the bottom line is that the application can be used even on small phones. Maybe you have to scroll a lot on a small device, but that’s a small price to pay. Without Bootstrap you’d have to scroll both horizontally and vertically, which is clearly worse.

Let’s write a simple BootsFaces application showing how easy it is to add responsive design to JSF applications. I’ve prepared a repository on GitHub, so you can check out the source codes used in this article. Today’s project is the subfolder ResponsiveDesign of this repository.
Continue reading

JSF 2.2 HTML5 Cheat Sheet

I’ve read a lot about the new JSF 2.2 HTML5 input fields, but until today I didn’t realize I hadn’t read a comprehensive introduction about this feature. I used to be happy with the short examples I was presented at conferences. However, there’s more than just <input type="text" jsf:value="#{my.favoriteBean.attribute}" />. As it happens, the documentation hides in plain sight. The JavaEE Javadoc tells you everything you have to know about the Mapping between HTML tags and JSF components. For the sake of convenience, this article summarizes the key points.

The general idea is to enable a web designer to design your JSF page without running a server. So it’s native HTML, and it should display nicely in a browser if opened as a simple HMTL file. Putting it in a nutshell, renaming a JSF file from *.xhtml to *.html doesn’t modify the design of the page.
Continue reading

How to Display PDF Files in the Browser

PDF files are very popular in web applications. They make it possible to deliver documents that can’t be easily tampered, and you know in advance how PDF documents look like when printed. That’s a major advantage over HTML page: printing an HTML page will almost invariably result in surprises. In many cases cross-browser compatibility – which is always a challenge – comes to a screeching halt when it comes to printing the page. You can avoid a lot of headache by simply using PDF files.
Continue reading