前端模板引擎（想写一个web应用，有没有前端框架和后端php框架推荐）

本文目录

• 想写一个web应用，有没有前端框架和后端php框架推荐
• php开发，是否大多数公司都用模板引擎
• PHP模版引擎和框架有什么区别，各有什么用
• 转行Web前端工程师怎样学习
• 你最喜的前端编译器，说出你的理由
• 为什么现在又流行服务端渲染html

想写一个web应用，有没有前端框架和后端php框架推荐

如果是小白，推荐框架thinkphp3.2或者5.0的版本，毕竟连注释都是汉字，更适合小白，如果是想写接口式的，那就用5.0点版本，更适合前后端分离，如果有基础的话，又希望快速，推荐使用yii2，毕竟所有的基本crud都可以通过gii生成，然后少写代码，前端如果不懂框架就直接用后端框架自带的模板引擎，直接在页面中输出，如果非得用前端框架，推荐使用Vue框架

php开发，是否大多数公司都用模板引擎

我们公司改版之前就是用的smarty ，实话说确实挺好用的，不过PHP用来处理模板引擎真的效率不咋地。

1。IO速度太慢了。有几次压测的瓶颈都在模板渲染这一步卡住了，虽然有缓存，但是有了缓存反而有更大的问题，就是缓存失效…当你们项目有了集成推送环境，你就失去了线上甚至测试服务器的权限，等待缓存失效，将是一个噩梦…

2。smarty继承很好用，但是很容易变成滥用。不止smarty，还有别的引擎都有这个功能，确实节约很多时间，但是这会造成所有项目都会继承公共模板。以后有需求迭代，要在头部加个东西，随便谁都去改头部，容易出问题，无法集中管理。

3。smarty的函数很好用，但是让前端变得像PHP工程师…有些时候可以靠前端自己写smarty函数拼接一些字符串无可厚非，但是PHP不愿意做的，前端可能直接smarty函数就搞定了…一个smarty模板文件越来越臃肿…

综上所述，楼主使用模板引擎一定三思，制定好规范，考虑到踩坑，不要项目形成规模了再来后悔。

PHP模版引擎和框架有什么区别，各有什么用

模板引擎是一个过气的技术，当初写模板引擎作者的初衷就是前后分离，让视图页面中不夹杂PHP代码，好让前端开发者自己整合视图页面，但是理想很丰满，各种各样的模板引擎不同的语法无疑提高了前端的学习成本，而学一个模板引擎语法本身对自身价值提高不大导致整合视图页面的还是PHP程序员，但PHP程序员写模板引擎的语法又显得很累赘（模板引擎的视图最终还是会转换成PHP代码），所以模板引擎现在来看是一个很鸡肋的技术，唯一的作用大概就是页面缓存了，况且现在真正的前后分离趋势越来越流行，模板引擎的地位就愈加不堪了。

框架就是整合了很多常用功能的基本架构，一般包含ORM，事件驱动，模板引擎，减少开发者重复造轮子的时间，提高开发效率。

转行Web前端工程师怎样学习

1. 学习基础: HTML, CSS, Javascript

2. 掌握流行框架: Vue, Bootstrap, Webpack, EasyUI, ...

3. 上GitHub学习优秀开源项目和代码

4. 多总结经验写博客，上GitHub开项目

5. 多混圈子，保持技术更新，交换心得

你最喜的前端编译器，说出你的理由

前端有编译器？前端的编译顶多就是用babel将es6/7编译成es5，将ts编译成js吧？

前端一般只要一个器就够了。我就简单说说我用过的几个器的优缺点。

DW

这种古董级别的东西就不要拿出来谈了，已经要淘汰的了。

SublimeText3

首推。

优点：

1. 免费试用，当然，免费版有弹窗。
   
2. 轻量级。基本上我所有用过的电脑都会安装，就算是最差劲的速龙XII 打开也只需要2s。
3. 大量的插件。st3的插件可以说是海量的，基本上能想到的都有。
4. 大量的主题。默认的主题比较丑，跟任何系统都不搭。但是使用了flat主题的st3，可以和使用了flat主题的Ubuntu完全融合在一起。不像windows下面，顶部还有一条又白又丑的菜单栏。
5. minimap。用过都说nice、

缺点：

1. 插件安装方式难度较大。没有图文说明，只有名字和简介，一切需要自己去摸索。
2. 配置主题，插件等，基本上都要通过去修改设置json文件，而且字段名，键值要完全匹配才可以生效，对于新手来说，不友好。
3. 默认主题太丑了，必须安装主题，而且有时候主题要更新的时候，就会出现各种未知的bug。

首推的原因：下面几个器的sftp插件，都是针对当前打开的整个项目而言的，二sublimetext3下的sftp插件，是可以单独配置到某个文件夹，这样我就可以同时打开多个项目，并且每个项目都可以配置上传信息。如果atom或者vscode也有同样的插件，请告知，谢谢。

Atom

免费开源，强大。

优点：

1. 免费开源。
2. 庞大的插件系统。
3. GUI配置器和插件功能。
4. UI美观。

缺点：

1. 太臃肿了，一个器400MB，打开太慢了。我的是6700HQ+16G内存，nvem的固态，打开需要5s。而且在windows下，这货是自动安装到C盘的。
2. 插件太难安装了，被墙了，没办法。windows下面各种失败。
3. 优化不太好，有时会卡顿。

使用原因：好看。

VS Code

免费，轻量级。

优点：

1. 轻量级。
2. 插件很好找，很好安装。
3. UI不错。
4. 自带很多功能性很强的插件。

缺点：

1. 快捷键和st3不太一样，用惯了st3很难适应过来。
2. 没了。

总的来说，这个器真的很不过，但是不知道为什么就是用起来很别扭。

Brackets

免费，轻量级

体验一般般，没怎么用过，好像自带一个静态文件的服务器，插件也是各种装不上。然后就删掉了。

WebStorm

功能强大，堪称神器。

但是以前没换MBP的时候，电脑配置不行，带不动，打开要差不多半分钟，而且要钱，于是乎没怎么深用就卸掉了。但是各个前端工程师都说是神器。我也没怎么用过，不评价。

HBuilder

前端神器，还能打包APP。

没错，下载下来就是用来玩打包成APP的。之前在windows下用过，用来写JS真的soso的。那个代码提醒功能，简直是弱智都能写。而且还可以一键选择用Chrome还是FF还是IE打开，多浏览器调试挺方便的。但是仅限于JS，其他语言支持度几乎为0。而且，该器好像是基于eclipse开发的，所以你懂的，eclipse的卡顿和慢各种缺点全部继承过来了。还有对Mac的retina屏支持不好，发虚。

为什么现在又流行服务端渲染html

题主有点搞错了,现在的服务端渲染跟以前的服务端渲染是完全不一样的.

首先介绍一下以前的传统模式:服务端渲染,代表是PHP这类,那时候前端只是写网页的,偶尔写点ajax,但是不多,大部分靠服务器查找数据然后渲染出来页面发送给浏览器展示,每次跳转都要从新执行一遍这个逻辑.因此挺消耗服务端的资源的.

后来H5出来后才有所改观,单页应用也逐渐兴起,Nodejs使前端可以脱离浏览器,进军服务器写后端代码.

非常多的人按捺不住内心的激动,终于不被人称为“切图仔“了,而且前端人群非常的多,此时我写这个回答的时候,NPM上的包就已经有654,218个了!

移动端开始兴起,网站的加载速度也开始变得重要,各个网站也开始考虑用户的感受,如果能降低用户的流量成本,就能使用户更快的进入页面,停留的时间也就更久,更能为公司带来经济效益,因此这变得越来越重要.

如果还是以前的传统方式,每次跳转都要重新加载页面下载数据,那么用户肯定受不了等待从而离开,损失是非常严重的,因此这时候的人瞄准了H5,使用H5构建的单页应用开始越来越多,只需要加载一次网页,后面就不需要再次下载,而且还可以做缓存,减少用户的流量费用.

但是前端很快发现了一个严重的问题,爬虫是不认js的,也就是说你无法给自己的网站做SEO.

SEO 搜索引擎优化是一种利用搜索引擎的搜索规则来提高目前网站在有关搜索引擎内的自然排名的方式.当百度或者其他搜索引擎的爬虫来到你的网站的时候,它发现这里面什么东西都没有,就只有一些css和js资源连接,但是它并不执行你的js,因此是无法获取到你的网站信息的,它就无法记录你的网站信息,用户使用搜索引擎的时候也就无法查询到关于你网站的数据信息,这是很严重的问题,你的网站流量会断崖式下跌.

因此针对这个问题,前端想到了一个预处理方案:服务器端渲染(SSR).

前端使用Nodejs搭建服务器,然后在用户访问的时候预先执行一些页面中js的逻辑,渲染成HTML,将它们直接发送到浏览器,很多流行的开源前端框架已经集成了这类方式,比如Vue.js,React.js,Angular.js等等.

与传统 SPA（Single-Page Application - 单页应用程序）相比，服务器端渲染(SSR)的优势主要在于：

1.更好的 SEO，由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面。如果 SEO 对你的站点至关重要，而你的页面又是异步获取内容，则你可能需要服务器端渲染(SSR)解决此问题。

2.更快的内容到达时间，特别是对于缓慢的网络情况或运行缓慢的设备.无需等待所有的 JavaScript 都完成下载并执行,才显示服务器渲染的标记，所以你的用户将会更快速地看到完整渲染的页面.通常可以产生更好的用户体验,并且对于那些时间就是金钱的应用程序而言,服务器端渲染(SSR)至关重要。

使用服务器端渲染(SSR)时还需要有一些权衡之处:

1.涉及构建设置和部署的更多要求.与可以部署在任何静态文件服务器上的完全静态单页面应用程序(SPA)不同,服务器渲染应用程序,需要处于 Node.js server 运行环境.

2.在 Node.js 中渲染完整的应用程序，显然会比仅仅提供静态文件的 server 更加大量占用 CPU 资源,因此如果你预料在高流量环境下使用,请准备相应的服务器负载,并明智地采用缓存策略.

在对你的应用程序使用服务器端渲染(SSR)之前,你应该问第一个问题是否真的需要它.这主要取决于内容到达时间对应用程序的重要程度.例如，如果你正在写一个活动页,那么初始加载时的额外几百毫秒并不重要,这种情况下去使用服务器端渲染(SSR)肯定是一个小题大作之举.然而,内容到达时间(time-to-content)要求是绝对关键的指标，在这种情况下，服务器端渲染(SSR)可以帮助你实现最佳的初始加载性能.