同构JavaScript应用以及前后端分离

同构JavaScript应用

就是在浏览器客户端和Web应用服务器端间共享同一套JavaScript代码的应用
简单的说，就是可以运行客户端和服务器端的JavaScript应用程序，后端和前端共享相同的代码

后端渲染指传统的 ASP、Java 或 PHP 的渲染机制；
前端渲染指使用 JS 来渲染页面大部分内容，代表是现在流行的 SPA 单页面应用；
同构渲染指前后端共用 JS，首次渲染时使用 Node.js 来直出 HTML。一般来说同构渲染是介于前后端中的共有部分。
前后端同构出现的原因是现在流行的SPA前端单页面应用比较沉重，首次访问需要加载文件较多，第一次加载过慢，用户需要等待前端进行渲染页面。而且不利于SEO及缓存，并且有一定的开发门槛。

前后端同构通过复用模板和JS文件，让一份代码可以同时跑在服务器和浏览器，首次渲染使用nodejs渲染页面，之后使用SPA路由跳转。可以有效减少用户首次访问的等待时间，并且对SEO比较友好，也便于缓存。

【SEO:搜索引擎优化,是一种透过了解搜索引擎的运作规则来调整网站，以及提高目的网站在有关搜索引擎内排名的方式。搜索引擎优化是任何一个网站想要在网站推广中获取成功至为关键的一步，其最终目的是做好用户体验。】

1.传统的Web应用

所有的标记——至少是关键渲染路径的标记——是通过服务器使用某种服务器端语言（如PHP、Ruby、Java等）进行渲染的，浏览器解析文档后，用于丰富用户体验的JavaScript代码会被初始化。

2.单页面Web应用（SPA)

3.同构JavaScript应用

同构JavaScript应用是传统Web应用和SPA架构的完美结合。
同构应用具备以下优势：
1、SEO默认支持使用完全合法的URL——不再需要“#!”的变通方案了——通过History API进行跳转，在不支持His-tory API的浏览器中可以优雅地回退到服务器端渲染模式。

2、在支持History API的浏览器中，后续的页面请求使用了SPA模型的分布式渲染。这种实现还可以减轻服务器的负载。 * 对于同一个渲染周期，客户端和服务器端可以重用同一套代码。这意味着我们不需要重复劳动，也不会让界限变得模糊。这可以在降低UI开发成本与bug数量的同时，提高团队的开发速度。

3、通过在服务器端渲染首屏页面提高加载速度。用户不再需要在首屏渲染之前等待网络请求完成和一直看着加载指示器动画了。

4、纯JavaScript技术栈，这意味着应用界面的代码可以由前端工程师单独维护，而无须经过后端工程师。

参考链接：https://www.jianshu.com/p/948ff42c95fb

前后端分离

首先前后端分离并不完全等于SPA
就我个人看法，发展流程应该是这样的
传统的Web应用–>单页面Web应用（SPA)–>同构–>前后端分离

前后端分离并没有网上说的那么复杂。

1.首先要知道所有的程序都是一数据为基础的，没有数据的程序没有实际意义，程序的本质就是对程序的增删改查。

2.前后端分离就是把数据操作和显示分离出来。前端专注做数据显示，通过文字，图片或者图标等方式让数据形象直观的显示出来。后端专注做数据的操作。前端把数据发给后端，有后端对数据进行修改。

3.后端一般用java，c#等语言，现在的node属于JavaScript也能进行后端操作，此处不意义裂解语言。后端来进行数据库的链接，并对数据进行操作。

4.后端提供接口给前端调用，来触发后端对数据的操作。

基本原理就是这样，可能语言上不准确，思想是没有问题的。

所以开发网站的核心现在基本上就是：

html + css ：页面展示

javascript + ajax（这个算是浏览器的一部分，可以通过 javascript 调用） : 页面交互、逻辑处理

通常的开发框架选择：

简单网站： jquery + bootstrap

后台管理系统： angularjs + jquery + bootstrap + webpack

复杂的产品： react + redux + webpack

链接：https://www.jianshu.com/p/fa257d439d74

前后端分离解析

从通常意义来讲，说到必须，就是指最佳实践上，实现前后端分离，最好的方案就是SPA。
所以才会有 前后端分离=SPA 的近似，忽视了其中的差别。
但是，既然有疑问了，我们就来看一下，为什么SPA是实现前后端分离的最佳实践。
先从前后端不分离开始，2010年前后，主流的方案，还是前后端不分离，以JSP为例，所有的请求，都是发送到服务器端，服务器端生成整个页面，再返回给浏览器。

1、这么做的好处是什么呢？就是服务器端可以缓存整个页面，做静态化，访问的时候，都不用访问数据，那时候读取数据和缓存还比较少，很多时候，缓存的失效都很难处理，页面静态化很容易，多数论坛都选择用这种方式处理问题。
2、坏处是什么呢？就是每一次，传输的数量量太大了。包括了整个Html页面，还有CSS，还有JS。而网络传输速度，又没有想像中的那么快。

所以，在当时的场景下，要解决的问题就是，如何提升性能？一般有两种方式，一个是提升服务器的响应时间，一个是压缩传输文件。如果一个网页是500K，压缩到250K，时间会减少多少？emmm，跟服务器带宽有关系，不考虑用户带宽的情况下，可以算一下，服务器1兆的带宽，传输500K和传输250K需要的时间是怎么样的，我反正算这个一直很头晕。

但是，结论很清楚，后端的优化，其实都比不上传输文件大小的优化。而且，真的每一次都要传送这么多内容么？
我们来看一下一个Html文件的结构。包含了三部分Html，CSS，JS，然后就是数据。
抛开数据不谈，CSS和JS一般都用外联文件，来利用浏览器的缓存机制，节省传输时间。那Html的部分呢？

我们打开一个网页，通常都是有菜单栏，侧边栏，底部这些，这些每一个网页只是正文切换有变化，我们为什么要把这些Html加载过来一遍又一遍呢？能否把不变的部分留着，只加载变动的内容？有的，这就是Ajax。

有了Ajax，就可以在访问相同结构的网页的时候，只加载数据就好了。这样，就解决了数据的问题。这种情况也持续了很多年，但是大家还是觉得很不爽。
原因有两个。一个是，就算是有Ajax了，前端代码和后端代码的耦合度还是很高。特别是后端那群理工男，压根理解不了半点儿CSS，套个页面经常把样式弄混。前端要改东西，还要跑后端环境。协作效率太低了。

另一个就是，页面的跳转控制权通常在后端那里，而使用Ajax之后，前端在某种程度上，也有了控制权，所以，什么样的链接应该后端跳转，什么样的链接应该前端跳转？太混乱了，分不清。这个时候，App突然出现了。

在使用App的时候，后端程序员突然觉得好爽，我只需要提供数据就好了，压根不用管跳转。你给我接口，我给你数据，简单干净。App程序员也很爽，自己搭页面，就和后端调个数据，后端没数据，也可以自己Mock，根本不用等他们了。

可是这个时候，很多应用都是又有App，又有网站，导致后端程序员很烦燥，一边要写一个前后端不分离的页面，一边还要写一个独立的数据接口，如果有需求变动，那简直了。。。

所以，能否网页也和App一样，完全通过数据交互来处理？这就是前后端分离，本质上来讲，App是彻底的前后端分离。

现在，答案很清楚，是可以的。那么，既然App和网页都是前后端分离，为什么只有网页有SPA的概念，而App中很少听到有提起过？SPA又为什么是前后端分离的最佳实践？

再回过头来看，我们之前说过的，为了减少网络传输，出现Ajax的事情。本质上，这种设计理念的原则就是，复用一切可以复用的内容。同样的，这种理念，落地实践上，就有了模板的概念。就是一个概念，我把它先切割成几个部分，像刚刚所说的，头部，菜单，左侧边栏，右侧边栏，底部等等等。如果我这么切割了，理论上来说，前端就只需要一个页面就足以完成整个网站的内容了。

哪里的内容需要更新，我就替换哪里的内容嘛。这是SPA的由来，好处就是，尽可能的减少了模板中重复内容的获取。因为是网页，模板本身还是要从服务器端来读，所以肯定是越少越好。

但是实际上，一个网站的布局模板很多，几乎一个子模块一个。在这种情况下，所谓的单页面，在某种程度上，也算是多页面，但是还是把公共的内容可以抽取出来，当成是一个大的模板。前端实现了SPA，最方便最好用的，就是跳转控制权完全在自己这里了，所有的页面都可以统一管理。

App端本身的页面，都是存在用户的手机本身，不存在远程加载问题，所以对于SPA的需求没有那么强烈。

但实际上来说，整个App也可以遵循SPA的方式去构建和管理。所以，如果你是前后端分离，要解决的就是复用内容和页面模板的管理问题，在这个基础上，目前的SPA框架做的很好。如果说你要前后端分离，又非不用SPA。。。怎么解决相同的Html重复加载问题呢？如果你手动用JQuery来解决了，说明你是用JQuery重复发明了一套SPA的轮子，而且还未必有现成的好用

作者：暗灭
链接：https://www.zhihu.com/question/352047943/answer/993693504