当前位置:Gxlcms > html代码 > WEB开发模式浅析_html/css_WEB-ITnose

WEB开发模式浅析_html/css_WEB-ITnose

时间:2021-07-01 10:21:17 帮助过:9人阅读

WEB技术随着互联网的崛起而崛起,又随着移动互联网的发展而呈现更加多样化的趋势。

黑暗时代:大约在2005年以前,所谓的WEB开发主要还是美工的活,HTML/CSS占主导,Dreamwaver做为页面设计三剑客之一,成为大多数WEB程序员的必备利器。Javascript能不用就不用,能少用就少用,浏览器只考虑IE。那时候的Javascript显得非常异类、原型继承、语法灵活多变、调试困难(还记得在IE中调试Javascript的痛苦经历吗?),一般程序员都不愿意干前端的活。好不容易出来一个Bindows,被许多程序员捧为神器。但稍加试用就发现慢如蜗牛,问题不断,根本不能实用。由此可见那时的浏览器也不重视Javascript引擎的优化。那是WEB开发的黑暗时代。 文艺复兴:到了2005年左右,大家慢慢也都注重用户体验了,AJAX技术也日益普及了,WEB2.0的提法也甚嚣尘上,自己的应用若不贴上WEB2.0的标签都不好意思和人打招呼了。那时候的Java社区在Struts/Spring/Hibernate的带领下风风火火、异常活跃。此时,Ruby On Rails出现了!其约定优先的理念,简直让SSH模式下繁杂的XML配置方式无地自容。在新技术新理念层出不穷的大背景下,jQuery于2006年横空出世。jQuery的出现,彻底终结了WEB开发的黑暗时代,迎来了WEB领域的“文艺复兴”。Ajax技术的广泛运用、WEB标准化的逐步推进、浏览器市场的缓慢变化,等等,都是这种“复兴”的佐证。 百花齐放:如今,在距离Apple于2007年推出首部IPhone以来,时间已过去6年多,这正是移动互联网从起步到高速发展的年份。对用户体验的极致追求,导致WEB技术发生了更加深刻的变化。Javascript走向服务端成就了node.js,而Flush技术由于商业和技术的原因似乎正逐步走向衰落,各种基于Javascipt的MVC框架层出不穷,流式布局、响应式布局、自适应、拟物化设计、扁平化设计等概念不断涌现,现今正是WEB领域百花齐放的时代。

现在做WEB开发,也如同做Java服务端开发一样,要在众多的基础库、开发框架当中做出合适的选择:

jQuery:以简洁的链式操作而闻名,封装了底层浏览器的API,屏蔽浏览器实现的差异,是当前最流行的基础库;不过随着HTML5标准逐渐被各大浏览器厂商所接受,jQuery的作用也大打折扣,其发行包大小也常常为人们所诟病。 mootools:当年与jQuery一较高下的框架有prototype.js和mootools。当年prototype得到ruby社区的大力支持,一度与jQuery较量得不相上下。而mootools则得到Java阵营的支持,虽然比不上前两者,但由于其api设计比较符合java程序员的习惯,因此也发展得风生水起。前段时间看到prototype作者撰文承认了prototype的失败,如今在底层库的选择上还是jQuery一家独大的局面; dojo:dojo是类似于java swing的完整框架,既包含了基础库,也包含了大量的UI组件。尽管dojo得到了struts2的大力支持,但还是无法扭转其江湖地位; extjs:类似当年的Bindows,在WEB中实现类似桌面程序的效果。当年Bindows因为性能问题惨死沙场,只能说它生不逢时。不过extjs如今的命运也让人堪忧,一成不变的界面风格和操作模式其实是违背WEB千变万化的本质特征的; easyui:基于jQuery的声明式UI组件库。所谓声明式组件,是指不需要象传统桌面程序一样通过写代码的方式创建和设置组件,只需要遵循最原始的HTML声明式理念,在原始HTML Tag上设置属性就能得到想要的效果;类似easyui的国产框架DWZ也是类似思路; backbone:基于Javascript的MVC框架,MVC理念在浏览器中的完整实现。可以想见,这类框架在处理客户端多视图数据同步方面具有很大的优势,可以大大简化客户端展现及交互逻辑的开发过程;

选择上述某一种或某几种基础库或开发框架,就意味着选择了一种开发模式。从开发模式的角度我们可简单总结一下:

传统的HTML+CSS+JS模式:这种模式下,开发人员需要编写大量的HTML代码,用于实现页面的展现逻辑,编写JS代码用于实现交互逻辑。这是最传统的开发方式,同时也是运用最广泛的开发方式,不论企业级管理系统还是电商类网站、拟或手机WEB应用,都可以采用这种方式实现;该方式的缺点是实现单页面应用或复杂交互应用时JS代码量较大; 桌面应用开发模式:如EXTJS,页面全部使用JS来实现,开发人员基本不需要编写HTML代码,大量的展现逻辑和交互逻辑使用JS代码完成。这种方式用于实现单页面应用非常方便;但要求开发人员对JS及开发框架的组件库有深入了解;思维模式上要适应基于组件的事件机制; 声明式UI开发模式:如easyui及国产DWZ,页面的展现逻辑如同第一种模式一样使用HTML实现,但是相比第一种模式,这种模式对组件的抽象做得更好,部分传统模式下用JS实现的展现逻辑甚至是交互逻辑也可以使用声明方式实现。可以说这是对第一种模式的增强; 客户端MVC开发模式:如backbone,这种模式与桌面模式相似,通过大量的JS代码实现页面的展现和交互逻辑,但通过在客户端维护数据模型及其状态,再运用视图与模型的绑定机制,可以大大减少JS代码量;

第一种模式与第三模式相似,都是以HTML代码实现展现逻辑、以JS代码实现交互逻辑,只是第三种模式通过更多的抽象组件,尽量使用HTML实现尽可能多的展现和交互逻辑;第二种模式与第四种模式类似,都是偏重于尽量使用JS实现展现逻辑和交互逻辑,HTML仅仅做为页面布局或页面容器。相对来讲,第二种模式偏重于使用JS实现界面视图的组装,而第四模式偏重于使用JS实现完整的MVC机制,在backbone中,视图也通常是使用基于HTML代码片断的模板方式来实现。

由于第三种模式是第一种模式的增强,因此在实际项目中可以尽量选择第三种开发模式;第二种模式相比第一种和第三种模式来讲,主要是开发方式的不同,前者侧重于JS,后两者侧重于HTML,除此之外,两者的应用场景和应用范围都很相似。

尽管第四模式与第二种模式一样也是偏重于使用JS实现页面逻辑,但由于其强大的MVC机制,因此它与第二种模式有着本质的不同。试想对于gmail之类的应用,如果客户端底层没有维护一套邮件的数据模型的话,要单纯使用前面三种方式实现当前gmail的页面交互效果将是非常困难的。

总之,对于WEB开发模式的选择,现阶段个人建议优先选择第三种模式。如果应用交互非常复杂,或者需要实现更好的交互体验(比如支持本地存储、undo、redo等),而导致大量的JS代码的话,则可以考虑使用第四模式。

人气教程排行