HTTP/2
HTTP 协议已重写。这已不是文本的协议，而是二进制的。二进制协议更加高效，并且不易出错。HTTP/2连接也是多路复用的，简单地说 - 允许你在一个连接中同时传输多个响应。
The HTTP-protocol has been completely rewritten. The protocol is no longer textual, but binary. Binary protocols are much more efficient and less error-prone. HTTP/2 connections are also multiplexed which - to put it simply - allows you to transfer multiple responses simultaneously within a single connection.
另外，HTTP2 实现了服务端推送。之前我在谈 polyfill 时候所遇到的功能。
Additionally, HTTP/2 implements server-push. And this is the feature I was getting at earlier when I was talking about polyfilling.
服务端推送允许无须客户端请求的情况下服务器会发送数据到客户端。例如，客户端请求 index.html 跟着服务器响应 index.html 啊、 styles.css 啊、 script.js 啊等等，都会打包一起给你送过来。
Server-push allows your server to send additional data that the client may not have requested. For instance, a client requests index.html andyour server responds with index.html, style.css, script.js, polyfill-1.js and polyfill-2.js.
虽然这对减少体积没啥帮助，不过关键的是服务器和客户端来回之间没必要的通迅减少了很多。况且，您可以通过添加服务器端配置以匹配请求的浏览器版本来缩小大小，并动态地决定在每个客户端上推送哪些 polyfills。
This doesn't solve the application size problem, but it reduces the number of round-trips to the server. However, you can reduce the size by adding server-side configuration to match the requesting browser version and dynamically decide which polyfills to push on a per-client basis.
这就是 Webpack和其他模块加载器/捆绑器落后的地方，因为捆绑对于HTTP/2是不好的做法。 现在捆绑之所以使用其唯一原因是减少了对服务器的请求数量，但由于 HTTP/2 本身是多路复用，实现了服务器推送，并且可以独立缓存每个资源，所以不再是这种情况。 如果您要捆绑并同时使用 HTTP/2，则不会应用到 HTTP/2 提供的所有缓存功能。不妨想象一下，如果只更新一个JS文件中的一行，用户将不得不再次下载整个包（即使是没有更新的代码）并缓存它。 如果没有捆绑，只有被更改的文件才需要重新下载，从而就能大量节约流量大的网站带宽。 这也使得您的网站更适合手机用户，因为带宽和解析运算对于移动设备来说可是要相当的考虑的。
This is where Webpack and other module loaders/bundlers are falling behind, because bundling is bad practice with HTTP/2. The only reason bundling is being used is to reduce the amount of requests made to the server, but since HTTP/2 is multiplexed, implements server-push and can independently cache each asset this is no longer the case. If you would bundle and still use HTTP/2, you wouldn't get all the caching capabilities HTTP/2 offers. Because imagine if you only update a single line in a JS-file, the user would have to download the entire bundle again (even the code that hasn't been updated) and cache it. Without bundling, only the changed file would have to be re-downloaded - thus reducing bandwidth drastically for websites with large amounts of traffic. It also makes your site much more mobile-friendly as bandwidth and parsing is a huge deal on mobile.
另外，你可以针对 HTTP/1.x 访问者实现捆绑策略而对 SPDY 活 HTTP/2 访问者就非捆绑。
Additionally, you could serve a bundled application for HTTP/1.x visitors and a non-bundled application for SPDY & HTTP/2 visitors.
HTTP/2 已经得到浏览器广泛的支持。写作之时，70.15%的访问者已经对新协议得到支持。关键问题在于主机供应者这网站站长没有把 web 服务器配置好而已。
HTTP/2 is widely supported by web browsers already. At the time of writing, 70.15% of visitors has support for the updated protocol. The problem is that hosting providers and website owners haven't enabled it in their web server configurations yet.
程序结构 Application structure
当你开始一个项目的时候，提前计划和评估需求自然必不可少。 如果这是一个真正的单页面网站，你肯定不需要一个框架。 一 个index.html，样式或加点的脚本就足够了。 例如，如果您想使用 Stylus 和 ES2015，则可以使用 npm init，安装 Babel 和Stylus，并在 npm 运行脚本中使用它们的命令行版本。 您也可以添加一个更快捷的开发环境的监视。
When you start a project, it’s always a good idea to plan ahead and estimate roughly what you need. If it’s a truly single page site (1 page), you definitely don’t need a framework. A single index.html, styling and optional script is enough. If you want to use Stylus and ES2015 for example, you can npm init, install Babel and Stylus and use their command-line versions in a npm run script. You could also add watch for a more snappier development environment.
package.json :
{
...
"scripts": {
"build": "babel src -d dist & stylus src/styles -o dist/styles & cp src/index.html dist/index.html",
"dev": "watch 'npm run build' ./src"
}
...
}有一个小的，但不错的 Gist，你可以看看更多的片段。
npm run build and you have a production-ready build.
There's a small, but great Gist that you can look at for more snippets.
包管理器和模块加载器 Package manager & Module loader
当您的应用程序变大时，可能会使用包管理器。我推荐JSPM，因为它基于SystemJS，而SystemJS则基于标准的ES6模块加载器规范。
不过要知道，这会遇到和 HTTP / 2 支持的Webpack 都相同的问题，所以不妨使用 NPM 并构建一个简单的脚本，在构建期间复制所依赖的关系。
When your application grows large, it could be an option to use a package manager. I recommend JSPM as it is based on SystemJS which in turn is based on the standard ES6 module loader spec.
Know though that this introduces the same problem as Webpack with HTTP/2 support, so you might as well just use NPM and and build a simple script that copies your dependencies during build.
使用库的复制粘贴来处理依赖关系不是个好方法。这就是浏览器的包管理器一直存在的问题，当前的包管理器实现（除了bower）由于支持模块加载而在生产版本中注入某种脚本。由于不同模块格式的 cheer 量，模块加载引入了许多问题，并且在HTTP / 2中目前不能很好地运行。在这个问题得到解决之前，你可以像我刚才提到的那样，在NPM中留下来，或者复制粘贴你需要的东西。这当然也是一个应用程序大小和依赖关系的问题。
Using copy-paste of libraries is not a bad way of handling your dependencies. That's the way it was before package managers for the browser existed and the current package manager implementations - except for bower - inject some kind of script into your production build due to having support for module loading. Module loading introduces many problems due to the cheer amount of different module formats and does not currently play very well with HTTP/2. Until that's fixed, you may as well just stay with NPM as I mentioned earlier or copy-paste what you need. This is of course also a question of application size and the amount of dependencies you have.
小结 Conclusion
我真的希望，你至少再试一次原生Web开发，我都说了那么多了。如果你出于某种原因不习惯原生的 Web API 或 DOM API，并想坚持你的框架，我不会责怪你。做你自己感觉舒服的事情，并尽量做到最好！最后，我想道歉，这必须是一个不严谨的帖子。干杯，汤姆。
I really hope that I've inspired you to try out native web development at least one more time. If you for some reason don't feel comfortable with the native Web APIs or DOM APIs and want to stick to your framework, I don't blame you. Do what you feel comfortable with and try to make the best out of the situation!Lastly, I want to apologize that this had to be a Slack post.Cheers, Tom.
更新 UPDATE:
我读了一些关于 React 的评论和反馈。我很抱歉，我没有深入了解，但现在尽可能多地尝试。尽管如此，请注意我原文并不是说你的框架不好，而是要问你自己，如果你真的需要它。想一想，打开心扉，试着自己写 JavaScript，原生 Web API 和 DOM API重新构建旧项目。你觉得需要多少时间？你将节省多少带宽？它会更复杂吗？我明白，React 只是视图层，但实际上你们中有很多人正在使用像 Redux 一样的东西 - 以及其他插件。其结果是一个相当重的应用程序。
React 不是关注性能的，它是关心处理 UI 状态的，这是道难题。
I've read some comments and feedback about mentioning React. I apologize that I didn't go more in-depth into it, but I'll try to cover as much as possible now.Note though, that my message for you was not that your framework is bad - it was for you to ask yourself if you really need it. Play a bit with the thought, open your mind and try to picture yourself re-building your previous project using vanilla JavaScript, native Web API and DOM API.How much more time do you think it would take?How much bandwidth would you save and would it be much more complicated?I understand that React is only the view-layer, but in reality many of you are using things like Redux with it - along with other plugins. The result of that is a pretty heavy application.
React is not about performance, it's about handling UI state, and that is hard.
是的，但这不是我的意思。 UI 状态对于您的应用程序的大小并不困难。一个普通的JavaScript对象拥有最高级别的状态，并且使用 Object.observe（或者 Proxy，用 Object.observe 大概过时了）已经足够让您在组件之间实现自动 UI 状态同步功能。它不一定比这更复杂。我完全可以理解为什么像 Facebook 和 YouTube 这样的大公司需要这样的功能，但是这对于你的博客编辑或者7类网店来说是没有意义的。
构建你自己的实现会使下一个进来维护你的工作的人很难。
Yes, but that's not my message for you. UI state isn't hard for the size your applications are. A plain JavaScript object holding the top-level state, and using Object.observe (or Proxy since Object.observe has been made obsolete) should be more than enough for you to implement automatic UI state synchronization functionality, across components. It doesn't have to be more complex than that. I can definitely understand why large companies like Facebook and YouTube need such functionality, but it doesn't make sense for your blog editor or e-store with 7 categories.
Building your own implementations makes it hard for the next person that comes in to do maintenance of your work.
这确实是一个问题，但是通过适当的评论和文件，它不应该是。这不像你正在编写一个新的框架 - 你正在为你经常重用的功能编写包装。最后，它是普通的JavaScript和Web API。仅仅因为你不再使用框架并不意味着你必须构建一些过于复杂的东西。如果你是财富500强公司的一员，要做项目，你可能会编写自己的框架，因为Facebook解决方案可能无法解决你的问题。
当图像> 500KB时，JavaScript大小就无所谓了。
That is indeed a problem, but with proper commenting and documentation it shouldn't be. It's not like you're writing a new framework - you're writing wrappers for functionality you often re-use. In the end it's plain JavaScript and Web APIs. Just because you don't use a framework anymore doesn't mean that you have to build something overly complex. And in the case of your web app becoming part of a fortune 500 company, you'd probably write your own framework either way as Facebooks solutions would probably not solve your problems.
JavaScript size doesn't matter that much when there are images > 500KB.
不幸的是， JavaScript 引擎必须解析，解释和执行代码。大多数框架在 DOM document 的启动阶段执行繁重的任务，为第一次渲染增加了更多的时间。即使他们有很好的联系，这在移动设备上也是非常糟糕的。
它会变成坏的，意大利面代码 - 不可能继续维护开发。
Unfortunately it does. The JavaScript engine has to parse, interpret and execute the code. Most frameworks runs heavy tasks in the startup-phase of the document, adding even more time to first paint. This is really bad on mobile, even if they have a good connection.
It will turn out bad, spaghetti code - impossible to continue development of.
对于初学者，你必须学习如何编写干净，可重用的代码。如前所述，多写文档！
你还没有建立任何复杂的应用程序。
For starters, you've got to learn the how to write clean, reusable code. As mentioned earlier, document your code!
You haven't built any complex applications.
我已经构建了一些实时同步的脱机支持，通知和数据的复杂应用程序。真的不知道该怎么回答，感觉就像一个完全不相干的问题。我曾写过 Angular，React，Aurelia，Angular 2.0，jQuery和Polymer，感觉都不好弄，Aurelia可能是我最喜欢它的不显眼的东西。
I've built a few complex applications with offline-support, notifications and data that is synchronized in real-time. Don't really know what more to answer, feels like a completely irrelevant question.I've worked with Angular, React, Aurelia, Angular 2.0, jQuery and Polymer. None of them are very pleasing to work with, Aurelia is probably my favorite for its unobtrusiveness.
我想说的是……My message for you
我想说的并不是指你的框架太糟糕，我想激发你再次尝试原生的DOM和Web API的欲望。有很多新功能和东西，你可能还没有看到。
My point was not that your framework sucks or anything like that, I wanted to inspire you to try out the native DOM and Web API again. There's a lot of new features and stuff that you probably haven't seen yet.