mirror of
https://github.com/discordeno/discordeno.git
synced 2026-09-17 08:47:22 +00:00
FlenyandJonathan Ho
70bcd16e8d
* Update docusaurus to v3.8, improve performance Docusaurus: - Update to v3.8.0 - Enable new faster features, rspack bundler cache and worker threads - Update CI to cache rspack bundler cache - Update dependencies to latest versions - Update blog posts to use the truncate tag - Update caniuse-lite Removed duplicated type documentation generation for bot package * Use .jsonc files for typedoc And use the readme option instead of a custom script * remvoe typedoc script --------- Co-authored-by: Jonathan Ho <heiheiho000@gmail.com>
53 lines
3.3 KiB
Markdown
53 lines
3.3 KiB
Markdown
---
|
|
slug: why-we-switched-from-deno-to-nodejs
|
|
title: 'From Deno to Node.js: Why We Made the Switch'
|
|
authors: [itohatweb, skillz]
|
|
tags: [deno, node.js, library]
|
|
date: 2023-04-03T17:01:03Z
|
|
---
|
|
|
|
# Our move from Deno to Node.js
|
|
|
|
As a team, we have recently made the decision to move away from Deno and migrate to Node.js. This was not a decision we made lightly, but rather one that was based on several factors.
|
|
|
|
<!-- truncate -->
|
|
|
|
## Deno's Broken Promises: Why we had to make the switch
|
|
|
|
One of the primary reasons we decided to make the switch was because we found that Deno had become a worse version of Node.js.
|
|
While Deno promised to be more secure, simpler to use, and more modern than Node.js, we found that it fell short on some of their promises.
|
|
|
|
Deno started to feel like a worse version of Node.js.
|
|
Initially, Deno was seen as a promising alternative to Node.js, but we found that it was ditching many of its principles.
|
|
For example, Deno initially didn't support configs or package.json, but now it does.
|
|
Additionally, they never wanted to support npm modules, but they have now added that support.
|
|
The same applies to the fact that imports were only allowed via relative or absolute URLs.
|
|
|
|
## Technical Issues with Deno: Difficulties in installation and usage
|
|
|
|
In addition, our team members were facing difficulties installing Deno on their machines.
|
|
Some of them spent hours trying to figure out why they couldn't install it, and it ended up being a major blocker for them.
|
|
On the other hand, Node.JS is well-established and easy to install.
|
|
|
|
Another issue we faced was with the Deno LSP. It would use 100% of the CPU for no apparent reason, making it unusable. Additionally, the VSCode extension for Deno had some wonky problems, making it a frustrating experience to use.
|
|
|
|
One other issue we encountered with Deno was with its formatter.
|
|
We found that it was quite inconsistent in its formatting, making it difficult to achieve a consistent codebase.
|
|
In some cases, it would add unnecessary changes to every file, even if the code was already properly formatted.
|
|
For instance, we had a recent PR where half of the changes were just from deno fmt, even though the code was already properly formatted.
|
|
This inconsistency in formatting made it frustrating to use, and we often found ourselves spending more time trying to fix the formatting than actually writing code.
|
|
|
|
## Our Focus on Efficiency and Scalability: Moving forward with Node.js
|
|
|
|
As a result of these issues, we have decided to move to Node.js.
|
|
While we understand that this may come as a surprise to some of our users, we believe that this decision is in the best interest of our community.
|
|
|
|
Moving forward, our main objective with the library remains the same - to deliver the same level of efficiency and scalability that was achieved with the Deno version.
|
|
However, we have decided to transition our focus towards Node.js to take advantage of its vast ecosystem and stability.
|
|
Discordeno will remain a runtime-agnostic library functioning in any javascript runtime including Deno.
|
|
|
|
## Our commitment to providing a reliable library for our users
|
|
|
|
We understand that this decision may not be popular with everyone, but we believe that it is the right decision for the future of our project.
|
|
We are confident that the library will continue to provide the same level of quality and reliability that our users have come to expect from us.
|