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
TypeScript erasable syntax is a fairly new subset of TypeScript that supports very fast, very minimal transformation to run as regular JavaScript simply by erasing the TypeScript annotations from the source. It is particularly beneficial given that it preserves line and column positions and does not rewrite any of the JavaScript parts making generation and use of source maps unnecessary.
The approach was pioneered by bloomberg in the ts-blank-space project where they were able to massively reduce the compile time of these TS files. Node.js has recently adopted the approach and can now run TypeScript using the erasable syntax profile directly without tsc, transpilation, etc.
Currently, workers itself is not directly able to support TypeScript. While many workers developers use TypeScript, we still require transpilation/compilation before the worker bundle is deployed. What's even more inconvenient, editing through the dashboard does not support the TypeScript syntax/transformation at all.
I think it would be worthwhile for us to explore adding direct support for TS erasable syntax in the runtime such that a deployed worker does not need to be transpiled. The removal of the TS syntax dynamically at runtime can be extremely fast.
To give an idea of what erasable syntax does... take this example from ts-blank-space:
Which, in human readable terms is ugly but is perfectly executable JavaScript.
Node.js' implementation of erasable syntax is built around Amaro/SWC. SWC is a very fast rust-based tool that does all of the heavy lifting here.
We obviously would need to verify that introducing this transform wouldn't unreasonably impact cold start times but given the benchmarks I've seen so far I would be surprised.
They key benefit that this would provide is that it would allow users to upload TypeScript workers directly, without transpilation. If those are edited in the dash they would continue to see the type annotations, making the editing experience more seamless. It would also mean that our own tests and built-ins could also take advantage of TypeScript annotations. There are limitations, of course, as not all TS is erasable (enum for instance) so it does not entirely eliminate the need for transpilation but it is a step in the right direction that the other runtimes and build tools are embracing.
The text was updated successfully, but these errors were encountered:
TypeScript erasable syntax is a fairly new subset of TypeScript that supports very fast, very minimal transformation to run as regular JavaScript simply by erasing the TypeScript annotations from the source. It is particularly beneficial given that it preserves line and column positions and does not rewrite any of the JavaScript parts making generation and use of source maps unnecessary.
The approach was pioneered by bloomberg in the ts-blank-space project where they were able to massively reduce the compile time of these TS files. Node.js has recently adopted the approach and can now run TypeScript using the erasable syntax profile directly without tsc, transpilation, etc.
Currently, workers itself is not directly able to support TypeScript. While many workers developers use TypeScript, we still require transpilation/compilation before the worker bundle is deployed. What's even more inconvenient, editing through the dashboard does not support the TypeScript syntax/transformation at all.
I think it would be worthwhile for us to explore adding direct support for TS erasable syntax in the runtime such that a deployed worker does not need to be transpiled. The removal of the TS syntax dynamically at runtime can be extremely fast.
To give an idea of what erasable syntax does... take this example from ts-blank-space:
By erasing the TS annotations, this becomes:
Which, in human readable terms is ugly but is perfectly executable JavaScript.
Node.js' implementation of erasable syntax is built around Amaro/SWC. SWC is a very fast rust-based tool that does all of the heavy lifting here.
We obviously would need to verify that introducing this transform wouldn't unreasonably impact cold start times but given the benchmarks I've seen so far I would be surprised.
They key benefit that this would provide is that it would allow users to upload TypeScript workers directly, without transpilation. If those are edited in the dash they would continue to see the type annotations, making the editing experience more seamless. It would also mean that our own tests and built-ins could also take advantage of TypeScript annotations. There are limitations, of course, as not all TS is erasable (enum for instance) so it does not entirely eliminate the need for transpilation but it is a step in the right direction that the other runtimes and build tools are embracing.
The text was updated successfully, but these errors were encountered: