我们先来截个图看一下
第一个是后端渲染，第二个和第三个是前端渲染。
nuxt是后端渲染，通俗来说：优点：首屏加载快 seo友好，坏处是更吃服务器资源，并发会受到影响。举例来说：原本并发3000 后端渲染估计会降到200。
以上是个人通俗解释，下面是从网上找来的解释，希望大家可以了解更清晰。
后端渲染（SSR、服务端渲染）
后端渲染HTML的情况下，浏览器会直接接收到经过服务器计算之后的呈现给用户的最终的HTML字符串，这里的计算就是服务器经过解析存放在服务器端的模板文件来完成的，在这种情况下，浏览器只进行了HTML的解析，以及通过操作系统提供的操纵显示器显示内容的系统调用在显示器上把HTML所代表的图像显示给用户。
前端渲染（SPA、单页面应用）
前端渲染就是指浏览器会从后端得到一些信息，这些信息或许是适用于题主所说的angularjs的模板文件，亦或是JSON等各种数据交换格式所包装的数据，甚至是直接的合法的HTML字符串。这些形式都不重要，重要的是，将这些信息组织排列形成最终可读的HTML字符串是由浏览器来完成的，在形成了HTML字符串之后，再进行显示。
题主所提到的几个技术，我认为模板这个词语并不能用来区分这些技术的本质，模板只是一种提供给程序来解析的一种语法，换句话说，模板是用于从数据（变量）到实际的视觉表现（HTML代码）这项工作的一种实现手段，而这种手段不论在前端还是后端都有应用。
以下为本人自己的想法：在性能上，我认为后端渲染最终会被前端渲染，因为后端渲染将所有的HTML生成集中在了一个服务器上，而前端渲染将这部分工作分发到各个终端上。另外，对于开发而言，这样能够避免后端开发人员过多的编写HTML代码，后端开发人员只需和前端开发事先商定好数据格式，后端就只需将数据生成，用数据交换格式包装，再发送出去就可以了，这样能够使开发人员之间的分工更加明确。
再附上稀土掘金上的一段理解：
SEO
很重要，所以要普及。
SEO： 搜索引擎优化（Search Engine Optimization），它是指通过站内优化，如：网站结构调整、网站内容建设、网站代码优化以及站外优化等方法，来进行搜索引擎优化。
简单说： 通过各种技术（手段）来确保，你的Web内容被搜素引擎最大化收录，最大化提高权重，带来更多流量。
常见关键词：白帽、黑帽、SEM、Backlink、Linkbait、PageRank、Keyword Stuffing...，总之都围绕着一个核心：SEO；流量是变现的快车道，SEO是低成本获取流量的最佳方法。
SPA
SPA：单页Web应用（single page web application，SPA），就是只有一张Web页面的应用，是加载单个HTML 页面并在用户与应用程序交互时动态更新该页面的Web应用程序。
简单说： Web不再是一张张页面，而是一个整体的应用，一个由路由系统、数据系统、页面（组件）系统...组成的应用程序，其中路由系统是非必须的。
大部分的Vue项目，本质是SPA应用，Angular.js、Angular、Vue、React...还有最早的"Pjax"均如此。
SPA时代，主要是在Web端使用了history或hash（主要是为了低版本浏览器的兼容）API，在首次请求经服务端路由输出整个应用程序后，接下来的路由都由前端掌控了，前端通过路由作为中心枢纽控制一系列页面（组件）的渲染加载和数据交互。
而上面所述的各类框架则是将以：路由、数据、视图为基本结构进行的规范化的封装。
最早的SPA应用，由Gmail、Google Docs、Twitter等大厂产品实践布道，广泛用于对SEO要求不高的场景中。
SSR
SSR： 服务端渲染（Server Side Render），即：网页是通过服务端渲染生成后输出给客户端。
在SPA之前的时代，我们的Web架构大都是SSR，如：Wordpress（PHP）、JSP技术、JavaWeb...或者DEDECMS、Discuz!等这些程序都是传统典型的SSR架构，
即：服务端取出数据和模板组合生成html输出给前端，前端发生请求时，重新向服务端请求html资源，路由也由服务端来控制。
其次，有个概念叫预渲染（Prerendering）。
如果你只是用服务端渲染来改善一个少数的营销页面（如 首页，关于，联系 等等）的SEO，那你可以用预渲染来实现。
预渲染不像服务器渲染那样即时编译HTML，它只在构建时为了特定的路由生成特定的几个静态页面，等于我们可以通过webpack插件将一些特定页面组件build时就编译为html文件，直接以静态资源的形式输出给搜索引擎。
但实际的商业应用中，大部分时候我们需要的是即时渲染，这也是我们今天讨论的主题。
Why
为什么要SSR，为了体验，还有SEO。
首先，用户可能在网络比较慢的情况下从远处访问网站 - 或者通过比较差的带宽。 这些情况下，尽量减少页面请求数量，来保证用户尽快看到基本的内容。
可以用Webpack的代码拆分避免强制用户下载整个单页面应用，但是，这样也远没有下载个单独的预先渲染过的HTML文件性能高。
对于世界上的一些地区人，可能只能用1998年产的电脑访问互联网的方式使用计算机。
而Vue只能运行在IE9以上的浏览器，你可能也想为那些老式浏览器提供基础内容 - 或者是在命令行中使用 Lynx的时髦的黑客。
在大部分的商业应用中，我们有SEO的需求，我们需要搜索引擎更多地抓取到我们的内容，更详细地认识到我们的网页结构，而不是仅对首页或特定静态页进行索引，这是SSR最重要的意义。
且，我们还需要在SSR的基础上实现SPA，即：首屏渲染。
基本流程是：
在浏览器第一次访问某个URI资源的时候（首屏），Web服务器根据路由拿到对应数据渲染并输出，且输出的数据中包含两部分：
- 路由页对应的页面及已渲染好的数据
- 完整的SPA程序代码
在客户端首屏渲染完成之后，此时我们看到的其实已经是一个和之前的SPA相差无几的应用程序了，接下来我们进行的任何操作都只是客户端的应用进行交互，
页面/组件由Web端渲染，路由也由浏览器控制，用户只需要和当前浏览器内的应用打交道就可以了。
之前在各大SPA框架还未正式官方支持SSR时，有一些第三方的解决方案，如：prerender.io，
它们做的事情就是建立HTTP一个中间层，在判断到访问来源是蜘蛛时，输出已缓存好的html数据，此数据若不存在，则调用第三方服务对html进行缓存，往复进行。
另一方法是自行构建蜘蛛渲染逻辑，当识别UA为搜索引擎时，拿服务端已准备好的模板和数据进行渲染输出html数据，反之，则输出SPA应用代码；
我当时也考虑过此方法，但有很多弊端，如：
需要针对蜘蛛编写一套独立的渲染模板，因为大部分情况下SPA的代码是没法直接在服务端使用的
搜索引擎若检测到蜘蛛抓取数据和真实访问数据不一致，会做降权惩罚，也就意味着渲染模板还必须和SPA预期输出一模一样
所以，最好的方法是SPA能和服务端使用同一套模板，且使用同一个服务端逻辑分支，再简单说：最好Vue、Ng2...能直接在服务端跑起来。
于是，陆续诞生了基于React的Next.js、基于Vue的Nuxt.js、Ng2诞生之日便支持。
没错，Nuxt.js就是今天的主角。