知乎这种纯前端渲染真的没问题么？

[autoxbc]

类似专栏页面这种，body 里就是空标签和 json
https://zhuanlan.zhihu.com/p/26644788

我就不说禁用 js 会怎样了
就是那大几万行的脚本，随便抛出个错误就会导致页面白板
Web 设计第一课，老师说要 "平稳退化，渐进增强"
是不是知乎的高逼格导致他们的前端也很吊？

看来短标题是不行的，因为真的有人只看标题就开始回复

这里想说的是平稳退化问题，不是过度兼容，和 IE6 没关系
平稳退化是说，行为层的非预期错误，不应妨碍内容层的展现
至少是基本内容的展现
行为层的非预期状况是普遍的，退化问题不会过时

纯前端渲染暴露出退化问题，纯前端渲染不是退化的敌人

[hronro]

平稳退化也要看时代，讲道理现在还能有不支持 js 的浏览器？

[GordianZ]

“我就不说禁用 js 会怎样了 ”
试验一下两秒钟要不要 😂

[NCR]

改版后的页面加载速度比原版慢了

[licraft]

@GordianZ 你名字后面的 mod 是什么东西？

[chengluyu]

这种纯前端渲染不都是用现有的框架吗，比如 React、Angular 和 Vue 之类的框架。

构建是基于组件的，一个地方崩了一般不会全炸的。而且几万行其实不都是手写的，所以不存在“随便抛出个错误就导致页面白板”，顶多部分组件工作不正常而已。

[Phariel]

@licraft 这里的超管 ʕ•͡•ʔ

[tabris17]

对 SEO 超级不友好，可能是 zhihu 觉得自己根本不需要 SEO 吧

[luo123qiu]

@licraft 大 V

[ynyounuo]

禁用 js 依旧可以在 Amazon 买东西 - -

[ynyounuo]

@licraft Mod(erator)

[ibm360]

知乎这种纯前端渲染真的有问题么

[vimutt]

@licraft
@Phariel 分明是充黄钻获得 mod 称号 233

[Shura]

@licraft 超级 VIP 专属标签，风投即可得到

[7654]

NoScript 用户需要多点击一次鼠标，才能确定这网站要不要逗留。。。。

[autoxbc]

@hronro 不要把平稳退化狭义化

@GordianZ 我试了，请您也试一次

@NCR 脚本有 2MB，展开 8 万行，一个纯展示弱交互网站，搞成这样

@chengluyu 脚本开头就崩的话，后面组件化也没用

@tabris17 SEO 不是关键，google 已经收录了，但是对用户不友好

@ibm360 纯前端没问题，没有退化就有问题

[tabris17]

@autoxbc 看了下源代码，内容是写在<textarea>标签里，然后脚本渲染，所以搜索引擎能采集到文本，但是图片就无能为力了

[XueSeason]

这年代还有人会禁用 JS ？

[GordianZ]

[GordianZ]

没看到是专栏，专栏确实白板……

[explon]

@GordianZ 禁用 JS 那个专栏页面一片空白

[chengluyu]

@autoxbc 开头不会崩，不然开发和测试都是干啥的。

知乎并不只是一个纯展示弱交互网站，投票、评论、答案的展开折叠、图片的动态加载、消息查看与回复。虽然交互性不如微博网页版这样的网站强，但也不算很弱了吧。

[qiayue]

@tabris17 给搜索引擎的另有页面

[tabris17]

@qiayue 这个算是作弊了

[zander1024]

你这就好像要人家兼容 ie5 一样恶心

[jsq2627]

在想这年代还有谁会禁用 js...

[wxsm]

"平稳退化，渐进增强" 是正确的理念，但是实际上要考虑的东西要更多一些，反正说肯定是这么说，具体怎么做那得跟着实际情况来。就最简单的一个开发效率问题，React 那得比后端渲染 + jQuery 要快得多，这是一大块成本，不可能不考虑的。至于其它问题，SEO 什么的，都可以有解决方案。当然禁用 JS 肯定得炸，只是今天禁用 JS 的浏览器有多少呢？

[jsq2627]

知乎专栏用了 angular，针对 seo 是有预渲染的，ua 改成 googlebot 就能看到返回的是渲染后的结果

[haogefeifei]

@tabris17 知乎现在很多内容都出现在百度的搜索结果里，SEO 看来是不用担心的

[libook]

个人不认为纯前端渲染就一定是只为了高逼格，任何技术的选型都是要综合考虑的，而不是凭借书本上或者老师的一句话。

通常会在以下几个方面考虑：
网站业务特点：网站是更适合纯前端渲染还是更适合非纯前端渲染？
开发成本：使用纯前端渲染技术和非纯前端渲染技术的成本差距有多大？
风险：纯前端渲染和非纯前端渲染在网站可靠性方面的差距有多少？是否有额外的产品设计可以保证在有问题的情况下正常提供核心功能或者引导解决问题？
运营成本：使用纯前端渲染和非前端渲染，在网站的运营成本上有多大差距？
人力资源：目前有限的开发人力资源是适合纯前端渲染还是非纯前端渲染？
技术发展趋势：目前网站技术的发展趋势是纯前端渲染还是非纯前端渲染？趋势是否已经成熟？

我司（不是知乎）选择纯前端渲染架构是因为：
网站业务特点：我们的网站的业务是以内容展示为核心，UI 有大量复杂的交互功能，而且并不是每次操作都需要重新渲染整个页面，只对页面中的特定元素做变化处理，而且也没有很多的敏感业务逻辑必须要隐藏在服务器端，所以我们的网站是更适合纯前端渲染的。
开发成本：有很多现成的纯前端渲染框架可以使用，不需要开发者关心前端渲染本身，只需要关心交互方式、视觉样式和数据流，极大地缩短了开发时间。
风险：我们使用的 React 只兼容 IE9 及以上版本的“旧浏览器”和所有的“现代浏览器”，截止到 2017 年 6 月，IE 整体的占比已经下跌到 9%，而其中 IE9 以下的版本占 IE 总量的 49%，也就是浏览器市场总量的 4.4%，加点余地的话差不多有 5%的网民是排除在 React 之外，假设我们的用户是在网民中均匀分布的，那么就会有 5%的用户不能正常使用我们的网站，但若为这 5%的用户做兼容的话可能要多花费 50%的开发成本，所以即便有 5%的不兼容也算是性价比较高的方案，同时会有辅助方案如页面发现兼容性问题即引导用户安装现代浏览器或使用 PC 版客户端，可以进一步削弱对这 5%用户的影响。React 本身有世界顶级软件公司的支持，技术水平和质量把控要远远超过我司这种小公司，所以在这方面无论是用前端渲染框架还是服务端渲染框架都是差不多的，毕竟服务端渲染出 Bug 也不能保证前端不是空白的，容灾设计无论在前端还是后端都是要有设计的。
运营成本：纯前端渲染的时候，渲染压力被转移到了前端浏览器上，服务端只需要关心核心的业务逻辑，不需要关心 UI，节省了大量服务器计算资源；用 AJAX 等技术可以有效减少数据的传输量，节省昂贵的带宽费用；前端除了 index.html 以外全部托管在 CDN 上，任何地区的任何量级的用户都能流畅加载前端页面，而且 CDN 的流量费用比服务器的流量费用比起来简直就是白菜价。
人力资源：我司所有前端开发都有纯前端渲染架构开发的经验，所以采用纯前端渲染的架构方案是没有问题的，反而服务端渲染架构的话多多少少需要服务端开发人力的介入，两端工作有一定程度相互耦合，项目可能会互相牵制。
技术发展趋势：这个就不多说了吧，看一看纯前端渲染相关技术栈在国内外受到关注的上升速度，就大概了解了。React 已经是第二代真正意义上的前端框架了，此类技术已经完全成熟。而且我前两个月招实习的时候发现绝大多数的投简历的实习生都自学过至少一种前端框架，而像 Ract 这样的前端框架，正是纯前端渲染架构的基础。

综上所述，我司决定使用纯前端渲染的架构设计。
具体情况具体分析，我司的情况并不一定适应于所有其他公司，但思路可以作为参考。

软件工程没有银弹；没有最好的方案，只有最适合的方案。

[qiayue]

@tabris17 看你具体怎么给，可合法，可作弊

[j]

SEO 是什么鬼？把内容免费提供给百度么？需要么？

[sunjourney]

@tabris17 #7 textarea 里的不是就 SEO 吗

[sunjourney]

@tabris17 #23 “作弊”这个词应该没法洗成褒义的吧？世界通用的做法原来是作弊

[371657110]

没毛病...

[zythum]

要不你再看下 facebook 吧....

[learnshare]

纯前端渲染是趋势，就是为了实现更复杂的 Web App。
你们说禁用 JS，那前端行业还要不要发展了

[autoxbc]

@XueSeason
@zander1024
@jsq2627
@wxsm
@libook

我提纯前端渲染，大家就揪着纯前端渲染
我提禁用 js，大家就揪着禁用 js
这是我没想到的

我提平稳退化，大家打个哈哈，提开发成本云云就算过去了
这个我预想到了

从理念上讲，完全没有退化就是错的，这和用户是否禁用 js 没关系。进一步说，我们不仅要考虑退化问题，还有可访问性，无障碍浏览，这才是前端应该做的，不然和切图仔有什么分别。

从技术上讲，只要把几百个字的正文复制一份放在标签里，不要说 IE6 IE5，就是 lynx 都没问题，这很难么？需要多少开发成本？浪费流量？那 2MB 的脚本是怎么回事？

提技术栈的，桌上没筷子就上手抓么？ React 不做退化，所以选择 React 就没办法做退化？退化的核心是内容权重分析，是 UX 体验调整，前端技术栈不能思考，前端程序员可以。

[LINAICAI]

对用户来说，第一不知啥是 js，第二找不到禁用开关吧
别鸡蛋里挑骨头啦

[just1]

这年头禁用 js 的除了 tor 浏览器没了吧。。
这又不是银行一定要兼容所有客户端

[autoxbc]

@just1 #39 这里讨论的不是兼容，是退化，退化是允许功能缺失的
@zythum #35 我去看了 google search，gmail，退化做的相当好

[jimages]

1.使用 JS 渲染页面确实会提高用户体验，提高显示效果，降低服务器的压力。
2.知乎的受众群体大部分应该是能够接受新事物，应该不是坚持什么 IE6、IE7 的用户了。估计知乎在改版前在做了调研（在浏览器加一段代码），使用 JS 渲染对用户基本没有影响。
3.JS 渲染针对搜索引擎做了特别的处理。你把 User-Agent 改成 Googlebot 你看看下，切换了渲染，而且好像主流的搜索引擎都上了 JS engine 吧。

[jarlyyn]

说明不用 Js 压根不是别人的目标用户。

[droiz]

平稳退化，渐进增强的意思不是这年代还要考虑会不会禁用 js

[otakustay]

楼主说得没有错，知乎专栏就是一个烂字足以表达，和主站完全就是两个世界，退化做得不好
但是！

> 就是那大几万行的脚本，随便抛出个错误就会导致页面白板

不抛错不就好了？

[dou4cc]

@NCR 那是缓存没做好，做好了绝对比原版快，还能抵抗高丢包网络

[ljcarsenal]

直接打开的话 textarea 里不是有主题内容么

[xi_lin]

@tabris17 SEO 有别的做法，和这个没关系

[overflowHidden]

又是一个被教条坑害的

[ibufu]

看到大家都在喷楼主，我就放心了。

[ibufu]

@jsq2627 已经重构成 react 了

[blanu]

后端渲染就不存在报错？一个组件的数据写错，Node 可能直接蹦 500 了就，比纯前端出错体验更差。如果你说 PHP 或者其他模板引擎，当我没说。

[coderluan]

我在手机上一个浏览器禁用了 js （部分网站屏蔽广告好办法），貌似只是提醒功能不好使了，别的都好使。

[xiaonengshou]

随便找个脚手架就写了，你觉得知乎的前端会考虑那么多？大家都很忙的。

[toto]

经常禁用 js 和 cookies 和 img，以便一刀切不想要的东西……

[sunber]

笑死了，不懂前端别乱喷

[sagaxu]

退化？我司直接把 pc 端下架了，从 mobile first 变成 mobile only

[think2011]

最早看到这种原则的时候记得是在几年前的书上面，那时的环境得考虑这种情况无可厚非。

现在设施完善很多了，我觉得从效率上来看的话，完全是可做取舍的。

[fytriht]

> 就是那大几万行的脚本，随便抛出个错误就会导致页面白板

????????

[DlYgod]

楼主可以去跟真阿当探讨一下

[mingyun]

也只有程序员才会去禁用 js

[libook]

@autoxbc

楼主是从完美主义来考虑的，而我以及一些朋友们是从实用主义来考虑的，双方考虑的角度完全不同。

楼主对于技术本身的观点没有问题，但仅限于学术上面，实际情况往往不像学术研究那样理想化，而且复杂得多。

相信这里回复的朋友们在企业里工作的居多，企业的最终目的是赚钱，赚钱的主要原则是以最小成本实现最大收益，只有高性价比的事情都做完了才会考虑性价比不那么高的事情。知乎也是企业，而且是互联网创业企业，对于互联网创业企业来说，收支平衡+稳定的盈利模式才算作“能活下去”，暂且不说他们在技术层面的决策是否合理，但毕竟作为一个离“能活下去”还相差甚远的企业，不得不持续和融资余额赛跑，所以必须在每一个决策上都要掂量性价比。

只有企业实现了“能活下去”的目标，并过上了“衣食无忧”的日子，才会逐渐从实用主义转变为完美主义，一个很好的例子就是 Alphabet(Google)，靠着强大无比的营收能力，Alphabet 现在市值 6295.74 亿美金，基本上到了想干啥就干啥不愁钱花的状态。
而知乎前段时间才估值 10 亿美金，看起来觉得很多，但实际上只是估值而已，实际余额远少于这个数。余额就这么多，搞出了稳定的盈利模式以及达到了收支平衡，公司就可以活下去；否则的话运气好还能再融资续命，运气不好就只能散伙。

综上，知乎的网站并不适合拿来讨论“平稳退化，渐进增强”，因为技术理想并不是决定知乎技术团队决策的唯一因素，甚至可能都不是主要因素。

[tlday]

@autoxbc 无障碍浏览这么长时间我只见 mdn 和 w3c 有做过。理想确实很丰满，标签语义化，无障碍浏览，平稳退化这些东西，很酷，但几乎是前端界的 OSI 七层模型。你要求一个商业网站花与收益不对等的成本去做额外的开发工作来取悦极少数用户是不现实的。

知乎: 北京智者天下科技有限公司

公司是指一般依法设立的，有独立的法人财产，以__营利__为目的的企业法人。
公司是指全部资本由股东出资构成，以__营利__为目的而依法设立的一种企业组织形式；
企业一般是指以__盈利__为目的，运用各种生产要素（土地、劳动力、资本、技术和企业家才能等），向市场提供商品或服务，实行自主经营、自负盈亏、独立核算的法人或其他社会经济组织。

如果你喷教你这些的那个老师自己做的网站或者学校做的网站都不标签语义化，平稳退化，无障碍浏览，那我是兹辞的。

[autoxbc]

@libook
@tlday

我觉得成本驱动是对的，那么知乎这个级别的站，写一个退化规则，要求专栏可以看见文章，问答可以看见问题和答案，需要多少人月？

[FragmentLs]

noscript 用户表示现在真的没几个网站能够无 js 正常运作了，即使是简单的 landing page 都没几个人去做平稳退化了

[markocen]

我猜知乎会判断是不是爬虫访问，如果是就在服务器端渲染，这样比较节省资源

[isbase]

@autoxbc 你不是 Google

[jingniao]

知乎的前端风格还是没有统一，两种风格切换好难受啊

[GoBeyond]

相信现代浏览器的性能，当然如果非要拿低版本 ie 讲这个的话，我相信谁也没办法

[libook]

@autoxbc

这并不是单单需要多少人月开发的问题，通常在正式制定开发方案之前就要首先评估需求的“合理性”，可能要考虑更多的问题：
1. 受众有多少？目标用户在其中的占比为多少？
2. 能带来多少盈收或潜在盈收？
3. 长期维护成本有多少？
4. 运营成本有多少？
5. 目前全公司整体项目计划优先级和排期以及人力资源的分配是什么情况？

第 1 项我已经做过简单说明，我不清楚知乎自己在市场营销和产品设计方面的“目标与用户”是什么定义，所以也无法给出估计。
第 2 项需要有进行中的或者实验中的盈利模式，和内部的数据分析，这个外部人是不知道的。
第 3 项肯定是存在的，而且不一定会少，基本上日后所有产品需求设计都需要考虑是否要同时在两个前端上实现（或修改）、有什么区别设计、功能逻辑是否互恰、现有架构是否能够实现、因为差异化带来的额外技术成本有多少。
第 4 项不一定会便宜，最起码渲染用服务端要有一套分布式集群，要做负载均衡和弹性伸缩，而且也要长期负担带宽和流量费用，也要有足够的人力运维。
第 4 项要看知乎内部的具体情况了，如果项目排满而且有很多更高优先级的项目在占用资源的话，即便服务端渲染机制要开发，也会被排到后面，而且前面有可能会不断有更高优先级的新项目插入。

以上几项评估出来的结果会被作为此项需求“合理性”的参考。举个例子，如果成本远大于盈收期望，而现阶段还有更多盈收期望大于成本的项目在计划中，那么这个需求就暂时可以被定为“不合理”。

如果是“合理”的需求，可以安排开发计划的话，只从开发成本上来说：
1. 因为之前是前后端完全分离的项目，至少需要单独写一套渲用染服务端，渲染用模板要重新开发，简单来说会按照原有纯前端渲染的产品能设计取一定的完成度比例重制。
2. 原有提供数据和业务逻辑的服务端，要针对渲染用服务端，进行 API 和业务逻辑的重新设计，以保证通用性或者兼容性；因为如果服务端渲染的产品呢不能完全实现纯前端渲染产品的所有功能的话，必须要确保服务端渲染的产品也能够具备严密的业务逻辑。这其中最恶心的莫过于在两个前端产品中出现完全不同的功能逻辑设计，这会增加数据资源服务端的复杂度。
3. 原有纯前端项目里，要重新考虑整个优雅降级的机制如何糅合进去，如果遇到架构或可行性问题的话可能要对其进行一定程度的重构。
具体工作量要按照产品设计者规定的产品设计来评估。当然因为并不清楚知乎内部的项目运作方式，这里只是做一个简单的猜测。

[Reign]

这可苦了百度这种上古时代的爬虫了，不识别 js 咋办？要不我把知乎全爬下来提交给百度，百度会不会认为我的全是原创新鲜内容，给我高权重？

[libook]

另外一个方面，产品设计上会因为某些目的故意对用户做出限制。举个例子，如果市场营销方面认为手机号极其重要，那产品设计上有可能会故意关闭除了手机号以外的其他注册方式，虽然用户可能会觉得不够友好，但是产品设计和市场营销方面认为可以在其中获得的好处远大于对用户的影响。

[Silicon]

我的看法是，如果关了 JS 这个页面的主要内容没展示出来，那么这页面最高 59.9 分

[doubleflower]

这个专栏基本一个静态的网页也用纯 JS 是不是脑抽了？这个开发更麻烦，用户体验更差。

[Clarencep]

textarea 里面的居然真的有助于 SEO。。。

[tairan2006]

楼主，你是产品经理？兼容到哪个版本是产品说了算啊…老板讲究的是性价比，既然不影响绝大部分用户，为什么不能用…

愿意的话，兼容到 IE1 也行啊，又有什么意义。

[leewayhsu]

现在有些前端兼容到 IE8 都不愿意的，你还让他们平稳退化？不过话又说回来这个还是产品和老板决定的，前端的想法只是一个参考。

[dtysky]

前端渲染没毛病
不过我觉得首屏服务端渲染至少要做的吧。。。

[AntiGameZ]

个人揣测下几种可能：

1、知乎团队压根没想到这层事儿。

解决办法：提一个 ticket，看他们怎么应对。

2、知乎团队知道这回事儿（比如已经有人给他们提过 ticket ），但是选择不处理。

解决办法：不停的提这件事儿，搞个大新闻，逼着知乎表态。确实像你说的，这不是一个真要耗费多少人月的事儿。

3、知乎知道这件事儿，并且已经在做了，只是还没做出来。

解决办法：和上面一样。

--

个人做点无端揣测，在公司里大家都是一堆 TODO list 等着做，无数个 Deadline 要赶。如果一个设置紧急级别为普通的 Task，因为一直有紧急的 Task 插队排在它前面的话，那么这个普通的 Task 就永远也不会被完成。

上面也说到了，互联网创业公司做事儿有个轻重缓急，如果就这么“知道但是没实现”的话，我觉得可以理解。我们作为局外人，唯一能做的，似乎就是应该想些办法，去看看有没有办法提高这个 Task 的优先级吧。

[shunia]

瞎说什么大实话,不整点高科技,怎么才能在下次找工作的时候要更高的工资啊.难道告诉面试官:我做了一些退化的支持工作?

[coolzjy]

> 就是那大几万行的脚本，随便抛出个错误就会导致页面白板

同理

就是那大几万行的脚本，随便抛出个错误就会导致服务器当机

就是那大几万行的脚本，随便抛出个错误就会导致数据库死掉

就是那大几万行的脚本，随便抛出个错误就会导致操作系统崩溃

处理异常难道不是程序员的基本工作？楼主是小学生？

[coolzjy]

@coolzjy 顺便说一下，虽然没有去看，但生产环境的 js 难道不是始终是一行？

[silentsora]

直接去知乎提问不好吗，说不定就有官方回答

[chemzqm]

八成是专栏的前端只会 angular 这种东西，初次加载一大坨的 JS 才能看到文章，要不是知乎的 CDN 给力，估计这帮人早被骂死了吧

[zhaoyulee]

如果更换 UA 为 googlebot 确实渲染会变

[xiaody]

专栏会给蜘蛛类的 UA 做完整 server 端渲染 /baidu|google|w3m|pocket|instapaper|bot|crawler|spider/i.test(userAgent) 。
给人类用户的就只有数据，然后在浏览器端渲染。一般用户几乎没有人会去禁用 JS，所以没处理这种情况。

[bk201]

google 做法真的不能和国内公司比。

[Dzinlife]

一群人没一个答到点子上的。

知乎这种做法有点类似 BigRender，但又结合了 react 这种现代前端框架。

首先正文内容已在服务端渲染好，但放进了 textarea，这样既可以 SEO，又不会被渲染进 DOM 树阻塞进程影响 js 加载速度。同时放进 textarea 的还有 react 的初始状态。

js 加载执行，react 立即从 textarea 中取得状态数据完成渲染，接管处理各种交互行为。
全程只有 html 和静态文件的下载，不产生 ajax，速度很快。

总结：是个结合了 SEO，首屏加载优化，和组件化开发模式的良好方案。

[hantsy]

看标题，以为五年前的老帖子浮起来了。

[meepo3927]

"就是那大几万行的脚本，随便抛出个错误就会导致页面白板 "

这个认识过于粗浅。
前端项目将 js 合并+压缩，是非常常见的，如果哪个项目大型不这么做，那才是真正的灾难。

至于说抛个错误，
如果是语法错误，那知乎的开发工程师可以扣奖金了；
如果是运行时错误，那么无论是否合并 js，影响都是一样的。

总而言之，po 主对前端应该是一知半解，而不是知乎逼格高。

[chengluyu]

> 我觉得成本驱动是对的，那么知乎这个级别的站，写一个退化规则，要求专栏可以看见文章，问答可以看见问题和答案，需要多少人月？

知乎都六年了，六年前的页面恰恰就是你说的那个样子“专栏可以看见文章，问答可以看见问题和答案”，这不就是“平稳退化”吗？随着这几年的发展，知乎的需求已经不是原来的需求了，也进化成了现在的样子，这不恰恰就是“渐进增强”？

你根本就不懂知乎的需求，以为知乎就是看个答案、读个文章的 CMS 系统，难怪你有这样的想法。

[blingbling55555]

才发现 chrome 现在左上角禁用开启各种东西都好方便……（跑题

[autoxbc]

@libook #69
您的方法论是对的。不过就这个例子来说，成本并不高，相信大家是看得出来的。

@tairan2006 #75 , @leewayhsu #76
这里说的是平稳退化。兼容是产品说了算，退化的话前端还有发言权吧，至少我所见的前端都还在研究 UX，并不是纯码农。

@AntiGameZ #78 , @silentsora #82
我怕知乎的开发说我是用 IE6 的乡民，当然 v2 也有人这么说，还是有点意外。退化和兼容 IE6 是没关系的，反应的是开发者是否务实，是否承认设计可能会以非预期的形式展现，并给出合理安排。

@coolzjy #80
服务器端异常，少见而可控；客户端异常，则难以预计。顺便说一下，我说的是格式化展开的行数。

@meepo3927 #89
您脑补过头了，我的话怎么都看不出有批评合并压缩的意思。

@chengluyu #90
您对"平稳退化，渐进增强"这几个字的理解完全不对，这是讲狭义设计思想的，不是广义运营思想。知乎的需求我也不关心，我说的是他们没有满足用户的需求。

[chengluyu]

@autoxbc 您单纯讨论设计当然没错，可更多的时候设计要按照运营的思路来，毕竟知乎是商业公司，还要忙着用 Live 等产品赚钱。现有的纯前端渲染，恰好可以满足运营思路多变。

[chengluyu]

@autoxbc 还有一点，我也不认为知乎满足了用户的需求（有些功能的用户体验确实很差），让我做我也会采用更 clean 的方式。

[autoxbc]

@chengluyu #93
「 @autoxbc 您单纯讨论设计当然没错，可更多的时候设计要按照运营的思路来，毕竟知乎是商业公司，还要忙着用 Live 等产品赚钱。现有的纯前端渲染，恰好可以满足运营思路多变。 」

可能您研究技术思想升华，开始从更高层面考虑，这也是一个角度。

我个人相信看不见的手，尽量避免充盈同理心，避免从大局考虑，专以自己的私心为出发点，这一刻我只是用户，一个看了白板的用户。

[SilentDepth]

老板不懂 or 不关心这个，程序员卖命写代码不想处理这种很可能带不来利润的需求，所以没有退化、没有基本内容保证、没有……所以这是个很复杂的问题吗？

[DOLLOR]

虽然我觉得知乎的体验也是超烂的，但是
他们有底气认为禁用 JS 或者使用原始社会的浏览器的人不是目标客户、不能创造价值，他们当然可以拒绝过度“退化”。

[autoxbc]

@DOLLOR #97
「 虽然我觉得知乎的体验也是超烂的，但是他们有底气认为禁用 JS 或者使用原始社会的浏览器的人不是目标客户、不能创造价值，他们当然可以拒绝过度“退化”。 」

那请问什么是"过度退化"?

Web 的基石是 html css js，强调 内容、样式、行为 分离，现在前端已经发展到只要行为了吗？还把要看内容的需求叫做"过度退化"，我真看不懂了。

[DOLLOR]

@autoxbc

你说关闭 js 浏览网页的用户能占知乎用户群体的多少比例呢？有万分之一么？
站在产品角度，为了不知多少分之一的人再去额外投入资源开发一个 noscript 页面，能带来多少收益？

知乎页面用得是 React 开发的，React 推崇的不是结构、样式、行为分离，而是组件化，React 的 JSX 语法就是在 js 里写 html 和 css，不存在你所谓“只剩行为”的误解。所谓合久必分，分久必合吧。

你不必因为别人的开发理念与你相悖就这么愤慨，也不必如此对空气开炮。
现在前端的技术发展太快太野蛮，技术周期更新短，我说的也不算数，没准再过三年又是一轮全翻新。像 wasm 要是未来真的成功了，估计前端要大洗牌，你说的 web 三大基石就彻底没了。

[AntiGameZ]

@autoxbc 我觉得务实的首要在于按时交付产品，这包括但不限于解决用户 /公司 /产品经理丢过来的需求或问题。你后面说的合理安排，也可以归到务实中间去。

问题在于，我们都是局外人，没有办法和手段去评估知乎内部怎么看待这个问题（甚至连他们知道不知道我们都不清楚）。我们每个人，既然可以作为知乎的用户，提意见要说法似乎是现阶段我们可以做的唯一的事情。

我打个不恰当的比方，假若就下一个 24 小时，知乎修复了这个问题，那么知乎是逼格高呢还是屌呢？