Deno Support

[deeprobin]

Hey,

Vite is supposed to be a fast framework. Even if Deno is built on V8 just like Node and thus the code gene is the same, which accounts for a large part of the performance, Deno is still faster (and can also be used productively) ¹.
Nevertheless, it must be clearly mentioned that Deno is not the fastest JavaScript runtime on the market. Bun surpasses this significantly, of course, but Bun is still very experimental ².

Due to the fact that Deno is a really great runtime (I think many can agree) and additionally the security aspect is lived, there should also be a Deno implementation of Vite.

I am aware that this will be a big project with a lot of effort.

I am not talking about the possibility to deploy a Vite project under Deno, which is currently already possible, but about the whole Vite ecosystem.

For example there is packages/vite/src/node, but no packages/vite/src/deno.

---

Feel free to leave feedback.

Footnotes

1. Benchmark Deno vs. Node / January 2021 ↩

2. Bun website with Benchmarks ↩

[theArianit]

deno is actually comparable fast to bun after the recent deno updates. and it also depends on the modules and frameworks you are using on top. deno astro and deno fresh was much faster than bun.
anyway, I support the idea of vite for deno.

[patak-dev]

@deeprobin Vite already runs in deno. Use pnpm create vite-extra to start from a Vite+deno template.

Instructions at denoland/deno#15427 (comment)

See https://twitter.com/biwanczuk/status/1575206412296372232 and https://twitter.com/biwanczuk/status/1562784584978546689

And I recommend you don't miss Bartek's talk at ViteConf https://twitter.com/ViteConf/status/1565688339604422657

[patak-dev]

Deno has compatibility for that consumed Node APIs. Where it makes sense, we should be moving to use Web based APIs allowed in all environments. Having a complete fork of /node in /deno isn't going to work from a maintenance POV. If you see places where we could take advantage of a particular deno API (that we can apply conditionally using an env variable), please create a PR so we can evaluate it in a case-by-case basis. Thanks!

[deeprobin]

The web-based APIs are of course even more useful, but unfortunately not applicable everywhere. For the parts that are explicitly specific to the underlying runtime, I think there should be two implementations.
Of course, maintenance may be somewhat different in the case of Deno, but what is the concrete argument against it?

---

In any case, I'll have a look at the Vite-internals and maybe I can make one or the other PR.

[patak-dev]

A complete port of node/ to deno/ should probably be done as a fork. The concrete argument is that we don't have the resources to maintain two codebases in Vite Core and that having different code paths will introduce environment-specific bugs. In the long run, we should probably rename node to core.

[jjdive]

Now that deno runs Vite, more than performance I'm thinking in the ability to just import TS files using their URL inside the actual frontend code.

Do you guys have any idea if a rollup plugin is needed? Where do I start to try and implement one?

[ktiedt]

A complete port of node/ to deno/ should probably be done as a fork. The concrete argument is that we don't have the resources to maintain two codebases in Vite Core and that having different code paths will introduce environment-specific bugs. In the long run, we should probably rename node to core.

I was curious (tangentially related to this subject as well) If Vite and Deno had maybe researched combining efforts since yall are both using Rust to accelerate these dev processes. Instead of both teams creating a linter, formatter, etc, they could just share common ones to save on dev time for each set of maintainers... (in theory) and help carry forward more of the "common configs" that Vite has done a great job of building on like Rollup compat plugins and Linting, etc) which help Devs save time and learning new config methods and formats.