@shintendo #86
谁说了 jsx 是 es 标准？另外 jsx 也不是只有 react 在用。
className 是因为 html 原生有 class 的属性，所以在书写 jsx 的时候避免冲突新增了 className 这个属性。

首先没必要对立 react 和 vue，两者本来就不一样。
其次我解释的原因是很多人对 react 并不了解，就非要去搞对立，我就我懂的部分作出解释。

@shintendo #84 所以整楼也没人抓着 vue 的 template 说什么，那我觉着也没必要觉得 react 的 jsx 就是什么洪水猛兽了吧？

@murmur #51 51 楼的说法是错误的，react 本身没有任何写法上的要求，不需要你内置样式，甚至不依赖 jsx 。全程正常写 js 就可以。
官方文档第一篇就写着“你并不需要 jsx”，jsx 其实可以认为是 react 世界的语法糖，它把手写嵌套 React.createElement 的过程用 jsx 来代替，最终交给编译器（ Compiler ）去转化。
内联样式（ styled-components, emotion ）则纯粹是业界更高形态的工具，高内聚方便组件化。如果不喜欢，使用原始的 css 文件根本没有任何问题。

如果要这么考虑 react 的话，那你对 vue 可能是有点过于主观了，因为 vue 要学的东西只多不少，而你认为 vue 的指令只是学单词，这不合适。

首都大国贸 CBD 最核心区域一堆高楼中间的小小十字路口，表示绿灯过马路小心翼翼，必须得好好让着所有要左拐或者右拐的车，如果你已经在路上了而他刚过来，他不但不停车让你，还怠速一点一点贴近你试图逼你让他。
就这么一个垃圾分类都执行不起来的地方，枉称首都。

@ggmood #1 要注意的是逮虾户并没有安全保障

@shunia #9 不在意那些花里胡哨的界面，我只求能有一个普通人用起来不费脑子的统计功能。
在 ga 上做一点稍微自定义的数据统计可老费劲了，产品、策划甚至都不愿意用。

能不能支持 url 参数自动参与统计（或者至少可以计数，用户选择过滤或者筛选条件统计）？比如 a=1&b=2，a 和 b 可以像 utm_ 参数一样作为一个统计项。
每次新项目用 ga 我都在想怎么才能不用为 url 参数手动打点。。。

@yohole #49 至尊系列本来就不是主打型号吧，我记得 10 的尊享版也是很早就不卖了？（刚去京东确认了，确实如此）。K30 和米 10 都直接买的啊，所以好像只是至尊纪念版的销售策略问题？

另外我感觉是两点导致需要抢：
1. 小米太穷了，没那么大承受风险的能力，所以只能平衡产能换消费者的抢购体验；
2. 消费者被市场引导成要去“抢”小米，所以加剧了所有消费者不仅需要抢购而且还抢购不到的体验；

另外还有一个不容忽视的点就是蓝绿厂和华为都有更多的机型销售，去店里一看好多你叫不出名号的机型（基本都是坑人的机型，用什么 ABCD 开头），所以你感觉买的更容易，因为这部分机型有不少十八线的销售量，所以把你熟悉的机型的销量让出来了。
反观小米总共就两条线，一次性才发布几款手机？店里才摆了几台机器？而且每次出新机总给你感觉比上一代值，就导致大家都只买新的，老的放那也基本没人买。恶性循环而已。

@yohole #28 你买华为新机试试，不用抢？

@bthulu #42 Unity 因为是渲染引擎所以做 App 是挺耗性能的，很少有人选择。
@murmur 游戏工具有用 Unity 做桌面端的，比如： https://www.fairygui.com/ 这个 UI 工具就是用 Unity 开发的跨操作系统的桌面端。

@noqwerty #30 应该是最新的稳定版发布后就计划好的，我感觉说是 2，其实主要就是网页平台基本 production-ready 了

你们这些社群里吐槽我的渣渣连我的尾灯都摸不到。

所以如果我开源了项目我就可以这么瞧不起你们？使用者的吐槽和建议对于开源者来说就可以用“爱用用不用滚”的态度来回应？一个大厂超过百万用户的开源项目，应该可以有一点起码的对技术本身的尊重吧？（有问题解决问题，有建议根据实际情况进行处理）

所以我去你们尊贵的开源项目里，既不能吐槽缺乏某个功能，又不能建议增加某个功能，最后你还要看不起我让我一边玩去？

楼上的高赞答主如果都是这种心态，我觉得也不需要什么开源社区了吧？

我没看过 antd 的 github issues，但是社区里面举个例子 Typescript 的 issue 区是“官方关帖子”的重灾区，好多人的建议或者吐槽都被直接关闭了。但是即便是如此，被关闭的帖子基本都有非常详尽的解释：功能上为何不允许，特性上为何不满足，为什么不能直接做到而是要拐个弯实现。而且我相信它也不会被删库也不会玩彩蛋。
相比来说，国内顶级大厂的开源产品，虽然做到了足够多的用户，可是自己本身的开源品质就不够稳定，而且甚至还要冒出这种言论，还有精神支持者，真不知道都是从哪儿冒出来的“社区用户”。

Material-UI 它不香吗？

首先认识是错误的，牙周并不能吸收几十年，可能几年时间牙周就毁了最终导致拔牙。虽然可以带上“美丽的假牙”但是永远也恢复不了原本的牙齿功能。如果牙疼和出血一直持续到你换牙为止，并且还可以接受牙齿坏了之后的功能弱化（吃不了硬的难嚼的东西），那可能是无所谓吧。

其次现代医疗已经能越来越明确的处理疾病问题了，像牙周炎这种问题，有简单而且有效的治疗手段，就是龈下刮治。相当于口腔清洁+消炎，没什么神奇的特殊的地方。但是对治疗牙周炎很有效，成本也不高（北大口腔一共花了 2000 左右吧）。过程也不难受：根据牙周炎的程度不同，轻度的情况下可以无需麻药，中重度可以无痛。

这其实类似于肝疼胃疼忍忍自我感觉吃点止疼药就好了，然后去检查知道是胃溃疡、脂肪肝，觉得无所谓再忍忍，最后发展到。。。你懂的。

@shunia #3 哦，是对于没有依赖项的页面，看起来就是歪的

/{package} 页面的 readme 部分的样式是不是歪了，看起来偏左呢

@ClassicOldSong #172
关于模板逻辑的问题可能是我看的不够仔细，例子太长并且掺杂了不少符号在里面，主观的就避开了去仔细读它。

关于性能的问题你说的没错。
React 也就算了，毕竟它的设计思路就是以重建为主，在重建过程中进行优化。然而 Vue 确实是有机会避开 vdom 的。
而且 function component 的设计加重了性能优化的急迫性，组件深度增加后，“渲染”带来的性能问题越来越严重。

这可能也是为什么 svelte 崛起的如此之快：它用 compiler 避开了重建 vdom 的性能问题，又混合了 Vue 和 React 的语法，通过这两点很轻松的就获得了两方的用户，优秀的文档和基于原生 html/js/css 写法的方式甚至获取了三方的用户。

@ClassicOldSong #143
我想了一下，绝大部分情况下其实大家可能不需要功能完美的模板引擎：比如说 HTML 。。。用更加灵活的 JS 来处理动态内容更符合模板引擎的定位。就目前的开发环境来说，大家可能更希望三者分工是明确的。或者说至少我是这么觉得的，我并不想在模板字符串里进行低语意的逻辑处理，新的语法、格式化 /高亮、可能无法直接调试，这些问题都可能让开发过程并不舒适。如果你的引擎或者框架解决了这个问题，我觉得最好还是大字描述出来，降低大家使用的障碍。

引擎 /框架内部使用什么样的机制来处理，绝大部分人根本不关心，即便性能不够完美，在 80%以上的页面上性能可以达标理论上就够了。当用户需要追求那 20%的性能的时候，框架可以提供足够的便利性给用户去处理就够了。极端一点来说，JQuery 一把梭不够快吗？

认真讨论之外呢我还要主观一点表达个人态度：我觉得 PO 主有点过于自以为是了，首先且不说技术的优秀与否并不是驱动项目成功的关键，单说好多人提到给一个中文文档都没有正面答复这一点，我就觉得你也许适合做技术，但是并不适合面向公众，活在自己的理想主义世界里就够了。