Seija
首页
Travellings
登录
注册
首页
文章
Web的前端渲染和WebApi
之前的html渲染都是服务器完成的,页面的变化主要通过跳转到不同的页面实现的.可能个别页面会通过JavaScript和Ajax实现一些动态的功能但还是以服务器渲染为主的. 但是: * 随着Web的逐渐复杂,传统的jQuery显的越来越简陋. * Flash的逐渐退出导致复杂的客户端没有可以使用的解决方案. * 移动端的出现,WebApi概念的提出,服务器端的良好设计变成了平台无关的,渲染需要交给各个平台自己去渲染. 这个时候前端渲染和WebApi需求就应运而生了. 使用前端渲染会得到这些好处: * 丰富的UI引擎生态,无论是通过组件化或者模板或者渲染函数等概念,使前端的UI变成了真正合理的UI结构了,要知道之前的服务器渲染引擎可是十分原始的.能提供html块重用的就算很不错的了. * 使用WebApi可以给所有平台之编写一份服务器代码.服务器实现了和具体交互对象的完全剥离.这个前端可以是PC网站,手机网站,甚至手机App,桌面应用.对服务器都是完全没有影响的. * 减轻服务器的渲染负载 * 可以实现全程无刷新 *
创造工作岗位,让只写JavaScript可以说自己是程序员
但是这里不得不提一下,前端渲染的问题: * SEO问题.其实之前的Flash富客户端也有这个问题. * 首屏加载速度.浏览器需要把你的所有JavaScript文件下载下来之后,然后再通过你的渲染引擎,将你的所有UI元素都通过JavaScript动态创建出来.如果你的JavaScript文件很大或者你的渲染引擎效率不高这个问题会特别明显.同样的Flash也有这个问题,我们之前见到的Flash页面一进入都会走一个Loading条. *
前端框架群魔乱舞,奇技淫巧遍地横飞,在这之中进行选择一不小心就会掉坑
#### 前端渲染和WebApi的优点和缺点 这是一个很麻烦的问题,我们慢慢讨论一下. 如果单纯的剥离上下文,说提供一种只传输纯粹数据的HTTP接口是否是合理的呢? 很显然这是没有什么问题的做法. 但是挂载上Web这个上下文呢? 对比一下传统Web的方案,和WebApi Web的方案: 传统方案: ServerLogic -> (PCRender,MobileRender) -> HTTP网络 -> 浏览器 -> (PCView,MobileView) WebApi方案: ServerLogic -> Web API -> HTTP网络 -> 浏览器 -> (PCRender,MobileRender) -> (PCView,MobileView) 对比一下这两者的不同点一个是WebApi+前端渲染一个是后端渲染.除了渲染不同之外前端渲染还多了一个层WebApi层. 渲染端的不同:前端渲染要正确一些,服务器不应当承载渲染这种逻辑无关的操作. 多出来的WebApi层:这是前端渲染附带的代价,由于Server和Client之间隔着网络,不能直接操作服务器的数据,所以需要多出一个通用的中间层进行交互. 单从以上的不同来看,前端渲染要合理的多. #### 前端渲染的问题 **启动慢** 但是问题在这个HTTP网络和浏览器上. 现在的应用之所以逐渐Web化是因为Web应用不需要单独下载客户端,数据和脚本从网络上拉取,运行他们就可以显示出页面来.但是这么做的代价呢? 代价就是这个下载数据和脚本的开销.和浏览器这个中间层解析运行脚本的的开销. 这似乎是一个无解的问题,**你不可能既要原生应用的加载速度和运行速度,又要Web应用的即开即用**. 传统的服务器端渲染这个问题不明显是因为页面在服务端渲染好了,网络只传输该传输的部分. 这个时候要提一下SSR了 他的结构是:ServerLogic -> Web API -> RenerServer (PCRender,MobileRender) -> HTTP网络 -> 浏览器 -> (PCView,MobileView) 我认为这完全是一个错误的设计,如果你要服务器端渲染就不需要WebApi,更不应该分成多个进程,这样只会徒增好几个中间层,把简单的问题变复杂. 所以说这还是一个取舍问题,你要减轻服务器负载,要干净纯粹的服务器,那么你的客户端就不能加载的那么快.你要把渲染写到服务器那么你的服务器就不会完全是一个纯粹的逻辑服务器了. 其实我倒觉得服务器内部的合理结构设计也可以使逻辑和渲染分离 例如这样: Server (Logic -> CommonRoute -> (PCHTMLRender,MobileHTMLRender,JsonRender)) -> HTTP网络 -> 浏览器 -> (PCView,MobileView) 这样采用服务器端渲染相对于前端渲染的缺点就只有服务器负载问题了.
所以ASP.Net天下第一?
**SEO** 至于SEO的问题,我想这是搜索引擎的问题而不是应用的问题.Google是可以收录前端渲染的应用的页面的.不能收录的搜索引擎需要升级了. #### 总结 仔细一讨论的话,由于Web应用的固有问题限制,我发现前端渲染好像没有提供什么绝对的好处
除了增加前端工作岗位
,反而加深了Web应用的一些问题. 如果你愿意通过服务器的负载来换取应用的加载速度的话,其实对传统服务器端渲染的服务器端结构进行一些升级是最好的解决方案.
我想现在前端渲染能够兴起很大一部分原因是,服务器端的模板引擎都太TM烂了
登录
登录
注册
最热文章
引擎中Template DSL的设计思考总结
10-19
ReaderT 设计模式
04-23
非主流引擎开发不出来 (n+1) : purescript侧结构设计
04-04
FRP系统的设计
03-17
非主流引擎开发不出来 (1) : 轻骨架
02-11
非主流引擎开发不出来 (0) : 引擎定位
12-09
Rust的ECS库specs
11-20
Haskell类型类高级扩展详细说明
05-31
CMake 速览
05-29
尼采导读:超人与永恒轮回
02-24
为什么elm的结构并不是最合理的?
02-20
React速览
02-20
尼采命运之爱
02-18
AspNetCore 速览
02-17
由Haskell和面向对象引出的关于抽象的思考
12-26
二进制文件压缩工具upx
12-24
Reflex介绍
12-17
Web的前端渲染和WebApi
12-16
前端FRP框架深度踩坑
12-16
Yesod - RESTful (11)
12-16
链接
github
gitee