豆瓣的 web 移动端为什么那么傻？

app 更是烂。

@shinwood app 没用过。。。不予评论

豆瓣的web前端，布道者？？
有啥作品？像 seajs 那样有吗？

同意，稳定和正确性应该放在第一位，然后才是体验的优化

比较早的抄了国外评论模式。连布道者都出来了。。。

APP最傻的一点是，用不了几天就得重新登录。特傻。

所以我都拒绝去看小组文了！打开真是要命。

豆瓣哪里不傻！！

登录都登不进去，还刷新！

移动版简直没法用

@kmvan 克军挺有名的，http://www.zhihu.com/question/19731796

@avrillavigne 豆瓣评论还是很多，没办法只能看他家

@fox 完全赞同

@tangzx 非常赞同，我特别喜欢wap版本的各个站点，因为刷的快，移动端绝对是信息重要性 > 交互。最快速度刷出信息，并且结构清晰就可以了，css都可以不要复杂 简单点就好。最好不要加载什么js，浪费流量，拖累体验，用户甚至不知道是在载入还是死掉了，然后想刷新一下页面都不行，刷一下就只能从头开始。我就没看过一个做的好的复杂型移动端web。凡是用js来load资源和内容的，基本用起来很不爽。

@ispinfx 用户

同意移动版应该简洁（节能）轻快是第一用户体验。现在线上这版的思路、原理详见 http://www.douban.com/note/347692465/ 。不完善是事实，无论是完善或是改版都要投入更大的人力也是现状。必须要说这牵连产品、设计、后端诸多因素，几个前端工程师能力再强也受限于边界。骂声再大些吧，很多项目都是用户骂声（关爱）驱动起来的。

几乎没法用，上下滚动不停触发阅读全文。

@zhangkejun
克军老师快换2.0出来围观下

我是这个豆瓣移动web版本的负责人，这件事情简单来说是这样：

1、我在这个项目中，过于专注于技术本身，过于依赖前端自身的解决方案，过于信奉个人努力，不重视人的因素，以致设计和开发了并不适合豆瓣团队的UI组件库、不解决豆瓣历史遗留问题的技术方案，进而导致项目的其他参与者在负责具体实现时做的不好，最终的产品体验不佳、可靠性不高、进展迟缓、缺乏维护。

2、这套UI组件和技术方案的核心考量是『有利于迭代』，很多特性和妥协都是建立在这个目标之上的，包括视觉交互的迭代尝试、组件的积累完善、最佳实践的探索，但在实际执行中，几乎一次迭代都没有过，所以『不完善』是自然的，给人一种额外的『复杂感』也是自然的。

3、当前这个移动web版本的体验、可靠性和技术问题，早在年初的CardKit2.0版本里就都已经解决： http://douban-f2e.github.io/cardkit-demo-gallery/ 但考虑到人的因素和豆瓣的长远利益，选择了放弃部署到豆瓣

4、当前这个移动web版本的体验、可靠性和技术问题，也并非源自楼上提到的『不用页面刷新』（实际上正是围绕页面刷新而设计的）和『用JS来load资源』（如果真是这样工作反而会好很多）

5、新的豆瓣移动web已经在不断开发和上线了，『旧版』虽然在部分移动设备上不可靠甚至不可用，而且不再维护，但由于被认为在多数情况下可用性仍然高于桌面版网页，所以不会直接下线，而是会被『新版』逐步替换

6、当前移动互联网实际上已经接近或进入『后app阶段』，传统上基于浏览器的web技术和要素，正在以新的形态重新占据核心位置，这个领域可以说是大有可为的，我接下来的创业项目也与移动web有关。无论技术还是体验，如果像楼上某位所说的那样停留在wap时代，虽然可以一时躲避那些困难和失败，但很快也会远远落后于时代和用户的期望，要么早点被黑被骂，要么晚点悄悄的死，无论人、产品还是企业，都不可能永远活在过去。

@zhangkejun
@dexteryy 感谢回复，每个人做任何事，都有理由。你们有技术选型的理由，我也觉得没有问题。用户有抱怨的理由，就是在某些情况下，移动web端完全不可用。我前面说的wap，是移动产品相对更安全的呈现方式，当然开发者可以自行相对增强体验，以不被时代抛弃。只是做更交互的移动web端，真的要多考虑一些网络多变的情况，避免信息无法载入的情况，希望尽快改善吧，还是很喜欢豆瓣，望越做越好。

国内的前端基本上都是半桶水还整天热衷于分享些给实际项目增加复杂度的破玩意，都懒得说了

@pepsin 不说国内 其实国外很多前端项目也很谨慎，facebook不是做了移动web端后没办法还是做客户端么，自此以后国外移动web端都比较谨慎。

@qdwang 因为富交互而布局不常需要更新的东西用原生性能更好啊，跟谨慎不谨慎没什么关系

@pepsin 我说的谨慎是指用移动web端还是移动native端的决策谨慎。

再补充一条：

『为了技术实验和技术目标而牺牲用户体验和产品质量』既不符合事实，也不符合本意，实际上整个技术方案和实现中有很多地方都因为太保守太谨慎而增加了负担，要说产品拖累了技术还差不多，而之所以在结果上影响了用户体验和产品质量，完全是因为具体执行中的各种问题，最终都可以归结为人的因素（包括我在内）

其实想吐槽很久了。体验太差。

@qdwang 这个不是非此即彼的。基于需求搞才是正道。

豆瓣这些年做的这些东西，看下来给人的感觉就是：出主意的太多，干活的太少。

APP确实无爱，豆列什么的完全无爱啊。

@dexteryy 产品拖累技术，技术反过来拖累产品，最后哪里都不好。

——别在意，我是说我也经常遇到这样的问题。好的解决方案是，找观念和想法一致，乐于接受理解和使用新技术，追求以用户为中心的设计、产品、开发。

——但是去哪找这么契合的人呢？

——所以大部分情况下，做出来的产品都是经过多方妥协的四不像。

@kmvan

oz.js ，你没听过不是你的错，dexter.yy 他们的team太低调了，分享极度的少，但是我看过的分享当中豆瓣的干货是最多的，从我个人角度来说至少领先2年。seajs的玉伯和dexter.yy有过一次关于oz.js的讨论。

@qdwang

“真是讽刺”这四个字真是刺耳啊。

摘自[HTML5史上最惨重的失败：Facebook放弃HTML5转投iOS Native](http://www.csdn.net/article/2012-08-24/2809122)
““
其实，html5, nodejs等的失败，最基本的原因是，它们都是反上帝的。
宇宙虽然纷繁复杂，但是基本的物理学原理缺很简单，爱因斯坦晚年曾想把宇宙中4种基本力统一成一种基本力。最近科学家一直在苦苦寻求上帝粒子来统一物质。这就说明，简单，统一才是万事万物的终极目的。
就拿网络游戏来说，现在有些游戏采用全3D, 玩家想怎么玩，想怎么看都行，但是这样的游戏大都半死不活，因为玩家都转得头晕了。相反那些固定视角、甚至是二维的游戏呢, 缺凝聚了一大批忠实玩家。
html5/nodejs就是这样的东西，不该是它做的事，它非要做，不失败上帝都不同意。
另外一个走入歧途的是Web 2.0，web 2.0大量使用所谓ajax技术，所谓“用户体验”，但是却违反了网页里面还有一个“页”字，网页就应该和小说、报纸一样，以阅读为主、方便阅读为主，而不是在那里让用户惊叹你的交互性和体验。网页，就应该是一个电子版的报纸、杂志、小说等，加你妈比的动态性啊。

经过冲动之后，必然会回到本质。web 2.0必将冷却，生存下来的，还将是那些认真做事，做有意义事的人和公司。
””

感觉楼主和上面的这位理念差不多。但是技术好和实用产品有很大的联系么？按照楼主说的用WAP开发即可，回头不是有其他人说豆瓣前端技术差劲么？

CardKit对兼容性的误判算是最致命的 ，其他的从前端技术角度来说 @dexteryy 他们的思路已经相当超前了。如果算2012年11月启动的话，他们的技术可以秒杀国内大部分做移动前端的，因为那年android的各种差劲到极点的浏览器和严重的分化，作为一个不能控制网络环境不能控制runtime的前端来说，没有什么好值得讽刺的。

另外就楼主说的facebook而言，"facebook不是做了移动web端后没办法还是做客户端么，自此以后国外移动web端都比较谨慎。"看到这句就知道当年历史没有好好细细的品味过。摘录上面链接的原话：
“又过半年，Facebook宣布放弃其基于HTML5的iOS App，彻底转为Native，又一次让HTML5 vs Native的话题升温。”

看起来，好像facebook他们有很多大牛，然后大牛说“哎呀，我技术这么高也搞不定”。中国是一个看“脸”的国度，所以当时大部分也开始说“哎呀，搞不定啊搞不定”。

但是老外说：“.... 浏览器里打开Facebook的网页都比应用快3倍。”

不知道楼主看清楚原文和你说的区别没有？别人facebook放弃的是hybrid app，不是移动web端，然后别人不是没办法才去做native客户端，是有hybrid客户端然后改成native。2012年hybrid app的性能很差，部分功能缺失，ios还相对好一点，android的webview还没转到chrome上面。至于说国外移动web端都比较谨慎我倒是完全没有觉得，sencha就在2012年直接反击，在移动端游戏上面2012年的时候DeNA就已经做的非常不错了，不过当年毕竟算是少数。


至于豆瓣产品方面我没具体看过，web前端技术本来就有极限：runtime。但是要“最好不用js load”，就能省下流量，除非楼主不是做移动前端的，否则怎么看怎么像扯淡，websql / indexdb / local storage / application cache 这几个技术可以用来做cache。如果是douban的重度用户，怎么看怎么都省流量，还能解决部分网络环境的差的问题。

不就是webapp没玩好嘛，有什么好解释的

移动难玩的是适配设备

Native 优势在适配

感觉豆瓣在走下坡路，产品做的越来越烂。。是不是干不动啦

@iwege 感谢你回复那么多，我不是一个较真的人，我比较懒，就不一一回复你了。

我自己回复的有几句话，主要是表达这个意思，有共鸣的人能看懂就行了。

我看过太多网上技术方面的争论，最后都没结果，我觉得主要是我们看问题的角度不同。只要立场不同，怎么说都怎么有道理的。

我只希望在手机浏览器上使用豆瓣的时候，能更顺畅，无他，对于前文提及的可能不恰到的言辞，表示抱歉。

首先，我觉得大家应该有个基本的认识：产品烂、不好用和工程师技术好坏没有什么关系。可能是产品设计的问题，可能是团队配合的问题，可能是后端性能的问题，没人想做出烂产品，但事情就这么发生了。单就豆瓣这个案例来看，我不觉得是前端能力不够导致的，你的吐槽有两句，这两句根本没有逻辑关系。

从@qdwang 的表述看，你认为一个产品要“能用，保证基本的用户体验”，我猜测你应该属于比较保守的人，以我对@dexteryy 的了解，他不是这样的人，他对新技术的追求在上面的自白中显露无疑，甚至看得出对产品、后端的保守策略的吐槽，他也做了妥协，但是我猜产品觉得他妥协的还不够，合作始终不顺畅

@dexteryy 2009左右写的oz.js目前还在土豆网使用，足以说明他算得上是合格的前端架构师，也不是一个脱离实际的人。我和他在土豆共事过3年，知道他是一个不断学习，不断提升自我的人，之后我们联系少，但这种“上进”的状态是不会改变的。

彼此不合适就早点分吧，祝@dexteryy 离开豆瓣后创业成功。

@jetyang “一个产品能用，保证基本的用户体验”。。。这句话和保守与否没关系吧。。。一个产品都不能用。。不知道还要这个产品干嘛。。。

@qdwang 我完全不针对你，随口一说：）我是在吐槽这个项目的产品经理，他不了解和自己配合的前端、后端的技术特点&性格特点，也对以前的项目架构缺乏了解，也不清楚引入cardkit带来的风险有多大

@jetyang 嗯，希望能变得可用一些。

还是不要为了使用技术而使用技术

一直在豆瓣前端上收获很多干货，希望移动版能越来越好。