The company I work for has a kitchen like no other. This is not due to the industrial coffee machine which has queues every morning. There is another reason: the conversations. It is difficult to pass by and not get involved in conversation: leaves of absence, kindergarden, the weather, cars, gadgets and beliefs. When I talk about beliefs, I refer to the technical aspect of our work.
I hear the following sentences on a weekly basis "And this is the reason why I don't like Angular." or , "JavaScript? Hahaha…" I also hear "You front-end developers are not even real developers!" (This one really hurts!) But wait, not a minute goes by, and there's another comment: "Angular? Are you serious...?" Last but not least, another opinion comes along "Typescript? Well, that has JAVA written all over the place!" Folktale or not, I know you got the picture. Dear reader, I know that, like myself, you have very nimble adversaries. Therefore, I thought I should walk you through the world of the recently launched Angular 2, because you can never know who you will end up meeting in the kitchen.
If you somehow haven't been around for the past 5 years, we write SPAs (Single Page Applications) today, not just websites. Why do we do so? Users want speed. They don't have any time to wait for server round-trips or HTML pages being delivered one by one. In conclusion, we cannot allow ourselves to deliver 20 JS files in only one page. There is no way we can allow for that to happen. Today, we deliver only one file which contains our entire application. The file is called a bundle, but this bundle is more than just JS. It can contain everything: HTML, CSS, and JS.
"This doesn't sound all that bad" you will say, "but who knows how to gather all these files and place them in this bundle?" There are many tools for this tasks, but one of the top ones is Webpack. Webpack is a module bundler. What does this mean? A module bundler is a tool to which you give the modules you have written. The tool then solves the dependencies among modules. The end result is a file: your bundle. That bundle creates all the necessary HTML documents, so that the bundle can run in the browser. Moreover, the application bundle injects the CSS in the application at runtime. It's magic!
"But what do you mean by modules?" This is an excellent question! Everybody poked fun at JavaScript until not long ago, because JS enabled you to declare global variables easily. This meant that any area of your application could have access to the variable you created, and modify it. This is where the problem actually stems from: it becomes increasingly difficult for you to monitor the state of your application throughout time. Who modifies the variable and why? This is where the modules come to play. Instead of everything being exposed in open air, as was the case of the global variables, a module is like a fence around your yard. Whatever you do in that yard stays there. If you want to show your neighbor what you are doing, you take what you have and you export it over the fence. In this way, the neighbour can use the items you have in your yard, but you control what the neighbour can use. Therefore, the application is like a neighborhood made up of several closed yards, which communicate among them in a controlled way.
Therefore, one module can import elements from other modules and can export information towards other modules in the same manner. This means that the application becomes a graph made out of dependencies among modules. Who can offer us this functionality? JavaScript can do it in its latest version ES2015 (also called ES6, a name which comes from the group which defines JS standards: ECMAScript, or briefly — ES)! Things have changed quite a lot from the jQuery era, haven't they? You should not be deterred by the fact that we need to convert ES6 code into ES5 code. This is a temporary problem. Browser makers are more convinced than ever before that they must keep up with the new ECMAScript standards. Therefore, we will no longer have this problem in a few years.
If you are still reading these lines, you may ask yourself why I haven't said anything about Angular 2 until now. This is a very good question! The way I was writing JavaScript in the past (Angular 1 included) is different from the way the writing is done in Angular 2. The major change was actually brought about by … React. Yes, you read it well! In 2013, at the time React appeared in the JS world, it introduced a new concept which was meant to influence web development considerably: Web Components. These are customized elements, created by developers, which are meant to enable their reuse along the way. In other words, one part of the application receives a piece of information and knows what to do with it. This is an embedded part of the application. The modules and classes introduced by ES2015 give us access to the vocabulary we needed to write these Web Components. We know that React is powerful precisely because of the way the information is conveyed among components, which enables the optimization of costly UI operations. Therefore, Angular 2 naturally becomes better than the initial version, precisely for this reason. The fact that there is such a level of openness which can enable teamwork across the different projects in the JS world represents an advantage for each of us.
Now that we have basic notions about Web Components, we probably wonder how these communicate among them. Change Detection is completely rewritten in Angular 2. This new change detection mechanism which appears in information structure was embedded in a new library: Zone.js. This library offers the possibility of executing code in a delineated environment (called Zone), where changes on variables are detected even asynchronously. Due to their performance and utility, Zones were suggested to be included in a future JavaScript version.
There is another change which influences the way in which information circulates within Angular 2 applications. If, in the previous version, we were accustomed to change data on one side and to see the effect of those changes in all the places where that data is used (a concept also known as Double Data Binding), this has proven not to be the best approach because of performance issues. Therefore, as noted earlier, Angular 2 follows in React's footsteps and adopts a default working style in the form of Single Data Binding. If, before this change, we had a two-way street for data to circulate in applications, we now have a one-way street by default. The information leaves from one side and circulates towards the UI layer. As a result of this change, the performance level of Angular 2 is visibly better by comparison with its predecessor.
If you feel that this is the moment when silence will fall on the kitchen setting, it is now the time to say "Hold on, I am not done yet!" Angular 2 recommends that we use TypeScript. What is TypeScript? This is an extension of JavaScript which enables the annotation of various data types. I know that this is controversial. Almost a year ago, when I first saw TypeScript, the idea of it did not impress me. However, in the meantime, I saw that there are two means of using TypeScript: as a tool which increases the development speed, but also as a burden, because you want everything to be annotated to the last dot and comma. In brief, my recommendation is to use TypeScript as far as it is useful and it helps us be more efficient. In my experience, I noticed that I am faster when using it.
It's impossible to learn everything about Angular 2 from one paper. I already have the feeling that I have to write in smaller letters, to make sure that everything fits on the page. The new framework version offers other functionalities as well. Server-Side Rendering enables the generation of the first view directly on the server and its delivery in static version - everything in the name of increased speed. The fact that it was not developed for browser purposes, but for server purposes as well (even reaching the mobile ecosystems), makes Angular 2 a platform, not just a framework. Ahead of Time Compilation (AoT) entails that the HTML templates can be compiled directly on the server and then directly sent towards the browser so they can be used. The old method, Just in Time Compilation (JiT) entails that the browser must perform the entire template rendering work. In addition, we can also use Tree Shaking, a method which presupposes the statistical analysis of the generated bundle and the elimination of unnecessary code. The purpose of this technique is to eliminate as much code as possible from the framework. The list doesn't end here, but these are the most important pieces of news.
In conclusion, I hope that the topics discussed above will help you when you find yourself in the middle of a conversation about the frontend world. Angular 2 is an excellent tool which will stick around … for a couple of months. Google is already preparing the launch of Angular 3 in the first part of 2017 (they switched to Semantic Versioning). Obviously, the differences will not be as dramatic as were the ones which marked the switch from version 1 to version 2, but there will be changes. And this is not bad, on the contrary, it's not only the tools that we use which need to advance. We also need to keep up with them. Instead of complaining about the many libraries and tools in the JS world, we should be thankful for all the toys made available by the connected world we live in. In the end, being a JS Dev in 2016 is like being a child set loose in a toy store, as Eric Elliott might say. It's a tough world in company kitchens. I want to believe that both you and I have an extra weapon that can help us survive.
by Claudia Mihu
by Oana Călugar
