You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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
The text was updated successfully, but these errors were encountered: