{"id":21083212,"url":"https://github.com/zhoukekestar/alibaba-interview-code-review","last_synced_at":"2026-02-19T11:02:39.020Z","repository":{"id":83127527,"uuid":"99231559","full_name":"zhoukekestar/alibaba-interview-code-review","owner":"zhoukekestar","description":"Try it on your browser!","archived":false,"fork":false,"pushed_at":"2017-08-07T05:41:46.000Z","size":191,"stargazers_count":2,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-10-22T15:09:55.999Z","etag":null,"topics":["alibaba","codereview"],"latest_commit_sha":null,"homepage":"https://zhoukekestar.github.io/alibaba-interview-code-review/","language":"HTML","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/zhoukekestar.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-08-03T12:44:50.000Z","updated_at":"2021-05-07T09:40:00.000Z","dependencies_parsed_at":null,"dependency_job_id":"afe3af29-1222-4322-b05e-38310d5ec998","html_url":"https://github.com/zhoukekestar/alibaba-interview-code-review","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/zhoukekestar/alibaba-interview-code-review","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zhoukekestar%2Falibaba-interview-code-review","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zhoukekestar%2Falibaba-interview-code-review/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zhoukekestar%2Falibaba-interview-code-review/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zhoukekestar%2Falibaba-interview-code-review/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/zhoukekestar","download_url":"https://codeload.github.com/zhoukekestar/alibaba-interview-code-review/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zhoukekestar%2Falibaba-interview-code-review/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29611002,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-19T10:52:55.328Z","status":"ssl_error","status_checked_at":"2026-02-19T10:52:26.323Z","response_time":117,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["alibaba","codereview"],"created_at":"2024-11-19T20:16:57.157Z","updated_at":"2026-02-19T11:02:39.002Z","avatar_url":"https://github.com/zhoukekestar.png","language":"HTML","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Code Review [![MIT](https://img.shields.io/badge/license-MIT-brightgreen.svg?style=flat-square)](./LICENSE)\n\nChrome 54+ Only!\n\n\u003e 这个样例不太现实，这是面向未来编程！Yeah ~~ \u003cbr\u003e\n框架只是过客，标准才是未来。（此话略偏激，不用太在意）\n\n# What's this?\n\n这个一个我想象中的、理想的开发状态，用了最新的`组件化`去编写页面。 虽然，在实际项目中，可能并没有什么用，但目标总归在哪儿了。虽说，给人的感觉又是在造轮子，但我更愿意把他称之为：`拼积木`。把一些小而美的东西，拼接起一个更漂亮的东西。\n\nPS: 就因为喜欢小而美的东西，老想着想把一些好玩东西，拆成小零件（比如：`vue` 抽取各种模块单独使用），汗，没想到，小时候拆收音机的习惯还在。。。\n\n# 几点思考\n\n我用 `Vue`, `React` 等框架的想法，或最看重他们的一些什么特点？\n* 组件化，组件化，组件化\n* 模板\n* 数据流的管理，组件间的通讯\n* 双向绑定\n* Virtual Dom\n\n## Virtual Dom\n\n关于 `virtual dom`, 可能说是他们的一大亮点，也确实因为 `virtual dom` 把页面性能提高了很多。性能提高主要也有两点：\n* 采用了 `AST` 去生成代码，并 `render` 出 `view`\n* 采用 `diff` 算法，动态、局部更新 `view`\n\n### AST\n关于第一点，使用纯 `JS` 去构建一颗树，而不采用 `real dom` 的原因是，因为 `real dom` 有太多的属性和特性了，这点是 `W3C` 的标准，标准就定哪儿，没办法，使用了 `virtual dom` 后，因为可以去掉很多无用的属性，一些需要用到的，比如: `click`, 这些，也可以通过在 `AST` 上添加一个对象属性就完成了，所以，确实有优化很多。做了不少努力，也是值得肯定的。\n\n如果像未来看，可能结果又不太一样了，随着浏览器性能的提升，正如 [`morphdom`](https://github.com/patrick-steele-idem/morphdom) 中说的（里面也有一个[性能对比图](https://github.com/patrick-steele-idem/morphdom#benchmarks)）：\n\u003e No, the DOM data structure is not slow. The DOM is a key part of any web browser so it must be fast. Walking a DOM tree and reading the attributes on DOM nodes is not slow. \u003cbr\u003e\n---- from https://github.com/patrick-steele-idem/morphdom#isnt-the-dom-slow\n\n受他影响，我觉得，浏览器的 `dom` 以后应该不会太慢吧？ `Dom` 速度的优化应该交给浏览器去做，而不是框架层面。我也`盲目乐观`地想着：`Let Chrome do this, let it go.`。 当然，也给自己留了条后路，万一浏览器不实现呢？给个 `document.createVirtualDocumentFragment` 也行啊，留条活路啊！~\n\n\n### diff\n\n`diff` 算法是主要的功臣，要是浏览器原生实现的话，那就爽翻了，简直不敢想！回到现实，`diff` 还是需要的，可预见的未来，浏览器也不打算做这块。所以，在 `TemplateMustache` 的 `render` 函数中，可以用 `morphdom` 优化一下页面的渲染。\n\n使用`morphdom`的前后对比：\n\n![before](https://user-images.githubusercontent.com/7157346/28958284-55a214dc-7928-11e7-8a1b-681ce30e41f4.gif)\n\n![after](https://user-images.githubusercontent.com/7157346/28958286-55cfdee4-7928-11e7-97b9-1c6eb71b3712.gif)\n\n\n## 数据双向绑定\n\n使用 `Object.defineProperty` 会有更好的兼容，如果兼容性要求比较高的话，还是用这个会比较好。但面向未来的话，在组件内部天然定义了 `set` 和 `get` 方法，可以对属性进行监控，从而对 `view` 进行更新。当然 `vue` 在这块做了很多工作，而 `WebComponents` 只是仅仅对组件属性可以做相应的 `observe`。\n\n面向未来的话，还可以使用 `Proxy` 来进行双向绑定，从而也可以解决：\n\u003e 无法监听数据的 length，导致 arr.length 这样的数据改变无法被监听 \u003cbr\u003e\n通过角标更改数据，即类似 arr[2] = 1 这样的赋值操作，也无法被监听 \u003cbr\u003e\n参考：http://jiongks.name/blog/vue-code-review/\n\n在源码中也可以写：\n\n```js\nawait sleep();\nletter.webcomponents.length = 4;\nawait sleep();\nletter.webcomponents[0] = webcomponents[0];\n```\n\n## 数据流的管理\n\n这个，`redux` 设计之初就是通用的，所以，直接拿来主义就行了，一个小而美的库。\n\n`Todo`: 数据的修改通过 `store` 去 `dispatch` 数据，而不是直接修改数据，这是一个可优化选项。\n\n\n## 模板\n\n这个一个既轻松又沉重的话题。轻松是因为，官方给的标准就是一个 `template`, 很简单。沉重是，太简单而无法满足项目需求，而且，各种模板层出不穷。包括 `mustache`, `art-template`, `jade`, `pug`. 还有各个框架有各个框架的一套 `template` 语法。\n\n我实际项目的升级改造中，`template` 语法的切换时一个大工作。就是因为没有统一的标准，也没被标准化，所以，这块其实是挺痛苦的。\n\n在样例中，我采用了 `mustache` ，主要是因为它小巧，但不足也有，很多时候无法满足项目需求。\n\n在模板语法的各种标准中，我会更倾向 `HTML-based` 或 `DOM-friendly` 的语法。虽然它不会像 `mustache` 那样去破坏 `HTML` 语法。但也会因此而破坏原有 `Element` 的属性标准。两者比起来，我会更倾向于后者。这个也是受 `Vue` 模板的影响。\n\n这么想起来，对比`mustache`, `vue` 和 `polymer`:\n\n* mustache\n```\n{{#list}}\n\u003cli\u003e{{.}}\u003c/li\u003e\n{{/list}}\n```\n\n* vue\n```\n\u003cli v-for='item in list'\u003e{{item}}\u003c/li\u003e\n```\n\n* polymer\n```\n\u003ctemplate is=\"dom-repeat\" items=\"{{employees}}\"\u003e\n  \u003cdiv\u003e{{item.first}}\u003c/div\u003e\n\u003c/template\u003e\n```\n\n写到这儿，我有点想明白为什么 `polymer` 要这样做了，我也能隐隐约约能感受到，`polymer` 正推动着前端`标准模板`往哪儿方向走了。\n* 破坏标准，肯定不行，`HTML` 和 `XML` 语法摆在哪儿\n* 私有属性太多也不行，原有元素的属性已经够多了，还加模板语法？感觉也不太行的样子\n* 所以。。。未来的模板标准会是 `polymer` 目前的样子吗？\n\n\n## 组件化，组件化，组件化\n\n这个，不用多说，标准已经定好了。在未来，无论是组件的可维护性，测试性，持久性，按标准来会有更好的前景。前段时间看了 `React` 能兼容 `WebComponents`, 也是蛮欣慰的。\n\n\n# 最后一点\n\n还有最后一个问题没写。我觉得好的地方。\n\n## 变化中求不变\n\n前端发展太快，需要学的东西也很多。想当初，`vue` 刚推出来哪会儿，几百的 `star` 的，大概看了一下当初简单的官网，主要就双向绑定功能，看上去感觉没什么（知道双向绑定，但没具体看源码）。双向绑定在哪会儿，概念也挺多了的，所以没在意。之后，随着它越来越火，看到了`组件化` 的概念，然后又接触了 `Custome Element v0`，然后就开始自己搞自己的组件化（在这儿就不献丑之前的源码了），基本上也就是 `html`, `css`, `js` 的混合。\n\n然后，发现 `React`, `Polymer`, `WebComponents`等，发现，虽然他们框架，用法，语法都各异，但组件化的思想都一样。比如，我们可以类比`React`:\n* `constructor` 都一样\n* `extends React.component`, 和 `Fancybutton extends HTMLElementButton`\n* `componentDidMount` 和 `connectedCallback`\n* `componentWillUnMount` 和 `disconnectedCallback`\n* `componentWillReviceProps` 和 `attributesCallback`\n\n所以，在平时的学习，不变的就是标准的 `WebComponents`, 很多框架只是在 `WebComponents` 这个核心上，添加各种功能，锦上添花。所以，我觉得好的地方是：`抓住了核心不放松，任儿东西南北风`.\n\n## 小而美\n\n组件化中使用 `morphdom` 和 `mustache`, 数据流还可以用 `redux`, 我偏爱小而美的库。小而美的库，专注做自己本分的事，虽然大项目，大框架也会做大量测试，但总感觉小而美的库会更好，更易于测试。而且，比较重要的一点是，各个库相互隔离，且可替代。比如，不喜欢`mustache` 语法的话，可以选择其他模板语言，甚至是自己设计也行。\n\n## 无编译\n\n不用 `webpack`, 不用 `glup`, 不用 `grunt`, `rollup`, 只要浏览器，升级你的浏览器，买不了吃亏，买不了上当。。。`HelloWorld`, 写起代码就上浏览器！==\n\n# 理想与现实\n\n关于兼容这块，一直比较欠缺，也是比较抗拒去做一些 IE 上的兼容，实在被逼无奈也会硬着头皮上，查各种 IE hack手段。\n\n我一直想象着，在面向小众系统的应用架构上，能使用最新的前端技术去解决问题。比如，公司内部的系统，要是能请个客，吃个饭，把用户群体的浏览器升级上去，解决浏览器升级的问题的话，那该会多好啊！\n\n喂！醒醒吧！别睡了，该写你的 `vue` 代码了！\n\n# 框架之外\n\n一篇受赵振宇老师启发的笔记：[框架之外](https://zhoukekestar.github.io/notes/2017/08/07/beyond-framework.html)\n\n# References\n\n* [Custom Elements](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Custom_Elements)\n* [mustache](https://github.com/janl/mustache.js)\n* [morphdom](https://github.com/patrick-steele-idem/morphdom)\n* [Custom Elements v1: Reusable Web Components](https://developers.google.com/web/fundamentals/getting-started/primers/customelements)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fzhoukekestar%2Falibaba-interview-code-review","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fzhoukekestar%2Falibaba-interview-code-review","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fzhoukekestar%2Falibaba-interview-code-review/lists"}