New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The Angular 7 API should be IDL-based #22398

Closed
eamon-otuathail opened this Issue Feb 23, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@eamon-otuathail

eamon-otuathail commented Feb 23, 2018

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

Angular currently works best with TypeScript application code. WebAssembly is supported by all four leading browsers in their shipping web browsers. Though WebAssembly needs a bit more evolving to become really useful, it is clear that it will play a significant role in browser development over the next few years. At the moment, Angular 6 and WebAssembly live in two separate worlds though they run in the same browser.

Expected behavior

The 20+ programming languages (Java, C#, Swift, Python, etc.) that are likely to be supported directly in the browser via WebAssembly should be able to easily use the Angular 7 Framework. For this to happen, some form of Interface Definition language (IDL) is needed to accurately describe the Angular 7 API and this will allow language-specific client wrappers to be generated for each client language. There are multiple kinds of IDL - perhaps the simplest to get started is to just use a subset of TypeScript that might act as an IDL. This will allow use of what is essentially the current Angular 6 exported API with some simplifications (e.g. pretty much all programming languages support class/method/property - so these are fine in an IDL, but some may have difficulty with TypeScript-specific metadata or type aliases).

Minimal reproduction of the problem with instructions

A more detailed explanation of the idea is here:
http://www.clipcode.net/content/angular-api-should-be-idl-based.pdf

What is the motivation / use case for changing the behavior?

All the programming languages coming to WebAssembly will need a powerful web framework for the same reason TypeScript developers needed one that they found in Angular.

@vicb

This comment has been minimized.

Contributor

vicb commented Feb 23, 2018

I agree when you say

The best software engineer is the one who does the least work (is that true?).

Do you think TypeScript .d.ts would answer your question ?

@eamon-otuathail

This comment has been minimized.

eamon-otuathail commented Feb 24, 2018

Using .d.ts is the easiest way to get started but I think more effort in producing an IDL-based Angular API will be needed over time. All the mainstream compiler teams are currently experimenting/prototyping with WebAssembly. In seven months time when Angular 7 arrives, they will be shipping compiler toolchains. Application developers using them will all be in need of a powerful web framework.

Let's say adding any random additional feature to Angular 7 will increase the Angular application developer population by 10%. Making Angular 7 callable from WebAssemblified Java/C#/Python will double the population overnight.

@ngbot ngbot bot added this to the needsTriage milestone Feb 26, 2018

@mhevery

This comment has been minimized.

Member

mhevery commented May 10, 2018

I see that you have put a lot of effort into this. Unfortunately this sounds like a great idea until you get deep into the details. The main issue is that IDL can only marshal primitives, All other objects have to have Proxies for them. This creates large amount of friction not to mention performance problems.

A secondary issue is that IDL can not be seamlessly converted into rich type system of typescript, which would create a less than ideal user experience. One way to think about it is that IDL is the least-common denominator of all supported targets, hence not very expressive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment