We went away from node as a backend technology for a bunch of reasons. Here's a list of the biggest pain points: - Lack of a good standard API; compared to environments like Java, C# or Go, node's standard library is significantly sparse. - The tendency for small libraries/frameworks leads to a very high number of third party code with all the problems attached; bigger attack surface, licensing challenges, it's econo…
1. https://deno.land/std is deno's standard library.
2. Yet to be seen. Deno has few good modules like deno cliffy and drash which are structured nicely and easy to use. Otherwise, plenty of matured library for web and node can be used too.
3. Yet to be seen. Module management in deno is very explicit and there are no magic updates.
4. Deno support workers with an additional sandbox layer for multi threading. There are few proposals to solve cumbersome worker setup (requiring a separate file) in the pipeline. They will get standardized soon.
5. Deno has first class support for typescript. Type checking speed is a bit faster due to some optimizations and you can use no-check in development to run your typescript code. That will give it a huge boost.
Having type checking at runtime would be great but it would add significant performance penalty. There were some attempts to add it to typescript via plugins but nothing panned out.
6. You can share much more code between deno and browser. It is more compatible with web than node. Huge win for switching context for front-end developers and using the same skill set.
Other than that, deno cli will feel exactly like go and cargo. It tries to provide a similar tool chain and UX which node ecosystem lacks. That should feel fast (most stuff is written in rust except the type checking part).
At the moment, they are trying different approaches to speed up type checking. One is to convert swc AST to something that tsc can understand.