一步
意见建议收集区
该 issue 专门用于收集大家对该项目的意见和建议，欢迎大家积极留言建议。 一个人的能力和精力是有限的，众人拾材火焰高，希望一起把这个项目做成 h5 写移动应用的最佳模板🤠 （如果是反馈 bug，还请另外开 issue）
> 文章首发于我的博客 https://github.com/mcuking/blog/issues/86 ## 背景 这几个月在公司内做一个跨前端项目之间共享组件/区块的工程，主要思路就是在 [Bit](https://github.com/teambit/bit) 的基础上进行开发。Bit 主要目的是实现不同项目 **共享** 与 **同步** 组件/区块，大致思路如下： 在 A 项目中通过执行 Bit 提供的命令行工具将需要共享的组件/区块的源码推送到远端仓库，然后在 B 项目中就可以同样通过 Bit 提供的命令行工具拉取存储在 Bit 远程仓库的组件/区块。听起来比较像 Git，主要的区别是 Bit 除了推送源码之外，还会包括组件的依赖图谱分析、组件的版本管理等功能。下面这张图就描述了 Bit 的实现思路。更多细节可以参考 Bit...
跨项目区块复用方案实践
> 文章首发于我的博客 https://github.com/mcuking/blog/issues/88 ## 背景 在平时的前端业务开发中，常常需要使用一些组件库里的组件开发页面。然而单单这些组件一般很难完全满足业务需求，还需要针对不同的业务场景进行开发添加业务逻辑。当随着开发的前端项目数量越来越多，就会发现很多业务场景会经常遇到，而且基本大同小异，可能只需要修改少量的代码，原来开发的代码就可以在新的项目中使用。 例如账号绑定手机号这个场景，除了使用了 input、button 等组件等，还要添加很多例如校验手机号、设置倒计时、接口校验验证码等逻辑。如果输入验证码的样式比较特别，可能还会有基于通用 input 组件二次封装出专门针对验证码的输入框。当再次遇到类似绑定手机号的需求时，大部分前端往往会直接从原有的项目中拷贝一份到新的项目，然后做一些微调即可。 这方式可能会遇到以下几个问题： - **可复用的业务场景代码散落在形形色色的前端业务项目中，信息不互通，跨项目搜索很难**。 往往需要问些资历比较深的开发同事，才能知道某个业务场景在哪个项目中开发过。如果刚来的开发同事并不知道之前已经开发过，而是自己闷头从零开发，就会导致开发资源浪费的问题。 - **相似的业务场景在不同的业务项目里有着不同的代码实现，无法做到统一标准，共同实现一个最佳实践**。 平时开发时经常会有这样一个问题：在不同的业务项目中都编写过相似的业务场景的代码，但都是不同人各自维护的，之间也没有过交流。就会导致后面新的项目开发相似的业务场景时，面临有多个版本代码的选择。无法做到共同维护一个版本代码，并不断优化和改造，最终实现在这个业务场景的最佳实践。 后面的内容就是笔者为了解决上述问题，而开发的跨项目区块复用平台的实践总结。讲到这里读者可能会有个疑问：什么是区块？为什么是区块复用而不是组件复用？ 为了解答这个问题，我们先明确下这些概念的定义，下面直接引用阿里飞冰相关的定义： > 组件（component）：功能比较确定同时复杂度较高，例如用户选择器、地址选择器等，项目中只需要引入对应的 npm 包即可，项目不关心也无法修改组件内部的代码，只能通过组件定义的 props 控制。 > 区块（block）：一般是一个 UI 模块，使用区块时会将区块代码拷贝到项目代码中，项目里可以对区块代码进行任何改动，因此区块后续的升级也不会对项目有任何影响，这是区块跟业务组件的最大区别。...
> 文章首发于我的博客 https://github.com/mcuking/blog/issues/63 ## 背景 在 H5 + Native 的混合开发模式中，让人诟病最多的恐怕就是加载 H5 页面过程中的白屏问题了。下面这张图描述了从 WebView 初始化到 H5 页面最终渲染的整个过程。  其中目前主流的优化方式主要包括： 1. 针对 WebView 初始化：该过程大致需耗费 70~700ms。当客户端刚启动时，可以先提前初始化一个全局的 WebView 待用并隐藏。当用户访问了 WebView 时，直接使用这个 WebView 加载对应网页并展示。 2....
> 文章首发于我的博客 https://github.com/mcuking/blog/issues/110 ## 背景 距离发布如何私有化部署 CodeSandbox 沙箱的文章[《搭建一个属于自己的在线 IDE》](https://github.com/mcuking/blog/issues/86) 已经过了一年多的时间，最开始是为了在区块复用平台上能够实时构建前端代码并预览效果。不过在去年云音乐内部启动的基于源码的低代码平台项目中，同样有**在线实时构建前端应用**的需求，最初是采用从零开发沙箱的方式，不过自研沙箱存在以下几点问题： - **灵活性较差** 被构建应用的 npm 依赖需要提前被打包到沙箱本身的代码中，无法做到在构建过程中动态从服务获取应用依赖内容； - **兼容性较差** 被构建应用的技术选型比较受限，比如不支持使用 less 等； - **未实现与平台的隔离** 低代码平台和沙箱没有用类似 iframe 作为隔离，会存在沙箱构建页面的全局变量或者样式上被外部的低代码平台污染的问题。 当然如果继续在这个自研沙箱上继续开发，上面提到的问题还是可以逐步被解决的，只是需要投入更多的人力。 而 CodeSandbox 作为目最主流且成熟度较高的在线构建沙箱，不存在上面列出的问题。而且实现代码全部开源，也不存在安全问题。于是便决定采用私有化部署的 CodeSandbox...
## 背景 在上一篇文章 [《云音乐低代码：基于 CodeSandbox 的沙箱性能优化》](https://github.com/mcuking/blog/issues/110) 中有提到过 CodeSandbox 方案在构建规模较大的前端应用比较耗时的问题，并在文章结尾提到会尝试采用 bundless 构建模式来解决这个问题。而本文就是来介绍笔者在这块的实践成果 —— 对 Vite 进行改造使其可以运行在浏览器中，并结合其他技术实现一套基于浏览器的 bundless 在线实时构建沙箱方案。 在正式开始介绍本方案之前，先阐述下目前主流的沙箱方案以及存在的问题。 ### 云端沙箱方案 针对通用的应用进行实时构建可以采用云端沙箱（Cloud Sandbox）模式。该方案首先会在服务器中出初始化一个代码运行环境（Docker 或 microVM 等），然后将需要被构建的应用代码从指定位置（例如某个 git 代码仓库）拷贝到该运行环境中，安装依赖，最后执行构建命令对应用进行构建。该种模式对应用所采用的编程语言等没有特定要求，完全等同于本地环境。目前 CodeSandbox 的 Cloud...
> 文章首发于我的博客 https://github.com/mcuking/blog/issues/96 Wasm 解释器项目地址： [https://github.com/mcuking/wasmc](https://github.com/mcuking/wasmc) ## 背景 从去年年底开始笔者决定深入 WebAssembly（为了书写方便，接下来简称为 Wasm）这门技术，在读[《WebAssembly 原理与核心技术》](https://book.douban.com/subject/35233448/)这本书的过程中（这本书详细讲解了 Wasm 的解释器和虚拟机的工作原理以及实现思路），萌生了实现一个 Wasm 解释器的想法，于是就有了这个项目。接下来我们就直奔主题，看下到底如何实现一个 Wasm 解释器。 ## Wasm 背景知识 在具体阐述解释器实现过程之前，首先介绍下 Wasm 相关的背景知识。 ### Wasm 是什么 Wasm 是一种底层类汇编语言，能在 Web...
挖坑 目标是实现类似 Stackblitz 的 WebContainer 在线沙箱，希望后面实现出来然后回来填坑 相关资料： [Introducing WebContainers: Run Node.js natively in your browser](https://blog.stackblitz.com/posts/introducing-webcontainers/) [Stackblitz 的 WebContainer 探秘](https://zhuanlan.zhihu.com/p/446329929)
> 文章首发于我的博客 https://github.com/mcuking/blog/issues/106 > 原文链接 https://hacks.mozilla.org/2019/08/webassembly-interface-types/ > 文章名词解释 > MVP: 即 Minimum Viable Product，也就是最小可用版本。文章主要指的是 2017 年提出的 WebAssembly 的 MVP。 > > interface types: 即接口类型 > > IR: 即 Intermediate Representation，也就是中间表示。我们通常将编译器分为前端和后端。其中，前端会对所输入的程序进行词法分析、语法分析、语义分析，然后生成中间表达形式，也就是...
> 文章首发于我的博客 https://github.com/mcuking/blog/issues/108 > 原文链接 https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-future/ 人们对 WebAssembly 有误解。他们认为 2017 年登陆浏览器的 WebAssembly —— 我们称之为 WebAssembly 的最小可行产品（也称 MVP）—— 就是 WebAssembly 的最终版本。 我能理解这种误解的来源。WebAssembly 社区组确实致力于向后兼容。这意味着你今天创建的 WebAssembly 将在未来继续在浏览器上工作。 但这并不意味着 WebAssembly 的功能是完整的。事实上，情况远非如此。WebAssembly 将提供许多功能，它们将从根本上改变你可以使用 WebAssembly 执行的操作。...