为什么现代Web开发如此复杂?

为什么现代Web开发如此复杂?


image.png



源自 | vrk.dev best log译者 | 王强编辑 | Yonie前端

现代前端 Web 开发的体验是两极分化的:一些人对它的评价很高,另外一部分人则认为它很是恼人。webpack

我是现代 Web 开发的忠实粉丝,我认为它称得上是一种“魔法”——但全部的魔法都有其优势和不足:
  • 若是你能熟练使用 Web 开发的一系列神奇工具(Babel、bundler、watcher 等),就能打造出快速、强大而使人愉悦的开发流程;
  • 若是你不熟悉 Web 开发的这些神奇工具就会步履维艰;
  • 想要搞清楚这些魔法的工做机制每每是条不归路,除非有人引导你区分 Web 业内的术语、热点和过期信息。git

最近,我经常须要向新手解释“现代 Web 开发流程”的内容,可是……github

这很难解释!web

哪怕是泛泛而谈都须要长篇大论才行。npm

千里之行始于足下,本文就是针对 Web 开发演变的一系列归纳介绍的第一篇内容:静态网站到 Babel 的演变。小程序

最简单的网站:静态网站

故事要从“经典”的前端 Web 开发模式讲起,相信你们对这部份内容很熟悉了。数组

在经典的前端 Web 开发模式中,咱们会直接修改 HTML/CSS/JavaScript 文件。想要预览更改时,咱们在本地浏览器中打开 HTML 文件,更改代码后刷新页面以更新内容。浏览器

开发流程这种开发流程以下所示:
  1. 在 Atom 这样的文本编辑器中编辑 HTML/CSS/JavaScript 文件。
  2. 在文本编辑器中保存文件。
  3. 在浏览器中打开并从新加载文件。服务器

  4. image.png

编辑 JavaScript,保存文件,刷新页面以查看更新

部署

而后当你想将网站发布到互联网时,只需将 HTML/CSS/JavaScript 文件上传到网上便可。

只要使用像 Netlify 这样的服务,把包含文件的文件夹拖上去便可将页面发布到 Web 端。

如下是一个简单的示例: https://sleepy-lichterman-6811cc.netlify.com/

 简直太简单了!为何咱们还要让事情变得那么复杂呢?

若是你了解“经典”Web 开发流程的机制,你可能会问:这么简单的方法为何咱们要抛弃它?!为何现代 Web 开发流程如此复杂?

简短的答案:好吧,也许我得给出两个简短的答案:
  • 你并不必定选择那么复杂的道路。“经典”的 Web 开发流程很是棒!而且足以知足你的需求!你根本用不着添加多余的,或者你看不懂的那些工具。
  • 但对于某些项目来讲,更复杂的流程自有其好处。你添加到流程中的每项工具都是用来解决某种问题的。

为了理解现代 Web 开发的工具系统,咱们必须理解 Web 开发面临的问题。

在这段漫漫长路中咱们将逐一解决这些问题,首先来看一个已经存在了几十年的 Web 开发老问题吧。

一个老问题:JavaScript 的局限性

直到今天,JavaScript 和一系列 Web API 都有不少局限(缘由多种多样,这里就不细说了)。

举几个例子:
  • 没有模块。

  • 没有常数。

  • 没有 Promise/ 异步。

  • 没有 Array.includes()。

  • 笨拙的语法 / 缺失不少经常使用原语(没有 for-of、模板字面量、箭头函数语法、模板解包....)

  • (Web API)有无数 DOM 操做根本不必那么复杂(好比添加 / 删除类名、隐藏元素、选择元素、删除元素......)

浏览器只能执行 JavaScript,所以当限制是来自 JavaScript 语言自己时,你无法简单地换成别的语言来解决问题;你只能忍受这些局限。

 小故事:JavaScript 和 Web API 之间的区别?

你可能已经注意到我在上面说的是“JavaScript 和 Web API”。这是两件不一样的事情!

当你为网页编写 JavaScript 时,与网页自己交互的 API 调用都是 Web API(只是恰好用 JavaScript 编写而已),而不是 JavaScript 语言的一部分。

一些例子:
  • Web API:文档和文档上的方法;窗口和窗口上的方法;事件、XMLHttpRequest、获取,等等。
  • JavaScript:函数、const/let/var、数组、Promise,等等。

好比说你正在写一个 Node.js 服务器,你会用 JavaScript 编写,意味着你可使用 Promise 这种东西,但不能使用 document.querySelector(这样作也没有意义)。

古老的解决方案:jQuery和它的小伙伴

jQuery 早在 2006 年就诞生了:它是一个用来解决 JavaScript 和 Web API 中许多缺陷的库。

jQuery 中的 API 对常见 Web 任务助力颇大,如 DOM 操做、异步处理、处理跨浏览器差别和资源获取等。

基本上来讲,虽然用旧的 JavaScript/ 旧的 Web-API 处理这些事情在技术上都是可行的,但它们很是烦人、无趣,并且每每很难编写——因此为了把 Web 开发者从编写头疼代码的负担中解放出来,你能够下载 jQuery 库并用它的精美 API 来处理 JSON 文件之类的任务。

新的解决方案:改进JavaScript自己

可是今天距离 2006 年已经好久了!

自 2006 年以来,JavaScript 和 Web API 获得了极大的改进。jQuery 和不少开发者都贡献巨大!

JavaScript 是一种不断发展的语言。与软件的更新相似,JavaScript 语言也会更新不少版本。

你可能据说过“ES6”一词。ES6表明“ECMAScript 6”,指的是ECMAScript的第 6 次迭代。ECMAScript 只是 JavaScript 的另外一种叫法,区别只是人们一般使用“ECMAScript”来指代规范,而使用“JavaScript”来指代人们编写的语言。

顺便说一句,这又是一件让人头晕的事情:JavaScript 不是 ECMAScript 的实现;就像你不能把“HTML”称为“HTML”的实现同样,叫成“HTML 规范”也不行,都是错的!维基百科就写错了!JavaScript 和 ECMAScript 是一个东西。

无论怎样,ES6(2015 年发布)是一次重大更新,由于它为 JavaScript 添加了不少很是好的语言功能,好比 const、模块和 Promise 等。另外 ES8 引入了我最喜欢的语言功能,也就是异步。

与此同时,自 2006 年以来 Web API 也获得了极大的改进,加入了 document.querySelector、fetch 以及 classList 和 hidden 之类的东西。

所以在 2019 年的今天,大多数状况下咱们能够直接使用 JavaScript 和 Web API,无需 jQuery 之类的库了。

……但也有例外

一个长久以来的难题:跨浏览器支持

更新 JavaScript 语言时浏览器也要更新才能支持新的语言功能。Web API 也是如此,但简单起见咱们如今只谈 JavaScript。

但如下步骤之间是有延迟的:
  1. 在 JavaScript 中定义语言功能。
  2. 浏览器实现所有功能并发布支持。
  3. 用户所有升级到最新版本的浏览器,一般经过自动更新 / 从新启动浏览器来完成(有时还作不到!)。

  4. image.png

矛盾:咱们应该用旧版 JavaScript 仍是最新的 JavaScript 编写呢?二者都有利有弊

这给 JavaScript 开发人员带来了两难的处境:咱们但愿使用现代化的 JavaScript 语言功能,由于这些改进一般会让某些内容编写起来更容易。但咱们也但愿网站可以为全部用户服务,无论他们是何时重启浏览器更新版本的都应该看到一样的内容。

这种困境一般要由 Babel 来解决。

Babel 是一个 JavaScript 编译器,能够将 JavaScript 代码转换为... 不一样的 JavaScript 代码!具体来讲,它能把用最新版 JavaScript 编写的 JavaScript 代码转换为被更多浏览器支持的旧版 JavaScript 等效代码。image.png

Web 开发人员将 Babel 整合到流程中,就可使用最新的 JavaScript 功能编写代码,无需担忧浏览器兼容性。

 小故事:Babel 不包括 Web API

例如,若是你在 JavaScript 中使用 fetch,Babel 将不会提供兼容性支持(兼容支持也称为“polyfill”-ing),由于 fetch 是一个 Web API 而不是 JavaScript 自己的一部分。他们正在从新考虑这个决定: https://github.com/babel/babel/issues/10008

所以你还须要一个独立的解决方案来 polyfilling Web API!以后的文章中咱们会谈到这一点。

再来看流程:静态网站 +Babel

好的,因此如今咱们已经知道为何要用 Babel 了。那么使用 Babel 的 Web 开发流程是什么样的呢?

如下是最简单的 Babel 流程,人们一般不会用它。(由于像 Parcel 或 webpack 这样的包更方便,咱们之后会提!)

安装
安装 Babel

能够按照 CLI 说明(详见下方连接)操做,但它假设你了解 npm 的机制。他们建议你在本地安装 Babel 做为每一个项目的 npm dev 依赖项,而不是在你的计算机上全局安装。

CLI 说明: https://babeljs.io/setup#installation

 开发流程

  1. 像普通的静态网页同样开发你的网站。

  2. image.png

示例:src 目录是你的 JavaScript 所在的位置

 部署

当你准备将网站发布到互联网时,不可能直接把写好的 JavaScript 文件上传到 Web 端,由于你一直都用的是全部浏览器都不支持的 JavaScript 功能。

你要作的事情是:
  1. 使用 Babel 编译 JavaScript,以得到与浏览器兼容的代码:

  2. image.png

这将在单独的文件夹中建立新的编译好的 JavaScript 文件:image.png

示例: Babel 将生成第二个“script.js”,该脚本具备跨浏览器兼容的代码
  1. 将编译好的 JavaScript 与 HTML 和 CSS 一块儿上传到互联网:

  2. image.png

编译好的 JSimage.png

加上你的 CSS 和 HTML 文件

你的网站看起来和动起来都和开发模式中的同样,但用户拿到的是 Babel 编译过的 JavaScript。
  • 这是没有 Babel 的项目:https://sleepy-lichterman-6811cc.netlify.com/script.js

  • 这是用了 Babel 的项目:https://zen-lamarr-b74cd8.netlify.com/script.js

    (希望如此!有时调试和发布版本会有差别,但这些都是错误!)

 停一下,谈谈开发代码与发布代码 image.png

请注意,咱们如今将“开发”代码和“发布”代码区分开对待:
  • 开发代码:你在开发 Web 应用程序时编写的代码。
  • 发布代码:用户访问你的 Web 应用程序时要运行的代码。

咱们有意区分这二者,由于:
  • 开发代码对开发人员有利,但对用户不利。
  • 发布代码对用户有利,但对开发人员不利。

在前端 Web 开发中,不是每一个人都会用或者须要 Babel。

但下面的模式:
  • 编写不向用户显示的开发代码
  • 而后编译成另外一个版本的发布代码 显示给用户。

不只很常见,并且在现代前端 Web 开发中常常会用到。

请注意,区分“调试”与“发布”构建是软件工程中的经常使用模式,并非 Web 开发引入的新事物。但它特别适合前端 Web 开发,由于它太常见了,并且前端 Web 开发的调试 / 发布版本之间区别巨大。

下面是一个简短的前端技术列表,能够用来区分调试和发布版本:
  • npm 模块
  • 各类 CSS 预处理器

  • React/Vue/Angular/ 各类 Web 框架

以后的文章会反复提到这种模式,因此如今好好记下来!

英文原文: https://www.vrk.dev/2019/07/11/why-is-modern-web-development-so-complicated-a-long-yet-hasty-explanation-part-1/

  活动推荐

游戏大佬,很久不见!8 月 17 日下周六 13:30-18:00,在广州南国酒店的 “小程序·云开发”系列沙龙(小游戏专场),咱们邀请来自微信团队与腾讯云团队的资深工程师们将就游戏话题与你一同探讨,并经过 Workshop 上手开发一款属于本身的小游戏呦~ 扫描下图二维码和阅读原文连接免费报名参加。

报名到场还有机会赢取小霸王游戏机、华为无线充电器等超值礼品。

相关文章
相关标签/搜索