前端难处 -- 致即将开发移动 Web App 的新人
时间:2025-04-04
时间:2025-04-04
前端难处 -- 致即将开发移动 Web App 的新人
In many ways, I think being a front end engineer is one of the most complicated jobs in computer science. Most traditional programming concepts don’t apply and there’s a lot of soft science being applied to numerous technologies for usage on numerous platforms. The technical expertise necessary to be a good front end engineer is a vast and complicated terrain made more complex due to the parties you’re ultimately responsible to serve. Technical expertise may get you in the door as a front end engineer, but it’s your application of that expertise and your ability to work with others that makes you good.
-- Nicholas C. Zakas What makes a good front end engineer?
什么? 你这是在逗我吗? 前端也好意思说难? 只需要一个文本编辑器就能够搞定一切, 复制粘贴三下五除二, 随便找个做网站的, 分分钟解决问题, 你在这里跟我说难, 这不是逗我是什么?
我相信绝大多数没有真正深入过前端的人, 都会有这样的想法, 觉得前端实在太简单了, 简单到我都不屑于学.
在我看来, 大家对前端的误解, 就好比大家对JavaScript的误解(世界上最被误解的语言).
其实一个专业前端在知识的深度和广度上要求都非常之严, 肯定不仅仅是复制粘贴几段HTML标签, 网上找点CSS特效, 下载个jQuery插件什么的.
前端更多的与W3C标准息息相关, 你什么时候领悟到Web页面的3层架构(内容/展现/行为), 你什么时候开始关注HTML结构语义的重要性, 你什么时候真正理解CSS渐进增强(Progressive Enhancement), 你什么时候开始思考你写的是Unobtrusive JavaScript吗? 什么是优雅降级(Graceful Degradation)呢? 你什么时候真正将 JavaScript 做为一门编程语言来学习过?
这一切的一切都不单是你看上一本书或码一晚上代码所能够学到的, 前端是一个非常非常需要积累, 非常非常需要总结经验教训的地方. 前端日新月异发展是如此之快, 你一定要稳打基础, 理解最根本的基石, 跟上那些先进的思维模式, 在前端的路上永远都不会缺少酷与创新, 记住自己的目标, 不要迷失了最初的梦.
如果你从现在开始, 摆正姿态, 就请来见识下什么是最牛逼的 HTML 和 CSS 代码与君共勉.
<div class="mod">
<div class="hd"></div>
<div class="bd"></div>
</div>
.content {
width: 980px;
margin-left: auto;
margin-right: auto;
}
接下来让我们回到主题, 为什么开发移动 Web App 更难?
什么你跟我说更难? 你这是要闹哪样啊?
首先要说的是移动 Web App 的特殊性, 就是要尽量模仿成 Native App, 让用户用起来相当爽, 达到以假乱真的目的.
这主要是因为当下多是 Native App 为主, 用户一般都习惯了那种流畅的操作感觉, 如果你一上来就草草地将你的 Web 网站通过 PhoneGap 打包成 Hybrid App, 那就等着被用户K.O.吧: 你丫这是拿WAP网站来忽悠我呢?
其中最大的问题就是, 传统 Web 网站页面之间的跳转, 会产生一个比较大的空白时间, 让用户感觉很不爽, 整个 Hybrid App 就像一盘散沙, 缺乏连贯性, 没有像 Native App 那种页面切换时衔接的效果. 还有重要的一点就是需要保存页面的状态, 在用户不停地切换页面后返回来, 又必须恢复到最初用户选择的那种状态和所处的位置.
这就是为什么我们要选择以单页面(Single Page Application)来开发移动 Web App 的原因, 关键是方便实现切换"页面"时的过渡效果以及"保存"页面上的状态. 但单页面的开发模块必然增大开发难度, 也徒增了其他问题, 因此很有必要引入前端MVC的概念, 让它来统一组织前端的代码结构. 这就是为什么我们选用Backbone的原因. 它可以说就是为SPA而生的, 简洁明了, 没有太多硬性规定来干预你的开发, 也没有任何魔法绕得你晕头转向. 你所要做的仅仅是转变思维, 将界面元素拆分成一个个独立的View, 仅此而已, 别无其他.
Head First Backbone.js https://http:///jaceju/head-first-backbonejs
如果真有其他的话, 那一定就是前端模块与前端模板的渲染问题, 考虑到团队的因素, 我们直接使用了Backbone依赖的Underscore.js来做模块渲染. 其实模块真心不难, 想想你以前怎么写JSP就是了, 其实JSP就是一个模板引擎而已.
都说了是要开发移动 Web App, JavaScript 肯定跑不了, 那么接下来我们就说说 JavaScript 开发过程中最最黑暗的领域 -- 全局变量, 作用域, 原型(prototype), this, 闭包(closure), 嗯...讲完了, 大家懂了吗?
再有就是我们为了在开发复杂程序时让 JavaScript 更适合团队开发, 引入了模块化概念, 引入了RequireJS. 因此很有必要回顾下 JavaScript 模块化开发的历史, 主要是为了弥补 JavaScript 语言中最最缺乏的一块 -- 封装模块, 让别人知道你的代码提供了哪些功能, 以及如何使用, 还有依赖管理避免混乱.
1. 全局function
function log() {}
2. 命名空间(package), 模拟其他语言中包的概念, 或许是你最接受的方式
var myUtil = {
log: function() {}
};
3. 匿名闭包(Anonymous Closures), 代表作大家再熟悉不过了
var myUtil = (function() {
var privateVar = 0;
return {
log: function() {}
};
})();
4. Module规范(CommonJS, AMD), 模块化风格趋向于ruby, 模块就是模块没有包/文件夹的束缚, 想想java中的包名与类名纠缠的关系
define(function(require, exports, module) {
var private …… 此处隐藏:3716字,全部文档内容请下载后查看。喜欢就下载吧 ……
上一篇:纳米材料导论复习材料
下一篇:政治经济学第一章