JavaScript 的轻框架开发 已翻译 100%

一个人的中台 投递于 2014/08/29 14:05 (共 15 段, 翻译完成于 09-03)
阅读 9545
收藏 134
10
加载中

为什么我们不用 Angular, Ember 或者 Backbone!

Muut 是一个特殊的论坛平台,它也有着巨大的梦想! 当后端的性能已经极大优化的同时,前端也有着自己的目标:简单API,小体积,快速迭代。写代码就像在纸上先起个草稿,然后写入到许多文件中即可(猜译)。任何一个前端框架,比如,Angular 或者 Ember 都没问题!

下面是我们自己实现,而不用它们的原因。

一个人的中台
一个人的中台
翻译于 2014/08/29 15:06
1

首先是 API 方面的因素

开发 Muut 客户端时,我们基本的要求是简单的 API。它必须易用,没有额外的属性方法,不应该提供新的编程习惯(即不要制造另类的代码语法)。它应该易上手。不仅最终用户用它,而且个人也要用它,因为所有的网页界面都建立在它之上。

开始设计API之前,通常要先打好草稿。一个干净的桌子、一支笔、一张纸。我开始站在使用者角度构思API。从没有一切框架开始。

一个人的中台
一个人的中台
翻译于 2014/08/29 15:17
1

API 在 MVC 中是一个模块,要用 POJO(Plain Old JavaScript Object) 的形式。因为框架提倡API的设计必须"single source of truth“。API不仅能跑在浏览器上,也能在后端(node.js)执行。它必须完全独立且易单元测试。

我不喜欢交差相关的方法及属性把API搞杂乱。Backbone.Model.extendEm.Object.extend 都添加了大量的方法,给用户使用增加了复杂度。违背简单的目标,它不被我们接受!

 

一个人的中台
一个人的中台
翻译于 2014/08/29 15:29
1

小体积

更小的文件会更快加载,节省带宽。这是看得见的利益。更大的优势就是代码维护。小代码更容易把握,更快学会,更少的条条框框。

目前 Muut 客户端压缩后是 89kb,gzipped压缩后是 32kb。这比其它的论坛平台要小10 倍。体积明显很重要,当一半的网络访问来自于移动设备,开发人员就会寻找小工具来完成他们的工作。

一个人的中台
一个人的中台
翻译于 2014/08/29 15:40
3

下面的表会让你知道,我们使用的具有独立功能的工具应该是多大的体积。下面列的是我也在使用的,我正好做一下对比,以下均是minified后的大小:

模版、绑定、表单验证 Backbone.js 33.9kb
语法加亮,支持20+语言 Rainbowjs 28kb
提示,遮罩层,下拉框、标签切换等 Misc. tools 20kb
WebSocket communication socket.io 40kb
Markdown 分析器 markdown-js 23kb


在实际的项目开始之前,这些大概就已经有150kb了。

当前,Muut的包含界面视图、控制器(api与视图之间的结合代码)等合并后再minified,仅40kb。一个框架应该是多大呢?框架的目标是更小的工作量去达到目标,所以它应该很小。40 kb是容易管理并继续在之上进行开发。在事情复杂化之前,我还可以增加大量功能。

一个人的中台
一个人的中台
翻译于 2014/08/29 16:31
1

全面掌控

Muut 使用原生的 pushState 方法来控制URLs,John Resig's "微模版" (6) 来显示视图,内部的模型与视图的交互使用自定义事件。而不使用路由及自动数据绑定的功能。

每个事情都完全按照我们预期的执行,出现bug也容易找到。这里没有不可知的,不明道理的代码。这里没有秘密,并且调用堆栈也很浅。我们可以针对特殊需要而去组织代码,而这里没有固定的框架来控制必须如何做。

不混合编程样式

没有外部包更新

没有这依赖hell

每周都能愉快发布新版本!

一个人的中台
一个人的中台
翻译于 2014/08/29 17:57
1

特殊需求

Muut客户端只是一个包含全部HTML代码的JavaScript文件。当文件加载后它会在一个单独的anchor(A)标签中渲染自己。项目的打包与启动与传统的单页面程序有很大不同。

Muut服务端必须能够随时通知客户端。客户端与服务端以一种点对点的双向模式进行通信。

pseudo
pseudo
翻译于 2014/08/30 15:02
1

我们通过WebSocket发送JSON-RPC消息,而不会考滤使用REST:像Muut这种实时程序不能构建在REST之上,因为REST所采用的是一种请求-响应模式并且它不能理解push事件等东西。

现在的框架,例如ember数据,是面向REST的,并且它们的示例和文档也是基于REST的。WebSocket示例有遗漏,或只是试验性的。Muut所面临的挑战是很独特的。

pseudo
pseudo
翻译于 2014/08/30 15:17
1

技术锁定

如果你查看了任何编程语言的框架史你会发现它也是一部失败史。框架来了又走了。今天的JavaScript框架都很年轻。Backbone, Angular和Ember现在可能很流行,但几年后就不一定了。

我们来看下Angular (蓝), Backbone (黄) 和 Ember (红)的Goole Trends(谷歌公司的一项搜索产品) (2):

JavaScript Framework trends

JavaScript是世界上最流行的编程语言,并且提供了多种编程风格。但事物也在以一种不可思议的速度变化着。因此使愤怒的框架社区不断推翻曾经最好的应用构建方式。

pseudo
pseudo
翻译于 2014/08/30 15:29
1

没有最好的方式.

有许多不同的替代方式,目前Angular正处于巨大的增长之中. "AngularJS允许你的应用程序拓展HTML." 这是最好的方式吗? Backbone和Ember是否正处于危险的境地?2012年在X框架中有所投入的公司,可能马上会意识到,他们的开发团队已经在谈论下一个新技术了.作为使用这些框架其中之一的开发者,我担心他们的生命周期.

另一方面,让我们来比较一下jQuery和Angular (3):

jQuery vs Angular

上面的图告诉了你jQuery的普及程度.它正在全世界57.2%的网站中使用,其中92.7%的网站的JavaScript库是公开的. (4) 这里没有技术限制.但是作为一个嵌入式应用程序,我们不能期望人们,在已经使用jQuery的网站中,加载其他的框架.

Muut使用了jQuery的全部内容,在设计API的时候,我甚至偷师jQuery.它很简洁好用.我(依旧)喜欢这点.

gones945
gones945
翻译于 2014/09/02 00:39
1
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(33)

刘jianbo
刘jianbo
不错
0Scn
0Scn

引用来自“With0ut”的评论

如果只用数据绑定的话,vue.js足够小巧。。。
同感!!!
Tkks
Tkks
angular是一个风向标,一个时代
佑海
佑海

引用来自“郑纳智”的评论

为什么不试试knockout?这个框架更注重可扩展性,并且压缩后很小

引用来自“采女孩的小蘑菇”的评论

+1
支持,knockout早就是asp.net的御用框架了,虽然国内不太出名
小99
小99

引用来自“开源中国匿名会员”的评论

还是我大dotNet好。爱怎么绑怎么绑,前端还在努力的全栈的时候,我大dotNet早就前端到后端都统一了。有人说收费又有服务,没错了,就是说的我大dotNet。还有无数的组件,随手拖拖一个网站就出来。工作的目标是为了什么,不要搞那么多事情让自己失去跟亲人跟炮友一起快乐玩耍的时间。觉悟吧少年们。
但是只能在中小型项目使用
hello_152
hello_152
为什么我不用 Angular, Ember , Muut或者 Backbone ? 谁能告诉我为什么?我请吃饭!
开源无憾

引用来自“开源中国匿名会员”的评论

还是我大dotNet好。爱怎么绑怎么绑,前端还在努力的全栈的时候,我大dotNet早就前端到后端都统一了。有人说收费又有服务,没错了,就是说的我大dotNet。还有无数的组件,随手拖拖一个网站就出来。工作的目标是为了什么,不要搞那么多事情让自己失去跟亲人跟炮友一起快乐玩耍的时间。觉悟吧少年们。
你确定你不是在黑dotNet么。。。咋看都像啊
我也叫龙哥
我也叫龙哥

引用来自“开源中国匿名会员”的评论

还是我大dotNet好。爱怎么绑怎么绑,前端还在努力的全栈的时候,我大dotNet早就前端到后端都统一了。有人说收费又有服务,没错了,就是说的我大dotNet。还有无数的组件,随手拖拖一个网站就出来。工作的目标是为了什么,不要搞那么多事情让自己失去跟亲人跟炮友一起快乐玩耍的时间。觉悟吧少年们。
虽然有些戏谑,但我还是挺同意的。小项目,轻框架不如无框架;大项目,重框架不如直接拖控件。
一个人的中台
一个人的中台

引用来自“With0ut”的评论

如果只用数据绑定的话,vue.js足够小巧。。。
如获至宝,
渔樵耕读
渔樵耕读
瞎折腾。。
返回顶部
顶部