听说2017你想写前端?

640

不好意思,没有像其他公众号一样赶着发文章,每年到这个时候总有一大波什么今年前端预测,技术框架预测什么的。我这次写这篇文针对的对象,是想在今年踏入前端这行的人们,不管你现在是徘徊在门口,还是已经半只脚踏入这片未知领域,都可以参考一下先行者的经验。

先来个大概预览:

  • 项目工程化
  • 发展方向
  • 职业环境
  • 总结要掌握的框架/技能

小结放在前:

  • 2017的前端与其说更残酷,不如说更规范化,前两年各种培训了几个月就出来随口开价上万,几万的新手将被市场淘汰。
  • 前端开发工具/编译工具 逐渐成型,虽然比不上object-c, java, C+ 等排名靠前编程语言有完善的IDE环境,但是。工程化模块化的概念开始深入人心,这年头还编写原始HTML CSS Javascript 代码的,要么就是小项目,要么就是新手。
  • 前端的工作更具有挑战性,方向更多样化

假设我今年要入WEB前端开发的坑

这里强调web前端是因为,现在很多iOS,安卓开发加入大前端的这个称呼。主要是因为React同构的出现吧,很多开始混合在一起了。

首先我们来回顾一下我们老同学印象中的前端:

  • 老古董: PS切图导出
  • 新手小白:  Adobe Dreamweaver 写代码
  • 懒人: UltraEdit, notepad++ …

或许你精通之后随便找个能敲字的东西就可以开始写代码,但是我遇到过一个有着多年丰富经验的前端老前辈,就是因为懒惰打开编辑器,手写了一段代码也没有检查,就直接提交,然后不小心敲错字符,导致整个项目差点烂尾的事情。真正厉害的人,任何时候都应该是非常谨慎的。 请善用IDE的查错纠错功能。

跟以往不同,如果你今年要开始web前端的开发(下面都简称前端),那么至少你是不用去折腾太多的浏览器兼容,但并不是完全不需要去关心,只是开发环境不像以前那么多坑,因为各种编译器的出现。

前端面对的国内最严峻的挑战是:

落后的浏览器版本迭代。
我拿到过国内某500强手机企业的手机,我一看自带webkit内核,居然是2003 的 Releases 版本 webkit. 我当时是比较震惊的,毕竟安卓内核也是 4.x, 我至今不知道他们是如何做到把一个那么旧的浏览器内核塞进一个比较新的安卓系统的,也不知道这么干是几个意思,当然即使是高通soc基带,要升级一下系统也是登天还难,更别说其它soc基带。

安卓版微信在截稿之前是大概Chrome35的版本(最新是Chrome55) 并且持续了1年不变,据说是为了稳定。

UC,百度,等套壳浏览器大行其道,但它们调用的只是系统的浏览器内核,你别跟我说优化了加载速度什么东西,加载速度是网络状态、系统硬件决定的,跟你一个套壳浏览器有半毛钱关系?所以我不知道它们几十兆容量到底写了什么东西,细思极恐。

总之,在桌面时代,我们面对的是IE6,7,8这个毒瘤, 在移动时代我们面对的是安卓这个毒瘤(限国内)

推荐两款编辑器:

  • ATOM 目前最热门的编辑器
  • Sublime text 良心编辑器,虽然是收费的,但不强制,偶尔提醒而已
  • vscode 基础插件完善但第三方插件更新缓慢
工欲善其事,必先利其器。

前端框架的高速发展,意味着各种插件的不断快速迭代,那么Dreamweaver这种半封闭式的大型工具,虽然单方面很强大,但明显版本更新跟不上社区更新的脚步,即使我装了最新的2017版本体验了一下,我也觉得它无法胜任这个时代了

项目工程化

避免毫无意义的报错

老实说,虽然前端开发工程化的概念终于开始普及,是一件好事,但事实上还是属于初级阶段,对入门新手并不友好。还不能像xcode一样,直接建立一个工程,然后配置,然后就一条龙写代码搞定,虽然 macOS 平台有个CodeKit已经做得非常好了,但由于更新力度跟不上各种框架发展的速度,所以,也只是能参考。

现在写前端,你起码要建一个本地运行环境(localhost) 之类的。这是非常非常基础的东西,请不要 再像以前那样,双击HTML去预览你写的代码,有个问题我在一些群里回答新手不止上百次: XXXXX  is not allowed by Access-Control-Allow-Origin , 基本上99% 就是直接双击HTML导致的(剩下1%是http跨域之类的)

既然都要建立 localhost 了那么部署 IIS , os server, 之类的,都是非常麻烦的一件事至少我觉得是。 并且还涉及到一些付费软件之类的,成本上升不少。

得益于nodejs的发展,现在 Browsersync , webpack dev server都能快速的部署起一个工程目录,前提是你装了node。

前端不再直接编写CSS,HTML,JS

虽然这个小标题写得有点夸张,但是一个趋势。
浏览器运行铁三角:css html js,这些必须文件,如果现有浏览器保持不变的话,那么以后的工程师,奖越来越少直接编写这些文件, 转而通过 编译工具,选择一款自己喜爱的新兴语言去编写,然后编译成浏览器可以认识的铁三角文件,当然不排除以后浏览器可以直接运行 less、scss、ts 等文件,这都是有可能的。

最有名的例子就是 jQuery 的语法被ES2015 甚至被新时代的浏览器吸收并内置原生支持了(以前甚至传出浏览器要内置jQuery)

CSS:

现在大部分都是通过 less、scss、sass 等去编译成普通css文件
然后通过著名的postCSS插件,补全各种浏览器前缀。
举个例子:

在less文件我们这么写:

编译出来的css是这样:

😓 这效率,这补全,你手写要写多久? 搞不好还写漏。 所以,无论是出于对老板给你的工资负责, 你父母给你生命负责,还是你自己对你的身体负责,都请采用编译工具去书写你的css,html,js。

上面是用css做例子,

还有针对 HTML 的  pug (以前叫jade), HAML
针对JS的 typescript, coffeeScript
不过这里js我要特别说一下, 新版本的ES6,ES7,其实已经非常完美了,
语法模块化什么的应有尽有, 然后通过著名的 Babel 编译器,编译成现在流行浏览器兼容的版本即可,虽然typescript我觉得蛮不错的,但个人觉得这个就没必要增加团队学习成本了,除非你个人爱好。

大型项目无法避免 MV* 工程

从 Ajax 的兴起, requirejs 的新兴思维模式一些专用术语就不逼逼了
随着前端的发展,nodejs 的成熟,前后端分离势在必行,那么前端项目越来越复杂,一个健壮清晰的模块体系非常重要,不然随时会把自己做蒙。

现在流行的 MV* 框架有

  • Angular 2
  • Vue.js 2.0
  • React
  • React-Native

注:MV* 框架一般指 MVC、MVP、MVVM 这些,具体什么意思,其实懂了也没啥意义。

我个人看好 vue2,还有它的全家桶

这些框架,无法避免需要编译器,需要工程目录,需要nodejs。

Koa2, Express 我就不说了,有兴趣的人自己去研究但也是后期要学的

所以现在入门,工程化你的项目,势在必行,别嫌麻烦。当然这里只指出路子,并不进行深入介绍,会在以后单独一篇介绍如何开始工程化你的项目。

发展方向

前端一直有2个方向:

  • 交互向
  • 数据向

不黑不偏,交互向是非常难走的一条路。也是非常缺的。
总之,选择一条你喜欢的路,并坚持走下去就对了。这里说说这两个方向今年的一些趋势吧。

交互向

16年大热的东西,无疑就是VR,大概在 2013年的时候,Google的工程师热推过一波webGL,但是各种性能跟渲染问题那时候没有完全搞定。(其实我觉得现在也没搞定)
但无论如何 webGL 必将大热。

就目前来说比较能继续跟下去的就是
Three.js还有 Mozilla 搞的A-frame,
特别aframe最近动作很大,都配合 threejs 搞起webVR
但是我在这里还是建议大家先学webGL再玩webVR.

很多人不知道怎么没开始webGL,确实一大堆三维矩阵算法定点渲染一开始就能把人看晕,但是别怕,试试看 blender 这款开源建模软件, threejs 也是有针对这款软件的导出插件。 blen4web 虽然收费,但也是可以参考。

其它的库要么就弃,要么就突然没下文了。

当然技能与财力突出的朋友可以去尝试 unity3D

小提示:尽量在手机上尝试, 现在的 Retina 桌面显示器…webGL真心带不动,别说web了,原生的3D渲染在Retina显示器上都很难,不过可以设置参数1倍渲染,只是丑了点。

顺带说一句,你以为交互向的,就不用学数据向的东西? 不要天真,该学的还是要去学,所以我说路不好走。

数据向

毫无疑问,这是应该算是大家都认同的正统路线,也是发展得非常全面的一个方向,路已经有很多前辈踏平了。各种 MV* 框架, 各种服务端node中间件,大前端一下子吞并了本来后端要干的大部分工作。
前后端分离开发势不可挡,大数据可视化依旧是非常热门
如果一切顺利的话,这个方向的人学一下D3.js会利好升职加薪。

题外话:有个叫微信小程序的东西,大家可以作为技能提升去研究研究。

Chrome PWA 项目其实大家有时间也可以作为技能提升去看看。

作者个人观点:搞那么多事,还不如做好 Add to homescreen 的功能。有时候真感概Chrome在国内真不接地气。

职业环境

现阶段就业环境其实非常合适入门前端,扫清了微软三大毒瘤 浏览器(淘宝率先不支持IE8 ,干得漂亮), 即使在移动端webkit内核不是很完美的情况下,你依旧可以书写出很多你要的web效果,反正老版本的内核的那部分客户对象,根本不能给你带来任何利润,不如直接放弃。因为只有最新技术才能给你带来利益,成就感。

前端各种工具也渐渐给前端开发带来便利,虽然前期部署起来确实麻烦,但试问一下,你连这点耐心都没有,我实在看不到你的未来在哪。

然后我们要面对的,也是一个不可抗力因素,我这里不是怂恿你们干什么事,有时候一些封锁,错误的封掉了一些学习资料。这个请自己务必不要放弃,找方法突破封锁,我就举个例子,假设你要用 npm 安装 node 模块。那么首要面对的问题就是某些不可抗力的封锁,还有运营商的QoS限制,有些朋友向我推荐 yarn, 我亲身试过,也是被封得一塌糊涂。

这里我觉得可以曲线用npm, 非常感谢淘宝 fork 了一份 npm。 称之为 cnpm, 他们的网址是 npm.taobao.org  具体使用方法我不多讲自己看。

然而有时候这并不能满足我们的需求,例如命令行下的一些操作。

假设你有 SS 这种梯子。
那么你可以在命令行下做一些临时的 proxy 设置:
MacOS 终端(假设你梯子的端口是1087):

Windows 命令行(同样假设你的端口如下):

然后就可以愉快地 $ npm xxxxx… 或者 ATOM 的升级 package 也能这么干。

题外话:ATOM升级package不顺利的话,用这个方法然后命令行

总结:掌握的框架 / 技能

  • 要会部署nodejs环境
    • webpack
    • babel
    • gulp
    • postCSS的插件
  • CSS:Less, scss
  • HTML:pug, haml (可选)
  • Javascript: ES6, ES7
  • WebComponents (可选)
  • Vue.js / React (反正掌握一款MV* 框架是必要的)

对了还有即将大热的 hotfix, 代表作有:阿里热修复技术,据说饿了么,腾讯也出了。没去关注,但我个人觉得这个 apple 不会坐视不理的,毕竟你可以随时服务端修改APP绕过审核,这种外道招数我觉得可以学学但不要认真。

其它:

Angular 2 被小编你吃了?
Angular 3 开发组告诉我,你又得像 ng1 转 ng 2 一样, 从头学一次。 so…你们玩得开心就好,真的,我的项目连平滑升级都做不到,我真心没办法陪你们玩。

jQuery 要死了? 要死了啊!?
哥,稳住。不会死,即使死了,也是融入到原生支持,如果你要从jQuery过度到原生,叔叔推荐网址你去学,别怕:

说好的交互向呢?你上面说的都是数据向。
AE + bodymovin( https://github.com/bodymovin/bodymovin ) 去学,

svg不可少,

sketch 是神器,

webGL 见仁见智,但是自从2016年第二、三季度,各大科技巨头公司都在技术积累,你懂的。但真心不强求。

然后就是把数据向的也学了。

3 30 收藏 10 评论

相关文章

可能感兴趣的话题



直接登录
最新评论
  • 韶光密林   01/17

    谢谢楼主分享的前端学习方向

  • 王念一 高一学生 01/17

    呵呵

    原作者這麽説未必太過武斷

    像我這種沒事閑的整天寫原生代碼段的人基本上就是本地+鐵三角了

  • 风羿 测试 01/20

    分析的不错,但有一点不太赞同!无论原生是否流行,都是必经阶段,上来就直接各种工具各种中高端技术,对新人其实并不好,地基扎实了,楼层才能高,不要只关注地面上的华丽和便捷,这些都需要地下的地基来承载,一句话“夯实基础”很重要,否则后期回头补修基础会很痛苦的!

    • 风羿 测试 01/20

      要知道,前端技术飞速发展,工具和技术层出不穷,不段更迭,唯有基础是通用的!你是想一直停留在不断学习新工具中还是在有一定基础的情况下做到游刃有余呢!当然,还是看你自己的选择,喜欢就好!

  • 没有angular3,下一代会是angular4或者叫angular

    Angular 4将尽可能兼容Angular 2

    出处:http://www.infoq.com/cn/news/2016/12/angular-4

  • 菊千代1990 前端 01/22

    看了这篇文章我有点慌

  • 好文章,对我来说很及时,那个工程化的文章在哪里

  • 康桥河下   02/14

    前端太杂了,今年争取多学点

  • nicholaslee119   02/15

    其实,业界有很多人不推荐使用CSS预编译器,或者说要在合适的地方使用预编译器。不要一味的使用它们。

    以下摘自《CSS secrets》

    Should I use a preprocessor?

    You lose track of your CSS’s filesize and complexity.
    Debugging becomes harder.(Sourcemap is cool)
    They introduce some degree of latency in our development process.
    We are either restricted in our choice of collaborators or need to spend extra time for training.
    The law of Leaky Abstractions: “All non-trivial abstractions, to some degree, are leaky”
    There is already a draft about variable-like custom properties.
    The function calc() is well supported.
    The function color() function in CSS Color Level4
    Nesting is also under discussion.
    Note that native features like these are generally much more powerful than the ones provided by preprocessors.
    Their use needs to be a conscious decision.To avoid dependent on preprocessors.

    • nicholaslee119   02/15

      Because most of the aforementioned native CSS features are not well supported today, in many cases using preprocessors is unavoidable if main- tainability matters (and it should). My advice would be to start off every project with pure CSS, and when it starts being impossible to keep it DRY, switch to using a preprocessor then. To avoid becoming completely depen- dent on preprocessors or using them when they are not actually needed, their use needs to be a conscious decision, not a mindless first step performed by default in every new project.

跳到底部
返回顶部