In modern web development, there are several techniques for building the components used by web applications. Angular's templates are authored using semantic HTML, encouraging a strong separation between how a component is structured and how it behaves. This is a design choice aligned with the Rule of Least Power.
For performance reasons, we would change how templates are compiled to try various optimizations and techniques. And we would do that without affecting our clients.
Performance is a very tricky thing. Often it is hard to know ahead of time how a particular technique will perform. So having the ability to experiment without breaking anyone is extremely useful. And it is key for building a fast framework.
This also means that the framework can have multiple implementations of the template compiler optimized for different use cases.
It is certainly possible to achieve the same result without using templates--you just need a well-specified boundary around the view layer. But it is a lot easier to maintain such a boundary when using templates.
Normally, you would have to define all the queries needed by those libraries explicitly. And if you do not use templates, there is not much you can do about it. It is not possible, at least in a general way, to derive the queries from the JavaScript code rendering the components without actually running it.
The situation is different when the framework uses templates. They are much simpler, and more constrained than JavaScript, and, as a result, the data-access integration library could reliably derive the queries from the templates. And since the queries usually match the structure of the views pretty closely, we can remove a lot of duplication this way. To see how it can be done, check out [the second half of the talk Angular 2 Data Flow by Jeff Cross, Rob Wormald and Alex Rickabaugh.
Can't we transform JavaScript the same way by, for example, implementing a Babel plugin? We can. But it is a lot harder. At least if we want to do it correctly.
You see, most templating languages just define the structure of the view. They have a limited set of well-defined side effects, and there are fewer order constraints. And that is why automatically adding new things to the template is unlikely to break the guarantees the templating language provides.
Here is an analogy to give you an intuition of what I mean here. Using templates to render components is akin to using this array literal
Since in Angular these concerns can be handled by the template rather by imperative code, these features can be turned on or off to serve different users, for testing, etc.
This helps you, the developer, quickly see the structure of the view, and how it can change.
But what is even more important is that the framework can do it too. It can easily see what parts of your view are static and optimize those. For instance, Angular knows that only expressions can change, and the rest of the markup is static. So after the initial rendering is done, the static markup is essentially free. It is a lot harder to detect static parts of the view when using virtual DOM.
It can also notify you about the structural changes. For instance, since Angular 2 knows when views get added or removed, it can animate those, without you having to do anything.
In general, it is important to recognize that any big team will have multiple roles. And HTML templates are more inclusive of real-world workflow that includes designers, testers, and others who aren't deeply familiar with JavaScript, but who can interact with HTML templates directly or through tools.
the less powerful the language, the more you can do with the data stored in that language [...] I chose HTML not to be a programming language because I wanted different programs to do different things with it: present it differently, extract tables of contents, index it, and so on.Because components are pure HTML, tools and developers can make smart assumptions about what components are and how they behave, and Angular 2 can do a lot of interesting things that would have not been possible if components used JavaScript instead. This article explores some of those benefits.
Swapping Implementations
One of the best things templates give us is a clear boundary separating the view layer from the rest of the framework. This enables us to completely swap the implementation of the view layer without breaking any applications. We did it several times while working on Angular 2.For performance reasons, we would change how templates are compiled to try various optimizations and techniques. And we would do that without affecting our clients.
Performance is a very tricky thing. Often it is hard to know ahead of time how a particular technique will perform. So having the ability to experiment without breaking anyone is extremely useful. And it is key for building a fast framework.
This also means that the framework can have multiple implementations of the template compiler optimized for different use cases.
It is certainly possible to achieve the same result without using templates--you just need a well-specified boundary around the view layer. But it is a lot easier to maintain such a boundary when using templates.
Analyzing Templates
Being able to analyse or introspect templates is another consequence of the rule of least power. To see what I mean, imagine you use a data-access library like Falcor or Relay.Normally, you would have to define all the queries needed by those libraries explicitly. And if you do not use templates, there is not much you can do about it. It is not possible, at least in a general way, to derive the queries from the JavaScript code rendering the components without actually running it.
The situation is different when the framework uses templates. They are much simpler, and more constrained than JavaScript, and, as a result, the data-access integration library could reliably derive the queries from the templates. And since the queries usually match the structure of the views pretty closely, we can remove a lot of duplication this way. To see how it can be done, check out [the second half of the talk Angular 2 Data Flow by Jeff Cross, Rob Wormald and Alex Rickabaugh.
Transforming Templates
Template introspection is extremely powerful. But what is even more powerful is being able to transform templates during compilation. This allows you to implement some syntax sugar in a matter of hours.Can't we transform JavaScript the same way by, for example, implementing a Babel plugin? We can. But it is a lot harder. At least if we want to do it correctly.
You see, most templating languages just define the structure of the view. They have a limited set of well-defined side effects, and there are fewer order constraints. And that is why automatically adding new things to the template is unlikely to break the guarantees the templating language provides.
Here is an analogy to give you an intuition of what I mean here. Using templates to render components is akin to using this array literal
[1,20,2,4] to describe the collection of the four numbers. Using JavaScript to render components is similar to using the following instructions to describe the same collection: array.push(1);Yes, the resulting collection is the same. The difference is that we can analyze the literal statically. So it is a lot easier to write transformations of it. And though in simple cases it is possible to analyze JavaScript to figure out what the resulting array will look like, it is not trivial. And it is not possible for an arbitrary set of instructions.
array.push(20);
array.push(21);
array.pop();
array.push(2);
array.push(4);
Declarative Animations/I18n/Accessibility
An ability to analyze and transform templates has a lot of practical applications. One of them is internationalization, where the framework can transform static text from one language to another without any runtime cost. Other examples include animations and accessibility.Since in Angular these concerns can be handled by the template rather by imperative code, these features can be turned on or off to serve different users, for testing, etc.
Separating Dynamic and Static Parts
Another thing that using a templating language gives you is a clear separation of the dynamic and static parts of the view.This helps you, the developer, quickly see the structure of the view, and how it can change.
But what is even more important is that the framework can do it too. It can easily see what parts of your view are static and optimize those. For instance, Angular knows that only expressions can change, and the rest of the markup is static. So after the initial rendering is done, the static markup is essentially free. It is a lot harder to detect static parts of the view when using virtual DOM.
It can also notify you about the structural changes. For instance, since Angular 2 knows when views get added or removed, it can animate those, without you having to do anything.
Building on Existing Technologies and Communities
Finally, a lot of people are already proficient with HTML and CSS, and they can leverage this knowledge to write html templates. On top of that, there is a rich set of tools around these technologies, and being able to use them when building applications is a huge plus.In general, it is important to recognize that any big team will have multiple roles. And HTML templates are more inclusive of real-world workflow that includes designers, testers, and others who aren't deeply familiar with JavaScript, but who can interact with HTML templates directly or through tools.
Using Other Templating Languages
Since using templates requires the framework to have a well-specified boundary around the view layer, it is not hard to add support for other template languages. This allows us to build better integrations with other technologies. For instance, the Angular 2/NativeScript integration uses XML instead of HTML. But it is easy to go even further and add support for such languages as Twig or Haml.Summary
Angular 2 embraces the rule of least power and uses templates because of this. This brings the following benefits:- The implementation of the template compiler can be swapped without affecting applications.
- Templates can be analyzed and transformed to remove boilerplate and improve dev experience.
- Static and dynamic parts of the view can be handled differently.
- Internationalization and animations can be implemented in a declarative way.
- Templates are built on top of an existing set of tools, and they are designer-friendly.
If you like this post, you can follow Victor Savkin on Twitter and read his personal blog.
Không có nhận xét nào:
Đăng nhận xét