Category Archives: Angular2

ngx-translate and ngx-translate-extract – Internationalization Made Easy

It’s a bit surprising that there so many libraries offering internationalization for Angular applications. It’s surprising because there the Angular cookbook describes a well-thought approach to internationalization. Unfortunately, ng-xi18n was broken last time I checked, so let’s explore another library today. ngx-translate is a simple but useful library for supporting multiple languages. And ngx-translate-extract makes working with ngx-translate even easier by extracting texts to be translated automatically.

What’s the difference between ng-xi18n and ngx-translate?

Talking of ng-xi18n: there’s a big difference to ngx-translate. ng-xi18n has been developed with professional translators in mind. In particular, this library uses the well-known XLIFF standard. Developers probably tend to think this standard is clumsy. It’s XML, and it’s sort of bloated. ngx-translate, in contrast, uses slime Json file to map one language to another. The backside being it supports fewer use-cases than XLIFF.
Continue reading

Mocking HTTP Services With Angular Generically

Angular has been designed with testing and mocking in mind. This includes mocking HTTP services in general, and mocking REST services in particular. The Angular team even provides a fairly generic mock HTTP service. That service is a horn of plenty of good ideas. The only problem is the limited scope of the solution. It’s meant to serve the needs of the documentation of Angular. The team even promises that the service may break at any point in time.

In other words: it pays to implement your own generic mock HTTP service. That’s what we’ll do today.
Continue reading

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.

Oops!

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.

Trendscouting

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 (www.google.com/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 (www.google.com/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

Angular Takes the Sting out of Writing Components

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 multi-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 co-worker suggested to quickly write our own component. “It’s simple”, he said. “It ain’t much work”. It’s true. It wasn’t.

Key to success: template language

The key to success is the clever template language of Angular. More often than not, I’m unhappy with template languages because they always feel clumsy. Angular’s template language doesn’t. Of course, that’s simple because it doesn’t aim to be a general-purpose language. It’s been written specifically for a single purpose, and it serves this purpose well.

I don’t have the source code at hand, so let me sketch our source code from memory. The multiple-choice combobox consists of an input field, which is always visible, and a pane containing the options. The pane is hidden most of the time. So the HTML code (or rather: pseudocode) looks like so:

<input [(ngModel)]="selectedValues" 
       (onfocus)="optionsVisible=true"
       (onblur)="optionsVisible=false">
<div [attrs.visible]="optionsVisible">
  <div class="checkbox" *ngFor="let option in options">
    <label>
      <input type="checkbox" [(ngModel)]="option.selected"
             onchange="updateResult()"> 
      {{option.value}}
    </label>
  </div>
</div>

This little snippet reads and writes like plain vanilla code. But in reality, it’s revolutionary. It takes a lot more code in Java to write an equivalent JSF component. I also compared this code to my AngularPrime/Dart framework I wrote a couple of years ago. Dart is a fine language, but it took much more time and effort to write a simple component.

The component class

Of course, the HTML code is useless without the TypeScript glue code. But again, this code is fairly straight-forward. The sketchy pseudocode looks like this:

export class Option {
  label: string
  selected: boolean = false
}

@Component({
  selector: "multiple-choice",
  templateUrl: "multple-choice.html"})
export class MultipleChoice {
  @Input() options: Options[]

  @Output() result = new EventEmitter(string)

  optionsVisible: boolean = false

  updateResult(): void {
    let result = options.filter(option => option.selected).
             reduce((option, previous) => previous + "," + option.label, "")
    result.emit(result)
  }
}

Another key to success: @Input and @Output

We’re almost there! All we need to add is a little CSS file to arrange the panel properly below the input field. Everything else is handled by Angular: we can pass the list of options to the component using the @Input decorator, and @Output sends the result to the outer component:

<multiple-choice [options]="colors" 
                 (result)="setSelectedColors($event)">
</multiple-choice>

Wrapping it up

Of course, I’ve omitted some details to keep things simple, and I’ve shown only pseudocode. But even the real source code is surprisingly simple. Angular focuses on writing components. Therefore, it makes writing components as simple as possible without sacrificing power. I had the opportunity to compare different approaches, and I’m astonished by the ease of use of Angular.

How to Use a JavaScript DataTable in an Angular Application

Fork me on GitHubThere are several data table widgets for Angular, but none of them matched our project’s needs. I’m sure that’s simply a matter of time. Angular2 is young, and the third-party libraries are even younger. They simply didn’t have enough time to accumulate features and maturity. So why don’t we use one of the seasoned JavaScript data tables?

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.
Continue reading

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

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

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

Angular2 Component Libraries

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.

General purpose widget libraries

  • Ionic was already a well-known UI framework in the AngularJS 1.x age. There’s also an Angular2 port. Ionic comes with a CLI tool which simplifies getting started. It also provides its unique layout which blends in nicely with the look and feel of many current mobile devices. There’S a nice tutorial at scotch.io.
  • PrimeNG is an offspring of the well-known PrimeFaces JSF library. It’s an open source project hosted at GitHub. At the time of writing (Oct 07, 2016) I counted some 70 components, providing enough widgets for writing an enterprise application. Like PrimeFaces, PrimeNG is a commercial library. In this particular case, this means you can get the library itself for free, but you can order a support plan. There’s a PrimeNG PRO with commercial support and premium templates like Ultima NG. For some reason, the team didn’t make their pricing public yet, but they told me they already have a couple of very big customers. Judging from the list they showed me I daresay to call PrimeNG a great framework even if I haven’t used it myself.
  • ng2-bootstrap is a component library that combines the grid system and the theming of Bootstrap with Angular2. At the time of writing (Oct 07, 2016) it supports 15 components and both Bootstrap 3 and Bootstrap 4. 15 components doesn’t sound much, but the tool box contains most components you need. A co-worker of mine uses it for their current project and reports that they a happy with it.

Widget libraries providing individual components

Talking of data tables: PrimeNG has a fairly powerful data table. I didn’t compare it to the other data tables in this list, but I think they all play in the same league.

Commercial widget libraries

Since I don’t want to spend money on commercial libraries just to test them, let’s suffice to mention these libraries.

  • KendoUI is the Angular2 offspring of the well-known KendoUI library. So it’s not surprising that it looks fairly complete. Prices start at 999$ per developer license.
  • Wijmo 5 is also a library with a long history. Hence the Angular2 offspring also seems to offer almost everything you need. Prices start at 695$ per license.

TypeScript and ES2016 Decorators vs. Java Annotations

Consider this TypeScript snippet. It’s a very simple Angular2 component. It looks almost like a Java class, doesn’t it?

@Component({
    selector: 'my-app',
    template: '<h1>My First Angular 2 App</h1>'
})
export class AppComponent { }

In particular, the @Component looks like a Java annotation. In fact, it plays the some role as a Java annotation. It tells the Angular2 framework that this class is not an ordinary POJO, but something special. It’s a component, one of the building blocks of Angular.

Striking similarity

That’s exactly the same thing I already knew from the Java world. @Named converts a POJO into a CDI bean. Sometimes Java annotations even have the same fancy curly braces syntax:

@ResourceDependencies({ 
  @ResourceDependency(library = "bsf", name = "js/datatables.min.js", target = "body"),
  @ResourceDependency(library = "bsf", name = "css/datatables.min.css", target = "head")
})
public class DataTable extends UIData {}

So why do the JavaScript and TypeScript communities insist on calling their annotations “decorators”?

Decorators decorate!

The answer is simple: Decorators are called decorators because that’s what they are. You can use them as annotations. But in reality, they are function calls. The Angular2 framework contains a function called Component() that takes a function as a parameter and returns another function. The @ of @Component tells TypeScript and EcmaScript 2016 to call the Component() function and to pass it the function after the decorator. Usually decorators are used to add functionality to a function.

AOP

Does this ring a bell? Exactly – that’s more or less the same as aspect oriented programming. In fact, AOP is one of the classical use cases of Java annotations. Just think of @transactional. This annotation surrounds a method with the glue code needed to execute it in a transaction. In other words, it adds some code before executing the method (opening a transaction) and it adds code after the method (committing the transaction, or rolling it back).

Oops!

Making the @ symbol an alternative way to call functions is a very elegant way to implement both static annotations and AOP. Plus, it should be possible to pass variables as additional parameters. In Java, annotations only support constants that can be resolved a compile time, and every once in a while, that’s a nuisance.

In hindsight, it’s hard to understand why the Java team added simple annotations instead of full-blown decorators to Java 5. I suppose they didn’t want to add a complex multi-purpose tool. Annotations can be used for exactly one purpose. They resemble a comment. They rely on a framework to be useful. This framework can be the editor, the compiler or the runtime environment. Only a few years later the JavaScript world showed how useful decorators are.

Can decorators be added to Java?

Sure. Java 8 introduced default methods. So we could define a default method in an annotation class and execute it when the annotated method is called. We’d have to consider a couple of corner cases, though. Annotations can be applied to classes, static fields, class attributes and method parameters. We’d have to define useful semantics for each of these corner cases. But that’s not a big deal.

Wrapping it up

However, I don’t think this will ever happen. Annotations have become such an important part of the Java world it’s unlikely anybody takes the risk. So, for now, we can only marvel at the way the language designers took the syntax of the annotation and converted it into something even more useful. By the way, the flexibility of the JavaScript language allows for some tricks Java developers can only dream of. Only – Java applications tend to be a lot bigger than JavaScript applications, so this dreams would quickly turn into a nightmare. Nonetheless, the article I’ve linked in the “dig deeper” section is very interesting, and it’s full of surprises – at least for a programmer like me spending most of their day in the Java ecosystem.

Dig deeper

Exploring EcmaScript 2016 decorators in detail

Getting Started With AngularJS 2.0: Forms (Part I)

Let’s continue our journey into the universe of Angular2 with exploring forms. Actually, that’s something odd: many articles and tutorials on Angular2 spend a lot of time explaining that the old two-way-binding of AngularJS 1.x has been replaced by something different, something superior.

Putting it in a nutshell

Forget about that. You can learn about the subtleties of Angular2 later. From a beginners view of point, good old two-way-binding is still there. It even has become more simple.

Putting it in a nutshell, you simply use the new, slightly controversial syntax <input [(ng-model)]="someProperty" /> to bind an input field directly to a property called someProperty of your controller. Initially, the input field is populated with the value someProperty, and when the user starts to type in the input field, every key stroke immediately changes the variable someProperty.
Continue reading

Newsflash: How to Develop Efficiently In TypeScript

In one or two of my recent posts, I claimed that the TypeScript compiler is extremely fast, and that that Google Chrome caches your TypeScript code to aggressively.

Both things have changed since then. The bad news is that the editor I use, Atom, has started to compile the entire project each and every time I edit a file. I don’t know whether this is a configuration error of mine, or if it’s a bug of Atom, or even a peculiarity of the current version of TypeScript. I’m positive the error is on my side, but as long as I haven’t found the reason I reluctantly have to revoke my claim that TypeScript compiles in virtually no time.

Now for the good news. The Angular2 team recommends to use “live-server”, and it works just great. Install it via

npm i typescript live-server --save-dev

Next, open the file package.json, find the scripts section and replace it with

{
  "scripts": {
    "tsc": "tsc -p src -w",
    "start": "live-server --open=src"
  }
}

Now you can start your project by starting npm start at the command line. This starts the server, opens the browser, opens the index.html of your project within the browser and – that’s the really cool part – restarts your application each time you edit a file.

Read the full story at the Angular2 quickstart tutorial.