专治前端焦虑的学习方案

20

本文翻译自A-Study-Plan-To-Cure-JavaScript-Fatigue。笔者看到里面的几张配图着实漂亮,顺手翻译了一波。
本文从属于笔者的Web Frontend Introduction And Best Practices:前端入门与最佳实践

最近我也读了Jose Aguinaga的博文2016年里做前端是怎样一种体验。这篇博客引发了广泛的关注与讨论,无论是在Hacker News还是Reddit还是Medium上,都有很多人参与到了它的讨论中。我也是很早之前就感觉到了目前JavaScript生态圈中的群雄逐鹿,并且我还特地对目前JavaScript库流行现状进行了调查,希望能够在异彩纷呈的各式各样的库中寻找到真正的为大众所接受的。不过今天我希望能够更进一步,不仅仅再抱怨现状,而是从我个人的角度来给出一个逐步深入学习JavaScript生态圈的方案。(如果你尚对HTML/CSS/JavaScript并不了解,那么可以阅读前端攻略:从路人甲到英雄无敌)。而在文本中我们会涉及以下几个方面:

  • 一个现代的JavaScript Web应用会包含哪些部分

  • 为什么不推荐使用jQuery?

  • 为什么React是个不错的选择

  • 为什么并不需要你首先学透JavaScript?

  • 如何学习ES6语法

  • 缘何与如何学习Redux?

  • GraphQL到底解决了什么问题?

  • 下一步又会走向何方

Background

JavaScript vs JavaScript

在正式开始之前,我们先要搞清楚我所要说的和你目前理解的是不是同一个东西。如果你在Google中搜索‘Learn JavaScript’或者‘JavaScript study plan’,你能得到一坨一坨的资料与教程指导你如何学习。不过实际上在我们的真实项目中,我们只会用到一些相对简单的语法。换言之,可能你在学习Web应用编写中所需要的80%的知识点都包含在了任何一本JavaScript书籍的前几章。另一个角度来说,真正麻烦的点在于如何掌握整个JavaScript生态圈,这里包含了数不尽的框架与库。不过我相信本文可以给你一点启示。

Building Blocks Of JavaScript Apps

为了便于理解现代JavaScript为啥看起来如何复杂,我们首先要明白其工作原理。我们首先来看下2008年左右流行的所谓传统Web应用的架构:

1.服务端从数据库中获取数据。
2.服务端读取这些数据然后渲染到HTML中。
3.HTML文件被发送到浏览器,浏览器将HTML转化为DOM树并且展示出来。

现在很多的应用会在客户端使用JavaScript来保证应用的可交互性,不过本质上浏览器还是从收到HTML文件开始。下面我们再比较下2016年流行的所谓现代Web应用,典型的就是所谓的单页应用:

注意到区别了吗?与传统的Web应用相比,现在的服务端更多的承担起是提供数据的功能,而渲染HTML文件这一步交由客户端进行处理。这一个根本性的变化也会导致很多或好或坏的结果,好的一方面呢:

  • 对于某一块内容,仅仅发送数据会比发送整个HTML文件快很多

  • 以单页应用为例,客户端可以刷新局部数据而不需要刷新整个浏览器窗口

坏的方面:

  • 由于现在数据的加载与渲染放在了客户端,初始加载与渲染会耗费更长的时间

  • 现在需要在客户端提供一个存储与管理数据的地方,也就是我们目前所熟悉的状态管理工具

恶心的地方:

  • 随着客户端应用逻辑与交互的日渐复杂,你需要掌握像服务端技术栈一样复杂的前端技术栈

The Client-Server Spectrum

实际上很多才接触现代前端开发技术栈的同学,特别是才从后端转前端的同学都会有个疑问,既然这么麻烦为何还要进行转变?举个例子,如果用户希望得到2+2的结果,肯定不需要我们将这个计算发送到服务端然后等待结果,浏览器完全能够支持这种简单的计算。换言之,如果你是打算构建一个纯粹的静态内容站,譬如博客这样的,那么在服务端直接生成最终的HTML文件是个不错的选择。不过实际上很多Web应用中我们并不能很好地界定这个分割点,并且整个光谱并不是连续的,你并不能先构建一个纯粹的服务端应用然后慢慢地向客户端迁移。当到达某个分割点时,你不得不停止这种迁移过程而去重构大量的代码,或者你就会面对一个庞杂无序难以维护的垃圾代码库。

这一点与不建议使用jQuery不谋而合,你可以将jQuery看做胶带一类的存在。对于房子的修修补补很是不错,但是如果你想不断地增加内容与功能,你就会发现你的房子歪歪扭扭,到处都是狗皮膏药,越看越丑。而大部分的现代JavaScript框架则是更像3D打印技术,可能在开始之前需要大量的准备时间,但是它能还你一个更整洁稳定的房屋。

Week 0:JavaScript Basics

除非你是一个纯粹的服务端应用程序开发者,你肯定知道些JavaScript基础的内容。如果你还不是很了解的话那么也不需要担心,这里推荐个不错的教程Codecademy’s JavaScript lessons

Week 1:Start With React

在你了解了JavaScript基础语法知识之后,我推荐你下一步开始学习React

React是由Facebook开发并且开源的UI库,换言之,其专注于完成将数据渲染到HTML这一步骤,也就是所谓的View层。不过需要注意的是,我在这里并不是安利React为最优秀的库,这个是因项目而定的,不过我觉得React是个挺不错的合适初学者的库:

  • React不一定就是最受欢迎的库,不过其受欢迎程度相当高

  • React不一定是最轻量级的库,不过其谈不上是一个重量级的库

  • React不一定是最简单易学的库,不过其并不难学

  • React不一定是最优雅的库,不过其看上去还是很舒心的

总而言之,React并不一定适用于所有的场景,但是我觉得它是所谓最安全的,学了不吃亏。React还会引导你去了解一些像组件、应用状态与无状态函数等等现代Web应用框架的概念。最后,React的整个生态圈非常繁荣,你可以从Github上有关React的项目中找到很多可用的组件,或者在Stack Overflow上找到很多关于React的答疑解惑。我个人是比较推荐Wes Bos的React for Beginners这一课程。这课程包含了React从入门到最佳实践的全部知识。

Week 2:Your First React Project

到了这里我假设你已经完成了React的基础课程,如果你跟我差不多的话,那么我估计你现在的状态可能是:

  • 估摸着你已经忘了一大半学过的知识点

  • 你很想能够尽快付诸实践

众所周知,实践是学习某个框架的不二法诀,并且开始一个简单的个人项目也是学习新技术的不错的试验点。一个个人项目可以是简单的单页应用,也可能是像Github客户端这样复杂的Web应用。这里我推荐你可以尝试着去做一个简单的个人主页。不过还是要补充一句,如果你打算用React做一个简单的静态内容页就有点大材小用了,这里推荐一个不错的工具Gatsby,这是一个React静态网站生成器。

这里我把Gatsby推荐为你可以在初步实践React阶段一个不错的参考项目,主要是因为:

  • 其提供了配置好的Webpack,可以省去你很多学习配置的烦恼

  • 能够基于你目录结构动态设置路由

  • 所有的HTML内容同样可以服务端渲染

  • 生成的静态内容页意味着你可以简单地就可以部署在Github主页上

Week 3:Mastering ES6

随着我学习React的深入,我很快就感觉到了现在能够看得懂简单的代码示例,不过还有很多语法尚不能完全理解。举例来说,我还不熟悉ES6中的一些常见特性:

  • Arrow functions

  • Object destructing

  • Classes

  • Spread Operator

如果你跟我一样也不是很熟悉,那么建议可以花个几天时间来认真学习下ES6的特性。如果你喜欢上面推荐的React基础课程,那么你也可以看下ES6 for Everybody系列教程。不过如果你想找点免费的资源,那么这里推荐Nicolas Bevacqua’s book, Practical ES6.。最后,我还是想提到下对于ES6的好的学习方法就是回顾参照各种各样的代码库,学习人家的用法与实践。

Week 4:Taking On State Management

到这里我们已经能够构建基于静态内容的简单的React的前端项目,不过真实的Web应用项目不可能全是静态内容,他们需要从服务端获取数据然后交与React进行动态渲染。最直观的做法就是将数据一层一层地传递给组件,不过这很容易引发整个系统的混乱。譬如当两个组件需要去展示同样的数据时候,它们应该如何交互呢?
这也就是所谓状态管理工具的用武之处,不同于将你的数据存放到组件内,你可以创建一个独立的全局单例Store来为组件树存放状态:

在React的生态圈中,最著名的状态管理工具当属Redux。Redux不仅能够帮助你集中管理数据,还能强制使用者对于数据的修改操作进行统一规范。

你可以将Redux想象为银行,你并不能直接进入自己的账户然后修改账户中的余额,你需要通过前台来发出一系列的指令控制操作。Redux也是这样,并不允许你直接修改全局状态,你必须将Actions传入Reducers,然后由这些纯函数来返回新的状态值。这样整个系统的流程就清晰可见并且可回溯:

同样的,我们这里也推荐一些Redux 教程,以及免费的Redux作者的系列分享

Week 5: Building APIs With GraphQL

现在我们已经讨论了很多客户端开发中所需要的知识栈,不过对于有追求的前端开发者而言这远远不够。不谈整个Node生态社区,我们还需要注意这个服务端的数据是如何传递到客户端的。这里要着重介绍下GraphQL,一个由Facebook出品的可以替代传统的REST API的标准。

传统的REST API会通过暴露多个REST路由来允许用户访问些数据集,譬如/api/posts,/api/comments。而GraphQL将多个后端的REST接口整合为单个端点,允许用户从单个端点获取所需要的数据。

Beyond & Next Steps

章节所限,在我的调查里也提到VueElm都是很优秀的框架,推荐有兴趣的朋友可以了解下。另外,在学完了这些基础知识,你还可以了解以下几个方面:


如果觉得我的文章对你有用,请随意赞赏

你可能感兴趣的

14 条评论
戡玉 · 2016年11月07日

文章前面的分析还挺入好的,突然一下转到react了...我是去年转的前端,一度也对日新月异的前端非常困惑,但是现在已经没有了,我觉得前端的变化无非体现在3个方面:后端能力,工具链和业务框架。框架越来越多,也越来越好,没错;但是我觉得这种变化对于新入前端容易造成困惑和误导,整个行业技术标准和技术构成参差不齐。框架和工具诚然解决了业务和效率,但是也让越来越多前端开发者离底层越来越远,追逐框架,疲于奔命~

+2 回复

xiasf · 2016年11月03日

我是后端转过来的,前端只是皮毛,这篇文章缓解了我长期以来的一些焦虑,谢谢。我还有一个问题:artTemplate现在算是属于“2016年之前的”东西了吗,曾以为它就是DATA->DOM的完美方案,让我彻底从拼接HTML中解放了,我以为这就是最好的方案,随后就到了“2016”,就是我逐渐焦虑之后了。

回复

明就 · 2016年11月03日

artTemplate是html模板引擎,很便捷的将数据展示到页面。
我曾经也觉得它很好用,但是随着一些需求的数据量增加,以及交互逻辑逐渐复杂,artTemplate好像是不够用。目前数据视图双向绑定的框架就非常火,事实上也是非常实用。
个人角度,对于程序员,一些计算机基础理论还是十分的重要,至于用前端选用什么框架看项目。

回复

Songlairui · 2016年11月03日

已阅读,是有理清认知意识的效果的

回复

xiasf · 2016年11月03日

我可不可以这样理解,前端:浏览器展示的东西,其实不管什么技术,很多时候就是在折腾DOM,但是随着现代web前端的复杂性,传统的js , 后台渲染HTML等方式已逐渐不能满足需求了,比如Jquery,artTemplate这些可以用,但是导致项目时间久了维护复杂,不适应大型完整的项目,所以就有了“2016年”之后的变化,可以这样理解吗?

回复

paradise · 2016年11月03日

可以把现在前端的变化理解成从单纯的页面展示到MVC架构的转变,很多大型的项目需要前端支撑起复杂的交互和数据的流转,因此新技术和思想的出现几乎是必然的

回复

文若 · 2016年11月04日

先插个眼

回复

城南 · 2016年11月04日

写的不错,感谢楼主

回复

abcbuzhiming · 2016年11月04日

你这篇文章其实没解决什么问题,你只提到了为啥会出现客户端渲染这个东西,然后直接就跳到react去了。需知前端焦虑症的主要问题就是现在没有什么方案能通杀,大家都在纠结选什么。

回复

xiasf · 2016年11月06日

我觉得现在前端焦虑主要是指突然“2016”了,对于突如其来的各种技术让人无所适从,感到迷茫,这是前端发生最大的变化。至于什么能通杀,也属于这种的焦虑一部分。我也很焦虑,焦虑得不可描述,我想《2016年里做前端是怎样一种体验》这篇文章是帮我理清楚了我所困惑,和焦虑的一些原因,我觉得这一切其实还是源于自己,对自己技术的要求不够高,基础不够扎实,对新出现的技术不能快速的跟随,尤其前端技术发展得这么迅猛,这感觉就要被淘汰了一下,这才是我焦虑的根源。

回复

云巴 · 2016年11月09日

写得很好,另外有个小问题,『同样的,我们这里也推荐一些...』这半句,『同样』两个字貌似没有隔行,『传统的REST API会通过...』中『传』字貌似也没有隔行处理。另外,这篇文章可以转载到我们官方的公众号嘛?会附上本文、原文链接,本文、原文作者。

回复

lixioogo · 2016年11月13日

多谢分享

回复

lockeroots · 2016年11月27日

me too...

回复

bluedusk · 2017年10月31日

主要还是react向的介绍。 不太同意前端不需要精通javascript这个观点,如果js只知道皮毛的话,连看懂一些demo代码都很困难。其次调试的时候找问题会找到吐血。

回复

载入中...