pregular / core

⚠️Early Draft⚠️

Pregular

React has its Preact. It's time for Angular to get his Pregular! Full AOT support and as real WebComponents. Even the template syntax of Angular!

Source of quote: Bitcollage

Motivation

My main motivation for Pregular is Preact and the fact that I am fascinated about compilers (Babel, PostCSS), the love to Angular, Typescript, Reactive-Programming(RxJS) and of course to challenge myself. It is amazing that Jason Miller has developed against the interfaces of React and created an extremely slim version of React. Exactly the same I intend to do with Pregular.

Pregular should be fast and extremely slim in terms of file size!

Goal

Almost every line of code which could be executed at runtime should be created or optimized at compile time.

This way of creating code has many advantages. Huge runtime-libs, high memory usage, large bundled files, not optimize-code are practically almost nonexistent when the code generated at compile time. This is also called AOT. With this approach the JIT compiler has less work to do, and that is damn good for performance.

What do I mean when I talk about full AOT support?

This has nothing to do with Angular. It's more about AOT approach. Angular does it in his way and Pregular in his way.

Do not reinvent the wheel and simply use the official interfaces of Angular.

With Pregular you will have the same Angular Interfaces. I will use the Angular original ones. Internally I will map the interfaces to Pregular. The main difference is that the code will directly transpiled to WebComponents without any dependency to Angular. It will just be plain Javascript.

This procedure, also compiling directly to WebComponents has another advantage. You can use the written Pregular components in every conceivable Framework or Project. It does not matter if it is used React, Vue or Svelte.

Of course you could say why you are not supporting angular/elements and why putting in all this effort for Pregular?

Well let me explain. The Typescript Eco-System in terms of plugin development and how to traverse or manipulate easily an AST is hard and not well documented. Furthermore, Angular is huge, this fact will take me a very long time to understand what is happening under the hood of Angular. Maybe in the end, when Pregular is implemented I will be much more smarter on how Angular works because I will have to deal with it while implementing Pregular. Hopefully.

Awesome toolings exist already. I do not have to write my own compiler, Angular-Template-Syntax-Parser or CSS-Parser.

I decided to go with Babel, Typescript (only typing system), PostCSS-Compiler, Angular-html-Parser, lit-html and lit-html-server for SSR. I am very familiar with them. Especially with writing Babel and PostCSS plugins. I have already looked into Angular-HTML-Parser library, it is not magic, it is handcraft that I already know from Babel and PostCSS.

There are some challenges that need to be overcome.

Using exactly the same Angular Template Syntax

The biggest and most exciting challenge will be to implement the Angular Template Syntax in Pregular. Parsing should not be a problem, because there is already the Angular-Template-Parser. In my point of view 2 things are important. First, not to reinvent the wheel and to use an existing, flexible, fast rendering engine, e.g. lit-html s tag function html and Secondly, most important, writing an adapter that translates Angular-Template-Syntax into the desired rendering engine at compile time.

lit-html is like your very own template construction kit

lit-html is extremely customizable and extensible. Directives customize how values are handled, allowing for asynchronous values, efficient keyed-repeats, error boundaries, and more. lit-html is like your very own template construction kit.

Source of quote: lit-html.polymer-project.org

How could it be possible to implement directives with WebComponents?

There are two types of components in WebComponents. The classic one is to inherit directly from HTMLElement and define it with customElements.define:

Creation:

customElements.define('app-header', class extends HTMLElement {...});

Usage:

<app-header></app-header>

and secondly to inherit directly from an e.g HTMLButtonElement, HTMLDivElement or HTMLImgElement and interact directly in the instance of HTMLImageElement.

Creation:

customElements.define('ng-if-img', class extends HTMLImageElement {...}, {extends: 'img'});

Usage:

<img is="ng-if-img" ng-if-value="someValue" />

As you can see, the second variant is ideal for Angular Directive with WebComponents.

The shown concept (above) is on a very high abstract level. Of sure, in the implementation of Pregular there will more happens under the hood. I just wanted to show that even Angular directives can be implemented with real WebComponents.

Independent packages

At the end of the day it would be desirable if the Angular-Template-Syntax or other feature from Pregular could be used in other Projects, Frameworks or Libs. Therefore the development of Pregular is focused on loose coupling.

There are many frameworks out there. Many are self-contained. You can't just use features from other Frameworks, Libs or Projects. This should be different with Pregular. It should be like lit-html which expressed it very well.

lit-html is like your very own template construction kit

You will able to use any features of Pregular in other independent Projects!

Compiling not only to WebComponents

Theoretically, it would be also possible to use Pregular to compile directly into React, Vue or to another component Framework / Lib / Project.

Proposal platform for Angular Component

Let me first explain how BabelJS and the TC39 committee work together and what my intention behind Proposal platform for Angular Components is.

I assume that you have all heard of BabelJS and that it is used in almost every javascript project. With Babel you can use next generation Javascript today. I mean you can already test features in browsers that would normally not work. The best example is async await. This has been working long before native support.

What does TC39 committee do?

TC39 is the committee that evolves JavaScript. Their members are companies (among others, all major browser vendors). TC39 members meet regularly, and their meetings are attended by delegates who are sent and invited by experts.

Each proposal for an ECMAScript feature goes through the following maturity stages, starting with stage 0. The progression from one stage to the next one must be approved by TC39.

Source of Quote: 2ality.com

What is the relationship between BabelJS and TC39?

New Javascript features are only implemented by BabelJS if they reach Stage-1 in the TC39 committee. In short, TC39 invents new features, passes them to the next stage or discards them and Babel makes sure that can be used in not supported Browsers. This allows TC39 to detect design flaws early and even get feedback from the Community whether the new feature is accepted or not.

Note: Exactly the same is applied to Typescript. Only features will be implemented by Typescript which reached Stage-3 on TC39. There is one exception I can remember and that is the @decorators(stage-2) proposal.

What does this have to do with Pregular?

First of all, I would like to make it clear that my intention is not to propose e.g. a new decorator or a directive. These can already be implemented by Angular resources. Rather, it is about trying out completely new concepts. In an old project of mine app-decorators you can define real javascript events (see below @on load, @on click example Code) in CSS. A part of this feature is executed at compile time and the rest, a small runtime executes at runtime.

I think with BabelJS and PostCSS you can implement ideas faster than with Typescript and Angular. The tooling, the developer experience around BabelJS and PostCSS is simply more easier and the community has much more experience with these two tools. You would have more devs who might work on this project.

These are just two examples (see below code examples) what i already implemented with app-decorators and would like to port to Pregular.

Maybe we can 'build a bridge' between Pregular and Angular just like BabelJS and TC39 do.

// Example CSS-File

/** These atrule (@) events will be loaded asynchronous (non blocking) **/

/** will be loaded on load event **/
@on load {
  @fetch path/to/on/load.css;
}

/** will be loaded when clicked .up class **/
@on click .up {
  @fetch path/to/on/click/up.css;
}

/** will be loaded when url changed **/
@route hello/my/friend.html {
  @fetch path/to/on/some/route/action.css;
}

/** critical path (inline css will appear immediately) **/
my-box div {
  width: 100px;
  height: 100px;
}

Or moving an Element by declaring events in css properties.

my-box div {
  top: mousemove('top');
  left: mousemove('left');
}

And what about AI-Based which you can see at the top of the github repo?

I don't want to talk about that yet but when the time comes, you will be the first to know but in short, it follows a different approach like guess-js. The fetching of the files (HTML, CSS and Javascript) per Component by the Browser is much more fragmented or/and clustered. Interaction such as Events (Click, Hove) are also considered.

The only thing in common with guess-js is that the evaluation is done by an AI.

Conclusion

This is not a design document. These are just my thoughts on how I imagine Pregular to be. Design documents follow as soon as they are worked out. Of course you are welcome to participate in this project. I would be happy about it.

Pregular Features

Meanings

@Component({
  selector: 'lazy-img-polyfill'
  elementType: 'img'
})

<img is="lazy-img-polyfill" loading="lazy" src="image/url.jpg">

* Safari needs polyfill

@Component({
  selector: 'some-component',
  template: 
    <router-outlet name="myOutlet"></router-outlet>
})
class Foo {
  @Route('/name1/{{value}}', {name: 'myOutlet'}, BarComponent)
  route1 = 'myRoute1';
}

Browser Support

* Indicates the current version of the browser
In special cases lazy load polyfills for older browsers (+IE11 excluded) but not in first step of pregular

dev watch test

• npm run compile:watch
• npm run test

dev single run test

• npm run compile
• npm run test