Web前端发展及应用

1、web前端的开展及应用一、 简单明了的早期时代这个也称为web 1.0时代，非常适合创业型不分前后端，经常3-5个人就可以搞定所有的开发，根本上是效劳端给什么，浏览器就展现什么由web server层控制好处：简单明了，本地起一个Tomcat 或者Apache 就能开发了，只要业务不太复杂就都还好。弊端：但业务太多了，变得复杂了，server越来越多，开发人员增多时，就会遇到以下的一些问题1. Service 越来越多，调用关系变复杂，前端搭建本地环境不再是一件简单的事。2. Jsp 等代码的可维护性越来越差。jsp: 非常强大，可以内嵌Java代码。这种强大使得前后端的职责不清晰，jsp就变

2、成了一个灰色地带，经常会出现为了赶工程等各种紧急的需求，会在jsp里糅杂了大量业务代码，这种积攒到一定程度，往往会打来大量的维护本钱。二后端为主的MVC时代为了降低复杂度，以后端为出发点，有了web server层的框架升级，这就是后端的MVC时代。从上面的图可以看出来代码的维护性得到了明显的好转，MVC是个非常好的协作模式，从框架层面让开发者懂得什么是代码，应该写在什么地方，这使得模板里写不了Java代码，但功能看起来变弱了，正是这种限制使得了前后端分工更清晰，但任然会有问题存在：1. 前端开发重度依赖开发环境这种框架下，前后协作有两种模式：一种是前端写demo，写好后让后端去套模板。好处：

3、很明显，demo可以本地开发，很高效，缺乏是还要后端套模板，有可能会套错，而且还要前端确定，来回沟通调整的本钱较大。另一种协作的模式是前端负责浏览器的所有开发和效劳器端的view层模板开发，支付宝是这种模式。好处：UI相关的代码都是前端去写就好，后端不用太关注，弊端：前端开发严重绑定后端的环境，环境成为影响前端开发效率的重要因素。2. 前后端职责依旧纠缠不清Velocity模板还是挺强大的，变量 逻辑，宏等特性，依旧可以通过拿到上下文变量来实现各种业务逻辑。这样只要前端弱势一点，往往会被后端要求拿到的上下层写出不少业务代码，还有一个灰色地带是controller，页面路由等功能应该前端最关注的

4、，但是由后端来实现了。三 Ajax 的SPA时代2005年Ajax正式提出，加上CDN开始大量用静态资源储存，于是就出现了javascriptd的SPA时代。特点：这种模式下，前后端的分工就非常清晰了，前后端的关键协作点是Ajax接口，看起开很好，但回头看看，这与jsp时代区别不大。复杂程度从效劳端的jsp里移到了浏览器得到JavaScript，浏览器变得复杂，类似Spring MVC ，这个时代开始出现浏览器端的分层架构：对于SPA，有几个重要的挑战1 前后端接口的约定：如果后端的接口一趟糊涂，后端的业务模型不够稳定，那这样前端开发会很痛苦。2 前端开发的复杂度调控：SPA应用大多数以功能交

5、互型为主，JavaScript代码过十万行很正常。大量js代码的组织与view层的绑定等，都不是容易的事情。四前端为主的MV*时代为了降低前端开发的复杂度，例如：好处：1. 前后端职责很清晰： 前端在浏览器端工作，后端在效劳端工作。2. 前端开发的复杂问题可控： 前端代码很重，但合理的分层，让前端代码各司其职。3. 部署相对独立： 产品可以快速改良。缺乏：4. 代码不能复用，例如后端依旧需要对数据做出各种校验。5. SPA不能满足所有需求，依旧存在大量页面应用。五Node带来的全栈时代 前端为主的MV*模式解决了很多很多问题，但依旧缺乏，然后Node.js兴起了，JavaScript开始有能力运行在效劳端，这就研发了一种新的模式：在这种情况下，前后端职责很清晰。对前端来说，两个UI层各司其职：1，Front-end UI layer 处理浏览器层的展现逻辑。通过CSS渲染样式，通过JavaScript添加交互功能，HTML的生成也可以放在这层，具体看应用场景。2，Back-end UI layre 处理路由，模板，数据获取等。通过路由，前端可以自主把控URL Design，这样无论是单页面还是多页面应用，前端都可以自由调控，后端也可以摆脱对展现的强关注，可以专心于业务逻辑的开发。与JSP比拟，全栈模式看起来是一种回归，也确实是一种原始的开发模式的回归，不过是一种螺旋上升的回归。