Kipper-Lang / Kipper

The Kipper programming language for Browsers and Node.js 🦊✨ Made at HTL Leonding & JKU Linz
https://kipper-lang.org
GNU General Public License v3.0
26 stars 4 forks source link

[Feature] Use the Rust SWC Compiler to support older versions of JavaScript and TypeScript, and allow for faster compilations #257

Open Luna-Klatzer opened 2 years ago

Luna-Klatzer commented 2 years ago

Is there an existing proposal for this?

This feature does not exist in the latest version

Proposal

With #208, there are now rough plans to implement a target for JavaScript ES2016, which would likely be implemented using TypeScript.

There is a possible issue with that solution though, considering the time and effort that would be required to support multiple ECMAScript versions, the target would have to stick to a few or maybe even only one target, like for example ES2016. That would likely limit the functionality of Kipper to a single target JS version, which would make development a lot easier, but also usage of Kipper a lot more restricted, as modern features are only slowly supported.

A possible solution to that issue could be using @swc/core and @swc/wasm-web, which are both written in Rust and therefore fully memory-safe and more performant than default JS/TS. These provide, like Babel, support for multiple ECMAScript versions and translations to older versions. This would mean if the Kipper JS target generated ES2020 code, the SWC Compiler could transpile it down to ES2018 or ES2016, depending on what the user wants.

This also has the advantage of having very performant compilations, while also sticking to the easily customisable nature of Kipper. That could also be applied to the TypeScript target, where older TypeScript versions and ECMAScript versions could be supported. To that, the user wouldn't have to worry so much about configuring a compiler besides the Kipper compiler, as the SWC Compiler could be integrated as an npm dependency and also bundled in the Browser.

To that, Kipper could even create its own Rust Crate where it implements a basic API using SWC and customise its behaviour to add more Kipper-specific features.

Exact behaviour / changes you want

There are three good solutions to utilise SWC in Kipper:

  1. Add @swc/core as an NPM dependency and use @swc/wasm-web for the kipper-standalone.js browser bundle. In this case, both packages would be used to transpile the code after the JS or TS target generated it. The best case would be that the targets generate the most modern code possible, like for example rn ES2020 (As that's the most modern version supported by SWC yet) and then the SWC Compiler compiles them down to older versions (ES2015-ES2019).
  2. Add @swc/core as an NPM dependency and use @swc/wasm-web for the kipper-standalone.js browser bundle. In this case, only the TypeScript target actually implements code generation and the SWC Compiler would do all of the work for the JS target. This could potentially improve speed (Maybe 5-10%), but it would completely remove the ability to customise the compilation behaviour and result in a weird structure, where the JS target is barely even there.
  3. Add SWC as a Rust dependency and create a Kipper Crate, where the SWC Compiler is used to compile JavaScript and TypeScript. In this case, the SWC Parser could be also used to parse JS and TS files, and allow them to be directly imported into Kipper (within certain type limitations of course). This would likely be the best performant and most efficient way to do it, as it also allows for more advanced import features and integration with JS/TS, though it would require the most work and a whole new workflow to compile Rust to WASM and support a whole new eco-system.
Luna-Klatzer commented 2 years ago

This will be a focus for Kipper v0.11 and is likely going to be implemented as described in options 1 and 3. Option 1 will be a priority though to allow for specific compilation targets, and the JS and TS imports will slowly be implemented as Kipper continues to be developed.

ByteWolf-dev commented 2 months ago

Due to Browserify issues this issue will probably not be implemented, as Browser support takes precedence.