yui

在写这篇文章之前，我一直在思考该用什么的方式能讲清楚前端为什么要向智能化方向切换的理由，真的反复思考很久，后来决定还是以我做前端的过去 10 年的所见所闻来做个解答吧，这样让大家也都更有些体感。 起源 这段是我跟前端的结缘，想必很多人也跟我一样，懵懵懂懂地就撞入了前端这个行业。 一脚入坑 我接触前端，那还是 2010 年的时候，在那个时候最火的是 网络三剑客 —— Adobe Dreamweaver、Adobe Flash、Adobe Fireworks。 这三款软件都很热门，第一款可以通过可视化编辑器拖拖拽拽、填填配配就可以搞定一张网页，虽然上手起来概念众多、也挺难用的，但至少是那个时代做网页最牛逼的软件了； 第二款是做 Flash 的，配备一门 ActionScript 的语言，当时网上下载了不少大牛做的很极客的 Flash 网站源码，不过代码读起来很吃力； 第三款是做海报的（因为海报图比较大、比较长，切割起来比较耗费内存，这块软件速度比较快）和 Gif 动画的，但我用的少，大部分时间都用 Photoshop CS4 来搞定。虽说这三款软件最火，但真正让我入坑前端（那个时候还没有“前端”这个称呼，有的就是“切图仔”）的理由，是因为我想当一位网页设计师。 当时，想当一位网页设计师的理由有二： 软件工程搞 Java、C++、C 真是挺枯燥无聊的，写一段程序，还得编译、部署

本文主要选取了目前比较流行的JavaScript框架Dojo、Google Closure、jQuery、Prototype、Mootools和YUI进行对比，主要是根据网上的资料整理而成，希望可以供大家参考，如有错误欢迎指出：） 主流框架对比 Dojo（重量级框架） Dojo是一个强大的面向对象JavaScript框架。主要由三大模块组成：Core、Dijit、DojoX。Core提供Ajax,events,packaging,CSS-based querying,animations,JSON等相关操作API。Dijit是一个可更换皮肤，基于模板的WEB UI控件库。DojoX包括一些创新/新颖的代码和控件：DateGrid，charts，离线应用，跨浏览器矢量绘图等。 优点： 1. 功能强大，组件丰富（包括图表支持） 2. 面向对象的设计，有统一的命名空间和包管理机制，适用于企业级或是复杂的大型Web应用开发 缺点： 1. 复杂，学习曲线陡 2. html中也需要涉及dojo属性，将来换框架的成本高，例如： <button dojoType="dijit.form.Button" id="helloButton"> 3. 性能问题，dojo加载采用了同步机制，会暂时锁定浏览器 Google Closure（重量级框架） Google Closure

时光荏苒，美团十岁了，美团技术团队也走过了十个春秋。 2010年3月4日美团网上线的时候，整个公司总共十来人，在一套三居室的民房里起步。其中技术团队只有5个人，现在有4位还在美团。 今天，美团是中国市值第三的互联网公司，技术团队也已经达到9000多人规模，覆盖前端、后台、系统、算法、测试、运维、数据、硬件等8个技术领域。 2013年美团公司年会上，王兴特别引用了清华大学老校长梅贻琦先生的一句名言：“大学者，非谓有大楼之谓也，有大师之谓也。”他是告诉在场的美团同学：选择跟什么样的人在一起做什么样的事，很重要。 最近，美团技术学院陆续采访了20多位美团技术团队的同学，既有美团早期创始团队的3位“元老”，也有很多美团App、美团外卖等部门的技术骨干，听他们聊了聊自己跟公司一起成长的故事。故事里有争吵，也有友情；有汗水，也有泪水；有委屈，也有成长；有迷茫，也有坚定。我们从中摘录了他们印象最深刻的一些片段，与大家一起感受，10年来美团技术团队经历的那些坎坷与崎岖，收获的那些感动和期许。 时间开始了 2010年3月4日，美团网上线。 此后半年，团购是互联网领域最火爆的创业领域。如雨后春笋，冒出了数千家团购网站，这就是大家经常提起的“千团大战”。 关键是跟什么人在一起，做什么样的事情 美团技术团队创始成员付栋平回忆，2010年的时候美团的技术并不是很强，但是团队年轻、有激情、有闯劲

日历就是日历，但它不是合适的时间选择器。 大部分的表单中凡是涉及时间选择的，都会采用日历选择器。大部分UI框架也会默认提供。在许多场景中使用这种控件并不合适，特别是一些二流的公司甚至没有和日历同步时间。 比如： 看起来挺炫，其实毫无意义。这个控件不会和字段内的时间同步，照理说控件显示的时候应该反应字段内的日期和时间。如果我幸幸苦苦选择到指定日期，不小心点错了一格，我必须重新来一遍。 再有一个情况是，如果是输入生日，那么必须在年份上下按钮点100次（如果100岁的话）。 采用html内置的选择器是更加合理的时间选择器。 以下是我写的控件： {fieldName: "publishdAt",inputLabel: '发表日期',years:"-10,+10",ftype:'datetime'/*date*/,required:true,validators:{},gridSize:"1-2"}, 配置很好理解，years以当前时间（不一定后面再说）为参考，-10，+10，当然是显示前后10年（根据需要），如果是编辑，字段本身已经有了值，那么这个前后是根据这个值的年份前后10年。 这样设计还有问题，如果年份超越了这个范围，不是无法输入了吗？当你点击日期select的时候，最下方有一个“其它”选项，当你选择这个值时，select会变成text字段，允许你输入任何年份，当你输入年份

我正在使用Ajax和哈希进行导航。 有没有办法检查 window.location.hash 是否像这样更改？ http://example.com/blah ＃123 http://example.com/blah ＃456 如果我在加载文档时检查它，它将起作用。 但是，如果我具有基于#hash的导航，则在按浏览器上的“后退”按钮时将无法使用（因此，我从blah＃456跳至blah＃123）。 它显示在地址框中，但我无法用JavaScript捕获它。 #1楼 在IE浏览器中，有很多技巧可以处理历史记录和window.location.hash： 正如原始问题所说，如果您从页面a.html＃b转到a.html＃c，然后单击“后退”按钮，浏览器将不知道该页面已更改。 让我举个例子：无论您位于a.html＃b还是a.html＃c中，window.location.href均为'a.html＃c'。 实际上， 仅 当页面中先前存在元素“ <a name="#b">”和“ <a name="#c">”时，a.html＃b和a.html＃c才会存储在历史记录中。 但是，如果将iframe放在页面中，请从该iframe中的a.html＃b导航到a.html＃c，然后单击“后退”按钮，iframe.contentWindow.document.location.href会按预期更改。

Introduction According to Best Practices for Speeding Up Your Web Site , 80% of the end-user response time is spent on the front-end. Most of this time is tied up in downloading all the components in the page: images, stylesheets, scripts, Flash, etc. So it's bother-worthy to put attention on the front-end, though, there are also a lot of things need to handle in the back-end. This post will talk about several performance pitfalls in the browser and the steps to address them in ASP.NET MVC. Well, rather than talking the abstract concept of performance, we need some tools to help measure it.