老实讲，促使本文写作的动机有三点：
由于我目前的空闲时间有限，也就以条目的形式随意写一点东西吧。
按理说，这部分内容完全是多余，但其实不是。
在我的印象里，国内前端开发应该基本上被三大框架瓜分得差不多，但怪事恰恰被我遇上：某 dapp 项目在我介入的时候，居然发现了久违的 jQuery ，而且完全没有任何前端工程而言：一个 html 文件 + 一堆 js 文件。
这里首先声明，我已不是当年的我，现在早已对各类工具无感，只要能办成事，挣到钱，其实无所谓。因此 jQuery 并不在我歧视之列，并且自己写的 vscode-page 其实也用了历史悠久的模板库：handlebars.js。
上面那个 jQuery 工程的问题在于：代码杂乱无章，到处可见复制黏贴的痕迹，即便放在 10+ 年前，该工程也不能说得上好。因此，除非你对自己的代码掌控力十分自信且得到大家认可，还是俗套一点：选择一个前端框架，这样起码会有一个不错的起点。
至于语言，有条件的话还是采用 TypeScript，单单类型检查就能让你避免很多潜在问题。此外，也别忘了一些配套设施：自动化的代码风格检查、vscode 插件等等。这里摘抄一下以前文章的内容：
工程相关
因为本质上 vscode 插件开发是前端工程的范畴，并且我们团队主要采用 TypeScript ，因此用到的插件和规范如下：
代码风格：
- gts，强烈推荐，一键格式化和修复 lint 问题。
- TypeScript 开发团队编码规范
风格可商量余地：
- “strict”: true + “no-any”: false，允许
相关插件：
- ESLint
- Bracket Pair Colorizer 2
- Prettier
- markdownlint
- indent-rainbow
- Path Intellisense
- Peacock
最后，补充一个极大提高效率的 vscode 插件：tabnine，谁用谁知道。
数据精度问题让我丢了大人，至今觉得过意不去。但是，这类问题在做后端时候从未出现，现在想来，有几个原因：
结果待到上线日，出现了状况。
由于 dapp 项目对于数字很敏感，稍有差池就会出现问题，因此作为 dapp 开发者需要对数据精度保持高度重视。这里列出几个我觉得比较重要的地方：
本来，我觉得像 ethers.js 这么好用的库没有理由不被很多人知道。结果恰恰相反，实在让人大跌眼镜！
除非你有非常特异的需求，并且不仅限于跟合约交互，比如还想去试试发消息和存储，我建议直接使用 ethers.js，不要用 web3.js。原因很简单：
假如你还想增强合约方法（比如你想一次性完成：先预估 gas，然后设置 gaslimit ，然后执行合约方法）也很方便。
页面状态很关键，对于 dapp 更是如此。因为这里至少有两个地方需要注意：
以 uniswap 兑换为例：
所有这些状态应该在前端各个页面流畅地体现出来，即这里牵涉到状态传递地问题。如果不使用状态管理工具库的话，其实很容易写出很繁杂地代码。
可能有人说，这个简单，一个全局对象就行了：一个全局的 json 对象。不错，单从静态最终结果而言，全局对象是数据共享的最简单方法。但是，如何应对数据的变化呢？即，数据变化后能方便地通知出去。你可能会说，这个也很简单，封装成一个 Observable 然后让需要页面订阅就行了。不错哟，连 Observable 都知道。
但，即便如此，我还是希望劝你不要自己干这个事情，因为很快就会又有新的需求出现，而这些已经在那些成熟的状态管理库里实现好了。
这里，我推荐 Akita，简单、轻量、好用，相比 redux 和 ngrx 而言。
至于如何接收链上通知，你可以去看看 ethers.js 的文档，其中有相关的介绍。我建议的最简使用方式，直接监听 block mined 事件，然后去获取你需要的内容。
Metamask 在做些 breaking change 的事情，涉及到 API 的变化，比如不再注入 web3 ，取而代之的是 window.ethereum 。如果你还抄的是网上那些老代码，最好赶紧检查一下尽快替换。
关于 api 的情况，请检查其开发文档。
最后，说一说部署方式，这一点我原本以为也是常识性内容。
dapp 基本上就是一个静态站点，部署其实很简单，直接一个 web server 就行了。在当今处处大吹特吹“云原生”的时代，我们是不是也应该蹭蹭热点呢？！
停止自己买机器，然后搭 web server，再上传文件的做法！这里，我也发现不少人也没搞清楚前端构建是怎么回事。还以为放进去的代码可以很容易让人看出来咋回事。这完全是 10+ 年前的思维！
就当下而言，主流前端框架基本都至少具备了打包、压缩和混淆的功能，最后的代码基本没法看。因此，这种担心基本是多余的。
就部署方式而言，当前简单、省钱且更优的做法就是选用云服务商的：oss + cdn 架构。比起自建服务器而言，效果完全不是一个档次。
好了，这次就说这么多吧，等有时间再细聊。
或许你对以下的付费内容感兴趣 …… 😄
觉得有帮助的话，不妨考虑购买付费文章来支持我们 🙂 ：
付费文章