Skip to content
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

Current Research State: November Update #171

Open
frank-dspeed opened this issue Nov 27, 2021 · 1 comment
Open

Current Research State: November Update #171

frank-dspeed opened this issue Nov 27, 2021 · 1 comment
Assignees

Comments

@frank-dspeed
Copy link
Member

frank-dspeed commented Nov 27, 2021

Update 27.11.2021

I am Working since more then 8 years on ECMAScript tooling and found out that the problem is not solve able on the tooling level alone
We need to Integrate more Stuff into the Language it Self to give the Coders better Code hints and also improve code creation speed.

In a later step we can improve the compiler and runtime variables with high code reuse.

we will base on graal js oracle/graaljs#528 (comment) as it supports now custom resolve algos via the virtual filesystem that was the final step needed to offer a environment that is compatible to deno and node as also any other runtime

Some NodeJS behavior should get part of the "Stealify Standard" as also some Browser Behavior.

Resolving the right code is one of the biggest tooling issues that exist in ECMAScript and JS

Alternativ (Not So good but current State)

Create tooling that comp trans piles code and runs it in diffrent engines to get feedback.
as also configure project wide tooling to be aware of the diffrent environments the code will run in.
We are most of the time not able to tell where the code will run and how it will run there.

Final Goal Agenda

Create a Stealify Lang that is aware of diffrent runtimes it runs in as also offers feedback for the diffrent run times.
should be able to produce modules for any runtime: WebWorker, Browser TH, NodeJS , Deno, GraalJS, node-graal, AudioWorklet and so on.

ECMAScript is simply environment Agnostic Stealify will Know Target Environment and can this way Produce Environment Agnostic Code that Works!.

Who Knows what

What TypeScript ECMAScript
NodeJS x
Browser x

The Problem No Standard Module System is Implemented in other Engines only the Browser has a working Implementation and the graaljs one is working as expected.

List of Issues that can be solved

  • polyfills
  • environment shims
  • Polyglot debuging cross boundaries.
  • Cross Environment Live Debugging.
  • Optimization with live feedback.
  • Better overall integration.
@frank-dspeed frank-dspeed self-assigned this Nov 27, 2021
@frank-dspeed frank-dspeed changed the title Current Research State: Current Research State: November Update Nov 27, 2021
@frank-dspeed
Copy link
Member Author

Examples

  • Some Apis do exist on some browser versions others need shims this info needs to get to the developer or at last his tooling
    • Sure that sounds like babel but it is not that simple
    • Sure it sounds like lebab but it is not that simple

A Complex version and api matrix also exists for the web but not really for other runtimes.

@frank-dspeed frank-dspeed pinned this issue Nov 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant