deno VS swc

Here is the relevant Github issue with a better explanation:

https://github.com/denoland/deno/issues/16105

Deno, version 1.28 or later.

import { serve } from "https://deno.land/[email protected]/http/server.ts"; const handler = async (_request: Request): Promise => { const resp = await fetch("https://api.github.com/users/denoland", { // The init object here has an headers object containing a // header that indicates what type of response we accept. // We're not specifying the method field since by default // fetch makes a GET request. headers: { accept: "application/json", }, }); return new Response(resp.body, { status: resp.status, headers: { "content-type": "application/json", }, }); }; serve(handler);

Does this change your mind at all? https://github.com/denoland/deno/blob/be1fc754a14683bf640b7b...

It looks to me like they've documented the KV Connect protocol they invented to support this feature, in enough detail that anyone else could build an alternative backend for it.

This has helped me feel completely OK with how they're handling this. They get an advantage in that they've already built an extremely robust proprietary backend, but I find that acceptable given the documented protocol.

Yes, sort of - on Deno Deploy the authentication doesn't come from a token in env vars, but from intrinsic security tickets baked into the Deno Deploy system. Also, it's a bit faster on first connect, because compared to KV connect we can skip the metadata exchange[1] because the information it provides is already present in Deno Deploy through other means. Both the backend service and frontend API (JS->KV) is the same though :)

[1]: https://github.com/denoland/deno/blob/be1fc754a14683bf640b7b...

import { serve } from "https://deno.land/[email protected]/http/server.ts";

Deno is an alternative JavaScript runtime that was released back in 2020. I’ve been seeing more interest in it recently, and it has some compelling features:

Most platform connectors are written on Deno, that allows you to host them serverless for free!

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-...)

Why Speedy Web Compiler ?

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.

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?

[1] https://github.com/swc-project/swc

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.

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.

MyPy and tsc on the other hand? Please make a Ruff for MyPy and hurry up and fund the author of SWC to develop STC. I'm tired of waiting several seconds after each :w for my quickcheck window to update.

I've been thinking this too time to time and tried to apply some poc to one of the codebase (https://github.com/swc-project/swc) but wasn't able to make notable progress. There were couple of reasons and curious how you could solve it.