本文主要介绍了前端系统和Vue前端系统的分离。边肖认为这很好。现在分享给大家,给大家一个参考。来和边肖一起看看吧。
目录
前端知识体系概述前端三要素表示层(CSS)行为层(JavaScript)JavaScript框架UI框架JavaScript构建工具三端统一混合开发(Hybrid App)微信小程序后端技术主流前端框架ElementUlICEVantUlAtUlCubeUl基于AJAX的SPA时代前端发展历史这里的MV*模式如下:NodeJS带来的全栈时代总结
概述
Vue(读音/viu/,类似于view)是一套
渐进式框架
用于构建用户界面的,2014年2月发布。与其他大型框架不同,Vue设计为自下而上一层一层地应用。Vue的核心库只关注视图层,不仅仅是
易于使用,并且易于与第三方库(如vue-router: jump、vue-resource: communication、vuex: management)或现有项目集成。
https://cn.vuejs.org/v2/guide/,官方网站
前端知识体系
要成为真正的“互联网Java全栈工程师”还有很长的路要走,其中“我是大前端”是必修课。本课程的主要目的是带领我的Java后台程序员认识前端,了解前端,掌握前端,再向前一步,成为“互联网Java全栈工程师”。
前端三要素HTML(结构):超文本标记语言,决定网页的结构和内容。
CSS (Presentation):层叠样式表,设置网页的呈现样式。
JavaScript(行为):它是一种弱脚本语言。它的源代码不需要编译,由浏览器解释运行,控制网页的行为。
表现层(CSS)CSS级联样式表是一种标记语言,不是编程语言,所以不能自定义变量,引用变量等。换句话说,你没有任何语法支持。其主要缺陷如下:
语法不够强,比如不能嵌套,导致模块化开发需要写很多重复的选择器;
没有可变的、合理的样式重用机制,使得逻辑上相关的属性值必须以文字量的形式重复输出,难以维护;
这导致我们在工作中平白增加了很多工作量。为了解决这个问题,前端开发者会使用一个叫做CSS预处理器的工具,提供CSS的缺失样式层复用机制,减少冗余代码,提高样式代码的P可维护性。在风格上大大提高前端的开发效率。
什么是 CSS 预处理器
CSS预处理器定义了一种新的语言。它的基本思想是使用一种特殊的编程语言,在CSS中加入一些编程特性,以CSS为目标生成文件,然后开发者只需要使用这种语言对CSS进行编码。翻译成通俗的话,就是“
用一种专门的编程语言,进行 Web 页面样式设计,再通过编译器转化为正常的 CSS 文件,以供项目使用”。
”常用的 CSS 预处理器有哪些
SASS:基于Ruby,由服务器处理,功能强大。高分辨率效率。学习Ruby语言难上加难。
LESS: backbone NodeJS,由客户端处理,易于使用。功能比SASS简单,解析效率比SASS低,但在实际开发中已经足够,所以我们后台人员建议必要时少用。
行为层(JavaScript)JavaScript是一种弱类型脚本语言。它的源代码在发送给客户端运行之前不需要编译,而是将文本格式的字符代码发送给浏览器,由浏览器进行解释和运行。
Native 原生 JS 开发
原生JS开发,也就是咱们按照* * [ECMAScript] * *标准开发,简称ES,特点是all clear
所有浏览器都支持它。截至目前博客发布时间,ES标准已经发布如下:
ES3
ES4(内部,非官方发布)。ES5(完全浏览器支持)
ES6(常用,目前主流版本:webpack打包成为ES5支持!)
ES7
ES8
ES9
不同的是逐渐增加新的功能。
TypeScript 微软的标准
TypeScript是微软开发的免费开源编程语言。它是JavaScript的超集,本质上为这种语言增加了可选的静态类型和基于类的面向对象编程。作者Anders hejlsberg(c#、Delphi和TypeScript之父;网创始人)。
这种语言的特点是除了es的特性之外还包含了很多不在标准范围内的新特性,所以很多浏览器并不能直接支持TypeScript语法,需要编译(编译成JS)后才能被浏览器正确执行。
JavaScript 框架
JQuery:众所周知的JavaScript框架,优点是简化了DOM操作,缺点是DOM操作过于频繁,影响前端性能:只用于前端眼中兼容IE6、7、8:
angular:Google收购的前端框架,由一群Java程序员开发,特点是将后台的MVC模式搬到了前端,加入了模块化开发的概念。它是与微软合作用TypeScript语法开发的;对后台程序员友好,对前端程序员没那么友好:最大的缺点就是版本迭代不合理(比如:1代-2代,除了名字,基本就是两个东西;Angular6在博客发布时已经推出)
React:高性能JS前端框架脸书出品:特点是提出了新概念* *[虚拟DOM]减少真实DOM操作,在内存中模拟DOM操作,有效提高前端渲染效率;缺点是使用起来比较复杂,因为需要额外学习一门【JSX】* *语言;
Vue:一个渐进的JavaScript框架。所谓循序渐进,就是逐步实现新特性,比如模块化开发、路由、状态管理等新特性。其特点是结合了Angular(模块化)和React(虚拟DOM)的优点。
Axios:前端通信框架;因为Vue的边界很明确,就是处理DOM,它不具备通信能力。此时,它需要使用一个额外的通信框架来与服务器进行交互。当然,你也可以直接选择使用jQuery提供的AJAX通信功能。
UI框架
蚂蚁设计:阿里巴巴出品,基于React的UI框架
元素,iview,ice:由饿了么出品,基于Vue的Ul框架。
bootstrap:Twitter推出的用于前端开发的开源工具包。
AmazeUl:又称“姐妹UI”,HTML5多屏前端框架。
JavaScript 构建工具
Babel:JS编译工具,主要用于浏览器不支持的ES新特性,比如编译TypeScript。
WebPack:模块打包器,主要用于顺序打包、压缩、合并、加载。
三端统一混合开发(Hybrid App)
主要目的是实现三端(PC,Android:apk,iOs:ipa)并且能够调用设备的底层硬件(比如传感器,GPS,摄像头等。).有两种主要的包装方法:
云封装HBuild -HBuildX,由DCloud出品;API云
当地包装:科尔多瓦(前PhoneGap)
微信小程序
具体可参考微信官网。下面是一个方便微信小程序UI开发的框架:WeUl。
后端技术
为了方便开发,前端人员还需要掌握一定的后端技术。但是我们Java后台人员都知道后台知识体系极其庞大复杂,所以为了方便前端人员开发后端应用,出现了NodeJS这样的技术。
NodeJS的作者已经声称要放弃NodeJS(说糟糕的架构加上笨重的node_modules可能会让作者不爽),开始用新的架构开发Deno。
既然是后台技术,肯定需要框架和项目管理工具。NodeJS的框架和项目管理工具如下:
Express:NodeJS框架
Koa:速成简化版
NPM:集成项目管理工具,类似于Maven。
纱:NPM的替代品,类似于Maven和Gradle的关系。
主流前端框架vue . j
iView
Iview是一个基于Vue的强大的ul库,拥有许多比elementui更丰富的实用基础组件,主要服务于PC界面的中后端产品。使用单个文件的Vue组件开发模式基于npm webpack babel开发,支持高质量、功能丰富、特性友好的ES2015 API,自由灵活地使用空间。
官网地址。
开源代码库
iview-管理
备注:属于前端主流框架,选型时可考虑使用,主要特点是移动端支持较多
ElementUl
Element是饿了么前端开源维护的Vue Ul组件库。组件齐全,基本涵盖了后台需要的所有组件。文档很详细,例子也很多。主要用于开发PC端页面,是一个高质量的Vue Ul组件库。
备注:属于前端主流框架,选型时可考虑使用,主要特点是桌面端支持较多
ICE
飞冰是阿里巴巴团队基于React/Angular/Vue的中后端应用解决方案。在阿里巴巴内部,已经有超过270个项目在使用几乎所有的BUs。飞冰包含了从设计端到开发端的完整链接,帮助用户快速搭建自己的中后端应用。
备注:主要组件还是以 React 为主
VantUl
Vanul是由有赞前端团队基于有赞统一规范实现的Vue组件库,提供了一套完整的ul基础组件和业务组件。通过Vant,可以快速搭建风格统一的页面,提高开发效率。
AtUl
At-ui是基于Vue 2.x的前端Ul组件库,主要用于快速开发PC网站产品。它提供了一套npm webpack babel前端开发工作流程,具有独立的CSS样式,即使采用不同的框架也能保持统一的UI风格。
CubeUl
Cube-ui是滴滴团队开发的基于Vue.js的精致移动组件库。支持按需导入和后编译,轻量灵活:可扩展性强,可以轻松实现基于现有组件的二次开发。
等等UI…
前端发展史
后端为主的MVC时代
向前端控制器(DispatcherServlet)发出请求
前端控制器请求HandlerMapping找到Handler,可以根据xml配置和注释找到。
处理器的handler映射将处理程序返回给前端控制器。
前端控制器调用处理器适配器来执行处理程序。
处理器适配器执行处理程序
处理程序执行完成,并将ModelAndview返回给适配器。
外部处理器适配器返回ModelAndView。ModelAndView前端控制器。ModelandView是SprineMvc框架的一个底层对象,包括模型和视图。
前端控制器请求视图解析器解析视图,根据逻辑视图名解析成真实视图(JSP)。
视图解析器将视图返回给前端控制器。
前端控制器执行视图呈现,视图呈现将模型数据(在ModelAndView对象中)填充到请求字段中。
前端控制器将结果响应给用户。
优点
MVC是一种非常好的协作模式,可以有效降低代码的耦合度,可以让开发者从架构上明白代码应该写在哪里。要让View更纯粹,还可以使用百里香、Freemarker等模板引擎,这样就可以不用在模板里写Java代码,前端和后端的分工更清晰。
缺点
前端开发严重依赖开发环境,开发效率低。在这种架构下,有两种前端协作模式:
首先是在前端写DEMO。写完后让后端设置模板。优点是DEMO可以在本地开发,效率很高,缺点是需要后端的那套模板,可能会出错。设定后需要前端确认,来回沟通调整的成本比较高。
另一种协作模式是前端负责浏览器端的所有开发和服务器端的视图层模板开发。好处是U相关的代码都是前端写的,后端不需要太在意。不好的是前端开发严重绑定到后端环境,成为影响前端开发效率的重要因素。
前后职责纠结:模板引擎功能强大,仍然可以通过获取的上下文变量实现各种业务逻辑。
这样只要前端比较弱,往往会被后端要求在模板层写很多业务代码。还有就是大灰的颜色。
应该是前端最关心的控制器、页面路由等功能,却被后端实现了。
控制器本身往往和模型纠缠在一起,让人咬牙切齿的业务代码会出现在控制器层。这些问题不能都归咎于程序员的素质,不然JSP就够了。
前端的限制:如果性能优化的空间只局限在前端,我们往往需要后端的配合。然而,由于t
早在2005年,Ajax(异步JavaScript和XML,旧技术新用法)正式提出,CDN作为静态资源存储,于是出现了JavaScript王者归来。
SPA(单页应用)的单页应用时代(在此之前用JS在网页上贴狗皮膏药广告)。
优点
在这种模式下,前端和后端的分工非常明确,前端和后端的关键协作点是AJAX接口。看起来好奇妙,但是回过头来看,和JSP时代差不了多少。复杂度从服务器端的JSP转移到了浏览器端的JavaScript,浏览器端变得非常复杂。类似于Spring MVC,这个时代开始在浏览器端看到一个层次架构:
缺点
前端接口的约定:如果后端接口一塌糊涂,后端业务模式不够稳定,那么前端开发会很痛苦:很多团队都做过类似的尝试,通过接口规则、接口平台等来做。有了后台存放的接口规则,还可以用来模拟数据,让前端和后端在约定接口后实现高效的并行开发。
前端开发的复杂度控制:SPA应用大多是交互式的,JavaScript代码超过10万行很正常。大量JS代码的组织以及与视图层的绑定都不是容易的事情。前端MV*时代
基于AJAX带来的SPA时代MVC(面向同步通信):模型、视图、控制器。
MVP(主要是异步通信):模型、视图、演示者
MVVM(主要是异步通信):模型、视图、视图模型
为了降低前端开发的复杂度,出现了大量的前端框架,如:Angular]s、React、Vue.js、Ember]s等。这些框架总的原则是先按类型分层,比如模板、控制器、模型,然后再分层,如下图:
优点
前后端职责很清晰
:前端工作在浏览器端,后端工作在服务器端。分工明确可以让开发并行,测试数据的模拟也不难,前端可以本地开发。后端可以专注于业务逻辑和输出接口(如RESTful)的处理。前端开发的复杂度可控:
前端代码繁重,但合理的分层让前端代码各司其职。这首曲子很有趣。像模板特性的选择这么简单,还有很多很多精致的。越强大越好。有哪些限制,还剩下哪些自由,代码应该如何组织。所有这些设计都得拿一本书的厚度来解释。部署相对独立
:产品体验提升快。缺点
代码不能重用。比如后端仍然需要对数据做各种检查,检查逻辑无法重用浏览器端的代码。如果可以复用,后端的数据验证可以相对简化。
全异步,对SEO不好。经常需要服务器做同步渲染的降级方案。
性能并不是最好的,尤其是在移动互联网环境下。
SPA不能满足所有要求,仍然存在大量的多页面应用。URL需要后端配合,前端无法完全掌控。
此处的 MV* 模式如下:基于上一段的MV*模式解决了很多问题,但如上所述,也有很多不足。随着NodeJS的兴起,JavaScript有了在服务器上运行的能力。这意味着有一种新的R&D模式:
在这种R&D模式下,前端和后端的职责是明确的。对于前端,两个UI层有各自的功能:
前端ui层处理浏览器层的表示逻辑。通过CSS渲染风格和JavaScript添加交互功能,HTML的生成也可以放在这一层,具体看应用场景。
后端Ul层处理路由、模板、数据采集、Cookie等。通过路由,前端最终可以自主控制URL设计,这样前端就可以自由控制是单页应用还是多页应用。最后,后端可以摆脱对表现的强烈关注,转而专注于业务逻辑层的开发。
通过Node,Web服务器层也是JavaScript代码,意味着部分代码可以前后复用,需要SEO的场景可以在服务器端同步渲染。过多异步请求导致的性能问题也可以通过服务器端来缓解。该模型几乎可以完美地解决前一模型的不足
与JSP模式相比,全栈模式看似是一种回归,确实是对原有开发模式的回归,但却是螺旋式的回归。
基于NodeJS的全栈模式仍然面临诸多挑战:
前端需要对服务器端编程有进一步的了解。比如TCP/IP等网络知识的掌握。
NodeJS层和Java层之间的高效通信。在NodeJS模式下,都是在服务器端,RESTful的HTTP通信可能效率不高,但是通过SOAP通信效率更高。一切都需要在验证中前进。
精通部署、运维,需要更多的知识点和实践经验。
如何过渡大量历史遗留问题?这可能是最大的阻力。
NodeJS带来的全栈时代本文到此为止。希望能帮到你,也希望你能多关注我们的更多内容!