diff --git a/published/20230216.2 ⭐️⭐️ Writing Javascript without a build system.md b/published/20230216.2 ⭐️⭐️ Writing Javascript without a build system.md
new file mode 100644
index 0000000000..cafee37959
--- /dev/null
+++ b/published/20230216.2 ⭐️⭐️ Writing Javascript without a build system.md	
@@ -0,0 +1,195 @@
+[#]: subject: "Writing Javascript without a build system"
+[#]: via: "https://jvns.ca/blog/2023/02/16/writing-javascript-without-a-build-system/"
+[#]: author: "Julia Evans https://jvns.ca/"
+[#]: collector: "lkxed"
+[#]: translator: "wxy"
+[#]: reviewer: "wxy"
+[#]: publisher: "wxy"
+[#]: url: "https://linux.cn/article-15666-1.html"
+
+在没有构建系统的情况下编写 Javascript
+======
+
+![][0]
+
+嗨！这周我一直在写一些 Javascript，和往常一样，当我开始一个新的前端项目时，我面临的问题是：我是否应该使用构建系统？ 
+ 
+我想谈谈构建系统对我有什么吸引力，为什么我（通常）仍然不使用它们，以及一些前端 Javascript 库要求你使用构建系统时，为什么我觉得这让我感到沮丧。
+
+我写这篇文章是因为我看到的大多数关于 JS 的文章都假定你正在使用构建系统，而对于像我这样的人来说，编写非常简单的、不需要构建系统的小型 Javascript 项目时，构建系统可能反而添加了很多麻烦。
+
+#### 什么是构建系统？
+
+构建系统的思路是，你有一堆 Javascript 或 Typescript 代码，你想在把它放到你的网站上之前把它翻译成不同的 Javascript 代码。
+
+构建系统可以做很多有用的事情，比如：
+
+- （出于效率的考虑）将 100 多个 JS 文件合并成一个大的捆绑文件
+- 将 Typescript 翻译成 Javascript
+- 对 Typescript 进行类型检查
+- 精简化
+- 添加 Polyfills 以支持旧的浏览器
+- 编译 JSX
+- <ruby>摇树优化<rt>Tree Shaking</rt></ruby>（删除不使用的 JS 代码以减少文件大小）
+- 构建 CSS（像 [tailwind][1] 那样）
+- 可能还有很多其他重要的事情
+
+正因为如此，如果你今天正在构建一个复杂的前端项目，你可能会使用 Webpack、Rollup、Esbuild、Parcel 或 Vite 等构建系统。
+
+很多这些功能对我很有吸引力，我过去使用构建系统也是出于这样一些原因： 例如，[Mess With DNS][2] 使用 Esbuild 来翻译 Typescript，并将许多文件合并成一个大文件。
+
+#### 目标：轻松地对旧的小网站进行修改
+
+我做了很多简单的小网站（[之一][3]、[之二][4]、[之三][5]、[之四][6]），我对它们的维护精力大约为 0，而且我改变它们的频率很低。
+
+我的目标是，如果我有一个 3、5 年前做的网站，我希望能在 20 分钟内，
+
+- 在一台新的电脑上从 GitHub 获取源代码
+- 做一些修改
+- 把它放到互联网上
+
+但我对构建系统（不仅仅是 Javascript 构建系统！）的经验是，如果你有一个 5 年历史的网站，要重新构建这个网站会非常痛苦。
+
+因为我的大多数网站都很小，所以使用构建系统的 *优势* 很小 —— 我并不真的需要 Typescript 或 JSX。我只要有一个 400 行的 `script.js` 文件就可以了。
+
+#### 示例：尝试构建 SQL 实验场
+
+我的一个网站（[SQL 试验场][5]）使用了一个构建系统（它使用 Vue）。我最后一次编辑该项目是在 2 年前，是在另一台机器上。
+
+让我们看看我今天是否还能在我的机器上轻松地构建它。首先，我们要运行 `npm install`。下面是我得到的输出：
+
+```
+$ npm install
+[lots of output redacted]
+npm ERR! code 1
+npm ERR! path /Users/bork/work/sql-playground.wizardzines.com/node_modules/grpc
+npm ERR! command failed
+npm ERR! command sh /var/folders/3z/g3qrs9s96mg6r4dmzryjn3mm0000gn/T/install-b52c96ad.sh
+npm ERR! CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/surface/init.o
+npm ERR!   CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/avl/avl.o
+npm ERR!   CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/backoff/backoff.o
+npm ERR!   CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/channel/channel_args.o
+npm ERR!   CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/channel/channel_stack.o
+npm ERR!   CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/channel/channel_stack_builder.o
+npm ERR!   CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/channel/channel_trace.o
+npm ERR!   CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/channel/channelz.o
+```
+
+在构建 `grpc` 时出现了某种错误。没问题。反正我也不需要这个依赖关系，所以我可以花 5 分钟把它拆下来重建。现在我可以 `npm install` 了，一切正常。
+
+现在让我们试着构建这个项目：
+
+```
+$ npm run build
+  ?  Building for production...Error: error:0308010C:digital envelope routines::unsupported
+    at new Hash (node:internal/crypto/hash:71:19)
+    at Object.createHash (node:crypto:130:10)
+    at module.exports (/Users/bork/work/sql-playground.wizardzines.com/node_modules/webpack/lib/util/createHash.js:135:53)
+    at NormalModule._initBuildHash (/Users/bork/work/sql-playground.wizardzines.com/node_modules/webpack/lib/NormalModule.js:414:16)
+    at handleParseError (/Users/bork/work/sql-playground.wizardzines.com/node_modules/webpack/lib/NormalModule.js:467:10)
+    at /Users/bork/work/sql-playground.wizardzines.com/node_modules/webpack/lib/NormalModule.js:499:5
+    at /Users/bork/work/sql-playground.wizardzines.com/node_modules/webpack/lib/NormalModule.js:356:12
+    at /Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:373:3
+    at iterateNormalLoaders (/Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
+    at iterateNormalLoaders (/Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:221:10)
+    at /Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:236:3
+    at runSyncOrAsync (/Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:130:11)
+    at iterateNormalLoaders (/Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:232:2)
+    at Array.<anonymous> (/Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:205:4)
+    at Storage.finished (/Users/bork/work/sql-playground.wizardzines.com/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:43:16)
+    at /Users/bork/work/sql-playground.wizardzines.com/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:79:9
+```
+
+[这个 Stack Overflow 的答案][7] 建议运行 `export NODE_OPTIONS=--openssl-legacy-provider` 来解决这个错误。
+
+这很有效，最后我得以 `npm run build` 来构建这个项目。
+
+这其实并不坏（我只需要删除一个依赖关系和传递一个略显神秘的 Node 选项！），但我宁愿不被那些构建错误破坏。
+
+#### 对我来说，对于小项目来说，构建系统并不值得
+
+对我来说，一个复杂的 Javascript 构建系统对于 500 行的小项目来说似乎并不值得 —— 它意味着放弃了在未来能够轻松更新项目的能力，以换取一些相当微小的好处。
+
+#### Esbuild 似乎更稳定一些
+
+我想为 Esbuild 大声叫好： 我 [在 2021 年了解到 Esbuild][8]，并用于一个项目，到目前为止，它确实是一种更可靠的构建 JS 项目的方式。
+
+我刚刚尝试在一台新电脑上构建一个我最后一次改动在 8 个月前的 Esbuild 项目，结果成功了。但我不能肯定的说，两年后我是否还能轻松的建立那个项目。也许会的，我希望如此！
+
+#### 不使用构建系统通常是很容易的
+
+下面是 [Nginx 实验场][6] 代码中导入所有库的部分的样子：
+
+```
+<script src="js/vue.global.prod.js"></script>
+<script src="codemirror-5.63.0/lib/codemirror.js"></script>
+<script src="codemirror-5.63.0/mode/nginx/nginx.js"></script>
+<script src="codemirror-5.63.0/mode/shell/shell.js"></script>
+<script src="codemirror-5.63.0/mode/javascript/javascript.js"></script>
+<link rel="stylesheet" href="codemirror-5.63.0/lib/codemirror.css">
+<script src="script.js "></script>
+```
+
+这个项目也在使用 Vue，但它只是用 `<script src` 来加载 Vue —— 前端没有构建过程。
+
+#### 一个使用 Vue 的无构建系统模板
+
+有几个人问如何在没有构建系统的情况下开始编写 Javascript。当然，如果你想的话，你可以写原味的 JS，但我常用的框架是 Vue 3。
+
+[这是我做的一个小模板][9]，用于启动一个没有构建系统的 Vue 3 项目。它只有 2 个文件和大约 30 行的 HTML/JS。
+
+#### 有些库需要你使用构建系统
+
+构建系统这些事情最近盘旋在我的脑海里，因为这周我正在用 CodeMirror 5 做一个新项目，我看到有一个新版本，CodeMirror 6。
+
+所以我想 —— 很酷，也许我应该使用 CodeMirror 6 而不是 CodeMirror 5。但是 —— 似乎没有构建系统你就不能使用 CodeMirror 6（根据 [迁移指南][10]），所以我打算坚持使用 CodeMirror 5。
+
+同样地，你以前可以把 Tailwind 作为一个巨大的 CSS 文件下载，但是 [Tailwind 3][11] 似乎根本不能作为一个大的 CSS 文件使用，你需要运行 Javascript 来构建它。所以我现在要继续使用 Tailwind 2。（我知道，我知道，你不应该使用大的 CSS 文件，但是它验收只有 300KB，而且我真的不希望有构建步骤）
+
+（更正：看起来 Tailwind 在 2021 年发布了一个 [独立的命令行工具][12]，这似乎是一个不错的选择）
+
+我不完全确定为什么有些库不提供无构建系统版本 —— 也许发布无构建系统版本会给库增加很多额外的复杂性，而维护者认为这不值得。或者，库的设计意味着由于某种原因，不可能发布无构建系统版本。
+
+#### 我希望有更多的无构建系统的 Javascript 技巧
+
+到目前为止，我的主要策略是：
+
+- 在某个库的网站上搜索 “CDN”，找到一个单独的 Javascript 文件
+- 使用 [https://unpkg.com][13] 来查看该库是否有一个我可以使用的内置版本
+- 托管我自己的库的版本，而不是依赖可能崩溃的 CDN
+- 编写我自己的简单集成方案，而不是拉入另一个依赖关系（例如，前几天我为 Vue 编写了自己的 CodeMirror 组件）。
+- 如果我想要一个构建系统，就使用 Esbuild
+
+还有一些看起来很有趣但我还没有研究过的东西：
+
+- 这个 [关于 Javascript 注释中类型语法的 Typescript 建议][14]
+- 一般来说，ES 模块
+
+--------------------------------------------------------------------------------
+
+via: https://jvns.ca/blog/2023/02/16/writing-javascript-without-a-build-system/
+
+作者：[Julia Evans][a]
+选题：[lkxed][b]
+译者：[wxy](https://github.com/wxy)
+校对：[wxy](https://github.com/wxy)
+
+本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
+
+[a]: https://jvns.ca/
+[b]: https://github.com/lkxed/
+[1]: https://tailwindcss.com/
+[2]: https://messwithdns.net/
+[3]: https://css-examples.wizardzines.com/
+[4]: https://questions.wizardzines.com
+[5]: https://sql-playground.wizardzines.com/
+[6]: https://nginx-playground.wizardzines.com/
+[7]: https://stackoverflow.com/questions/69692842/error-message-error0308010cdigital-envelope-routinesunsupported
+[8]: https://jvns.ca/blog/2021/11/15/esbuild-vue/
+[9]: https://github.com/jvns/vue3-tiny-template
+[10]: https://codemirror.net/docs/migration/
+[11]: https://tailwindcss.com/docs/installation
+[12]: https://tailwindcss.com/blog/standalone-cli
+[13]: https://unpkg.com
+[14]: https://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/
+[0]: https://img.linux.net.cn/data/attachment/album/202303/27/120324jeqlswqte9exfxhh.jpg
\ No newline at end of file
diff --git a/sources/tech/20230216.2 ⭐️⭐️ Writing Javascript without a build system.md b/sources/tech/20230216.2 ⭐️⭐️ Writing Javascript without a build system.md
deleted file mode 100644
index bd45ab0824..0000000000
--- a/sources/tech/20230216.2 ⭐️⭐️ Writing Javascript without a build system.md	
+++ /dev/null
@@ -1,226 +0,0 @@
-[#]: subject: "Writing Javascript without a build system"
-[#]: via: "https://jvns.ca/blog/2023/02/16/writing-javascript-without-a-build-system/"
-[#]: author: "Julia Evans https://jvns.ca/"
-[#]: collector: "lkxed"
-[#]: translator: " "
-[#]: reviewer: " "
-[#]: publisher: " "
-[#]: url: " "
-
-Writing Javascript without a build system
-======
-
-Hello! I’ve been writing some Javascript this week, and as always when I start
-a new frontend project, I was faced with the question: should I use a build
-system?
-
-I want to talk about what’s appealing to me about build systems, why I
-(usually) still don’t use them, and why I find it frustrating that some
-frontend Javascript libraries require that you use a build system.
-
-I’m writing this because most of the writing I see about JS assumes that
-you’re using a build system, and it can be hard to navigate for folks like me
-who write very simple small Javascript projects that don’t require a build
-system.
-
-#### what’s a build system?
-
-The idea is that you have a bunch of Javascript or Typescript code, and you
-want to translate it into different Javascript code before you put it on your
-website.
-
-Build systems can do lots of useful things, like:
-
-- combining 100s of JS files into one big bundle (for efficiency reasons)
-- translating Typescript into Javascript
-- typechecking Typescript
-- minification
-- adding polyfills to support older browsers
-- compiling JSX
-- treeshaking (remove unused JS code to reduce file sizes)
-- building CSS (like [tailwind][1] does)
-- and probably lots of other important things
-
-Because of this, if you’re building a complex frontend project today, probably you’re using a build system like webpack, rollup, esbuild, parcel, or vite.
-
-Lots of those features are appealing to me, and I’ve used build systems in the past for some of these reasons: [Mess With DNS][2] uses `esbuild` to translate Typescript and combine lots of files into one big file, for example.
-
-#### the goal: easily make changes to old tiny websites
-
-I make a lot [of][3][small][4][simple][5][websites][6], I have approximately 0 maintenance energy for any of them, and I change them very infrequently.
-
-My goal is that if I have a site that I made 3 or 5 years ago, I’d like to be able to, in 20 minutes:
-
-- get the source from github on a new computer
-- make some changes
-- put it on the internet
-
-But my experience with build systems (not just Javascript build systems!), is
-that if you have a 5-year-old site, often it’s a huge pain to get the site
-built again.
-
-And because most of my websites are pretty small, the _advantage_ of using a
-build system is pretty small – I don’t really need Typescript or JSX. I can
-just have one 400-line `script.js` file and call it a day.
-
-#### example: trying to build the SQL playground
-
-One of my sites (the [sql playground][5]) uses a build system (it’s using Vue). I last edited that project 2 years ago, on a different machine.
-
-Let’s see if I can still easily build it today on my machine. To start out, we have to run `npm install`. Here’s the output I get.
-
-```
-$ npm install
-[lots of output redacted]
-npm ERR! code 1
-npm ERR! path /Users/bork/work/sql-playground.wizardzines.com/node_modules/grpc
-npm ERR! command failed
-npm ERR! command sh /var/folders/3z/g3qrs9s96mg6r4dmzryjn3mm0000gn/T/install-b52c96ad.sh
-npm ERR! CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/surface/init.o
-npm ERR!   CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/avl/avl.o
-npm ERR!   CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/backoff/backoff.o
-npm ERR!   CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/channel/channel_args.o
-npm ERR!   CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/channel/channel_stack.o
-npm ERR!   CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/channel/channel_stack_builder.o
-npm ERR!   CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/channel/channel_trace.o
-npm ERR!   CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/channel/channelz.o
-```
-
-There’s some kind of error building `grpc`. No problem. I don’t
-really need that dependency anyway, so I can just take 5 minutes to tear it out
-and rebuild. Now I can `npm install` and everything works.
-
-Now let’s try to build the project:
-
-```
-$ npm run build
-  ?  Building for production...Error: error:0308010C:digital envelope routines::unsupported
-    at new Hash (node:internal/crypto/hash:71:19)
-    at Object.createHash (node:crypto:130:10)
-    at module.exports (/Users/bork/work/sql-playground.wizardzines.com/node_modules/webpack/lib/util/createHash.js:135:53)
-    at NormalModule._initBuildHash (/Users/bork/work/sql-playground.wizardzines.com/node_modules/webpack/lib/NormalModule.js:414:16)
-    at handleParseError (/Users/bork/work/sql-playground.wizardzines.com/node_modules/webpack/lib/NormalModule.js:467:10)
-    at /Users/bork/work/sql-playground.wizardzines.com/node_modules/webpack/lib/NormalModule.js:499:5
-    at /Users/bork/work/sql-playground.wizardzines.com/node_modules/webpack/lib/NormalModule.js:356:12
-    at /Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:373:3
-    at iterateNormalLoaders (/Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
-    at iterateNormalLoaders (/Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:221:10)
-    at /Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:236:3
-    at runSyncOrAsync (/Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:130:11)
-    at iterateNormalLoaders (/Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:232:2)
-    at Array.<anonymous> (/Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:205:4)
-    at Storage.finished (/Users/bork/work/sql-playground.wizardzines.com/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:43:16)
-    at /Users/bork/work/sql-playground.wizardzines.com/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:79:9
-```
-
-[This stack overflow answer][7] suggests running `export NODE_OPTIONS=--openssl-legacy-provider` to fix this error.
-
-That works, and finally I can `npm run build` to build the project.
-
-This isn’t really that bad (I only had to remove a dependency and pass a slightly mysterious node option!),
-but I would rather not be derailed by those build errors.
-
-#### for me, a build system isn’t worth it for small projects
-
-For me, a complicated Javascript build system just doesn’t seem worth it for
-small 500-line projects – it means giving up being able to easily update the
-project in the future in exchange for some pretty marginal benefits.
-
-#### esbuild seems a little more stable
-
-I want to give a quick shoutout to esbuild: I [learned about esbuild in 2021][8] and used for a project, and
-so far it does seem a more reliable way to build JS projects.
-
-I just tried to build an `esbuild` project that I last touched 8 months ago on
-a new computer, and it worked. But I can’t say for sure if I’ll be able to
-easily build that project in 2 years. Maybe it will, I hope so!
-
-#### not using a build system is usually pretty easy
-
-Here’s what the part of [nginx playground][6] code that imports all the libraries looks like:
-
-```
-<script src="js/vue.global.prod.js"></script>
-<script src="codemirror-5.63.0/lib/codemirror.js"></script>
-<script src="codemirror-5.63.0/mode/nginx/nginx.js"></script>
-<script src="codemirror-5.63.0/mode/shell/shell.js"></script>
-<script src="codemirror-5.63.0/mode/javascript/javascript.js"></script>
-<link rel="stylesheet" href="codemirror-5.63.0/lib/codemirror.css">
-<script src="script.js "></script>
-```
-
-This project is also using Vue, but it just uses a `<script src` to load Vue –
-there’s no build process for the frontend.
-
-#### a no-build-system template for using Vue
-
-A couple of people asked how to get started writing Javascript without a build
-system. Of course you can write vanilla JS if you want, but my usual framework
-is Vue 3.
-
-[Here’s a tiny template I built][9]
-for starting a Vue 3 project with no build system. It’s just 2 files and ~30 lines of HTML/JS.
-
-#### some libraries require you to use a build system
-
-This build system stuff is on my mind recently because I’m using CodeMirror 5
-for a new project this week, and I saw there was a new version, CodeMirror 6.
-
-So I thought – cool, maybe I should use CodeMirror 6 instead of CodeMirror 5.
-But – it seems like you can’t use CodeMirror 6 without a build system (according to [the migration guide][10]). So I’m going to stick with CodeMirror 5.
-
-Similarly, you used to be able to just download Tailwind as a giant CSS file,
-but [Tailwind 3][11] doesn’t seem to be available as a
-big CSS file at all anymore, you need to run Javascript to build it. So I’m
-going to keep using Tailwind 2 for now. (I know, I know, you’re not supposed to use the big CSS file, but it’s only 300KB gzipped and I really don’t want a build step)
-
-(edit: it looks like Tailwind released a [standalone CLI][12] in 2021 which seems like a nice option)
-
-I’m not totally sure why some libraries don’t provide a no-build-system version
-– maybe distributing a no-build-system version would add a lot of additional
-complexity to the library, and the maintainer doesn’t think it’s worth it. Or
-maybe the library’s design means that it’s not possible to distribute a
-no-build-system version for some reason.
-
-#### I’d love more tips for no-build-system javascript
-
-My main strategies so far are:
-
-- search for “CDN” on a library’s website to find a standalone javascript file
-- use [https://unpkg.com][13] to see if the library has a built version I can use
-- host my own version of libraries instead of relying on a CDN that might go down
-- write my own simple integrations instead of pulling in another dependency (for example I wrote my own CodeMirror component for Vue the other day)
-- if I want a build system, use esbuild
-
-A couple of other things that look interesting but that I haven’t looked into:
-
-- this [typescript proposal for type syntax in Javascript comments][14]
-- ES modules generally
-
---------------------------------------------------------------------------------
-
-via: https://jvns.ca/blog/2023/02/16/writing-javascript-without-a-build-system/
-
-作者：[Julia Evans][a]
-选题：[lkxed][b]
-译者：[译者ID](https://github.com/译者ID)
-校对：[校对者ID](https://github.com/校对者ID)
-
-本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
-
-[a]: https://jvns.ca/
-[b]: https://github.com/lkxed/
-[1]: https://tailwindcss.com/
-[2]: https://messwithdns.net/
-[3]: https://css-examples.wizardzines.com/
-[4]: https://questions.wizardzines.com
-[5]: https://sql-playground.wizardzines.com/
-[6]: https://nginx-playground.wizardzines.com/
-[7]: https://stackoverflow.com/questions/69692842/error-message-error0308010cdigital-envelope-routinesunsupported
-[8]: https://jvns.ca/blog/2021/11/15/esbuild-vue/
-[9]: https://github.com/jvns/vue3-tiny-template
-[10]: https://codemirror.net/docs/migration/
-[11]: https://tailwindcss.com/docs/installation
-[12]: https://tailwindcss.com/blog/standalone-cli
-[13]: https://unpkg.com
-[14]: https://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/
\ No newline at end of file