前端路由与后端路由
2017-06-09 17:23
225 查看
说起前端框架,我个人主张有框架不如无框架,这个观点要先从框架和库的区别说起。
我所理解的库,解决的是代码或是模块级别的复用或者对复杂度的封装问题;而框架,更多的是对模式级别的复用和对程序组织的规范,这里的模式是指比如 MVC,为了实现 M 和 V 的解耦,通过 IOC 或是 PubSub 等手段,把丑陋的耦合由经常变化的业务代码转移到不经常变化的框架内部消化。
对于前端来说,在 WebApp 概念兴起前,很少能看到所谓的框架,更多的是类似于 jQuery、YUI 的库,因为前端的一路下来的发展历程和开发方式的特殊性决定了很难有什么通用的模式能满足多样化前端的开发需要。如果一定要说,也就是近些年伴随着
SPA(Single-page application)概念兴起而出现的所谓前端 MVC 的一系列衍生模式,但是即便如此,光靠一个框架还是解决不了什么问题。
这里要重点说一下 SPA 这个随着 AJAX 技术火起来的概念,SPA 的好处有哪些相信不用多说,网上一搜一大堆,接近原生应用的表现、和 HTML5 技术发展方向向契合等等。SPA 的出现让前端变得越来越重,代码组织、逻辑解耦等后端常常面对的问题也开始在前端出现,人们也开始在前端引入
MVC 去应对这样一些问题,确实很有成效。但是前端变重所面临的问题就仅仅是 JavaScript 层面的 MVC 能解决的吗?
我们来看前端开发的特点,HTML + CSS + JavaScript 三种不同类型的语言相互配合实现需求;再来看页面加载的特点,先加载 HTML,再有策略的加载 CSS 和 JS,碰到对性能要求较高的场景还要考虑分模块按需加载,在大型 SPA 中还有可能要把页面拆成一个个组件,每个组件又包含模板、样式、脚本,页面拆分成组件的策略是什么,组件的按需加载策略又如何,这些显然不是 MVC 框架擅长解决的问题,这也是 AMD/CMD 等模块机制提供者和加载器流行起来的原因。
近两年开始流行大前端的概念,我的理解这里的大前端说的就是前端的工程化,前端开发的工程特点开始和后端开发越来越像,这也给我们提供了更多的思路,框架解决不了的问题,是不是能像后端一样靠工具解决,过程中的模式(指类似的、重复性的工作)是否可以借助于持续集成工具实现自动化。回到刚才说到的前端组件化问题,代码在开发环境应该对开发人员友好,开发人员可以分工编写不同的组件,每个组件的模板、样式、脚本代码可以分别写在独立的文件中,分目录组织;代码在发布环境应该对用户友好,组件的代码应该根据策略打包成一个或多个文件并进行压缩,便于按需加载和节省流量。而这些正应该是工具要做的。
说到这里,其实框架对于程序组织的规范性上面的作用已经不明显,为了更灵活的模块化,不如不去用框架,把自定义事件的能力封装成模块,PubSub 模式解耦形成约定,用约定和书面规范代替框架去约束程序的组织,让开发人员直面框架的本质,充分发挥人的能动性,相信这才是更利于人才成长的实践方式。
最后提一下前端基础架构方面的一些思考,不要放大框架的作用,随着前端的成熟,工程化的特点会越来越明显,框架、库、工具、过程规范、文档这些东西的发展缺一不可,只有系统的结合才能发挥出技术的最大效能,在这样的平台上去实践、去积累,人才能更全面的发展。
我所理解的库,解决的是代码或是模块级别的复用或者对复杂度的封装问题;而框架,更多的是对模式级别的复用和对程序组织的规范,这里的模式是指比如 MVC,为了实现 M 和 V 的解耦,通过 IOC 或是 PubSub 等手段,把丑陋的耦合由经常变化的业务代码转移到不经常变化的框架内部消化。
对于前端来说,在 WebApp 概念兴起前,很少能看到所谓的框架,更多的是类似于 jQuery、YUI 的库,因为前端的一路下来的发展历程和开发方式的特殊性决定了很难有什么通用的模式能满足多样化前端的开发需要。如果一定要说,也就是近些年伴随着
SPA(Single-page application)概念兴起而出现的所谓前端 MVC 的一系列衍生模式,但是即便如此,光靠一个框架还是解决不了什么问题。
这里要重点说一下 SPA 这个随着 AJAX 技术火起来的概念,SPA 的好处有哪些相信不用多说,网上一搜一大堆,接近原生应用的表现、和 HTML5 技术发展方向向契合等等。SPA 的出现让前端变得越来越重,代码组织、逻辑解耦等后端常常面对的问题也开始在前端出现,人们也开始在前端引入
MVC 去应对这样一些问题,确实很有成效。但是前端变重所面临的问题就仅仅是 JavaScript 层面的 MVC 能解决的吗?
我们来看前端开发的特点,HTML + CSS + JavaScript 三种不同类型的语言相互配合实现需求;再来看页面加载的特点,先加载 HTML,再有策略的加载 CSS 和 JS,碰到对性能要求较高的场景还要考虑分模块按需加载,在大型 SPA 中还有可能要把页面拆成一个个组件,每个组件又包含模板、样式、脚本,页面拆分成组件的策略是什么,组件的按需加载策略又如何,这些显然不是 MVC 框架擅长解决的问题,这也是 AMD/CMD 等模块机制提供者和加载器流行起来的原因。
近两年开始流行大前端的概念,我的理解这里的大前端说的就是前端的工程化,前端开发的工程特点开始和后端开发越来越像,这也给我们提供了更多的思路,框架解决不了的问题,是不是能像后端一样靠工具解决,过程中的模式(指类似的、重复性的工作)是否可以借助于持续集成工具实现自动化。回到刚才说到的前端组件化问题,代码在开发环境应该对开发人员友好,开发人员可以分工编写不同的组件,每个组件的模板、样式、脚本代码可以分别写在独立的文件中,分目录组织;代码在发布环境应该对用户友好,组件的代码应该根据策略打包成一个或多个文件并进行压缩,便于按需加载和节省流量。而这些正应该是工具要做的。
说到这里,其实框架对于程序组织的规范性上面的作用已经不明显,为了更灵活的模块化,不如不去用框架,把自定义事件的能力封装成模块,PubSub 模式解耦形成约定,用约定和书面规范代替框架去约束程序的组织,让开发人员直面框架的本质,充分发挥人的能动性,相信这才是更利于人才成长的实践方式。
最后提一下前端基础架构方面的一些思考,不要放大框架的作用,随着前端的成熟,工程化的特点会越来越明显,框架、库、工具、过程规范、文档这些东西的发展缺一不可,只有系统的结合才能发挥出技术的最大效能,在这样的平台上去实践、去积累,人才能更全面的发展。
相关文章推荐
- 关于前端路由和后端路由的一点思考
- 前端路由与后端路由
- 技术选型 — 关于前端路由和后端路由的个人思考
- 前端路由与后端路由
- 前端路由与后端路由
- 4.前端基于react,后端基于.net core2.0的开发之路(4) 前端打包,编译,路由,模型,服务
- Nginx配置实现前端Route路由与后端路由的分离
- Nginx前端设置反向代理,后端Apache如何获取访客的真实IP,结合PHP
- 前端和后端的输入合法性验证
- 前端后端分离,怎么解决SEO优化的问题呢?
- [后端人员耍前端系列]AngularJs篇:30分钟快速掌握AngularJs
- 前端和后端交互的一些原规范问题
- Sharepoint页面项目展示画廊纯前端实现,后端用list/library简单维护
- 前端(前台)工程师和后端(后台)工程师的区别
- 购物车Demo,前端使用AngularJS,后端使用ASP.NET Web API(3)--Idetity,OWIN前后端验证
- java从前端到后端的json处理
- 写给后端的前端笔记:浮动(float)布局
- ASP.NET MVC 前端(View)向后端(Controller)中传值
- Nginx 负载均衡 后端服务器获取前端用户真实IP
- 前端获取后端数据当key为数字或者为数字字符串的时候