Front end update: Angular 2.0 & HTTP/2

I have taken up learning Angular, yet it seems that a new angular is being prepared, Angular 2¹. Angular 2 seems to be a complete rewrite, and has a very different architecture. For one thing, it can work with ECMAScript 6 and TypeScript.

Luckily, I managed to be at a small session regarding Angular 2 at Quintor, today, Thursday the 18th of February 2016.².

As a matter of fact, I am writing this blog in the train home.

HTTP/2

The speaker was Martijn van Campenhout of Quintor. The first presentation was regarding the new HTTP/2 protocol (officially released in May 2015), which is rapidly replacing the old HTTP/1.1 version (released in 1996). It is based on the SPDY implementation developed by Google in 2010 and officially submitted for standardisation.

Statistics shown by Mozilla indicate that an decrease of pageload times of 2.2 seconds, results in an increase of Downloads by about 15%.^{3 4}

Old tips and tricks

The old tips and tricks that are used to deal with the defficiencies of HTTP/1.1 and the lack of bandwith and troubles with latency were:

• combining files as much as possible
• inlining everything
• minifying everything
• domain sharding
• using sprite files
• define critical CSS and JS files
• using GZIP

These different tactics are used to make sure the Webbrowser has to do a minimum number of requests and does not need to get a lot of data to the user.

It seems the Chrome browser development tools has excellent support for simulating bad connections or large latency, using a variety of set network connection types.

Another common tactic was to display/render only those parts of the web page that are visible to the user. Once the user starts scrolling, the parts that scroll into the viewscreen of the user are downloaded and rendered. This is called "the Fold"⁵, and is a common DTP term.

There was a most impressive demonstration, where a picture consisting of about 100 smaller pictures was being shown, with a one second delay (latency) between the request and the response for a smaller picture. The difference between HTTP/1.1 and HTTP/2 was very big. Where the Browser only allows 8 concurrent connections with HTTP/1.1 causing a severe bottleneck, a single connection using HTTP/2 was more than enough to show the entire picture in about a second.

The tactics used for HTTP/2 can be summed up as follows:

Multiplexing

different Streams of data (files, css, images, html, javascript) across the same HTTP connection

Priority

allowing a setting of priority based on content. For example that the big logo should be loaded first, and the little icons at the bottom of the page last.

Binary Headers

easier and quicker to parse, fixed length, unambiguous

HPACK

In the past headers were not compressed, this has now changed.

Server push

server remembers the combination of files requested. One file request will trigger the others automatically.

This is also the first time that I heard the term CRIME, "Compression Ratio Info-leak Made Easy". Basically it boils down to a man-in-the-middle-attack, adding stuff to a message to see if it increased the compressed file. If it does not, the item added already was part of the file, and he has learned something valuable regarding the message.

The HTTP/2 is already incorporated in Apache server, NGINX. Servlet specification 4.0 of Java EE 8 will have support for it (JSR-369).

Criticisms

There were some criticisms regarding HTTP/2, though.

It seems the HTTP/2 might just be available only using HTTPS. The configuring of priority and server push needs to be done on the backend right now and cannot be controlled by the webdeveloper. This causes a tight coupling between front end and back end, which most people (including me) might not like.

All these optimalisations mean absolutely nothing, if your resources (html files, images, etc) are retrieved from many different servers.

Note: the effect of HTTP/2 is also that the old tips and tricks are not only useless, but can actually hamper the responsiveness of the website. An example of this is caching.

Angular 2

The speaker, Rachèl Heimbach, went quite fast through his presentation, which means we had time for two presentations in stead of one. On the other hand, it did require an inordinate amount of attention and knowledge of Angular/JavaScript/TypeScript to follow.

Angular 2 uses both ECMAScript 6 and TypeScript.

Some of the most important features⁶ of ECMAScript 6 that will return when you are attempting Angular 2:

• class
• import
• export
• private namespaces (without export and import, everything is by default off limits)
• default values (used when parameters are omitted in the function call)
• lambdas (no longer do we require the use of "var self = this;".

Benefits of using TypeScript in angular 2 are as follows:

• safe typing, makes refactoring and debugging a whole lot easier
• @Decorators, makes injection and adding behaviour generically a whole lot easier

Instead of the familiar services, factories and controllers of Angular 1, Angular 2 has simplified this a bit. Angular 2 basically consists of only Web components (that make up your pages/views/etc) and singleton injectors (that can take the place of your controllers, factories and services.) As you can see there is no longer a distinction necessary.

Some more enhancements:

• ChangeDetection
• ViewEncapsulation (with a shadow dom)
• Provide function
• ngUpgrade thing

It is possible to upgrade an Angular 1 application piece-by-piece or add Angular 2 components to it. The other way around is also possible.

Notes

HTTP/2 seems to be more and more widely supported. Angular 2 is still in the beta phase, however, it seems to be fairly stable. Unfortunately, it is currently not recommended for production use. However, the presentation did point out that in order to make the task of porting your application from Angular 1 to Angular 2 less onerous, it might be a good bet to start by designing the new parts of your Angular 1 application according to the Angular 2 style.

A question was raised on whether or not you should use Angular 2 at all. It seems Google will support Angular 1 for as long as there is a market for it. I heard that they measure the traffic to the two websites (Angular 1 and Angular 2) to determine interest. I got the impression from the presentation that Angular 1 has slowly been moving towards the new Angular 2 way of doing things.

Performance wise, Angular 2 is a step in the right direction. Keeping new Angular 2 in mind, whilst working on an Angular 1 application seems to be a very safe bet. If the need will arise in the future that a port is required, at least it will not be as herculean a task as first thought.

References

[1] Angular 2

https://angular.io/

[2] Quintor - Front end update: Angular 2.0 & HTTP/2

https://www.quintor.nl/sessie-front-end-update/

[3] Webpage testing

http://www.webpagetest.org

[4] Can I use?

http://www.caniuse.com

[5] Wikipedia - Above the fold

https://en.wikipedia.org/wiki/Above_the_fold

[6] ES6 Features

http://www.es6-features.org

An Evening with Java Champion Martijn Verburg

I managed to attend a lecture of Martijn Verburg¹ at the Supernova conference room in the Jaarbeurs in Utrecht yesterevening. Courtesy of Blue4IT.

Martijn Verburg, a.k.a. The Diabolical Developer, provided two interactive sessions. The first was "The Diabolical Developer's guide to Performance tuning" The second was "The Habits of Highly Effective Teams".

"The Diabolical Developer's guide to Performance tuning"

Martijn Verburg is the CEO of JClarity¹, a company that does Performance analysis of Cloud applications. JClarity introduced the “Performance Diagnostic Methodology” (PDM) to quickly get to the root of the problem.

The points to aid in analysing performance issues were in the following order:

1. What is your Cloud made of?
2. Draw diagrams
3. Measure each Architectural Layer
4. What is the CPU doing? Overworked or Bored?
5. Linux commandline tools are pure awesomeness
6. Garbage collection logs
7. Oracle micro benchmarks
8. Visualvm, Netbeans

The talk had a focus sometimes on the Cloud. He seemed critical of it.

The Cloud, or virtualisation in general, seems to be 20 to 25% slower than the old situation of dedicated hardware. It seems a lot of the time virtualised resources are overcommitted on existing hardware. Apparently with virtualisation it is possible that your performance goes down because of "noisy neighbours", i.e. someone else gets a lot of traffic/cpu/stuff to deal with and the others on the same node suffer.

One of the things he noticed in the field, is that performance issues were seldom the cause of some badly programmed application. The issue was usually located a lot lower in the stack, somewhere between the hardware and the JVM.

When analysing performance, start at the bottom and work your way up. So, check the hardware and the Operating System. What is it doing?

Keep your methods small. Java is better able to optimise small methods during Runtime.

Tools

Some tools mentioned:

• JMeter
• Gatling
• there seems to be a JDBC driver, that is nothing more than a wrapper around an existing JDBC driver to analyse the traffic
• vmstat
• jcviewer
• visualvm
• javap -c
• Netbeans
• Protobuf
• Jclarity.com/censum
• Jitwatch

"The Habits of Highly Effective Teams"

I managed to find the slides at [3].

The points in order were:

1. Social interaction
2. Strong leadership
3. Empowerment over Control
4. Shared goals
5. Respect and Trust
6. Common culture
7. Automation and tools
8. Encourage debate
9. Embrace diversity

He mentioned Dunbar's number, on average people can sustain about 150 relationships.

He mentioned the Peter principle, which was interesting as I had never heard of it.

He did mention that where a lot of managers say that you have to earn respect and trust, that simply does not and will never work. It's better to assume total respect and trust, until you are proven wrong by the person you respect and trust.

When debating a technological something, as we engineers often do, the only thing that has any value in a debate are hard facts and empirical data (and not opinions, assumptions, emotions and the like). If you have an inkling that some decision is wrong, prototype it and verify it. Martijn Verburg and his team use the Matt Raible method, where they draw up a Matrix of all the technologically important stuff and give points for a certain framework where it excels or falls short. Then they start prototyping with the three frameworks with the highest scores.

Make the shared goals SMART (Specific, Measurable, Attainable, Relevant, Time-bound).

Quotes

Martijn Verburg seems highly quotable. Here are some that stuck in my mind.

“Virtualisation is ruining it for everyone.”

“Seagull managers fly in, make a lot of noise, dump on everyone, then fly out.”

“Having to use swap when running out of memory, is like getting your beer from Pluto instead of the other side of the pub.”

“Don't optimize. Java is way smarter than you are.”

“Lead, follow or get out of the way.”

P.S. the picture at the top of the article is the ceiling of the conference room in the Jaarbeurs in Utrecht. They have some very interesting architecture. Seemed like we were sitting right under a rocketengine.

References

[1] Blue4IT - Kennisavond met Java Champion Martijn Verburg

http://www.blue4it.nl/index.php/nieuws2/martijn-verburg/copy-of-microservices-with-java-ee-7-and-java-8-by-adam-bien

[2] JClarity

http://www.jclarity.com/

[3] Slideshare Slides - Habits of Highly Effective Teams

http://www.slideshare.net/jaxLondonConference/habits-ofhighlyeffectiveteams

Kodewerk

http://kodewerk.com/