找前端工作不太顺利，到慕课、腾讯课堂上自学了Vue，好像还是不太顺，有大佬路过支支招吗？
其实找一份前端工作，只会Vue是远远不够的，原生JS,移动端开发如果你不够熟练，是非常吃亏的。
物联网+时代，很多场景都是线上线下相互结合，导致移动端用户量激增。另一方面，以Angular,React,Vue为主的MVVM框架和NodeJS,ES6等前端新技术的出现和快速迭代，让前端得到前所未有的发展空间。
很多同学面试的过程中，被问到原生知识或底层原理，就答非所问。虽然使用Vue很久，但其中的响应式数据原理，Vue路由懒加载原理，Vue生命周期，这些理论知识却十分空白。更重要的是，面试官考察的，不仅是理论知识，还有你的编码习惯，拆分问题，解决问题的思维方式。我们要做的，就是夯实原生知识，设计模式，从前端走到后端，时刻关注前端动态，才能成为一名合格的前端开发工程师。
前文摘自以下链接的文章《学习Vue你需要你知道的前置知识》，有兴趣可以点进去看看还有很多技术干货，个人学前端觉得还挺有帮助的。
你们现在做前端的，还用jQ吗？还是用vue+js？
avaScript最初是为Web应用程序而创建的。随着前端技术的发展，比起纯JavaScript 脚本，大多数开发人员更喜欢使用基于JavaScript的框架来开发Web应用，如Vue、React等。这些框架大大简化了你的代码，也使你能够完成更多的全栈工作。
使用什么类型的框架决定了应用程序的敏捷程度。因此，您必须慎重选择。在充满多样性的前端生态中，有两个框架十分引人瞩目——Ember.js和Vue.js。
本文，我们将就这两个框架进行对比，帮助你判断哪个框架才更适合你。
开发者为什么要为选择框架而犯愁？
在开始对比这两个框架之前，我们应该先了解：选择一个框架的决定因素都有哪些：
代码必须简单易懂
应以更少的代码量产出更多的功能
应提供一个布局合理的工作框架
是否支持内置路由或外部插件的路由
应该能够在页面加载时传输更多数据，从而使页面成为单页应用（PS：单页应用程序的使用体验更好）
在单页架构中，如果用户需要共享应用子页面链接，那么框架应该具备基于URL路由不同功能的能力
更严格的模板选项有助于实现双向绑定
不应与任何第三方库产生冲突
应该很容易测试框架内的代码
应为Ajax调用提供HTTP客户端服务
文档必不可少，并且应该是完整且最新的
应该与浏览器的最新版本兼容
只有保证所选择的框架符合上述基本条件，才能够最大程度的确保Web应用程序的构建顺利。
下面我们就来详细分析Ember.js和Vue.js框架之间的异同。
Ember.js
请点击输入图片描述
Ember.js是一个基于MVVM模型的开源框架，该框架主要用于创建复杂的多页面应用程序。它最大的特点是：持续推出最新的特性，并不会丢弃任何旧功能。
与大多数前端开发框架不同，使用Ember.js，您必须遵循一套严格的JS体系结构，也就是说，Ember.js并不具备高度的灵活性。不过，正是得益于这套JS体系结构，Ember.js明显更加完善、稳定，您可以使用其任意版本推出的工具与最新版本集成，却不必过分担忧兼容性问题。
因为Promise无处不在，所以你可以用简单的方式编写代码和模块，通过调用 Ember.js提供的API，以实现高度复杂的功能。
在性能处理方面，Ember.js创建了相似的绑定机制和DOM更新，允许让浏览器一次性处理它们，以提高工作性能（这样做的好处是：避免为重复工作增加算力，浪费大量时间）。
作为一个流行的前端开发框架，学习指南必不可少。Ember.js明确了一般应用程序的组织和结构，确保你不会犯任何错误。
Ember.js的模板基于Handlebar 语法，借助它可以使你轻松阅读和理解模板，同样也能使页面加载速度变得更快。除此之外，你不必每次在页面上添加或删除数据时都更新模板，因为这一切，语言本身已自动为你完成。
最后，Ember.js拥有一个活跃的社区，其定期更新框架并确保向后兼容性。
让我们花几分钟总结一下Ember.js的特点：
Ember.js是适用于复杂结构、多页应用程序的MVVM模型的开源框架
Ember.js持续提供最新功能，且不会丢弃任何旧功能
Ember.js遵循一套非常严格的结构框架，不能提供太高的灵活性
借助Ember.js完善的控制系统可帮助你与新版本完美集成
Ember.js对避免使用过时的API版本有着严格的指导
Ember的API可帮助您以简单的方式使用复杂的功能
Ember.js提供高效的运算机制，以保证运行效率
Promise确保你使用Ember.js的任何API，以达到编写模块化脚本和简洁代码的目的
Ember.js是一个完全加载的前端框架
Ember.js框架稳定，因为所有组件都具有相同的功能和属性
Ember.js具有明确定义的限制，可防止您使应用程序复杂化
Handlebar作为Ember.js的模板语言，可使你可以轻松阅读和理解模板，且有助于更快地加载模板
Ember.js有一个活跃的社区，可以定期更新框架并保证其向后兼容性
Vue.js
请点击输入图片描述
开发人员一直在试图寻找新的框架来构建他们的应用程序，而他们的核心诉求只有一个：速度快、成本低。
基于此，用Vue就够了。
这个框架很容易被开发人员理解并且能够以极低的成本使用。当然，选择它的理由还有很多：简单的编码方式、健全的帮助文档和活跃的生态系统。
在Web应用程序开发中，Vue.js在软件语言方面结合了很多优点。它的体系结构更易使用，并且，使用Vue.js 开发的应用程序很容易与现代化的应用程序集成。
Vue.js使用了服务器端渲染流的方法，这样做有两个好处：1. 使服务器具有较高的响应速度；2. 非常适合SEO（自然搜索）。通过服务器端渲染，视图直接在服务器上呈现，这十分便于搜索引擎直接抓取到这些网页内容。
Vue.JS是一个非常轻量级的框架。正因如此，它也比其他框架快得多。
如果你愿意，甚至还可以进一步减少它的体积——使用Vue.js可以将模板和编译器分离为虚拟DOM，只需部署12 KB的压缩文件，就可以在您的机器中编译模板。
Vue.js的另一个重要特点是：它可以轻松地与使用JavaScript脚本创建的Web应用程序集成，使用此框架可以轻松地对已有应用程序进行更改。
提到集成，就不得不说Vue.js与其他前端库的集成情况。Vue.js可以轻松的集成到其他前端库中，也就是说，您可以在Vue.js中插入另一个库，以弥补此框架的不足，而这项功能也使得Vue.js成为了一个更为通用的工具。
学习前端vue怎么样？
vue是一个轻量级，学习成本低，使用方便的前端框架。vue的运行速度快，数据和结构分离，插件化，很多网站都用vue来进行搭建。因此学习vue是一个好的选择。但vue的缺点是不支持IE8以下的浏览器，需要根据项目用途进行考虑。
大公司前端一般用vue还是react
React。
在Vue2.0时代，国内大厂的前端开发框架，几乎清一色偏向React。其实现在来说，vue和react都相差无几，各有优劣，两者差距更多的是在语法，社区活跃度，实现原理之间的差距。能否做大型项目关键在于项目组的业务划分、部门之间的协调效率上，因为大型项目不是一两个人，三五个人能够完成的。一个项目之所以称为大项目是在于它是公司大量部门协同合作下的产物。也就是说，解决了项目划分等问题，使用vue和react都是可以的。
vuejs在前端开发起到什么作用
jQuery的诸多局限性导致前端工程师的发展受到了很多的限制，只能做一些表面性的工作，并不能实现前后端分离开发。
而近期出现的Vue，它给前端带来了无限的可能和改变。
改变一：真正意义上的前端工程师
之前开发都是前端做静态页面，把页面给到后台程序员改成jsp、php、asp等等...一顿乱改，一顿塞变量，做完以后页面样式乱七八糟，最后你再调整css。说白了你会html，css就行了，基本没什么门槛，可以这么说。
有了Vue和Node的前端工程化以后，前端工程师能做的事情越来越多，后台人员只需要抛过来一个Api，剩下的就可以都交给前端了。
改变二：服务端渲染VS客户端渲染
传统的jsp、php或是模板渲染也好，都是服务端渲染，就是客户端一个请求，服务器直接把整个页面返回给你，简单粗暴。（Spring Boot是通过模板引擎，由服务端完成的渲染工作）
但是vue开发是前后端分离开发，通过api进行交互，客户端请求服务器返回json数据，由客户端进行渲染。
不仅减轻了服务器的压力速度更快而且渲染更加优雅，代码更容易维护。
改变三：渲染优雅，代码易维护
jQuery是通过DOM来控制数据，不仅笨重而且渲染数据特别麻烦，而 Vue是通过数据来控制状态，通过控制数据来控制渲染，变量可以直接写在标签中，渲染更加优雅。
因为前端代码和后台代码都是分开的，所以项目更容易维护，开发效率更高。
改变四：项目工程化，结合npm直接安装第三方库
Vue让前端项目更加工程化，同时也规范了前端工程师的代码，而node和npm的加入才是vue能蓬勃发展的重要原因。
Node为Vue提供了本地server和模块化开发的思路，npm更能安装Vue项目需要的模块，配合Vue使用，比如Moment.js Element ui vuex等等，这些第三方库让Vue有了无限的可能。
敲黑板（补充下）：传统开发jQuery是命令式编程，现代框架开发是函数式编程。现代框架开发，可以使用Webpack（当然使用jQuery也可以使用Webpack），可以使用人家提供的现成的脚手架，比方说create-react-app，vue-cli。极大提高了开发的效率，并且可以使用最新的ES6、ES7语法进行开发，在编码体验上，就提高了一个档次。
总结
知其然，知其所以然，没有最好的框架，只有最合适的框架！