喜闻乐见啊，水深火热区就别隐藏了

@syhily 最后我下了 eap 2019.2 就没问题了

试了下，jdk8 以上的版本都没法启动，jdk8 的字体渲染又特别恐怖……

我还是喜欢 windows 2000 那种风格，简洁精炼不花哨，而且很快！

没啥好参观的吧，即便大楼进去了，每楼进办公区也要门禁，而且也没有参观机制。

看 u2b 不用字幕就秒杀了国内 >95% 的前端开发者了

python 的标准库混乱，全局函数和面向对象混用，某些语法晦涩不明，依赖 /包管理稀烂，2->3 也是个问题。始终无法理解为什么能吹得神乎其神，什么 zen of python 更是大笑话

这个都不是 vue 的问题了，这是编程基础的问题

作品集？

国产空调都是坑货，加一两千买进口的

我们生活在一个到处都是核反应堆的世界

正常，你在阿里工作肯定也不会让你用企业微信，你在腾讯工作也不会让你用钉钉，一个道理

@sodatea #64
> 2. 另外因为 function API 的灵活性，其实这个代码可以低成本自动化转换（并且不丧失可读性）。Akryum 昨天差不多一天时间就写出了这样一个在线工具： https://suspicious-mclean-0e54c3.netlify.com/

其实我意识到了一个挺有意思的问题，从 options 转成 setup 的确挺简单的，因为 options 的结构和层次分明。但是如果要从 setup 转成 options 的话……好像没有什么头绪，因为写法太灵活了，做不了静态分析，不知道这意味着什么。

@sodatea #64 感谢回复。

不知道我这么理解对不对，function-based api 是一个底层的组件定义方式，并且可以支撑起 object-based component 甚至 class-based component 的实现。而 Vue 是打算将 object-based component 等支持拆分出去，作为可选内容？

从昨天下午开始我就一直翻阅那个 PR 的回复，目前看来，Vue 团队挺有必要写一篇文章，或者在 RFC 中专门说明这个内容，来缓解社区对这个提案的误解的加深，不过我看 Evan You 似乎也已经开始着手这件事了。

我自己本身在大量的项目上使用 Vue，所以更能理解 Vue 之所以吸引人的地方。

- 我要实现某个逻辑，通常只有一种方法，马上就能开工。但是 Vue 3.0 还是之后的版本，则会让人纠结到底要用传统的 API 还是新 API，这个选择的过程就很使人难受，也是一个框架最不应该出现的问题。

- 代码组织轻松，即便是千人万人的团队，写出来的代码基本都差不多。因为基于对象（或者 Options ）的组件声明，把组件不同逻辑的编写方法和位置都约束起来了，而基于函数的声明方法给了开发者更大的自由，也产生了更大的不确定性。同时也降低了可读性（开发者需要在 setup() 里到处寻找 value 在哪里，methods 在哪里，分辨哪些是 computed，某个叫做 isEnabled 的字段到底是 value 还是 computed ）。

- 基于上面这些优点，随之带来的就是极低的上手门槛，不需要多熟悉 js 的语法糖或者未来特性，就能用 Vue 进行生产。然而在失去上面这些优势后，很难说 Vue 再会是一个亲民友好的框架了，而更像是一个被 React 社区不断影响干扰，而迷失了自我的失败品。

学习曲线陡峭度的提高、代码的可读性的降低、可能会出现的旧 API 被废弃导致的迁移成本，这些都是很可怕的问题。

而且基于函数的 API 的引入，这个改变太过巨大，在某种意义上可以认为这是一个新的框架了。所以为何 Vue 团队不考虑学习一下 Express 与 Koa，从 Vue 中分离出一个新的框架，从而服务那些真正需要这些新特性的高阶用户。毕竟某种意义上，引入这个新的 API，基本上所有现存的插件都要重写，这一点和 Koa 对于 Express 的改变来说，还是很相似的。

至少头条的应届价而已

obs studio