• 我感到了一股很重的翻译腔...

  • 《震惊!美女程序员去深圳某知名创新公司面试,对方居然提出了这样的要求!》

    不带“美女”都不算合格的震惊党

  • 我看了下,他只是说“你的女性身份让我很顾虑”,最终的理由是“没有大型项目的经验”,所以我个人认为他认为你没有大型项目经验可能对你就已经没兴趣,只是找一个他自认为不会那么伤面子的附加理由罢了。这可以算是弄巧成拙的善良吧,这是个人的一种解读。

  • IT 人的辛苦,何来价值 at 2017年2月23日

    “妈妈,那个半夜来,凌晨回家的人,是谁?” “那是你亲爸爸,他是隔壁老王。”

  • #19楼 @huacnlee 因为之前有很多帖子提到这个问题,甚至有详细的对比Turbolinks和React的渲染速度对比,然后回复就是一片声的赞扬Turbolinks的渲染速度。拿服务器渲染和客户端框架渲染速度作对比,就好比用一个HelloWorld裸框架和一个提供了很多基础设施的高级框架进行速度对比一样。

    这个对比很容易产生一个社区误导:React速度不行。(我已经在那个帖子看到不少了)

    你这个帖子只是略微提一下,那我也是略微提一下(我认为你不要再提这个了,尤其是Heroku这种例子,只会让社区更加不理解React)。

    以上,只是我的个人意见,并非抬杠。

    再看你的原话:

    所以鉴于上面的情况,这是有意义的,因为网络质量是不稳定的(例如,我的演示代码部署在 Heroku,首次打开以后几乎感觉不到 Heroku 的慢了),而且每个用户不同。

    强调了React在网络质量不稳定下的意义,至于其他的意义,只字未提。你说我理解错了,那就是说需要我脑补其他问题。

  • #17楼 @huacnlee 我引用的那一段后面是“关于 Webpacker”,你说我没看完后面的内容,我不知道我漏了哪一块?

  • #15楼 @huacnlee 是的,我“理解错了”,我说的要么你“不知道你在说什么”,要么就是“我当然知道”么?那我就不说了。😅

  • #13楼 @huacnlee

    我针对的是这个

    在网络质量好,服务器带宽足的场景下,大多数时候 Ruby China 这种 HTML 结果直接返回 + Turbolinks 的优化,打开的速度是更快的,因为前端几乎是无运算的,本身 Rails 做好了,单个页面 Response Time 在 100ms 左右,剩下的时间都是网络传输了(大篇幅 HTML 代码)。同时 React 应用典型的问题是首次打开慢。 所以鉴于上面的情况,这是有意义的,因为网络质量是不稳定的(例如,我的演示代码部署在 Heroku,首次打开以后几乎感觉不到 Heroku 的慢了),而且每个用户不同。

    1.Heroku的网络质量不稳定是国情,现在做网站一般多数不考虑这种情况

    2.大篇幅 HTML 代码 vs. React采用的API相比,网络传输节约的量微不足道

    结论:“所以鉴于上面的情况,这是有意义的,因为网络质量是不稳定的”

    你的意思是React的意义,就在于网络质量不稳定,节约流量。这个意义不大,现在网络已经不是以前的网络了,我觉得你考虑下react是不是简化了你的代码逻辑,易扩展,易维护,这个更值得分享,让我们更清楚哪些情况下更值得使用React,哪些情况下不值得使用(从你的描述来看,很容易得出结论:如果应对网络状况不佳的用户,React很有意义)。

  • 现在很多讨论都说react渲染和服务端渲染(Turbolinks本质上还是服务端渲染)速度的比较问题。其实我认为这个讨论没有太大的实质意义:react试图降低的是前端复杂性,而不是数据传输的大小(react做api,减少了html标签之类的数据传输微不足道,也不是react的重点,其他前后端分离的框架一样能做到;至于heroku什么的那是中国国情,也没什么代表性意义)。

    比如一个界面组成超复杂,交互逻辑很多,工程师都绕晕了的情况,react可以极大简化代码逻辑,更易维护。而ruby-china论坛这种网页前端复杂性停留在传统web1.0+时代的网站来说,并不是他的应用场景。

  • turbolinks 比 react快,结论:服务器渲染比客户端渲染快。这个意义是什么?