爱淘FE

Posted by:
Mickey

每件事最后都会是好事,如果不是好事,说明还没到最后

1,298

碎碎念——拥抱标准

新年第一天上班,有些碎碎念,无中心无思想~

群里抛出了个链接,chrome已经自带将线上文件代理到本地磁盘的功能

亲测,好用,只是第一次页面生效有点延迟。 下图是某页将sui.css的请求map到本地开发中wsui(无线商家版sui)的例子

替换前:
screenshot

替换后:
screenshot

突然想到

以前在mac下辗转学习尝试天马、nproxy,anyproxy等等,但总归感觉用的还不够爽,不能像windows下fiddler一样无痛使用。
如今chrome自己一集成,很多工具致力于解决的核心问题,瞬间化解了一大半(当然不同工具可能还有其他功能)。

这似曾相识的感觉

隐约熟悉的感觉,很类似前端做的一些各种工具、库、hacker,一旦被标准化并实现后,意义也就变小了, 但他们本身是推动了那些领域的标准化,从历史意义上说是起积极的推动作用。

一些完整的实现

比如最早的圆角实现,当时看过有不下3种实现方式,各种复杂、堆标签。最终border-radius被标准化,顿时都安静了。

json2.js着力解决的跨浏览器JSON转义、反转义工具,工具本身已然趋于完美,也在IE8和其他浏览器标准化后使用甚少。

一些仍在探索的实践

underscore对JS函数式编程的辅助工具集非常好用,和开发者圈的意愿一起,推动着ECMAScript逐步实现。

再如React、polymer各自对WebComponents标准的实现,谷哥现在对angular的态度有些微妙,也是想往自家polymer的WebComponents特性上靠。

依赖、包管理机制,殊途同归的感觉,最早CommonJS规范提出,为使其能在浏览器端运用,衍生出了RequireJS为代表的AMD和seaJS为代表的CMD,二者在发展中互相吸取优点扩展自身(以至于现在产生了UMD规范,试图统一Module Definition)。

他们都很好用,只是终究是标准在浏览器领域实现的hacker,而非标准化。于是最近(也有几年了)完全基于CommonJS规范的工具出现了,Browserify、webpack、DUO,各有特点,但核心思想都是:支持代码完全按照CommonJS规范的node方式编写,然后通过服务器端编译为可在浏览器直接使用的一个或几个文件。

思考一下未来,如果哪天CommonJS也通过某种方式在浏览器端得以实现,那么AMD、CMD的源代码多少需要进行一些修改才能使用;而遵循标准的开发模式下的源代码,可能只是不再需要服务器端编译,可直接使用。团队也就更愿意进行升级了。

举个不恰当的例子,一个前端库,版本1和版本2,假设后者是标准,前者是标准实现前的库。从前辈那里的听闻,标准实现后(版本2发布),旧库的升级需要大动干戈,成本过大,团队除非上层硬性要求,都不愿意升级。

所以, 框架、库如果不着眼于未来设计,会对未来的蜕变产生很大的升级成本

So...

对于尚无标准的web领域

百花齐放,针对某一方向,我们不管作为一种解决方案的创建者还是使用者,也就都有必要多多发展、推广了,可以推进业界圈子的良性发展。
最终某一种(多种?)方案可能会被纳入标准化草案加以完善。

之后该领域变为

已有标准的web领域

我们都应参与的事就是:了解学习标准。
不管是否与我们之前使用的方案、设计原理相驳,既然得到了全球大多数开发者、社区的点赞,自有他的优势。可以保留自有的方式,不过还是应该多了解一下标准,没准会有新的感悟呢。

发表评论


back up ↑