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.
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!
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.
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
by Mircea Vădan