• [置顶]Flash真的适合做网站应用吗？
    by  前端-qhwa  评论[51] - 前端开发
  • [置顶]用户界面设计中“状态”和“动作”...
    by  Tony Lee  评论[73] - 交互设计
  • [置顶]A/B测试：实现方法
    by  oldj  评论[20] - 用户研究
7评

“无后端”的web应用开发模式

by  王涛—前端开发 | 2013-05-26

最近看到前端趋势2013大会上的一篇文章，题目是《各位快看，不用后端》，觉得有点意思，恰好近期的一次讨论及半年前的一次开发实践也涉及到这种模式，简单谈谈我的想法。

不得不说，文章的题目确实很吸引眼球，开发应用可以不用后端了？前端同学完全自己搞定？那服务器、数据库、服务接口神马的怎么办?

说到这，大家可能会想到开放平台，开放平台不就是这种的架构模式吗？服务器、底层数据、OpenAPI大公司都给你提供了，前端同学完全可以通过JS来操作各种数据，把注意力集中在显示层上，独自完成一个应用的开发。

纵观国内的开放平台可以分为两大类：

一种是业务接口开放平台，比如1688开放平台，目的是为了让开发者围绕其业务生态圈创建自己的应用，它只提供业务型OpenAPI，开发者还是需要搭建自己的服务器，甚至是数据库等，算不上noBackend。

另一种是玩“云”概念的开放平台，比如GAE、BAE、阿里云等，他们提供的是服务器和存储（数据库），OpenAPI也有，但通常是比较底层的和业务无关的通用型接口，如存储，消息通信等，真正的业务接口还是需要用后台语言开发，也算不上是文章所谓的noBackEnd。

而国外目前有另外一种类型的开放平台，可以说是为移动应用而生的 (PC站点也能支持)，它真正的做到了noBackEnd。 我之前曾折腾过一个移动小应用，偶然接触了Titanium Cloud Services，真是感觉相见恨晚，佩服至极。。。服务器、数据库就不必说了，对开发者完全透明。而他的亮点在于OpenAPI，不像国内的那种纯底层接口，而是暴露给应用一些更偏向业务层面的通用API，比如用户注册API、好友关系API、json格式的KV存储API、文件处理API等等。这些通用接口组合起来，解决80%应用的后端逻辑是不成问题的。

有了这样的开放平台，应用开发时就可以完全通过js来完成各类业务逻辑，而无需进行任何的后台开发和配置工作，对开发应用的前端同学而言，这听起来貌似不错。类似这样的平台国外还有几个，比如 Firebase， Parse, Backendless。而国内的我尚未发现，但我觉得这种开放平台应该会很有市场，谁用过谁知道。。。 对一些大公司而言这是不是一个机会呢？

noBackEnd的开发模式其实对前端同学提出了更高的开发能力要求，当后端的模板层完全撤去，只剩下纯净的数据接口时，意味着js将负责更多的业务逻辑处理，代码的组织架构需要有更好的设计。责任大了，压力也自然不会小，据闻腾讯盛行这种开发模式，而其配有500+的前端开发队伍，也就完全可以理解了。

不管你信不信，我是相信noBackEnd的趋势的，应用致胜的关键是idea及用户体验，后台的服务功能是趋同并可抽象的，也因此有了新型开放平台的存在，让我们不必再重复开发后台逻辑；而显示层的设计是无法趋同的，对体验的追求不会有极致，更多的精力和开发将会投入其中。

6评

移动开发之touch event篇

by  xutao—前端开发 | 2013-04-27

一、前言

如今，智能手机和平板电脑越来越普及, 越来越多的人用过移动设备浏览网页。移动设备的流量已经占到北美网络总流量的20%(http://allthingsd.com/20120525/mobile-devices-now-make-up-about-20-percent-of-u-s-web-traffic/)。幸好目前最流行的两大移动操作系统IOS和Android都具备了解析标准的HTML、CSS和JS的能力,网页开发者还是可以用桌面浏览器来开发网页。通过这两个系统上的浏览器看到的网页和我们桌面浏览器上看到的网页几乎是一致的。虽然看起来是一致的，但是在交互上面还是有一些区别的，最大的区别就是，这些移动设备都没有鼠标，我们平时在桌面浏览器上用的鼠标事件，在移动设备浏览器上用起来怪怪的。想要发挥移动设备触摸屏的特点，给用户提供良好的体验，就要用到浏览器的触摸事件。

二、开发准备（Android）

Android设备可以使用ADB（Android Debug Bridge）来调试android程序，也可以通过ADB来调试移动版Chrome中的网页。

ADB调试说明

http://developer.android.com/tools/help/adb.html

远程调试使用说明

https://developers.google.com/chrome-developer-tools/docs/remote-debugging

想读更多 ->

18评

阿里巴巴中文站招聘前端开发&前端架构师

by  王涛—前端开发 | 2013-03-30

工作地点：杭州

简历请发送到：terence.wangt@alibaba-inc.com

职位有效期：2013-07-01前

来做的事：

1、阿里巴巴中文站新一代前端框架设计及UI组件库开发。

2、前端通用工具平台的开发及建设。

3、除此之外，还得研究些新玩意，尽情发挥你的创造力。

4、总之，不会让你做码农。

 

职位要求：

1、掌握良好的前端技能，包括XHTML/XML/CSS/Javascript，了解WEB标准化、性能优化方法，了解可用性、可访问性和安全性。

2、熟悉掌握一种常见JS框架，如Jquery，YUI，ExtJS等，并有一定的前端框架设计能力。

3、热爱前端，热爱设计，对新鲜事物充满好奇心，有折腾的想法和精力，喜欢捣鼓各种互联网应用。

4、自我管理能力强良好，崇尚团队合作，快速的学习能力，乐于分享与沟通。

5、有Web后端脚本的语言（如Java/NodeJS/PHP/C#/C++/Python）开发经验者优先。

18评

jQuery选择器探讨进阶

by  tiegen.zhutg—前端开发 | 2013-02-28

jQuery选择器探讨

在jQuery中，当用户把选择器表达式作为参数传递给$()函数时，jQery的Sizzle先对这个选择器表达式进行语法分析，然后再决定如何获得表达式所代表的这些元素。在框架底层，Sizzle应用了浏览器所支持的最高效的DOM 方法来获取一个节点列表(nodeList)，这个节点列表是一个类似于数组的对象的DOM元素的集合。下面的列表展示了jQuery的Sizzle内部采用的浏览器DOM遍历方法和浏览器的支持情况：

  1. 1. .getElementById()  浏览器支持情况：IE 6+, Firefox 3+, Safari 3+, Chrome 4+, and Opera 10+；
  2. 2. .getElementsByTagName()  浏览器支持情况：IE 6+, Firefox 3+, Safari 3+,Chrome 4+, and Opera 10+；
  3. 3. .getElementsByClassName() 浏览器支持情况：IE 9+, Firefox 3+, Safari4+, Chrome 4+, and Opera 10+；
  4. 4. .querySelectorAll() （这个是浏览器内置的css选择符查询元素方法，比getElementsByTagName和getElementsByClassName效率要高很多。）浏览器支持情况：IE 8+, Firefox 3.5+, Safari 3+, Chrome 4+, and Opera 10+；

想读更多 ->

14评

jQuery事件编写进阶

by  tiegen.zhutg—前端开发 | 2013-02-28

jQuery事件编程进阶

事件委托，是一种优化DOM元素事件绑定的技巧，利用事件冒泡的原理，通过绑定事件到父元素，检查event触发元素的target，最终执行相应的事件函数处理，它的几个好处一般前端开发程序员都知道。在jQuery中，一般是delegate()方法和.live()方法，但是，如何选择事件委托的方法，或者在什么情况下用.live(),什么情况下用.delegate(),这个值得讲一讲：

live: function( types, data, fn ) {
      jQuery( this.context ).on( types, this.selector, data, fn );
      return this;
    }
delegate: function( selector, types, data, fn ) {
      return this.on( types, selector, data, fn );
}

查看这2个事件委托的源代码可知，live方法中，有个元素的执行环境，这个执行环境默认是document,所以，如果把live事件委托写在$(document).ready(function() {})之外，也是没有问题的。live()在某种情况下会引起性能问题，这主要包括2个方面：1.live()方法虽然避免了绑定事件处理到很多DOM元素，但是，它在一开始选择了文档中的所有元素，如果一个文档有很多的子节点，比如文档中的一个表有几十列，几百行表内容，而事件要绑定到这个表的某一行某一列，那么，live()方法在一开始选择这个表的所有行，所有列的时候，就是一个非常大的性能消耗，会导致脚本反应很迟钝。2.因为live()是绑定到document上面，所以会有大量的事件冒泡，事件冒泡要从嵌套最深的DOM元素往上一直冒到document上面，这样长路径的事件冒泡也是一个很昂贵的性能消耗。而采用.delegate(),事件绑定到$()函数的选择表达式元素上，因此页面的事件注册更加清晰，而事件冒泡更少。

想读更多 ->

37评

5°专场视觉设计小析

by  山木—视觉设计 | 2013-02-06

专场视觉设计分析
这个主题是2012年下半年的一次内部分享，迟迟未形成文章，马上过年了赶紧整理起来，顺便给视觉设计师们拜年了！！！我自己内心的一个呼唤，明年脱离“苦逼”二字……

网站的专场设计，应该算是网页视觉设计师的必修课，应该也算是最基本功。她所需要的设计理论都是最基本，但同时也是最重要的。设计理论版本多如牛毛，我这里仅仅整理5个方面来分析网页专场设计的一些方法，本人并非大师或资深，欢迎各式拍砖。

设计理论每人都会或多或少的知道一些，但是我们作品是给谁看的，我们的真正用户是谁，用户的特性是什么，每个网站针对的用户都不同，在这里简单介绍下我们内部总结的阿里巴巴B类用户的特性：

在了解自己所针对的用户特性之后，我们做设计就会更有针对性，对作品的创意也会更贴近用户情景。在这里我分成5个方面来表述专场设计所需的基本功。
想读更多 ->

山木 : 一个做设计的木头人
16评

网站CSS选择器性能讨论

by  tiegen.zhutg—前端开发 | 2013-01-24

    CSS选择符由一些初始化参数组成，这些参数指明了要应用这个CSS规则的页面元素。作为一个网站的前端开发工程师，应该避免编写一些常见的开销很大的CSS选择符模式，尽量编写高效的CSS选择符，从而加快页面的渲染速度，缩短页面呈现时间。

我们先来看一下safari和webkit的架构师David Hyatt的两段话：

  1. 样式系统从最右边的选择符开始向左进行匹配规则。只要当前选择符的左边还有其他选择符，样式系统就会继续向左移动，直到找到和规则匹配的元素，或者因为不匹配而退出。
  2. 如果你非常在意页面的性能那千万别使用CSS3选择器。实际上，在所有浏览器中，用 class 和 id 来渲染，比那些使用同胞，后代选择器，子选择器（sibling, descendant and child selectors）对页面性能的改善更值得关注。

Google 资深web开发工程师Steve Souders对CSS选择器的效率从高到低做了一个排序：

1.id选择器（#myid）2.类选择器（.myclassname）3.标签选择器（div,h1,p）4.相邻选择器（h1+p）5.子选择器（ul < li）6.后代选择器（li a）7.通配符选择器（*）8.属性选择器（a[rel="external"]）9.伪类选择器（a:hover,li:nth-child）

上面九种选择器中ID选择器的效率是最高，而伪类选择器的效率则是最底。详细的介绍大家还可以点击Writing efficient CSS selectors。

综合上面的顺序，我们清楚的知道，id和类名用于关键选择器上效率是最高的，而CSS3的仿伪类和属性选择器，虽然使用方便，但其效率却是最低的。

知道了基本原理以后，我们编写CSS时就应该注意了。下面举几个例子，让大家理解的更透彻一些：

1.不要在编写id规则时用标签名或类名

  1. BAD
  2. button#backButton {…}
  3. BAD
  4. .menu-left#newMenuIcon {…}
  5. GOOD
  6. #backButton {…}
  7. GOOD
  8. #newMenuIcon {…}

由于样式系统从最右边的选择符开始向左进行匹配，只要当前选择符的左边还有其他选择符，样式系统就会继续向左移动，直到找到和规则匹配的元素，或者因为不匹配而退出，所以，在button#backButton {…}中，样式系统先找到id为backButton的元素，然后继续向左匹配，查看该元素的标签名是不是button，如果不是，查找下一个id为backButton的元素，再检查这个元素的标签名，如此周而复始，直到到达文档末尾。如果只是#backButton {…}，则样式系统找到id为backButton的元素后，因为左边没有其他选择符了，它就退出而结束查找了。

另外，根据HTML规范，id在HTML中是唯一的，也就是说一个HTML页面只限定有一个id为“XX”的元素，而不限制拥有这个ID元素的标签名，所以,在button#backButton {…}中,button标签完全是无意义的，可以，而且应该去掉，button#backButton {…}与#backButton {…}是等价的。在#backButton前多写了button,只会引起样式系统向左移动，继续查找页面元素，损耗页面性能，延长页面渲染时间。

另一方面，在id元素前面添加标签名，还会引起另一个致命的问题，比如原来id为backButton的标签名是button,如果原来样式声明写成button#backButton {…}，则现在需要把button标签改成input，id不变，则button#backButton {…}声明的样式规则在这个id同样为backButton的input元素上不起作用，不信大家可以自己动手编写试一下。

2.不要在编写class规则时用标签名

  1. BAD
  2. treecell.indented {…}
  3. GOOD
  4. .treecell-indented {…} //语言化和标签名绑在一起 假设treecell
  5. BEST
  6. .hierarchy-deep {…} //语言化和标签名无关

原理参考第一条。

3.把多层标签选择规则用class规则替换，减少css查找

  1. BAD
  2. treeitem[mailfolder="true"] > treerow > treecell {…}
  3. GOOD
  4. .treecell-mailfolder {…}

4.避免使用子选择器

现在我们来看看David Hyatt的第3段话：后代选择器在CSS中是最昂贵的选择器。贵得要命——尤其是把它和标签或通配符放在一起！

  1. BAD
  2. treehead treerow treecell {…}
  3. BETTER, BUT STILL BAD (see next guideline)
  4. treehead > treerow > treecell {…}

标签后面最好永远不要再增加子选择器

  1. BAD
  2. treehead > treerow > treecell {…}
  3. GOOD
  4. .treecell-header {…}
  5. BAD
  6. treeitem[IsImapServer="true"] > treerow > .tree-folderpane-icon {…}
  7. GOOD
  8. .tree-folderpane-icon[IsImapServer="true"] {…

5.依靠继承

  1. BAD
  2. #bookmarkMenuItem > .menu-left { list-style-image: url(blah) }
  3. GOOD
  4. #bookmarkMenuItem { list-style-image: url(blah) }

最后，我们来做个总结，网站编写CSS时，应该优先考虑使用class选择器，避免使用通配符选择器（*）和属性选择器（a[rel="external"]），后代选择器与标签选择器结合使用也应避免。使用id选择器的性能最好，但是编写时要注意其唯一性，谨慎使用。CSS3选择器（例如：:nth-child(n)第n个孩子）在帮助我们锁定我们想要的元素的同时保持标记的干净和语义化，但事实是，这些花哨的选择器让更多的浏览器资源被密集使用。引用David Hyatt关于CSS3选择器的论述：如果你关心页面性能的话，他们真不该被使用！

  1. 英文文档参考资源：
  2. http://blog.archive.jpsykes.com/151/testing-css-performance/
  3. http://blog.archive.jpsykes.com/152/testing-css-performance-pt-2/
  4. http://blog.archive.jpsykes.com/153/more-css-performance-testing-pt-3/
  5. Testing CSS Performance  Jon Sykes
  6. https://developer.mozilla.org/en-US/docs/CSS/Writing_Efficient_CSS?redirectlocale=en-US&redirectslug=Writing_Efficient_CSS
  7. •Original Document Information
  8. •Author: David Hyatt
  9. •Original Document Date: 2000-04-21
  10. •Original Document URL: http://www.mozilla.org/xpfe/goodcss.html
  11. http://css-tricks.com/efficiently-rendering-css/
  12. (Efficiently Rendering CSS)
  13. https://developers.google.com/speed/docs/best-practices/rendering?hl=zh-CN
  14. （google建议）
15评

web前端性能优化进阶路

by  王涛—前端开发 | 2013-01-20

Web前端性能优化WPO，相信大多数前端同学都不会陌生，在各自所负责的站点页面中，也都会或多或少的有过一定的技术实践。可以说，这个领域并不缺乏成熟技术理论和技术牛人：例如Yahoo的web站点性能优化黄金法则，以及大名鼎鼎的优化大师Steve Souders。本文并非一篇讨论性能优化技术方法的文章，而更多的是对中文站搜索List页面持续两年多的前端性能优化实践的思路总结。希望对正在从事这个领域研究的前端同学能有所帮助。

简单的说，我们的性能优化实践分为三个阶段：初探期、立规期、创新期， 每个阶段大概持续半年左右，有足够的时间形成一些优化思路的沉淀。

一：初探期 

2010年底我们开始接手搜索List页面，这是中文站历史最为悠久的页面之一，当时它的生命体征正如它的年龄一样，非常虚弱：当时的基调网络监控显示，页面的完全加载的时间是16秒！作为以“快”为核心业务指标的搜索页面，这个状态显然已是无法承担重任了。

性能是一定要优化的，但我们也面临着大多数前端同学所面临的共性问题 — 业务需求紧张，况且我们是刚刚接手这个业务，非常不熟悉，别说是优化了，就是做个小需求也都经常出现线上故障。就是在这样的情况下，我们开始了搜索页面的性能优化之路，并且给自己定下了当时看起来非常难以实现的目标：在2011年年中前把全页面加载时间降低到7秒以下。

我们很快成立了一个性能优化小组，3-4个前端同学参与其中，一个人的力量毕竟有限，尤其是应对这样一个历史业务繁多的页面。参与的同学多些，技术氛围也相对浓烈，大家很全面的分解了目前页面上出现的性能瓶颈，并分别领取了自己的优化任务。

在这个阶段里，我们基本是照葫芦画瓢，把雅虎性能优化的那些法则与我们的页面一一对照，完成了许多优化点，例如：

  • 小图片的合并，形成CSS Sprite，并优化图片
  • 模块的异步加载
  • 图片的懒加载
  • CSS文件引用放在页面顶部，JS文件引用放在页面底部，并对代码压缩
  • 缩小cookie体积
  • …
前人的技术理论果然是靠谱，经过我们半年时间加班加点的性能优化后，我们奇迹般的达成了优化目标！（附性能曲线图）

想读更多 ->

12345678910...