前端到底要不要学后台，这个问题估计困扰了很多个要入行的小哥，而且各大招聘信息上很多都写着需要了解一到两门后台语言优先。这一点让很多小伙伴很方啊。
那么要不要学了，我的观点的是需要了解，不需要深入学。
为什么这样讲了？首先，从逻辑上来讲。如果你一个做前端的去公司还要做后台的工作，那么不直接招一个更加专业的后台人员了？讲道理，现在市场上的后台技术人员是比前端要多的，就你的那点前端技术刚好可以混个工作，凭啥你可以去抢后台的工作了。所以，各位小伙伴们，不要想当然了，公司招你去是不会要你去做后端的事情的。如果是这个道理，那么写上那些要求干嘛了？这不是在有事没事制造招人障碍，让人知难而退？
任何一个有过3年以上的工作经验的前端最起码接触过后台的，不管是java，php，python或者说前端都可以是涉及的node.js，你可以去问问他们，基本都有过了解，但这个了解不是完全会去写，而且了解一个过程。
有过工作经验的小伙伴应该都知道，除了程序员跟讨厌的产品经理之间的矛盾外，最大的矛盾就是前后台的矛盾了。我之前有过好几个做后台的学员，我问他你为什么要学前端，他告诉我，迫于无奈，前端写的代码实在是太恶心了，太不规范了，每次拿到前端模板要改一半的代码，弄的我现在天天加班。我跟他说，要我的话就直接怼过去了，他说怼不得啊，基本都是妹纸，骂也骂不得，没办法，赶紧来学个前端，不然以后会猝死的。我相信有做后台的小伙伴看到这个故事肯定感同身受吧。所以，为了前后台开发效率更加高，更和谐，W3C和各大公司做了一系列的努力，什么前后端分离，基于MV*的前端架构等等。这也就是为什么，现在前端的要做的事情越来越越多了，学的东西也要越来越多了。
究其原因，实际上就是前端对后台的一个工作形式不了解，对HTTP协议，数据传输，服务器性能等等都不了解。要我说，这些前端也要去学，并且前端对于HTTP协议还有服务器性能还要了解更加深入，不要把眼光老是关注与页面以及浏览器的效率。
比如，你如果了解每一张图片的加载其实就是一个请求，而减少请求其实就是减少对服务器的负载，那么就会使用精灵图来减少请求。如果你了解阻塞I/O，那么你在面对高并发事件时会使用AJAX，而大部分的小伙伴刚刚开始的时候不是在一味觉得AJAX很强，但根本不知道用在哪里，只知道这个东西很强，很牛×，我要学。简直毫无意义。
读到这里，现在应该知道了吧，我们到底要不要学后台了呢？
但是对于所有学前端的小伙伴，我建议的是一定要学一个node.js。这个其实不是一个框架，应该叫基于JS的后台语言，只不过他的解释权是V8引擎而已，本质还是属于后台。如果你在前端学到一定的水平，那么JS肯定不会差的，那么这个语言你学起来不会很困难。只需要花时间去了解HTTP，数据库，服务器等方面的知识就可以了。至于高并发，非阻塞I/O，事件驱动啥的，等你学透了自然而然会懂的。等你用node到一定的阶段，会认识的node的一个不足和优点，到时候就会去扩展第二第三语言了，接下来学起来就没有那么困难了。你要知道一点，后台所有语言的本质是差不多的，所有，届时学起来困难也不会像刚开始接触那么困难。
不知道从何时开始，前端居然被框架统治了。这是一个不太好的现象，这会让很多学生直接忽略掉前端经典三板斧HTML+CSS+JS，毕竟说到底，基本所有前端框架都是由这个三个知识扩展的。
我也不否认，运用框架可以完美的搭建一个应用页面，而且效率非常高，某些框架学起来还很简单，所有很多企业是如此痴迷它们。
那么问题来了，我们要先学哪一个，学什么框架了。
首先纠正一点的就是，node.js并不是一个框架。所谓框架的定义是一个组件集，我们调用这个框架就可以运用里面的组件开发出自己想要的功能，而node.js是一个跟JAVA，PHP,python等语言一样的开发平台，只不过它的语言是我们平时见得比较多的javascript，而且也是可以运行在控制台的，真正实现了"javascript running eveywhere";
本人的话对node还算是比较了解，如果大家要入手node，建议把原生JS好好加强一下，不然你连什么是异步回调都不知道，那么node你基本等于在白学。至于新版本支持的ES6，这个不用慌，ES5会了，ES6只要了解关键的区分就可以了，这个不用太过担心。而且在学node后你就会发现也有node原生和框架的分支，是不是跟其他后台语言很像了？
至于其他的框架，可能我还没有各位读者研究的深入，要我来说，学框架之前，你至少得要知道什么是开发模式，比如不管是前端还是后台必备的MVC模式。前面的文章我提到过MVC一个大致架构，包括衍生的MVVM,MVP也都是现代项目开发比较流行的开发模式。他们不是一门技术，而是一个体系，想要玩得6，就必须了解这个模式的体系，不然一切也是白搭。这也是很多JS不扎实就去学框架的，学了很久的框架，都根本不知道其用处在哪里的原因了。
像大家认识比较多的Backbone，angular， Ember等就是属于MVC的框架，VUE，recat等这些是基于MVVM的框架，但MVP的前端框架还是比较少的，但你也不用担心，框架多的是，学是学不完的，我们只有掌握了这个开发模式之后再去花点功夫了解其框架的用法，到时候就算从来没有学过这个框架，你自学起来都会跟简单。当某一天你会发现，咦，这框架跟着开发模式好像啊。那么恭喜你，你基本就掌握了这个模式的精髓了。
作为一名web前端工程师，很多人认为前端不就是用来做页面的吗。在上一篇文章我已经说过了，前端可不仅仅做页面，今天我就来简单的介绍工作中的数据处理问题。
从传统的开发过程来说，前端的主要作用是页面模板，数据渲染都交给的后端去了，到现在，还有很多公司是这种模式。如果你不幸是这个体制下的前端worder，那就要多注意了，现在主流乃至未来的前端的工作流程是怎样的了：
跟传统模式一样，第一步永远是基本的页面架构，也是我们平时比较熟悉的HTML+CSS。第二部分，也是大家学习过程中很少有机会练习到的数据传输渲染方面。那么平时具体工作中到底怎么实现这些数据绑定的了。
一般情况下，这些数据是以后台的数据接口形式传输的，数据通过用户不同的操作指令显示渲染再页面中。这个数据模型，控制，视图渲染的模式也就是我们经常听说但一直都不知道是啥的MVC模式。简单来说就是model，view，controller，包括近几年衍生出来的MVVM，MVP模式都是一种解决方案而已。对与前端来说，这些模式在前端框架出来之前是很陌生的，因为大家根本就用不上，你写的页面模板就是给后台人员做视图渲染去了。
但近几年的大环境是怎么样的，前端框架井喷式爆发，包括比较火热的vue，angular，react，等等。这些框架都各有千秋，而且基本都是基于视图这个功能，也就是说，数据渲染部分开始由前端在控制了，而后台现在在专心处理数据以及服务器就可以了。
那么我们的数据怎么接收，怎么发送了。这就需要我们了解一点基本的HTTP协议，基于TCP链接的，说简单点，也就是说通过HTTP协议访问的网站实际是在请求一个服务器上的页面资源而已，建立链接后，服务器返回资源，客户机下载资源并解析我们的前端代码。所以，前端的代码是客户机内编译的，而后台的代码一般是在处理服务器的事务逻辑。
数据最简单的就是表单传输:
<form action="/login" method="post">
<input type="text" name="user">
<input type="text" name="pwd">
</form>
上面这段代码的意思相信有基础的学员都能看懂。我们把数据user和pwd通过post传输的/login中，这个/login就是我们所说的路由了，如果后台处理了/login的post的请求，那么就可以返回原页面一个数据以表示收到了登录请求，至于能不能输入密码成功并登陆成功，可能后台会控制跳转，也有可能AJAX接受这个/login返回的结果来判断是否登陆成功或者失败；
这是最简单的方法，也是表单传输最常见的方式。
接下来另外一种方式，也就是我们很多学JS的同学比较崇拜的一个知识点：AJAX（Asynchronous JavaScript and XML）异步的Javascript和XML。
有时候我很纳闷，很多同学学这一块不知道为什么一直抓不到重点是什么，重点只有一个，异步啊！！
同样是数据传输，异步这个东西就很有意思了；传统数据IO传输方式是一个线程处理一个IO，或者说一个线程处理多个IO，如果线程不够，那么IO就需要排队。而异步最大的特点就是不排队。这个IO请求后，下一个IO请求接着上，这样就不会出现IO传输阻塞的现象，自然而然会充分利用到了服务器的性能，不浪费任何一丝资源。为什么Node现在很多在做高并发的企业在部署服务器的时候都会加入一个Node分支来处理这些高并发，这样我们服务器的处理能力以及效率相比以前的传统方法高出N倍，这样的说法毫不夸张。比如我们在网上买一个1G的云服务器，能处理的并发量可以达到40W。这个数字很惊人，这了这个概念的存在，我们再也不用担心要在昂贵的服务器上投入过多的成本了。这对后台来说，这是一个福音。
以上两种就是数据传输的方式，现在看起来是不是很简单？往往很多前端学习者JS都玩不溜就去玩框架，这是一个误区，这些框架的出现除了Node以外，其余的都是各种自身机制，各种开发模式的数据渲染，样式渲染而已，并没有多么复杂的东西。
所以，包括很多大神写的文章中提到过，我们不要因为框架忘记了我们的本身，前端三板斧HTML+CSS+JS。基础打不好，任何东西都是玩不转的。如果基础好，玩什么都是尽在掌握而已。
最近看到很多准备入行前端的小伙伴，不仅仅是我的学员，还有很多自学的。感觉慢慢都是回忆与过去啊，他们遇到的苦逼事，我相信你们也遇到过。
尤其是越往后面学代码越多得时候代码一旦出错，就基本要找好几个小时。不知道你经历过没有，反正我当年学的时候都快被虐到怀疑人生了。好吧，辛亏有我在，哈哈！
首先我们调试代码的要用到啥了，那就是浏览器的debug，也就是浏览器调试工具。个人推荐使用Chrome的调试工具，因为用的比较习惯，如果你想用火狐的firebug，我也不反对，都一样。反正都是F12快捷键，或者右击鼠标点击审查元素or检查都可以。
那么怎么用了，我现在以debug为例子。先看看它长什么样子吧：
首先关注选项卡有些啥：
也不少，而且都是英文。首先先看Elements，这个是为了调试前端代码以及样式使用的，比如说我想知道一个页面中用什么样式写的，哪些样式影响了它。很简单，你知道鼠标移动到那个地方，再右击检查：
现在，再检查右侧栏的Style里面就可以看到所有的跟这个span相关的所有样式了。我们还可以在这个样式里面去直接改变样式：
所以其实很多时候，我们都没有必要老师在代码上动刀子，如果项目比较大很容易动错地方。因为CSS不会报错，最多是无效，所以大项目一旦出错不好找出错的具体地方，所以就一定程度上考验你的HTML和CSS的设计能力了。
这些事对样式的检查，前提你先把样式基础知识学扎实，不然也是白搭哟。
除了Elements之外，另外比较常用的还有console，netWork，application,Sources这些。我都稍微简单介绍下；
console:
这一块主要是调试JS以及在这里做一些简单代码的实验的。比如我们如果想知道 123+'' 是什么数据类型的，这么简单的代码重新写一个页面去查看没必要，直接打开F12的console。可以看到会有一个空白框，里面有光标，我们可以输入内容的：
我们接着去调试我们的需求
其实我们也不需要console.log
直接干：
因为这里的typeof会有返回值出现，而回车后如果有东西出现，其实那就是返回值。很多情况我们看到返回值为underfind
实际上很多情况下一个函数没有具体的返回值得时候其实都是underfind，这个关于返回值可以以后再说
netWork：
这个是我们前端比较忽略的一点，应该如果只做页面的话，这个栏目也确实没有啥作用。但是如果在学习ajax，或者我们要去分析调用其他网站的数据API的话，还是需要了解的。这一点对于学后台的同学应该是烂熟于心了，我大概介绍一下它有啥作用。
这个栏目在我们加载完毕之后再去打开时没什么意义的，当你打开网站的时候就这个栏目就开始有变化了，它的主要目的就是抓包，抓什么了，抓的都是我们通过域名访问服务器，服务器返回的数据在这上面会全部都展示出来。这些数据包括什么了。页面也就是我们所说的html代码，其实就是主页面，然后CSS,JS，媒体文件，文档以及其他类型的文件全部都有展示，并且一些获取的状态包括途径都会很详细的展示。比如：
除了这些东西，还有很多我们前端可能会涉及的跨域或者数据API。比如百度关键字联想：
当我们点击这个url之后，在展示栏的右边关于这个数据的大部分信息我们都可以去研究的。headers是头信息，如果你不是走全栈，那么没必要去看。preview就是具体数据了，其实我们具体去看这个数据，拿到之后我们是可以用script标签访问并编译的。而大部分的后台数据其实很多都是通过JSscript方式获取访问并调用使用的，所以，这个东西需要我们好好的去了解和研究一下。
以上就是初学时用的比较多的调试菜单，今后的话，像application也是比较重要的，主要以cookie，本地存储为主。
这个debug很强大，作用不言而喻。更多的细小功能一篇文章是说不完的，基本上也适用于你找到工作之前了。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
扫一扫
1415
