|
实在不明白其意义所在。难道jq的加载速度还值得抱怨吗？应该也不会是版权问题吧？ 【玉伯的回答(172票)】: 折腾过 KISSY 类库，简单说几点： 1. 开发 KISSY 之前，淘宝使用的是 YUI2 类库。但从 2009 年开始，YUI2 在逐步退出历史舞台，YUI 团队的大部分精力都投入到 YUI3 的开发中去了。从当时的情况来看，YUI2 前途堪忧，YUI3 则还不够成熟，并且 YUI3 的定位（大而全的框架型类库）不适合淘宝的前台业务场景（以浏览型为主的展现页面）。 2. 我自己是力推 jQuery 的。但由于历史原因，阿里系对 jQuery 的成见很深，认为其接口太灵活，不利于团队协作，以及其插件质量良莠不齐，社区不如 YUI 健壮。2008 年在淘宝前端内部争辩过 jQuery，可惜我没坚持，没推广成功。 3. 但当时不少新人都喜欢 jQuery 的 API 风格，jQuery 社区也发展得越来越好。我自己也是个铁杆 jQuery API fans. 因为前两点原因，2009 年在开发 KISSY Editor 时，底层虽然是基于 YUI2 的，但我逐步已经做了很多替换封装，实现了一个简易的杂糅了 YUI2 和 jQuery API 风格的底层类库，这就是 KISSY 的原型。 4. 接下来是技术驱动的一段时期，2010 年基于 KISSY core 写了 Switchable、Suggest 等在淘宝被大量使用的 UI 组件，一下来就推广开来了。（中间 YUI2 和 KISSY 并存了很长时间） 5. KISSY 进一步发展，得益于核心开发成员承玉的加盟。2011 年后，KISSY 从 KISS 的定位，逐步演化成了立足于淘宝、力争大而全、同时可定制的一个类库。承玉做的非常不错，还有龙藏的 Flash 组件等，以及仿 YUI3 Gallery 的组件贡献模式，这些让 KISSY 成为了适合淘宝业务的最佳类库。 上面说了这么多，总结下与楼主的问题相关的几点： 1. 选择什么类库，抑或自己开发，跟团队的技能倾向有关。如果雅虎和阿里没关系，或许阿里就不会这么雅虎味，或许也就不会对 jQuery 有成见，或许现在压根儿就没 KISSY 什么事。 2. 类库的选择离不开业务场景。如果淘宝不是浏览型为主的网站，而是个个页面都像 GMail 一样复杂，那也许淘宝选择的类库会是 ExtJS 或 Google Closure 或 YUI3 等等。其实淘宝的后台项目中，还真有不少是用 ExtJS 的。 3. 对于商业公司来说，类库的重点不是基础模块，而是业务模块。这里的业务模块包括淘宝的登录注册等模块，也包括 Switchable、Suggest 等泛业务模块（比如淘宝首页的搜索提示，看似是通用的，其实是跟淘宝的业务类型分不开的。YUI2 也有一个 Autocomplete 组件，但其庞大的体积根本不适应淘宝）。 4. 类库的选择，还跟整个业界的环境和团队决策者的眼光相关。比如从去年开始，前端社区越来越意识到了开放共荣的重要性，意识到了规范的重要性。CommonJS、AMD 等等，以及 NodeJS 的兴起，这一切变化，也在悄然改变着大家的抉择。这是我开发 SeaJS 的原因。如今，我们有了更好的、更偷懒、同时更灵活的选择和组合解决方案。 任何路都没什么错，关键是，要知道自己在哪。 【田乐的回答(14票)】: 代码用来解决实际问题，然后经过重构和更高的抽象形成框架。框架应该告诉你不要做什么，输出的是一种如何构建应用的价值理念。 功成名就的开源（js）框架主要是像prototype、jquery、mootools、underscore、backbone.js这样的有自己风格的产品。相比之下历史上出现的巨型以提供widget倾向的框架在口碑上就略逊一筹，如dojo、YUI、ext等等，他们也很成功，但是程序员员往往持有自己不同的看法，认为这种重量级的解决方案限制了他们的发挥。从某一个角度上来说这印证了框架要“告诉你不要做什么”的重要性，前面说的这些有风格的框架都做到了这一点，widget方案告诉你怎样做（因为组件已经提供好了）从长期来说并不讨好。 扯远了，回到这个话题。国内的团队写的偏widget的框架比较多，这很合理，因为它解决了团队协作问题，减少了团队内部重新发明轮子的危险。但是国内的开发者输出的核心库里面风格强烈的好像比较少，做来做去也就是在模块划分上有些不同。从理念上大部分的库都是工具库的集合，它和某一种编程泛型或者模式无关，内化的是对很多具体技术问题的解决方法。我个人觉得这更多的是自底向上的分析实现，而缺少自顶向下的设计。 从我的主观偏见回来。我输出授权宽松的开源框架是绝好的事情，我纠结于他们的质量是非常消极的。因为没有越来越多被输出到社区中的开源框架，也就没有出现更好的框架的社区环境。我们看到的这些名牌框架是明星程序员写的，他们碰巧在计算机科学和相应的社区比较发达的国家，这不是偶然。我们国家的社区正在向这个方向发展，我们看到有越来越多有自己『品味』的程序员输出自己的框架是非常积极的趋势。说不定下一个Jeremy Ashkenas就出现在我们这里呢。 闭门造车是缺乏交流的结果，所以我们不紧要看输出的框架有多少，还要看这些社区的经营。那么我觉得对于这个问题比较靠谱的一个答案就是：我国的开源社区运营，程序员对于开源社区的参与程度还严重的落后，这是很多团队自己造了很多方形的轮子的原因。 【yoyo的回答(9票)】: 也不能一遍概全吧，人人网有一些项目在使用jquery比如小站，朋友网底层则完全是jquery 之所以不使用jquery也是有原因的，举一个例子，比如jquery版本升级带来的问题，你很难保证这个库的升级一定是向下兼容，升级之后很可能带来一些意想不到的问题，但是不升级整个库，带来的问题就是无法使用新的特性，无法提高代码的效率等。 同时jquery没有做模块拆分，对于性能要求比较高的网站，一次加载整个库是没有必要的,无论是出于公司利益还是用户体验。所以很多公司会研发一些支持模块化拆分的js库。 【flamingtop的回答(7票)】: 提问者应该是专指js前端框架，所以基于nodejs的后端框架不在讨论之列，基于nodejs的后端框架和前端js框架没有可比性。 觉得大公司选择自下而上实现自己js框架的，原因是非技术大于技术，团队的主观需要超过了客观评估；强调自上而下是排除基于第三方基础库开发的所谓“自己开发”然后冠上自己公司名称的的框架，不在讨论之列。 实现一个js框架的难度比用后端语言（比如PHP）实现一个web框架要大得多，因为前端js框架必须处理跨平台的问题，自下而上实现一个js框架至少要处理好的问题是 隐藏（abstract away）多浏览器JS和DOM引擎的实现细节，为应用层代码统一调用接口 jQuery主要解决的就是这个问题，看过jQuery源代码的人都理解这不是件简单的事，难度主要还不是在于javascript语言本身，而是你需要对各类各版本浏览器的实现差异了如指掌，DOM实现，事件模型，甚至渲染方式。在这个方面，个人认为，重新发明轮子是非常不值得的，在企业开发的条件下，甚至是不可行的； 一些公司的js框架本质是实现了某组特定js或者DOM API的封装，从技术角度说更像是一个wrapper或者library，覆盖的广度离成熟的framework还是有距离的，不过那样确实可能是可行的。 另一些公司选择自己实现js框架（自下而上），更多是因为错误的评估，或者低估实现难度和复杂度，或者高估了团队的js和浏览器平台的底层知识的储备，觉得“可以做”；最终选择自己开发，有主观判断大于客观评估的因素。 现在的浏览器前端开发，如此多的优秀js框架和库，确实有绝对的必要自己闭门造车吗？我表示怀疑。 【郑海波的回答(5票)】: 我觉得. 产能过剩。 普遍国内的新库并无创新点(美其名曰微创新？)，对于类库构建者的经验提升当然是大有裨益的。为何不把有限的精力投入到成熟开源框架的贡献上？ 【张辰的回答(1票)】:
【李陈的回答(5票)】: 首先个人觉得你的‘很多’用词有事偏颇，我倒觉得国内很多公司在用jQuery。至于你说的公司自己开发JS库，我也觉得这要看公司的规模，业余需求。一般有自身的JS库的在国内也仅有一些大公司才有。在这些公司里养着一帮前端，而这些前端很大部分水平都是经过层层筛选的，一来他们有能力，二来有时间，三来也能为公司吸引人才。种种原因，他们便有了自己的库。如果还要说，那就是程序员有反骨，不喜欢做一些没有技术含量的事。哈哈，个人愚见而已，一笑置之。 【Cat Chen的回答(0票)】: NIH - Not Invented Here 【蒋又新的回答(3票)】: 这不算什么。还有自行开发的Key-Value数据库、分布式存储系统、HTTP服务器……稍大一点的公司都会有这些玩意的。 为什么它们会出现，大概有以下几点： (1) 架构级的工程师需要证明自己的能力和价值（晋升需要，或者手痒） (2) 自制轮子确实有些地方胜过标准轮子 (3) 公司足够大，能够支付自主开发的成本 以上三条中，头一条是原始推动力，后两条使事实能够成立。具体到jQuery这个例子。前端与业务逻辑的联系非常紧密，所以很容易找到一个“这更符合我们的需要”作为理由去重写一个前端的库（见(2)）。 【刘杨的回答(1票)】: 公司的框架，在没有达到JQuery的高度时，还是用JQuery吧，自己写的用起来爽，继任着就不爽了。 【mytharcher的回答(3票)】: 根据我写elf+js的经验，简单的说原因就这么几点：
【薛端阳的回答(8票)】: 说jQuery简单的人，根本没看过jQuery的代码， 同理，说xx简单的人也一样 无论在任何一家公司，首先要混口饭吃吧，你要混饭吃，就得好好干活，但是程序员都想偷懒啊，有现成的用，干嘛不用现成的？所以从打工者的角度来说，用jQuery之类现成的东西给老板自然是最好的，但是这里还涉及到一个美工的协调问题，很多直接拿来的控件，离美工MM设计出来的页面还是一定量的区别的，这里面就涉及到HTML结构的问题了，有些好改，有些不好改， 其次基于Web引用内容浏览的网页，其开发量主要在javascript的UI widget上，从打工者的角度来说，不干活或者少干活就拿钱当然是他们愿意的，但是从老板的角度来说，我花了钱请你们来打工，你小子天天不干活，就晓得抄，那不如找个高中毕业的好了，钱还要的少，活做的和你一样，这样矛盾就产生了。 还有一个很重要的是，无论在什么大公司啊，你总的要加薪把？要升职把，如何升职呢？你总得提高自己的技术水平吧，天天抄别人的东西，不用心学习如何内在实现如何体现自己的水平呢？ok，你才对了，腾讯就是最好的例子，无论出什么东西，我都拿来抄一遍，大家都是程序员，更别说有源代码的js，更好抄了，凭良心说，直接用jQuery和，抄一个jQuery，完全是两种不同的提高，就像小时候抄作业一样，用别人的原理，配合自己用自己的方式实现一个，毕竟还是要经过大脑的，不可能不提高自己水平吧，而且自己做的东西，名字就不一样，谁知道你里面有多少创新，多少抄袭，于是乎，领导看了之后就觉得小x，现在牛逼了吗，自己做了一个jQ吗，好，加薪吧，后面你就懂的。 这个是中国式的悲哀，追着别人的屁股，不是个傻瓜的人都会，问题是如何站在巨人的肩膀上，再迈一步呢？ 为了加薪，没有创新！ 【鄢敏华的回答(1票)】: 1. 业务的组件驱动，例如：Yahoo、阿里、百度 例如：阿里派的KISSY和百度的七巧板估计也是和自己的产品线（百度知道、百度百科）有关系； 2. 为了增加在开发者队伍中的影响力，这种公司一般推出都是重量级些的方案，例如：微软、Adobe、Google Javascript的影响力越来越大，大公司自然不肯错过 3. 其它一些不入流的开源框架，大多为证明自己的技术价值，做技术牛人，这种一般是以借鉴、模仿和重新封装为主 4. Jquery也不是万金油，比如下面的要求最很难做到：
【Yinkan Li的回答(1票)】: 一开始JQ够用了，JQ UI 也不错。但是直到有一天，需求太过蛋疼，当有一天把业务逻辑和控件绑定之后，你会发现，JQ只能被用来操作DOM，这时候JQ就显得鸡肋了。这时候，差不多是应该要自己搞一套控件库了，就自己用，高度复用，一些业务逻辑也需要做到控件里去。 【知乎用户的回答(1票)】: 第一时间想到了这张图： 
【刘大朋的回答(0票)】: 觉得吧 一：用第三方的有个迭代更新的问题，像微软那样，三天两头出点新东西新框架的。。。我们就得一直在后面追，自己去实现就不一样了，很大一部分是业务驱动的，所以可控度会更好。 二：公司自己开发的，其实。。。都不怎么通用。。。至少大部分是，同样是基于他们的业务模型的 【ChinarenWei的回答(0票)】: 对于没有什么根本性创新的自己“创作的” lib，称作抄袭不为过，不过公司内部用不开源也没啥问题。 【王允的回答(0票)】: 开发自己公司的库，主要是用起来方便得心应手，另一方面是适应自身发展的需求，不必要过多的引入一些不必要的累赘影响性能！我觉得另外还有习惯问题！ 【郑辉辉的回答(0票)】: 显得自己牛逼 【孙博的回答(0票)】: 因为淘宝腾讯出来的时候，还没有jquery，等jquery流行起来，已经搞了一大滩，换也不好换了。 jQuery在2006年1月由美国人John Resig在纽约的barcamp发布，吸引了来自世界各地的众多JavaScript高手加入，现在由Dave Methvin率领团队进行开发。 【丁雷的回答(0票)】: 看看一个流行的框架的发展历程： 1. 足够轻巧； 2. 足够灵活； 3. 足够丰富； 如果能够基本解决这些问题，它就能火起来... 呵呵。 【dong yan的回答(0票)】: 框架其实不是只是一个jQuery就可以的，他是一个生态系统，这样才应该叫框架。 现在的大家说的框架基本都是jQuery、YUI等，其实他们只是基础而ext、sencha这样的才叫框架。 每个公司都要开发自己的框架一般是从自身的需求出发，而不是为了创新。 【李寒的回答(0票)】: 造轮子的快感 【张旎耋的回答(0票)】: 个人感觉JQuery不是很好.不便于维护 基础不好的用它写的代码可读性更差!~ 【张散集的回答(0票)】: 个人觉得JQuery挺好。如果楼主需要的话，我投一票JQuery。但抛开文化、环境、历史等等问题，就纯技术层面，我提倡“面向对象的设计，函数式的编程”，用什么库和框架真的重要的吗？ 【郁辰磊的回答(6票)】: 用jQuery老板给前端的工资就少，觉得糊弄糊弄就能弄出来，就这么简单，中国特色 【季楠的回答(3票)】: 因为jQ太过简单...一个没有程序基础的人看两天视频也可以写出像样的东西，虽然可拓展性和效率比较低下，但是老板不觉得这是这个人写的问题，老板会认为jQ就是一个“简单+效率低下”的框架，进而给用jQ的工程师较少的工资... 原文地址:知乎 |
|
|
