Performance
When AngularJS was first created, almost five years ago, it was not originally intended for developers. It was a tool targeted more at designers who needed to quickly build persistent HTML forms. Over time it has changed to accommodate a variety of scenarios and developers have picked it up and used it to build more and more complex applications. The Angular 1.x team has worked hard over the years to make incremental changes to the design, allowing it to continue to be relevant as the needs of modern web applications have changed. However, there are hard limits on the improvements that can be made, due to assumptions that were made as part of the original design. A number of these limits relate to performance problems resulting from the current binding and templating infrastructure. In order to fix those problems, new strategies are needed.
The Changing Web
In the five years since Angular was first conceived, the web has changed significantly. For example, five years ago it was almost impossible to build a proper cross-browser site without help from something like jQuery. However, today's browsers are not only more consistent in their DOM implementations, but these implementations are faster and offer new features particularly pertinent to application frameworks.
And the web continues to change...
While massive changes have happened in the last couple of years, they pale in comparison to what's coming in the next 1-3 years. In a few months the ES6 spec will be finalized. It's not unreasonable to think that we'll see a browser in 2015 that implements the full spec. Today's browsers already support some of these features and are working on implementations of the rest right now. This means browser support for things like modules, classes, lambdas, generators, etc. These features fundamentally transform the JavaScript programming experience. But big changes aren't constrained merely to JavaScript. Web Components are on the horizon. The term Web Components usually refers to a collection of four related W3C specifications:
Custom Elements - Enables the extension of HTML through custom tags.
HTML Imports - Enables packaging of various resources (HTML, CSS, JS, etc.).
Template Element - Enables the inclusion of inert HTML in a document.
Shadow DOM - Enables encapsulation of DOM and CSS.
By combining these four capabilities web developers can create declarative components (Custom Elements) which are fully encapsulated (Shadow DOM). These components can describe their own views (Template Element) and can be easily packaged for distribution to other developers (HTML Imports). When these specifications become available in all major browsers, we are likely to see developer creativity explode as many endeavor to create reusable components to solve common problems or address deficiencies in the standard HTML toolkit (from Databinding With Web Components). It's already possible today in Chrome and the other browsers have some of these specs implemented and are working on others. The future sounds awesome right? There's just one problem: most of today's databinding frameworks aren't prepared for this. Most frameworks, Angular 1.x included, have a databinding system that works based on the assumption of a small number of known HTML elements with well-known events and behaviors. In order for Angular developers to take advantage of Web Components, a new implementation of databinding is needed.
Mobile
Speaking of five years ago...me oh my how the computing landscape has changed! Phones and tablets are everywhere! While Angular can be used to build mobile apps, it wasn't designed with them in mind. This includes everything from the fundamental performance issues I've already mentioned to missing capabilities of its router, the inability to cache pre-compiled views and even lackluster touch support. Some of these things can be bolted on to Angular 1.3 (like the router for example) but others require fundamental changes to fix.
Ease of Use
Let's be honest...AngularJS isn't exactly the easiest thing to learn. Yeah, you pick it up and you think to yourself "This is awesome. It's really easy and magical!!!" Then you start building your app and find yourself going "holy...what!!?? I don't understand!!!" I've heard this story over and over again. There's even a handy graphic to illustrate the point. A lot of this, once again, stems back to the original design and intent of the library. Originally, there were no custom directives, for example. They were all hardcoded. Then, an API to add them was made available. Originally there were no controllers, then.... You get the picture. This bolting on of features, many which are today considered core ideas, has resulted in a less than elegant API. If Angular is to be truly easy to learn and use, then it has to have a clear understanding of its own core features from the outset. A framework where directives and controllers are part of the initial design, rather than bolted on after the fact is going to be better on many counts.
No comments:
Post a Comment