sucrase
swc
Our great sponsors
sucrase | swc | |
---|---|---|
26 | 139 | |
5,560 | 29,773 | |
- | 1.3% | |
6.1 | 9.9 | |
about 1 month ago | 7 days ago | |
TypeScript | Rust | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
sucrase
-
Created a simple online JavaScript Playground, it's a place for you to try out your code and ideas.
Thanks u/OutlandishnessKey953, the playground built with React, Docusaurus(https://docusaurus.io/), CodeMirror(https://codemirror.net/), Sucrase(https://sucrase.io/), etc.
-
The TypeScript compiler is now implemented internally with modules
Hi, Sucrase author here.
To be clear, the benchmark in the README does not allow JIT warm-up. The Sucrase numbers would be better if it did. From testing just now (add `warmUp: true` to `benchmarkJest`), Sucrase is a little over 3x faster than swc if you allow warm-up, but it seemed unfair to disregard warm-up for the comparison in the README.
It's certainly fair to debate whether 360k lines of code is a realistic codebase size for the benchmark; the higher-scale the test case, the better Sucrase looks.
> worse it disables esbuild and swc's multi-threading
At some point I'm hoping to update the README benchmark to run all tools in parallel, which should be more convincing despite the added variability: https://github.com/alangpierce/sucrase/issues/730 . In an ideal environment, the results are pretty much the same as a per-core benchmark, but I do expect that Node's parallelism overhead and the JIT warm-up cost across many cores would make Sucrase less competitive than the current numbers.
Sucrase is faster or really close to SWC (see rhe benchmarks https://github.com/alangpierce/sucrase). Everyone still uses Babel because of the transforms.
And yes, Babel can also be made faster if enough effort is dedicated into it. it's not an impossible feat.
-
🚀 Building your own Javascript Library with bare minimum
As you might know there are a lot of Javascript bundlers out there, such as webpack, sucrase, parcel, rollup and etc. Bear in mind, not because they have thousands of stars on Github that means they're the best. sometimes new libs are as good as the popular ones but they're still building up their image/popularity in the community. what I bring today is a not sooooo, popular JS bundler called esbuild.
-
Five coding interview questions I hate
Sucrase JS was 2x the speed of esBuild and 50% faster than SWC last I checked.
-
I’m Porting the TypeScript Type Checker Tsc to Go
Webpack does way more than esbuild, including running a typechecking compiler instead of just transpiling, running compilers able to downlevel emit to ES5 and providing a deep plugin architecture allowing you to hook into any bit you like. But yes, it hasn't been designed with speed in mind - it has been designed with maximum extensibility instead. Its the same reason why Babel is slow compared to sucrase (written in JS, currently faster than SWC and esbuild but doing somewhat less - https://github.com/alangpierce/sucrase)
tsc has in fact been designed with speed in mind (I've been following the project since before it ended up on GitHub). Going beyond 1 order of magnitude performance improvement is highly unlikely.
- GitHub - alangpierce/sucrase: Super-fast alternative to Babel for when you can target modern JS runtimes
-
🚀10 Trending projects on GitHub for web developers - 29th October 2021
Try it out
View on GitHub
swc
-
Storybook 8 Beta
First, we switched the default compiler for new projects from Babel to SWC (Speedy Web Compiler). SWC is dramatically faster than Babel and requires zero configuration. We’ll continue to support Babel in any project currently using it.
-
What is JSDoc and why you may not need typescript for your next project?
SWC
-
Implementing auth flow as fast as possible using NestJS
As the reference explains “**SWC** (Speedy Web Compiler) is an extensible Rust-based platform that can be used for both compilation and bundling. Using SWC with Nest CLI is a great and simple way to significantly speed up your development process.”
-
Ruby Outperforms C: Breaking the Catch-22
This is specifically about breaking the myth that performing expensive self-contained operations (e.g, parsing GraphQL) in a native extension (C, Rust, etc.) is always faster than the interpreted language.
The JS ecosystem has the same problem, people think rewriting everything in Rust will be a magic fix. In practice, there's always the problem highlighted in the post (transitioning is expensive, causes optimization bailouts), as well as the cost of actually getting the results back into Node-land. This is why SWC abandoned the JS API for writing plugins - constantly bouncing back and forth while traversing AST nodes was even slower than Babel (e.g https://github.com/swc-project/swc/issues/1392#issuecomment-...)
-
Building a Minimalist Docker Image with Node, TypeScript
Why Speedy Web Compiler ?
- TypeScript Is Surprisingly OK for Compilers
-
FTA: Fast TypeScript Analyzer
FTA is a TypeScript static analysis tool built on the speedy foundations of swc. FTA is fast; capable of analyzing more than 150 files per second on typical hardware, it offers a powerful addition to your code quality toolkit.
-
Show HN: Ezno, a TypeScript checker written in Rust, is now open source
Very cool! I'm curious, is this intended for dev tooling?
For example, I could see this (or something similar) being useful as the engine for a typescript language server that would be faster than the standard one
But if it's not aimed at 1:1 with tsc, would it be intended more for something like swc[1]?
Or what would you expect people to use this for, besides just being a cool project to learn from?
-
[AskJS] Advantages of Rollup over other bundlers for creating libraries?
Rollup is highly configurable via plugins. It also supports a wide range of transpilation targets. However, it's written in JavaScript (well, TypeScript) so there's a ceiling on how fast it can go. esbuild and swc are orders-of-magnitude faster than Rollup.
-
Optimize your Bundle Size with SWC and GraphQL Codegen
There was already a Babel plugin for the client-preset for projects using Babel in the client-preset package. Now, as SWC itself, and Next.js is becoming more popular and uses SWC as its default compiler, there was a need for a SWC plugin as well. SWC is a fast and modern JavaScript/TypeScript compiler written in Rust, so the Babel plugin couldn't be used.
What are some alternatives?
esbuild - An extremely fast bundler for the web
vite - Next generation frontend tooling. It's fast!
ts-loader - TypeScript loader for webpack
tsup - The simplest and fastest way to bundle your TypeScript libraries.
vitest - Next generation testing framework powered by Vite.
ts-node - TypeScript execution and REPL for node.js
create-react-app-esbuild - Use esbuild in your create-react-app for faster compilation, development and tests
react-ssr-starter - 🔥 ⚛️ A React boilerplate for a universal web app with a highly scalable, offline-first foundation and our focus on performance and best practices.
Rollup - Next-generation ES module bundler
create-react-app - Set up a modern web app by running one command.