知识共享许可协议

玩转AMD - 设计思路

AMD 的全称是 Asynchronous Module Definition。顾名思义,这是一种定义模块的方式,并且是异步的。在其 Spec 的第一段描述中,就强调了特别适合浏览器环境。

The Asynchronous Module Definition (AMD) API specifies a mechanism for defining modules such that the module and its dependencies can be asynchronously loaded. This is particularly well suited for the browser environment where synchronous loading of modules incurs performance, usability, debugging, and cross-domain access problems.

我觉得,AMD 适合浏览器环境开发的主要特性有下面几点:

阅读全部

实战响应式图片

原文:Responsive Images in Practice

作者:Eric Portis

译者注:感谢米粽我佛山人otakustay为译文提出的宝贵意见。


魔鬼因一切我们享受的东西而惩罚我们。

—阿尔伯特·爱因斯坦

图片已经占了 Web 内容的 62%,而且我们每天都在制造更多。如果所有图片内容都能被好好加以利用那的确很赞。但是对小屏或低分辨率屏来说,其中大部分数据都被浪费了

为什么?尽管 Web 设计初衷是让所有人能通过任何途径来访问,但直到最近,设备的碎片化才迫使业界全面转向了响应式设计。我们在进行响应式设计时,内容可以优雅且高效地流入任何设备。这说的是除了位图以外的所有内容。位图是固定分辨率的。而且他们的容器——敬爱的 img 和它那孤零零的 src——没有任何适配能力可言。

设计师们面临这样一个苏菲的选择1:让页面在有些情况下变模糊,还是在所有情况下变慢。大多数人倾向于后者,给所有人发送能适配最大、最高分辨率屏幕的图片。浪费啊。

但是!经过三年的辩论,我们有了一些新的标记来解决响应式图片这个问题:

阅读全部

玩转AMD - 写在前面

我们决定全面使用 AMD 进行前端开发,到现在已经两年的时间了。最初做这样的选择很简单,国外已经有很多使用 AMD 的成功例子了,大多数主流的 Libraries 和 Frameworks 对 AMD 也都有很好的支持,并且 AMD 的模块异步加载也为按需加载优化从根源上提供了支持。而我们也不想自己生产标准。所以我们在2012年的时候,经过一两次简单的讨论,就这么愉快的决定了。

两年过去。在实践的过程中,我们充分感受到了 AMD 的好处,不禁感叹其完备的设计思路和考虑。另外,我们也感觉到 AMD 在前端开发中的门槛还是不低的。主要体现在新同学入门的时间比较长,老同学很多也没有真正理解 AMD ,在项目中还是会用出一些不太符合常识的玩法。刚好最近空出一些时间,就写写一些我理解的 AMD ,给在玩 AMD 的同学一些参考,也给自己一个交代,以后就不用每个同学讲一遍了。

在这个时间节点,写 AMD 是需要一定的勇气的。作为一个不太成熟的领域,前端技术的发展一直很快,以致于一个东西如果一段时间没有变化没有发出新的声音,就会被认为过时过气。我也经常听到大家更愿意谈论AngularJS、React、ES6、Mobile。在这样的技术环境下,写一个“过气”的 AMD 其实是很难找到什么共鸣的。但我一直崇尚 精工,这需要态度、坚持以及时间的沉淀,我觉得我们在 AMD 的实践上做的还算及格,就选了这个话题。

本着既然要写就写多点的原则,我打算从 设计思路应用实践 两个方面来写,顺便取了个title: Dissecting AMD。刚好我们有实现一个 AMD 的 Loader:ESL,所以顺便写一章 Loader实现,打打广告。