Nov 14 2018

My new book: Hands-On TypeScript for C# and .NET Core Developers.

Category: Asp.net core | JavaScript | TypeScript | AngularFrancesco @ 03:28

An exhaustive introduction to modern client side techniques for .Net Web developers.

All you need to learn for using modern client-side frameworks like Angular in a single place! I conceived this book to avoid the frustration of a never-ending search for the knowledge required to afford a modern JavaScript framework. This book consolidates in a single place all the knowledge required to implement a modern "rich-client" Web application using a non-trivial JavaScript / TypeScript code base:TypeScript, ECMAScript 6 features, JavaScript modules, TypeScript library development  and testing, bundling modules with WebPack, and the Angular single page application framework.

TypescriptCover_

JavaScript was initially conceived to enrich server-generated HTML pages with JavaScript widgets, including date pickers, autocomplete, tabs, and so on. With the increase in available internet bandwidth, and the enhanced computational power of desktops, laptops, mobile devices, and smartphones, in order to ensure faster responses to all user inputs, and to be in a position to better exploit all available resources, increasingly, application logic moved from the server-side to JavaScript code on the client machine, that is, until the diffusion of single page applications, where the entire application logic runs in JavaScript on the client machine and the server's role is limited to handling shared data, as well as authentication / authorization logic.The increasing complexity of JavaScript code bases led to the definition of new JavaScript specifications and toolsets to bring JavaScript from the level of a scripting language to that of modern object-oriented languages, like Java, C#, and C++. Among the significant changes and tools, the following are worthy of mention:

  1. The new ECMAScript 6 specifications that turn JavaScript into an advanced object-oriented language.
  2. The new TypeScript language that adds types to JavaScript to enable better compilation-time checks, and implements almost all new ECMAScript 6 features that are not yet supported by all browsers. What makes TypeScript great is that it is JavaScript of the future plus types, and that it transpiles to browser-compatible JavaScript.
  3. JavaScript library repositories, such as NPM, that are capable of automatically tracking dependencies among libraries.
  4. JavaScript test frameworks, such as Jasmine.
  5. The organization of JavaScript code into modules, and the usage tools called bundlers that facilitate the linking of several interdependent modules into a few JavaScript files to add to each HTML page.
  6. Frameworks such as Angular, that contain everything needed to implement single page applications.

Somewhat unfortunately, knowledge of the above subjects is spread across a variety of locations, so it is very frustrating when you come to write modern "rich-client" web applications. For instance, if you decide to learn Angular, you'll discover that you need to learn TypeScript beforehand, and then you'll discover that a knowledge of TypeScript is not enough either, because you also need to learn more about ECMAScript 6 and JavaScript modules. Finally, if you have resisted hitherto, you'll discover that you also need to learn about bundling and WebPack.

This book consolidates in a single place all the knowledge you require to implement a modern "rich-client" web application using a non-trivial JavaScript/TypeScript code base:TypeScript, ECMAScript 6 features, JavaScript modules, TypeScript library development  and testing, bundling modules with WebPack, and the Angular single page application framework.

What the book covers in detail.

Chapter 1, Introduction to TypeScript, explains how to install and configure TypeScript transpiler, TypeScript base types, variable declarations, and scoping. It also discusses TypeScript's mission, and how TypeScript types can help you to write, debug, and maintain your code bases.

Chapter 2, Complex Types and Functions, explains the basics of the language: arrays, tuples, interfaces, and function declarations. It also explains how to define new types by performing operations on existing types, and how to simplify your code with ECMAScript 6 destructuring and spread.

Chapter 3, DOM Manipulation, covers TypeScript types used to describe and manipulate the DOM, and how to use JavaScript libraries such as jQuery from TypeScript.

Chapter 4, Using Classes and Interfaces, covers TypeScript object programming, classes, interfaces, inheritance, and interface implementations. A complete code example explains how to architect a modular application with the help of abstract classes, interfaces, and inheritance.

Chapter 5, Generics, covers TypeScript generics, and how to define constraints on generics and type-mappings based on generics. TypeScript generics mimic C# generics, but, like C++ generics, they disappear in the compiled code.

Chapter 6, Namespaces and Modules, covers TypeScript's modular organization of code based either on namespaces, or on ECMAScript 6 modules. While TypeScript modules are completely based on ECMAScript 6 modules, they may run also in environments that do not support ECMAScript 6 modules, since ECMAScript 6 syntax may be processed by JavaScript bundlers such as WebPack, or transpiled in the syntax of AMD, CommomJs, or
SystemJs loaders, that run on all platforms/browsers.

Chapter 7, Bundling with WebPack, contains a quite complete and practical description of WebPack, and of its more frequently used modules and loaders. Here, the reader can learn everything that is worth knowing in terms of using WebPack with most modern JavaScript frameworks/libraries.

Chapter 8, Building TypeScript Libraries, describes how to develop a TypeScript library package with VS Code, how to test it with Jasmine, and how to package it as an NPM package.

Chapter 9, Decorators and Advanced ES6 Features, covers all ECMAScript 6 features, such as Symbols, Iterators/Generators, and Promises, that were not covered in previouschapters. The chapter also covers TypeScript's async/await notation, that is transpiled to Promise-based code, and TypeScript decorators and metadata that are important Angular building blocks.

Chapter 10, Angular ASP.NET Core Project Template, introduces Angular architecture, and describes all the parts an Angular CLI project is composed of, and how to configure a project. The chapter then lists all Angular building blocks, focusing on modules,
components, and data binding.

Chapter 11, Input and Interactions, explains how to take and validate user input, and how to customize standard data binding behavior with pipes and life cycle hooks. The chapter also covers the interaction of components through JavaScript and custom events.

Chapter 12, Angular Advanced Features, covers the details of attribute and structural directive usage and definition. The chapter also explains how to customize components with content projection (that is, filling predefined holes with input content), and how to improve the user interface with Angular animations, giving all details of Angular animation syntax.

Chapter 13, Navigation and Services, covers all Angular features conceived for complex applications, navigation among application pages, and how to dynamically load Angular modules. It also covers how components can communicate with the server using Angular HTTP Client class, and how HTTP Client and other services can be injected into components' constructors with the help of dependency injection. It also describes how to test components and other Angular classes.

Tags: , , , , ,

Jun 3 2016

Will Google Angular2 survive to Google own Polymer?

Category: JavaScript | TypeScriptFrancesco @ 00:56

A couples of weeks ago Google presented Polymer features at I/O 2016. In a few words Polymer is about Web Components. Web Components (also known as Custom Elements) are part of the Html and Dom specifications. They are a way of encapsulating both JavaScript, Html templates and Styles within reusable components. Everything is inside the component is not accessible from the external world. So for instance, component internal styles and JavaScript do not affect the remainder of the Web Page. Custom elements are associated with custom Html tags,so the developer may use them, by simply writing the custom tag. Since custom tags may contain other Html inside them Web Components may be nested. So for instance, you may define a “grid” custom element that may contain custom row or column templates inside of it..

At moment browser support for Web Components is limited basically to Opera and Chrome, but there are hundreds of polyfills that simulate them.

Polymer furnishes both:

  • A polyfill for browser not supporting Web Components
  • A complete set of already implemented components
  • Various tools to help you build web component based applications.

Angular team declared that they will end up adopting Polymer Web Components inside Angular. Since there is an overlap between Web Components and Angular custom elements, it appears that most of Angular UI logics will end up being completely substituted by Polymer Web Components.

This transition will be driven by the support provided also by other Browser to Web Components. In fact, with native browser support Web Components will over-perform slower simulated Angular UI constructs.

To say the truth, also polyfilled Web Components are faster than their equivalent Angular constructs, because normally Angular2 must visit the whole Model behind the page to perform changes detection each time an event occurs!

Thus for instance if you change a value in a grid with 10.000 items, it must check all all 10.000 items looking for changes that might affect the DOM. Luckily, if you use either Immutable objects or observables it is able to restrict changes detection just to the path within the overall page Model that contains the changed property. Please refer to this article for more details on Angular changes detection,and on how immutable objects and observables help the process.

However, this means you can’t use plain JavaScript objects as they are returned by the server, but you have to copy them into ad-hoc designed objects before binding them to the DOM .This was the main criticism moved by Angular sustainer against knockout.js, because of knockout.js usage of observables!

But why Angular1  started with plain JavaScript object and then moved toward immutable objects and observable? Simple! They hoped they might have improved performance thanks to the browser support of the forthcoming Object.observe api!

For the ones that never heard about Object.observe, changes in standard plain JavaScript objects should have automatically caused notifications to functions registered with Object.observe. Unluckily, Angular performance when using Object.observe was unacceptable! In a few words the reason of this unacceptable performance was the too many notifications coming from modified objects. In fact each event may cause a chain reaction of object modifications which in turn causes an unacceptable number of notifications being sent to  the Angular changes detection engine.

Similar problems with other software caused the removal of the Object.observe api from Chrome and  other browsers, and their consequent removal form the initial “standard” proposal.

Summing up, after this bad experience Angular team was forced to move to other techniques to improve performance, i.e.: immutable objects and observables.

So, from one side we have an UI based  on Polymer that has the following advantages:

  1. Based on a W3C standard
  2. Efficient, because in a short time all main browsers should support natively Web Components
  3. Modular, easily integrable with other frameworks, and not opinionated, since Polymer components are not tied to Polymer,but are completely independent chunks of software you may use in any application.The only constraint is that a polyfill be provided for browser not supporting Web Components yet. However, this constraint is going to be removed in a short time since Web Components will be soon implemented by all major browsers.

On the other side we have Angular:

  1. A complete framework, containing everything is needed to develop a client-techniques based Web Application, from User Interface  to client-server communication, and Dependency Injection. However, it is opinionated and quite difficult to integrate with other frameworks.
  2. Slow as compared to native Web Components and with no hope to overcome this gap.
  3. Forces the usage of Observables and/or Immutable objects in performance critique applications. True,that the usage of Immutable objects is expected to grow (give a look to this post for a quick introduction to JavaScript Immutable objects), but being forced to use them, for sure, makes life more difficult to developers in any case. Moreover, the immutable objects  paradigm doesn’t fit all situations,and for sure is not adequate for complex big business objects.

We might expect that with the increasing native support for Web Components Angular will be forced to integrate Polymer style web components,  till an almost complete substitution of its User Interface. Now the point is, is it worth using Angular once its UI stuffs have been substituted with another framework?

For sure a lot of people will continue using it, since it will continue being a “glue” that keeps together various client-side technologies, offering everything is needed to implement a client-based application. It will continue being attractive for companies that need its developers be guided by the “pre-defined style”  of an opinionated framework: a kind of guarantee all developers conform to a common universally accepted “standard”.

However, a lot of freelancers and company with a stronger “governance” of their teams, or company was strength is flexibility, will prefer implementing their applications by assembling modules from different authors/frameworks. Thus choosing each time the tools the more adequate to their current needs: say Polymer for UI,but tools from different authors for client/server communication and routing. In fact notwithstanding  the need of some companies for a complete  omni-comprehensive framework the community is preferring always more self-contained modules easy to assemble with other technologies.

Anyway while its difficult to forecast in detail the future of Angular, for sure it’s worth to start learning Polymer, and/or similar Web Component based frameworks like for instance React.js!

Have fun with Web Components!

Francesco

Tags: , , , ,