It’s astonishing how simple writing web components is with Angular. In a way, this shouldn’t be a surprise: components are the building blocks of every Angular application. However, last week we wrote a component I already knew to be difficult to implement in merely an hour or two. That was really a surprise.
Our choice was a multiple-choice select box. There are plenty finished components out there. However, Angular 2+ is still young, so there are few (if any) native Angular multiple-choice boxes we can use. Integrating a component based on other technologies like jQuery is possible, but usually, it takes some time and it’s always a compromise. So I reluctantly agreed when my coworker suggested to quickly write our own component. “It’s simple”, he said. “It ain’t much work”. It’s true. It wasn’t.
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.
It always pays to listen to Uncle Bob Martin. He’s clearly someone who’s got something to say. But that doesn’t mean I always agree. Today, I don’t. And I consider it interesting why we disagree.
I’ve just read Robert Martin’s post“The Dark Path”. He picks three innovative traits of Kotlin and Swift: strict null checks, strict exception handling and making classes final (in Java speech) or closed (in Kotlin lingo) by default. It’s an interesting post I recommend to read. Uncle Bob shortly explains these features, continues with complaining about languages becoming too complex because they try to fill each leak of their predecessor languages, and closes with an ardent call to write tests. Like usual, he arguments very convincingly. It’s hard to disagree after reading the article. Yet I do.
As it turns out, Louis Lin had the same idea creating the Angular DataTables project. It looks promising, but at the time of writing, it was only 26 days old. So the feature list is pretty short. When you’re reading this article, things have probably improved. However, today I don’t want to tell you how to use a third-party data table. Instead, I’ll tell you how to do it yourself. Before we start to wallow in the source code, let’s start with what developers usually do: a short market survey. If you’re in a hurry, skip that section or jump directly to the source code of the demo on GitHub.
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.
I’ve always promoted BootsFaces as a companion framework for PrimeFaces, but many developers report it’s difficult, if not impossible, to combine these two frameworks. Things are particularly nasty if you’ve already got a (possibly huge) PrimeFaces application. Some developers report that even adding a single BootsFaces component will distort your application’s layout. So I’ve decided to examine the problem more closely and to do something about it. This article sketches how to integrate BootsFaces components into a PrimeFaces application. I’ve also created a project at GitHub demonstrating the idea. Note that this article doesn’t show how to use a PrimeFaces component in a BootsFaces application. Of course, that’s almost the same problem, but the source codes below only consider the first use case.
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.
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.
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.
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.
A good third-party component library can give your application development team a boost. This article collects a list of popular UI component libraries for Angular2. It goes without saying that this list can never be complete, so it’s probably going to change and expand over time. If you know of a useful Angular2 widget library, don’t hesitate to leave a comment so I can complete the list.
By the way, this list is just that: a list. I’m adding a short introduction to each library, but it’s not the same as a review. I’ll postpone that to follow-up articles. If you like or dislike on of the library, I’d like to hear from you, especially if you also add a short explanation.
In a sense, Java has vanished from the client many years ago. With the exception of Android, the vast majority of Java runs on a server in a data center. From the average user’s perspective, Java has become invisible. When we talk about Java UI programming, most people think of Spring MVC, JSF and Ozark.
I’m still trying to make sense of the new Java EE 8 plans Oracle revealed at JavaOne a couple of weeks ago. My first impression was that the new focus on cloud computing means that Java is going to molt again. The Java EE 8 roadmap proposal indicates just that.
There seems to be a consensus in the Java community that the Scala programming language is already on the decline. I consider this a pity because I always enjoyed programming in Scala. Actually, I even started this blog to support alternative JVM languages like Scala. But the market has decided differently. Moshe Kranc has written an excellent analysis about the rise and fall of Scala. I found Moshe’s article interesting enough to summarize it and to add a couple of thoughts of mine.
However, I’ve also read some of the 169 comments to Moshe’s article, so I’d like to add a few words. First of all, I’m really fond of the Scala language. I’m not trying to write an anti-Scala article. Quite the contrary. I’m following the fate of Groovy and Scala for at least ten years now, and I’m still puzzled why the industry doesn’t adopt one of these languages. In many aspects, both languages are clearly superior to Java.
This newsflash is a true “flash”, currently consisting only of a single link to the current proposal of the JavaEE 8 road map:
Proposal of the JavaEE 8 road map as of September 19, 2016
However, if time allows, I’ll either add to this newsflash later or write blog entries covering certain aspects of the modified plans. Stay tuned!
So let’s have a look at Microsoft’s UWP platform and at Xamarin, a framework they’ve acquired in February 2016.
But before that, I’d like to introduce you to my co-author, Janis Saritzoglou. This article wouldn’t have been possible without him. Janis wrote his bachelor thesis about UWP and dedicated an afternoon to explain UWP and Xamarin to me. He also proofread this article and added a couple of interesting insights.
That said, let’s continue with UWP.
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.
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.
Performance considerations in the eighties
Time and again, I’m surprised by the performance of modern CPUs. Actually, the speed boost astonishing me most took place a decade ago, give or take a few years. Before that, floating point operations were a lot slower than integer operations. When I learned my first assembly language, the 6502 processor was state of the art. This processor was so simple that you had to write a program to implement the integer multiplication. Multiplying floating point numbers was an even longer program. I’ve forgotten the actual numbers, but as a rule of thumb, multiplying integers was ten times slower than adding two integers. Multiplying floating point numbers was another magnitude slower.