Having no choice is painful. Having too many choices is even more painful. The latter is a true picture of the current front end. New frameworks emerge all the time: Is it difficult? Does it write fast? How maintainable is it? How is the performance? What about the community? What are the prospects? Good employment? Is it easy to recruit? Is it easy to build a team?
Each framework has to evaluate countless problems until you’re exhausted. This dilemma is known as “Bridan’s Donkey” – a donkey standing between two seemingly identical haystacks, not knowing how to choose, eventually dies of starvation.
That, of course, is a philosophical fable. In reality, most people use a simple strategy to crack it: follow the trend and go with what’s currently popular. It’s a low-cost, high-return strategy, but it comes with a risk: the monkey Comes Down the Mountain. The ideal solution is to recognize the difference between the two stacks of hay and choose the one that works better for you.
This article will take you through the details of Angular 2’s haystack.
ALL-IN-ONE
Whether 1 or 2, the most notable feature of Angular is its integration. It is an integrated framework developed and maintained by a single project team all the year round, covering M, V, C/VM and other levels. Most front-end development tasks can be completed without the need to combine and evaluate other technologies. This can effectively reduce the cost of decision-making, improve the speed of decision-making, is very helpful to the team that needs a quick start.
Let’s rephrase the question: Do you want to build a living room out of Lego or buy an IKEA kit?
Angular 2 is the Ikea suite of front-end development. It is a well-designed framework that covers every layer of development and ADAPTS from one layer to the next.
Of course, you may remember all the fun Angular 1 brought you and… The pain. There are historical reasons for this. Because it evolved from a framework for prototyping, and because it was born so early (2009, for comparison, jQuery was born in 2006), the ecology was so imperfect that even the modularity mechanism had to be implemented by itself (which is where angular.module came from, and why it was abandoned in Angular 2). Over the course of seven years, the remnants of various evolutions are evident, leaving behind many “appendices”.
Angular 2, however, starts from a higher level, integrating the best of modern front-end concepts and providing comprehensive support at all levels, including framework, documentation, and tools. For example, its “component style” allows you to get the benefits of CSS Modules without knowing about them, its Starter project allows you to get advanced features like Hot Module Replacement without knowing about Webpack, It allows you to get information from Web workers (do you know what this is?) To achieve significant performance improvements.
Just flex your muscles at the front desk! Angular takes care of the rest behind the scenes!
Escape “Version hell”
If it’s one or two people developing a system with a life expectancy of less than a year, then any framework will do. But, in reality, we all call these systems “pits.” As a highly professional and highly engineered development team, we can’t leave the pit to friendly forces. The most obvious of these pits is the version of hell.
Imagine that you just upgrade a small version of the library and the original software becomes unusable, breaking N unit tests and M E2E scenarios. This is a nightmare for the development team — after all, you don’t want to reinvent the wheel, let alone do it over and over again. Or, it changes the big version number every time it makes a small change — yeah, I’m just not backward compatible, what can you do? All you can do is carefully upgrade not only the library itself but almost all the libraries it works with.
Visible, disorderly version of this number may let users pay a huge price. This is not only in terms of workload, but also in terms of recruiting and developing the development team. Imagine how much the development team has to remember for a framework that is incompatible with each other in smaller versions. It was a nightmare!
However, the issue of version numbers has long had a de facto standard in the industry, the SemVer Semantic version standard. The only problem is that as a framework/library author, the effort required to follow SemVer standards is enormous. Willingness to pay these costs is an important sign of maturity of a framework (and its development team).
Angular is one such framework, and the efforts of its development team are well documented. If you started with Angular 1.2, all the code you wrote for Angular 1.2 can migrate to the latest version 1.5 without any problems. The new version introduces new features, but does not break old ones. This is because the Angular development team writes a lot of unit tests and E2E tests, using CI to ensure a smooth transition. Only during the migration from 1.0 to 1.2 (1.1 was always beta and was ignored) did a number of disruptive changes occur, which were clearly documented and explained why they were made — mostly to improve front-end code security. Even if you happen to encounter one of these disruptive changes, it will give you a clear error.
This necessary and boring work is the key to escaping version hell. The willingness to do these tedious tasks is a key characteristic of a framework’s mature and professional development team.
Modular technology
Angular is an all-in-one framework, but that doesn’t prevent it from being a flexible ONE. Remember the OCP(Open close Principle)? A good design should be open to extension and closed to modification.
Angular 2 follows the PRINCIPLES of OCP and SoC well.
It effectively separates rendering and interaction logic, which makes it easy to use with rendering engines like React, as well as in-memory rendering engines for server-side rendering. You can also use a Native rendering engine to compile true Native programs.
It also separates data provisioning from change detection logic, giving it the freedom to use third-party data frameworks/tools including RxJS and ImmutableJS.
Not only that.
The most distinctive feature of Angular 1 and Angular 2 is the dependency injection (DI) system, which brings to the front end the DI techniques used in back-end development to solve complex problems and achieve highly elastic design. Angular 2 introduces TypeScript to make it more flexible and convenient.
However, instead of tying it tightly to the framework itself, Angular 2 designs it as a standalone module. This means that whatever front-end framework you are using, even the NodeJS backend framework, is free to use it and benefit from it.
Keep an open mind
Google, maker of Chrome, and Microsoft, maker of Internet Explorer, were the two main players in the browser wars that people remember well.
As the saying goes: no permanent friends, no permanent enemies, only permanent…… Keep improving.
Under the guidance of this common wisdom, Google and Microsoft have reconciled, dropped many lawsuits against each other, and even started to cooperate in some areas. In fact, they started working together publicly before they reconciled publicly, thanks to Angular 2.
That brings up a little bit of gossip.
In the early stages of Angular 2 development, the project team was frustrated that traditional JS(ES5) and the ES6 draft didn’t meet their development needs. Then someone had a brainwave and developed a new language called AtScript. What was it? An updated version of JS with type support and Annotation support. TypeScript already has type support, and it’s pretty mature by then. The only regret is that it doesn’t support annotations, which are Java’s way of defining metadata through the @ symbol.
The Angular team went through this alone for a while, and somehow the two lovers were openly holding hands. In short, the end result is that annotations are added to TypeScript, and Angular abandons AtScript to TypeScript.
It’s a happy ending for both companies and their fans, and it’s fair to call it the union of the century. Since then, Google and Microsoft have gone beyond making eye contact and started a series of gestures of affection. Either way, this is good news for developers.
Fans may remember that Angular 2 was publicly mentioned at the 6.1 Microsoft Developer Conference. In fact, TypeScript is pretty well established, but still not widely used. Personally, Angular 2 will be a killer app for TypeScript. Angular 2 has a lot to do with TypeScript being named TIOBE’s language of the Year.
Why did I interrupt this story? That’s because I think the future of a product ultimately depends on the future of the development team, not the other way around. The essence of software is human! An open mind, pay attention to cooperation, the courage to break stereotypes of the development team, is the framework to give people confidence in the fundamental guarantee.
Full life cycle support
Unless you’re going to write one-off code, the software life cycle is long. At the macro level, the real challenges are multi-faceted and constantly changing. In the beginning, we need to prototype very quickly, get it up and running, and get end users to try it out. The challenge is speed and reusable assets.
A gradually expanding project team will then be set up to refine the functionality of the prototype. The main challenge is to keep the prototype evolving through refactoring, especially during the second half of evolution when the product needs to be ready to go live. But technical challenges are not a thing! It’s the people.
How to let new people quickly into the project team, contribute to productivity? It’s not that simple. “You should learn XXX 0.5, YYY 0.9, ZZZ 5.3… I’ll show you the code. “I can’t say that. A good framework needs to support a division of labor where everyone can start with a few simple tasks and work their way up from modifying a file to modifying a directory to implementing a feature independently.
With this division of labor, each team member can move from one success to another. This requires the framework to be local in design: you can make bold changes to one part without worrying about affecting another. You can only change the CSS, you can only change the HTML, you can only change the TS/JS, and you don’t have to worry about breaking anything else. Angular 2 provides this security with declarative interfaces, component styles, and separate template files.
Then, if your software makes it through the online maintenance phase, congratulations, you finally have the big Boss! The big Boss is maintainability. The Angular development team has a lot of programmers from Google, and if you ask who has the most experience in software maintenance, Google and Microsoft are definitely on the list. Microsoft exemplifies its experience with TypeScript’s strong typing mechanism, while Google exemplifies its experience by incorporating OCP, SoC, SRP, and other software design principles into Angular. Technical details are: DI, lifecycle hooks, components, and so on.
Finally, if your software has fulfilled its historical mission and needs to be phased out, is that a relief? No, you’re gonna have to keep it maintained. If you choose an open source technology that is closed or where the community is weak, you can leave your key architects and senior programmers behind to maintain it. Or you have to summon the courage to say to the user: You play, I go first. Angular is a large open source project, supported by Google. Even after the initial PR failure of the Angular 2 project, it still has a thriving community that no other competitor can match — both globally and in China. Clearly, there is reason to believe that the Angular community will continue to thrive, whether it is the inheritance of traditional community resources or the exploitation of new community resources. At the very least, Angular is the best choice if you don’t want your software to be built on top of a bunch of personally maintained core libraries.
Meet the future standard
In programming, innovation is everywhere. But the rarest thing for an engineering team is standards. Standards mean:
- Recruiting is easy. Because standard stuff is the most popular, and people want to learn it because they know it won’t go to waste.
- Raising people is easy. Because there are many online tutorials available, even if you have to do your own tutorials, the price is the highest.
- Substitution is easy. Standards mean that it’s not proprietary technology, and one person leaves and another person takes over, without a long gap that affects the business.
But standards will always be a beat or N beat behind innovation. This means that if you go after something new, there are engineering costs as well as technological gains. Of course, you can’t have it both ways, but there are strategies to reconcile the two. The simplest strategy is to meet the standards of the future.
A future standard is a draft of a standard that has the potential to become a future standard. It represents the industry’s approval of a technology, so that people are willing to invest in it even if it is not yet mature. For example, although Google has proposed a number of proprietary technologies, including SPDY, Gears, OGG, etc., it has not made them proprietary, but has opened them up to the community and incorporated them into the W3C draft standards.
Angular 2 uses this strategy. It refers to many draft standards, one is WebWorker, it uses WebWorker to move heavy computing work into the auxiliary thread, so that the interface thread is not affected; Angular 2’s componentized architecture is an implementation of WebComponents. Finally, CSS Scoping. There are a lot of modular CSS technologies out there, but they will eventually be integrated into CSS Scoping. If :local doesn’t make it into the standard, it will become proprietary. Angular 2 implements CSS Scoping standard drafts directly, such as the host pseudo-class and the :host-context pseudo-class. Clearly, the success rate of “meet the standards of the future” is much higher with this strategy.
A passionate embrace of standardization runs through Angular 2’s design philosophy, which is another source of confidence for me that it will win in the future.
The Fast and the Furious
Angular 2 is finally breaking free of the old technical framework and embracing the ultimate in speed. Angular 1, while performance is not an issue in most cases, is under fire for a triple loop in its code that does dirty checking — as if someone could feel the difference between 30 and 100 milliseconds.
Still, it’s not always nice to have a soft spot. In Angular 2, a redesign and the introduction of new technologies increase speed in principle, increasing “change detection” efficiency by 500%, according to a previous official data.
It makes two major improvements to the change detection algorithm:
- In terms of design, the previous “multiple rounds of inspection until stability” strategy was changed to “one round of inspection, direct stability” strategy. Of course, this imposes a certain limitation on your code, but in practice this limitation is only encountered in a limited number of scenarios, and the official documentation clearly indicates it.
- In terms of implementation, the “change detection” algorithm is moved into the helper thread created by WebWorker for execution. Modern home computers are basically multi-core and hyper-threaded, but in fact, they cannot make full use of all threads when browsing web pages. WebWorker provides a new mechanism to make some relatively heavy computing work run in the auxiliary thread, and notify the main thread when it is finished. Even if you don’t understand how webworkers work, you should at least know that Ajax requests don’t block interface responses, and neither does Webworkers.
In addition, Angular abstracts the data source, and you can use ImmutableJS as the Angular data source to get all the benefits of faster change detection.
In addition to change detection, Angular, and all front-end spAs, have a common problem: the first load is too slow to render the entire interface until all the JS and CSS have been downloaded. React solves this problem with the virtual DOM, whereas Angular 2 solves this problem with a separate server-side rendering engine. As we mentioned earlier, Angular 2 separates the rendering engine so that server-side in-memory rendering can be implemented in NodeJS. The so-called in-memory rendering is to render the DOM structure in memory and send it back to the browser, so that the client can display the complete interface without waiting for the JS code to download. Another benefit of this separation is SEO. SEO is also a difficulty in traditional SPA, it and server-side rendering are two aspects of the same problem, so with the completion of server-side rendering, SEO problem is also incidentally solved.
Let you upgrade seamlessly
The Angular 2 team made a serious PR mistake early on in announcing Angular 1 compatibility and not providing an upgrade from Angular 1 to Angular 2.
This cost the Angular 2 team dearly and broke the hearts of their fans. As a technician, this kind of mistake is understandable, but it takes more effort to make up for it. Angular 2 does exactly that.
In Angular 2, the development team provides an UpgradeAdapter class that allows all parts of Angular 1.x to work with all parts of Angular 2.x.
The best part is that it allows you to upgrade to Angular 2 file by file, while the app continues to run online throughout the upgrade process. Does it look magical? It doesn’t really matter, Google has been doing this kind of thing for a long time. This is just a small testament to the Angular team’s engineering prowess.
But then, why the rush to declare incompatibility in the first place? It can be seen that even an excellent engineering team will pay a huge price if it lacks the product operation skills to communicate with the community. Hopefully, the Angular team will be more careful in what they say and what they do.
I’ll write another article about this story from a person’s perspective.