移动端开发者眼中的前端开发流程变迁与前后端分离 - 文章 - 伯乐在线
& 移动端开发者眼中的前端开发流程变迁与前后端分离
写在最开始
这是一篇面向移动端开发者的科普性文章，从前端开发的最初流程开始，结合示范代码，讨论开发流程的演变过程，希望能覆盖一部分前端开发技术栈，从而对前端开发的相关概念形成初步的认识。
本文会提供一些示范代码，然而他们无法运行，也不需要完全看懂，更多的是方便读者对相关概念和方案有更加具体形象的感受和更清晰的理解。
在写作过程中，我阅读学习了淘宝在前后端分离和前端开发技术演变方面的博客，受益匪浅，相关文章都罗列在文末的参考资料中。同时由于自身能力有限，对很多概念的理解比较浅显，甚至有误，欢迎交流指正。
移动端与前端的区别
在开发 App 的过程中，我们不会刻意思考开发流程，因为一切看上去都非常自然。可以本地确定的内容就直接写死，否则异步发起网络请求并动态的修改，最后把源代码编译成可执行的二进制文件供客户安装。
前端开发和移动端开发就有本质的不同了。一个网页的最终展现样式受到 HTML + CSS 的影响，而 JavaScript 脚本负责用户交互。一个页面不会被编译成可执行文件，它仅仅由几个文本文件组成，由服务端明文下发给浏览器并绘制到屏幕上。
下文中可能会反复提到“渲染”的概念，除非特别说明，它不表示解析 HTML 文档(DOM)并绘制到屏幕上这个过程，因为这一步由浏览器内核实现，普通情况下不需要做过多了解和干预。
网页可以分为静态、动态两种，前者就是一个 HTML 文件，后者可能只是一份模板，在请求时动态的计算出数据，最后拼接成 HTML 格式的字符串，这个过程就被称为渲染。
前端与移动端开发另一个显著差异是: 虽然可以在本地调试 HTML，但实际上这些 HTML 的内容需要部署在服务端，这样才能在用户发起 HTTP 请求时返回 HTML 格式的文本。
前端开发的混沌时代
一开始，我们没有任何工具，只能靠蛮力。我们知道 Servlet 是由 Java 编写的服务端程序，可以方便的处理 HTTP 请求和返回，因此可以直接把 HTML 文本当做字符串返回，也就是上文所说的渲染:
public class HelloWorldServlet extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
resp.setContentType("text/html");
PrintWriter out = resp.getWriter();
out.println("&html&&head&&title&Hello World Sample&/title&&/head&");
out.println("&body&&h1&Hello World Title&h1&&h2&" +new Date().toLocaleString() + "&/h2&&/body&&/html&");
out.flush();
123456789101112
public class HelloWorldServlet extends HttpServlet {&&&&&&@Override&&&&public void doGet(HttpServletRequest req, HttpServletResponse resp)&&&&&&&&throws ServletException, IOException {&&&&&&&&resp.setContentType("text/html");&&&&&&&&&PrintWriter out = resp.getWriter();&&&&&&&&out.println("&html&&head&&title&Hello World Sample&/title&&/head&");&&&&&&&&out.println("&body&&h1&Hello World Title&h1&&h2&" +new Date().toLocaleString() + "&/h2&&/body&&/html&");&&&&&&&&out.flush();&&&&}}
理论上来说，我们已经可以开始所有前端开发了，但在这混沌初开的年代，想写出一份可维护的代码恐怕得用上“洪荒之力”。把 UI 和业务逻辑写在一起是一种非常强的耦合，不利于项目日后的拓展。也无法要求每个人同时会写 Java 和前端。
上述方案的问题之一在于逻辑混乱不清，移动开发者在入门阶段大多也经历过，解决方案比较简单:使用 MVC，把业务逻辑抽离到 Controller 中，让 View 层专注于显示 UI。
MVC 方案实现
在前端开发领域，也有类似的技术，比如 JSP，它经过编译后变成 Servlet。在写 JSP 的时候，我们更加关心页面样式，因此代码看起来就像是 HTML，不过在
代码块中可以调用 Java 函数:
&TITLE&JSP测试页面---HelloWorld!&/TITLE&
out.println("&h1&Hello World!&/h1&");
12345678910
&HTML&&&&HEAD&&&&TITLE&JSP测试页面---HelloWorld!&/TITLE&&&&/HEAD&&&&BODY&&&&%&&&&&&out.println("&h1&Hello World!&/h1&");%&&/BODY&&&&/HTML&
JSP 相当于 View 层，它从 Model 中获取数据，说的再具体一点，是使用后端的语言(比如 Java)去访问 Model 层提供的接口。
Controller 作为直接和客户端接触的模块，负责解析请求，数据校验，路由分发，结果返回等等逻辑。路由分发是指根据请求路径的不同，调用不同的 Model 和 View 提供服务。
MVC 的缺点与改进
使用了 MVC 架构(比如大名鼎鼎的 Struts)后，似乎职责变清晰了，前端开发者负责写 JSP，后端开发者负责写 Controller 和 Model，然而在实际开发时还是有诸多问题。
首先业务逻辑依然没有严格区分，如果没有良好的编码规范，JSP 中就会混入大量业务逻辑。而一个框架存在的作用应该是让没有接受很多培训的新人也能写出合格的代码。此外，前端开发者还需要对后端逻辑有大致的了解，熟悉后端编程语言，因此也存在很多沟通、学习成本。
前端只写 Demo
一种解决方案是前端开发者只写 Demo，也就是提供静态的 HTML 效果给后端开发者，由后端开发者去完成视图层(比如 JSP)的开发。这样前端开发者就完全不需要了解后端知识了。
可惜这种想法很好，但是一旦付诸实现就会遇到不少问题。首先后端开发者依赖于前端的 Demo，只有看到 HTML 文件他们才可以开始实现 View 层。而前端又依赖于后端开发者完成整体的开发，才能通过网络访问来检查最终的效果，否则他们无法获取真实的数据。
更糟糕的是，一旦需求发生变动，上述流程还需要重新走一遍，前后端的交流依旧无法避免。概况来说就是前后端对接成本太高。
举个例子，在开发 App 的时候，你的同事给你发来一段代码，其中是一个本地写死的视图，然后告诉你:“这个按钮的文字要从数据库，那个图片的内容要通过网络请求获取，你把代码改造一下吧。”。于是你花了半天时间改好了代码，PM 跑来告诉你按钮文字写死就好，但是背景颜色要从数据库读取，另外，再加一个按钮吧。WTF？
显然这种开发流程效率极低，难以接受。
其实一定程度上来说，JSP 可以看做 HTML 模板的雏形。HTML 大体上肩负了两个任务: 页面框架和内容描述。所谓的 HTML 模板是指利用一种结构化的语法，表示出 HTML 的框架，同时把具体数据抽离出来。
比如 &p&111&/p& 表示一个段落，其中内容为 “111”。如果用模板来表示，可以写作 &p&Content&/p&或者 p Content 等等。总之，不要纠结于具体语法，我们只要知道:
数据 + 模板 = HTML 源码
比如在 Controller 层，可以这样调用:
// 这里没有指定模板的名称，是因为使用了依赖倒置的思想，在配置文件中绑定了 Controller 对应的 View
return res.view({title: "111"});
// 这里没有指定模板的名称，是因为使用了依赖倒置的思想，在配置文件中绑定了 Controller 对应的 Viewreturn res.view({title: "111"});
模板中的代码如下:
&h1&&%= Content%&&/h1&
&h1&&%= Content%&&/h1&
熟悉前端开发的读者可能会发现，这其实采用了
开发。前者是基于 JavaScript 的服务端应用程序，后者是基于 HTML 语法的模板，另一种风格的模板是 ，不过本文的目的并不是重点介绍这些工具如何使用，就不再赘述了。
回到模板的概念上来，它相对于 JSP 的优势在于，利用工具强行禁止前端开发者在视图层写业务逻辑。前端开发者只需要关心 UI 实现并确定 HTML 中的变量。而后端开发者只要传入参数即可获取 HTML 格式的字符串。
模板开发的另一个好处是前后端可以同步开发。双方约定一个数据格式，前端就可以模拟出假数据并用来自测，后端也可以用生成的数据与假数据对比进行测试。同时，这个约定的数据格式扮演了契约和文档的作用，规范了双方的数据交流形式，从而节省交流的时间成本。关于更多 Mock Server 的话题，请参考 。
后端 MVC 架构总结
使用后端 MVC 架构加上模板开发是当前比较主流的一种开发模型，但它也不是完美的。由于模板由前端开发者完成，所以要求前端开发者对后端环境(注意这里不是实现细节)有所了解。
举个简单例子，大型应用的后端要分很多文件夹，这就要求前端对代码组织结构有所了解，上传文件时需要掌握 ssh、vim 并且依赖于服务端环境。
总的来说，采用服务端 MVC 方案时，HTML 在后端渲染，整体开发流程也全部基于后端环境。因此前端工程师不可避免的需要依赖于后端(虽然使用模板后情况已经大大改善)。
AJAX 与前端 MVC
AJAX 的全称是 Asynchronous Javascript And XML，即 “异步 JavaScript 和 XML”。它并非一个框架，而是一种编程思想。它利用 JavaScript 异步发起请求，结果以 XML 格式返回，随后 JavaScript 可以根据返回结果局部操作 DOM。
AJAX 最大的优点是不用重新加载全部数据，而是只要获取改动的内容即可。这在移动端编程中看上去是天经地义的，而前端开发则需要专门使用 AJAX 来实现，默认情况下网页的任何一处微小改动都需要重新加载整个网页。
类比移动应用就会发现，AJAX 适合做单页面更新，但是不擅长页面跳转，就像你的 app 页面跳转都是新建一个 UIViewController/Activity 而不是直接把当前页面的内容全部换掉。
得益于 AJAX 的提出，HTML 在前端渲染变成了可能。我们可以下载一个空壳 HTML 文件和一个 JavaScript 脚本，然后在 JavaScript 脚本中获取数据，为 DOM 添加节点。
这时候就出现了很多前端的 MVC 框架，比如 Backbone.js，AngularJS(姑且认为MVVM 是 MVC 的变种) 等一堆名词，你可以从
找到他们各自的 Demo。以我相对熟悉的 React 为例:
&!DOCTYPE html&
&script src="../build/react.js"&&/script&
&script src="../build/react-dom.js"&&/script&
&script src="../build/browser.min.js"&&/script&
&div id="example"&&/div&
&script type="text/babel"&
var LikeButton = React.createClass({
getInitialState: function() {
return {liked: false};
handleClick: function(event) {
this.setState({liked: !this.state.liked});
render: function() {
var text = this.state.liked ? 'like' : 'haven\'t liked';
&p onClick={this.handleClick}&
You {text} this. Click to toggle.
ReactDOM.render(
&LikeButton /&,
document.getElementById('example')
123456789101112131415161718192021222324252627282930313233343536
&!DOCTYPE html&&&&html&&&head&&&&&&script src="../build/react.js"&&/script&&&&script src="../build/react-dom.js"&&/script&&&&script src="../build/browser.min.js"&&/script&&/head&&&body&&&&&&div id="example"&&/div&&&&script type="text/babel"&&&&&var LikeButton = React.createClass({ &&&&&&getInitialState: function() { &&&&&&&&return {liked: false}; &&&&&&}, &&&&&&handleClick: function(event) { &&&&&&&&this.setState({liked: !this.state.liked}); &&&&&&}, &&&&&&render: function() { &&&&&&&&var text = this.state.liked ? 'like' : 'haven\'t liked'; &&&&&&&&return (&&&&&&&&&&&p onClick={this.handleClick}&&&&&&&&&&&&&You {text} this. Click to toggle.&&&&&&&&&&&/p&&&&&&&&&); &&&&&&} &&&&}); &&&&ReactDOM.render(&&&&&&&LikeButton /&, &&&&&&document.getElementById('example') &&&&);&&&/script&&/body&&&/html&
这段代码不用完全读懂，你只要意识到，引入 React.js 这个框架后，我们就可以脱离 HTML 编程了。所有的逻辑都写在
标签块中的 JavaScript 代码中。
我们还创建了一个 LikeButton 组件，它可以拥有自己的方法，管理自己的状态等等。这里举 React 的例子可能略有不妥，因为它其实只是一个 View 层的实现方案，还需要配合 Flux 或 Redux 架构。不过也足以感受一下纯 JavaScript 开发的感觉了。
这种开发模式和移动端开发非常类似，使用 JavaScript 调用 DOM 接口来绘制视图，使用 JavaScript 来实现业务逻辑，处理数据，发起网络请求等。你完全可以理解为单纯用 JavaScript 在浏览器上开发移动应用，只不过用户下载的是 JavaScript 脚本而非传统静态语言编译后的二进制文件。
使用了前端 MVC 框架后，对于单页应用(Single Page Application)来说，前后端各司其职，唯一的联系就变成了 API 调用，前端开发者不再依赖后端环境，HTML 和 JavaScript 都可以放在 CDN 服务器上。这就是我们常说的 前后端分离 的基本概念，即前端负责展现，后端负责数据输出。
前后端分离的缺点
然而在我看来，上述前后端分离方案远远逊色于后端 MVC + 模板的开发流程，这是因为在实际开发中，纯 SPA 的场景并不多见，即使移动端也不是只有一个视图，而是有很多页面跳转逻辑，更何况到处都是超链接的网页呢？
我们来看看在 SPA 和多页面跳转并存的情况下，采用前端 MVC 框架进行前后端分离存在哪些不足。
双端 MVC 不统一
前端的 MVC 主要处理单个页面内的逻辑，而后端 MVC 框架处理的是整个 Web 服务器的逻辑。借用
的图片来表示:
前后端 MVC 架构示意图
由于前后端 MVC 框架关注的重点不同，它们的地位自然也不同。前端的 MVC 框架负责页面展示，因此它只是后端 MVC 框架的 View 层(或许只是一部分 View)。
这就会导致如下问题:
前端的 Model 和后端的 Model 结构上高度类似，比如前端用到一个 name 属性，后端也得在 JavaBean 中定义一个 name。有时候为了避免前端对数据做太多逻辑处理从而导致性能下降，后端可能已经做了一些预处理。这就好比我们写 App 时，拿到的 feed 流可能是筛选、排序过的，而我们在移动端还要在 ViewModel 中做一些转化才能给 View 使用。因此，前后端逻辑上的耦合还是无法完全避免。
前端的 Controller 负责页面调度，比如控件的状态管理和样式改变等。而后端的 Controller 负责调用服务，用户鉴权等。两者完全不等价。
前端也有路由模块，它主要负责页面内控件之间的跳转，比如 ，而后端路由则是把不同的网络请求分发给指定的 Controller。两者逻辑也无法统一。
SEO(搜索引擎优化)是一个移动开发者从来不考虑，但前端开发者视作生命的问题。搜索引擎的工作原理是访问每个网页，然后分析 HTML 中的标签和关键字并做记录。
一个纯异步的网页，HTML 几乎是空壳子，而偏偏关键的数据都是动态下发的，这就影响了搜索引擎爬虫的工作过程，他们会认为该网页什么都没有，即使记录下来的也是非关键数据。
早些年谷歌推出了
来弥补 AJAX 对 SEO 造成的负面影响，它的本质是为爬虫提供后端渲染的降级处理机制。目前谷歌的爬虫一定程度上可以阅读 JavaScript 代码并爬取相关数据，但 AJAX 在对爬虫的支持上终究不如 HTML 文本直接传输。
从上文中 React 的示范代码可以看出，HTML 文件非常小，很快就被打开。但是页面的渲染逻辑直到 JavaScript 文件被下载后才能开始执行，这就会导致一段时间的白屏。
在移动网络上，前端渲染 HTML 的性能当然不如后端渲染，频繁发送 HTTP 请求也会影响加载体验，因此依赖于前端渲染的页面，在性能方面还有很大的提高空间。
集中 Or 分离？
很多年前，JavaScript 和 CSS 并不用单独写在外部文件中，而是直接内嵌在 HTML 代码里:
&p style="background-color:green"
onclick="javascript:myFunction()"&
This is a paragraph.
&p style="background-color:green"&&&&&&onclick="javascript:myFunction()"&&&&&This is a paragraph.&/p&
为了便于管理和修改，我们把 CSS 和 JavaScript 分离出来。然而到了 React 中，好像走了回头路，所有逻辑都放在 JavaScript 中。
我的理解是，这种做法适合组件化，我们很容易定义出一个组件并且重用。这种思想对于复杂的 SPA 来说或许适用，但对于并不复杂但有多个页面的网页来说，就显得太重了。引入了 React 这样的框架，以及 MVC 的结构，反而会显得过度设计，增加代码量和复杂度。
考虑到之前所说的前后端逻辑不能复用的问题，这就更容易导致性能问题。
前后端分离的哲学
至此，我们已经尝试过后端 MVC 架构，HTML 模板，前端 MVC 架构等多种方案，但结果总是难以令人满意，是时候总结原因了。
我们在进行上述实践的过程中，过度强调物理层上的前后端分离，但是忽略了两者天然就存在一定的耦合。实际上，前端开发者不仅关注 View 的实现，还应该负责一部分 Controller 中的逻辑，后端开发者则应该关心数据获取与处理，以及一些跨终端的业务逻辑。
如果页面渲染在后端实现，会导致前端开发者依赖后端实现和开发环境，后端开发者被迫熟悉前端逻辑(此时不是调用 API 而是直接生成数据并套用模板，这就要求把获取的数据转换成模板需要的数据)。
如果页面渲染全部放在前端，业务逻辑就会太靠前，从而导致不能复用。这种做法似乎有些矫枉过正了。此外，上文中也介绍了不少 AJAX 的缺点，就不赘述了。
我们似乎陷入了两难的境地，页面渲染不管是放在前端还是后端都不合适。其实这很好理解，页面渲染涉及数据逻辑和 UI，他们理应分别由前后端开发者分别负责，单独交给任何一方都显得不合适。
但如果前端工程师可以写后端代码，问题不就迎刃而解了么？实际上数据的处理可以分为两个步骤:从数据库或第三方服务获取数据，把数据转化为 View 可用的形式。前者往往和 C++/Java 服务器相关，后者则和前端模板相关，它的作用更像是 MVVM 架构中的 ViewModel。
Node.js 分层
我在初步介绍了 Node.js 的定位:“一个用 JavaScript 进行开发的后端应用程序框架”。因此它恰好可以完美的解决前端不了解后端逻辑和代码的问题。
Node.js 作为一个中间层，调用上游 Java 服务器提供的服务，获取数据。自身负责处理业务逻辑，路由请求，cookie 读写，页面渲染等。前端则负责应用 CSS 样式和 JavaScript 交互，类似于最早期原始的模型。
中的图片来说明:
node.js 中间层
还有一个解释的非常详细的表格以供参考。
这不是一篇介绍 Node.js 的博客，我也不熟悉相关框架的应用，举这个例子是为了演示 Node.js 是如何做前后端分离的。
我选择了 ，项目的代码在 ，这里简单的分析一下。
视图都放在 views 目录下，采用 EJS 为模板，由 Node.js 负责在服务端渲染:
&div class="container"&
&h1&&%= __('Comment') %&s for SAILS&small&js&/small& + REACT&small&js&/small&&/h1&
&script src="/js/commentMain.js"&&/script&
&div class="container"&&&&h1&&%= __('Comment') %&s for SAILS&small&js&/small& + REACT&small&js&/small&&/h1&&&&/div&&&&script src="/js/commentMain.js"&&/script&
Controllers 负责页面转发与模板渲染，具体的服务转交给 Services 去完成:
module.exports = {
app : function(req, res) {
// 如果有必要，在这里调用 Services 获取数据
return res.view({});
module.exports = {&&&&app : function(req, res) {&&&&// 如果有必要，在这里调用 Services 获取数据&&&&return res.view({});&&},};
这个 Demo 中没有实现 Services，通常它用于和真正的后端进行交互，可以视情况选择 HTTP 或 SOAP，并对返回结果做处理。此外还有 policies/responses 模块分别对 HTTP 请求和返回内容做处理。
前端的相关代码都封装在模板层，能够与 Node.js 无缝接合。
虽然我们用增加 Node.js 处理层的方式解决了前后端分离中的一些痛点，但在实际应用中还是需要考虑得更加周全。
新增一层后，势必会导致性能损耗。然而分层本就是一个在衡量得失后做出的权衡，可以通过各种优化把性能损耗降到最低。况且，在 Node.js 这一层还可以使用 BigPipe 来处理多个异步请求。
传统网页在加载页面时，首先获取 HTML，然后获取其中引用的 CSS 和 JavaScript。在服务端准备数据和网络传输过程中，浏览器需要一直等待，而 BigPipe 将页面分成若干小块，虽然每个块的加载逻辑不变，但块与块之间可以形成流水线作业，避免浏览器无意义的等待。
使用 BigPipe 技术在一定场景下可以代替 Ajax 的多个异步请求。具体介绍可以参考 。
使用 Node.js 后，对前端开发者的技术要求提高了，编码工作量也会相应的增加。然而这都是工程化的必经之路，编码量增加的背后其实是沟通、维护效率的提高。
为了处理前后端复杂的逻辑，我们尝试了使用了后端 MVC 框架来分离业务，用 HTML 模板来分离数据和 UI 样式。使用了 Ajax 技术的网页更适合单页应用，虽然做到了物理层的分离，但在处理多页面时还是有不少问题。
实际上页面渲染本就是前后端共同关心的话题，我们更应该根据业务逻辑进行前后端分离。最终选择了 Node.js，借助它使用 JavaScript 的特性，由前端工程师负责获取数据后的处理和模板的使用，分担了一部分原本逻辑上属于前端，但技术上偏向后端的任务。这种开发模式看上去像是一种倒退，其实是螺旋式的上升与返璞归真。
Node.js 基于事件和异步 I/O 的特性，以及优秀的处理高并发的能力非常适合前后端分离的场景，使用 BigPipe 等技术也足以将分层带来的损耗降到最低。选择 Node.js 做前后端分离并不一定最佳实践，但在目前看来有不错的应用，同时也需要一边探索一边前进。
打赏支持我写出更多好文章，谢谢！
打赏支持我写出更多好文章，谢谢！
任选一种支付方式
关于作者：
可能感兴趣的话题
关于伯乐在线博客
在这个信息爆炸的时代，人们已然被大量、快速并且简短的信息所包围。然而，我们相信：过多“快餐”式的阅读只会令人“虚胖”，缺乏实质的内涵。伯乐在线内容团队正试图以我们微薄的力量，把优秀的原创文章和译文分享给读者，为“快餐”添加一些“营养”元素。
新浪微博：
推荐微信号
（加好友请注明来意）
– 好的话题、有启发的回复、值得信赖的圈子
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选文章
– UI,网页，交互和用户体验
– 专注iOS技术分享
– 专注Android技术分享
– JavaScript, HTML5, CSS
– 专注Java技术分享
– 专注Python技术分享
& 2017 伯乐在线问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
自己本来是学的java开发，但不知不觉发现自己更喜欢前端。
朋友劝我说，前端你一两个月可以自学会，别人也可以。
还是学java比较有前途。
不知自己是选后端研发好？还是前端好？
本人肯定希望从事有“钱”景的职业，不知如何选择？
这个问题已被关闭，原因：非技术提问的讨论型问题
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
一个好的前端工程是基本上就是一个全栈工程师了。
一般后台用 PHP 那么前端工程师也是有能力搭建整个网站的。自从node.js和mongodb出现之后，那么只会js的前端工程师也可以独立完成从前端到后台数据库所以的代码。这就是优势，在软件工程里人与人之间的交流成本还是很大的，有些时候会1+1&1。
自从HTML5出现之后，那么C/C++/JAVA 写的应用HTML+js+CSS基本都可以写，只是浏览器会提示要求某些权限。
后来出现了一个项目叫cordava，基本的作用就是JS构建应用，然后编译成跨平台的代码。基本原理就是，用HTML+js+CSS写应用，然后装软件就是装一个没有界面的浏览器内核，运行应用就是使用这个内核显示某个已经写好的网页（HTML+js+CSS）。（其实DOM不慢，至少比Andriod java要快。js下一层就是C++，而java字节码下一层是java虚拟机。你觉得那个更快？慢主要来源于CSS，有点儿过于复杂了）。这种优势就是一次编写到处运行（JAVA的理想），而且不一定要装你的APP就可以使用（谁不在手机/电脑里装个浏览器呀），现在大家都懒，不想费劲下载安装软件了。看下面的例子：
知道QQ（电脑版）不？右下角的弹窗和聊天窗口，就是一个网页（从这么看来主界面好像也是，这个不太清楚）。知道去哪儿网不？他的APP就是一个网页（就是安装一个浏览器内核显示放在某个地方的网页），不信你可以对比它APP的界面和用你手机浏览器访问他主页的界面。知道微信不？自从开放了js的API接口（微信JS SDK），官方的形容是，你可以在你的网页中在再写一个和微信功能一模一样的应用（如果你够无聊的话，当然实现某些功能需要官方认证）。
但是，问题是前端东西还是很多的，CSS好复杂，兼容性调着特别费劲，JS有些地方规定的比较不好，而且有些地方比JAVA更先进，这些的表现都是显得js很怪异。所以你看到一些怪异的地方就不知道是先进的东西还是不先进的东西，以后要尽量这样用还是避免这样用。npm社区发展好快，一年前出的书，上面的例子就不能用了。每次要完成一个功能，网上各种库，都不知道选哪个好。
一两个月学会?我都搞了快四年了，现在gulp,SASS,LESS还没开始看呢，某些CSS还要查手册
决定权在你。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
任何职业都分三六九等，看你自己能钻研到哪一步了，没有绝对性的说热门
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
前端没有个三五年， 根本不好意思说自己学会了。
前端发展太快了，至少目前是这样的。 或许你朋友心中的前端还停留在几年前，如果他稍微了解了解，也不至于说出这种话。不是能做几个简单的页面，能写一些特效就叫会前端了，如果还停留在这种理解上，只能说前端还没入门。
喜欢就去做，前景这东西变换莫测，谁知道几年以后会是什么样子，选择程序这一条路，还是要做自己喜欢的事，只要你做好了，财富都是自然而然的东西。
就算公司java工程师比前端工程师多两三千块钱，我也还是会选择后者，理由很简单，因为我能再这份工作中获得更多的快乐。 而且，好像现在优秀的前端比java更值钱吧？
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
前端后端，从事自己喜欢的才是最好的。
钱财乃身外物，不要太过追求了。
工作不要太累，记得休息。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
一两个月可以自学会，别人也可以；只能说明你朋友不了解前端；
前端水很深；现在的趋势是HTML5开发；自己喜欢就转吧，高端的js程序员不比java工资低；
二者兼顾才是最好，做前端还是得掌握一门后台语言。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
做技术能够坚持下去的动力就是兴趣！
在大学干了3年多的Java项目！一次机会需要页面优化！自己开始接触CSS, JavaScript刚开始就是陶醉于这种“及时行乐”的感觉，那也就是仅仅停留在表层！
后来接触数据交互，在后来工作了，全职在前段，自己越来越喜欢，越做越喜欢
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
javascript是唯一个做到多平台通吃的语言 既oo 又函数 为什么前端不好玩
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
现在都是大前端得时代了，好的前端要掌握好多东西，未来式前端得时代。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
前端一直都想着能和后端同薪同酬，然而真的是要看你工作内容的，优秀的前端基本上都是全栈工程师了。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
兄弟，我大学学了3年半java，现在的半年在弄前端和node，嘿嘿，前端很奇妙，你懂得~
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
前端大致分为:前端美工，和前端工程师，不是一个层次的。
前端工程师需要学习的内容比较多,是需要日积月累的
好的前端工程师可遇不可求。
目前前端工程师需求量较大。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
前端水太深，你得掌握多门语言和技能。不过还是很有意思的
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
丑美看脸，技术高低看人，行行出状元，你开心就好。
补，最近逛sf，发现好多都是题主的问题，好认真的题主，既然对前端感兴趣，就做前端咯，前端做好了，前景不差。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
我原本也是java开发出身的，在大学4年学习的基本都是后端开发的知识，但是对于前端开发比较有兴趣，所以毕业之后果断转到前端开发上来了。目前感觉还可以，每个行业每个岗位都有做的好的和做的不好的，所以关键是看自己的兴趣吧。只要有兴趣还怕做不好，做好了还怕没“钱”景~
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
你还没入门，入门了就不会这么说了~
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
「朋友劝我说，前端你一两个月可以自学会，别人也可以。
还是学java比较有前途。」
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
前端很复杂，但我还是觉得java更有前途（没有很好的理由），只是看好Android。物联网世界即将来临。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
目前以及未来3年，前端的市场更大。后端的架构很多已经很稳定了，而前端还在飞速发展。随着计算机技术与传统行业的进一步结合，市场对前端的需求只会越来越大。而后端基本上都在玩API了。无论客户端来自哪里，数据都是统一的。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
前端发展太快，es6，nodejs,angularjs,react,sass,gulp得不断学习，其实后端也一样
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
因为你的朋友是外行，外行嘴里能说出靠谱的话？
你别逗我了。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
一两个月能学会前端？我就呵呵了！
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
前端做出来的东西比较新鲜，能够带动学习热情。
前端一两个月入门是没问题，不过Java也是一两个月入门啊。
Java平均工资高一点不否认，但是要深入比前端更难吧。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
这个问题是一个辩论问题，也就是说，不会有个结果，不过，可以从辩论中找到你想要的结果，就是最好的答案。
中国的前端岗位大部分是由后端开发人员兼任的，因为，从某些老板的思维来看，前端是一个没有多少技术含量而且超级简单的职位，没有必要用钱去养一个前端，只要用户能看到数据，就可以了。所以，中国的前端就这样在委屈中缓慢发展着。年，是一个移动网站爆发的时期，我身有所感，智能机的全面普及以及创业板块的迅猛发展，移动APP发展迅速，所以，混合式APP被提出来，就在这时，中国开始更多的人关注起前端行业，或者更多的是移动前端。
前端以后的发展前景是广阔的，但是也有前提的，那就是html5与css3在客户端上的支持与普及程度，最关键的就是浏览器。
前端很杂，每天都会有新的插件，框架，解决方案冒出来，所以，前端是一个需要不断学习以及充实的行业，极具挑战性。现在猎头最烦找前端工程师职位，因为少也没有多少精通的，现在上海前端工程师职位已经开到13K-17K了。机遇随处可见，就看能不能把握得住了。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
无论是Java还是前端都很有前景，你在Github上搜索JavaScript编写的星多的开源项目和Java编写的星多的开源项目，就能大概了解了，这两种语言都有很高质量的项目。所以，关键不是做哪个，而是能做好哪个哈
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
技术这个还真得看自己的兴趣，前景是次要考虑的问题。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
其实对一个科班出身的程序员来说，什么语言不是一个月搞清语法，两个月学会上手。任何编程语言都有自己的特性和技巧以及平台，有几门敢说精通呢？
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
目前的市场是优秀的前端太少，所以优秀的前端工资很高，基本20K+，楼主你感受一下。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
java出身,不知道为啥就是学不懂,找工作的时候意外的试了前端,从此一发不可收拾,越来越喜欢
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
反正找自己感兴趣的，技术这个职业，如果完全通过钱去驱动你做事，基本上是坚持不下来的，需要去真正的热爱，你才有办法在一个领域去发展和延伸。至于说钱的问题，我感觉这个不是你应该考虑的问题，因为前端也有3 4K的，也有30 40K的，这个完全取决与个人。而且从需求来说，真正合格的前端其实市面上不多，BAT的需求量都非常大，他们的HR抱怨过其他的职位还好找，就是前端的太难找到好的了
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
一两个月自学会了什么？
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
话说题主其实是想问：对于同一个程序员而言，前端容易拿高工资还是后端容易拿高工资？
我也想知道，前端、后端、数据挖掘blabla那个更赚钱。。。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
哈哈 我看java才是烂大街
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
我永远只做自己喜欢的事情——————尼古拉斯，赵四
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
PHP程序狗路过说说自己的看法。
不管是前端还是后端，前景都是好的，因为我们IT行业的前景是好的，重要的是你喜欢哪一方面。
至于“钱”景，楼上各位也都说了，不管前端还是后端只要做到优秀，这都不是事，重要的是你有没有做到优秀。不要因为一个不懂得人的话而去质疑或者否定。
总之，行行都能出状元，做自己喜欢的吧。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
好奇怪啊！！！！！！为什么要分前端后端呢，为什么不把自己定位为全栈工程师呢？以后出来混，不说自己是个搞全栈你还怎么混嗯(?-ω-`)？两个月学会前端？你指的是html+css2+js基本语法？两个月你可以深入理解原生js?还是说你已经撸了一遍jquery源码？出来混只学这点就可以了？ 了不说别的，
yo grunt bower gulp
underscore backbone
这些工具你要撸多久？现在的90后不得了了，让我们80还怎么活啊？我前端两年还觉得自己前端太差了呢，尼玛，两天不学就跟不上节奏了
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
一两个月学会的不是前端，是美工！！！
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
前端可能回涉及到一些比较琐碎的事情，我是做后端开发的，可能不太喜欢这些琐碎的东西，可能大多数做后端开发的都会有这种想法吧，我觉得。。。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
前端开发没那么简单，比较琐碎和麻烦，而且前端也需要知道一些后端知识。建议先学后端，再从后端转前端！
原因有以下几点：
1、刚开始后端是比前端工资高的（大多数公司）
2、后端的问题第一找的就是前端，不懂点后端会被累死或气死
3、学后端或多或少的会接触一些前端的知识，所以对前端有充分的了解再去学吧
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
我的建议是朝着自己喜欢的方向走，不要听你那外行的同学的，你同学就那么“精通”前端嘛。外行人总是站着说话不腰疼的，对某一行业如若不是有很深的探讨和研究，还是不要妄下断论的好。前端工程师确实水很深，这个工种要学的技能实在太多了，知识很碎片化，该工种有的成为HTML5工程师，有的成为了Node.js工程师，还有的成为了全栈工程师，还有的再图形/可视化领域深耕。难道你不觉得前端是一门非常有想象力，非常有潜力的职业吗？
这个问题已经被关闭无法回答
分享到微博？
你好！看起来你挺喜欢这个内容，但是你还没有注册帐号。 当你创建了帐号，我们能准确地追踪你关注的问题，在有新答案或内容的时候收到网页和邮件通知。还能直接向作者咨询更多细节。如果上面的内容有帮助，记得点赞 (????)? 表示感谢。
明天提醒我
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：
扫扫下载 App}