现在互联网发达的时代，大家都会有很多的群，xxx 交流群、xxx 技术交流、xxx开发群、xxx技术学习群等，大家的初心可能都是想交流的，遇到点问题然后就可以在群里问。 然而很多时候你问的问题没人回答；也有时候问了半天还是没找到答案；也有时候当你把问题发出来了，别人正准备回答你的时候，你说知道了；然后刚开始群里很活跃，慢慢的就死了。 其实以上问题，都是大家不想看到的，然而在群里提问是我们加入群的初心，但是很多人做不好，最终导致你的问题无人解答，群慢慢的失去意义。 今天我所谈的就是群里提问的艺术，让你的问题快速得到解决。 我将今天的问题分成以下三部分进行介绍： 提问之前 提问之时，怎么提问 注意事项 提问之前 在群里提问之前首先我们应该做好功课，看自己是否完成以下步骤，否则你的提问将一塌糊涂，大概率得不到想要 的答案。 尝试自己解决 不能自己解决应该准备的哪些 尝试自己解决 尝试自己解决是非常重要的一步，这也是我们能否经过这个问题能够成长的关键所在。 通过搜索引擎搜索：baidu 或者 google(推荐)，搜索结果中前三页如果找不到你想要的信息，就进行下一步吧。对于成熟的开源项目，你遇到的问题，很可能别人也遇到过。这时通过 Google、StackOverflow 等网站的搜索服务，可以帮你快速定位并解决问题。永远记住，地球上的你并不孤单，包括你遇到的问题。 **查阅手册/文档：**确保自己阅读过至少一次官方文档。这样在遇到问题时，如果能回忆起只言片语，就可以再去读一遍相关文档，问题往往也就解决了。 **查阅社区/论坛：**阅读常见问题文件（FAQ）或者开源项目的 issue，或者论坛(类似 react china) **询问朋友：**如果你使用的开源软件，在朋友圈或同事圈里也有人使用，那么抬起你的脚、或拿起你的电话，真挚诚恳的探讨不会遭遇拒绝，而会增进友谊。不要犹豫，你的内心渴望面对面交流，你的朋友也是。 **自检并不断测试：**试自己检查或试验以找到答案。 **阅读源码(这步非必须)：**如果你是程序开发者，尽量尝试阅读源码以找到答案。 经过以上 6 步或者 5 步你都无法解决遇到的问题，那么你确实针对这个问题能力有限，准备去群里请教了，那么在尝试自己解决之后无果，应该做哪些准备呢？ 不能自己解决应该准备的哪些 一定要明白自己想要问什么问题：不能自己都说不清自己想要问什么问题，那么群里提问你也问不出什么来。 梳理准备您的问题：要说明之前你都干了些什么。 要用言简意赅的语言：这个是我们作为职场一个必备的技能，说重点，言简意赅。 怎么提问 抱着平和对等的心态，找到合适的途径后，就得静下心来将遇到的问题写成文字。书写文字不是一件简单的事情，我们可以从遵循一些简单的规则开始。 用词准确，问题明确 标题要简洁清晰，要言之有物。 Bad：救命呀/急/跪求，遇到了一个 react 问题，xxx 组件渲染不出来 Good：在使用 xxx 版本的 react ，我操作了 xxx，也写了 xxx，但是 xxx 组件渲染不出来 一个好标题范例是目标 —— 差异式的描述，许多技术支持组织就是这样做的。在目标部分指出是哪一个或哪一组东西有问题，在差异部分则描述与期望的行为不一致的地方。 描述清晰，信息充足 **准确有效的信息：**描述事实，而不是猜测，如果你想给出你的猜测，一定要先描述事实，给你的猜测一些证据，不然就不要猜测。 **问题表现/内容：**按照时间顺序列出问题症状。问题发生前的一系列操作，往往就是对找出问题最有帮助的线索。因此，你的说明里应该包含你的操作步骤，以及机器和软件的反应，直到问题发生。在命令行处理的情况下，提供一段操作记录（例如运行脚本工具所生成的），并引用相关的若干行（如 20 行）记录会非常有帮助。 **简单的做过什么尝试：**在描述你做过什么尝试的时候，简单的你描述你做了哪些尝试就行，为什么要这么做其实不是那么重要。 如果你想弄清楚如何做某事（而不是报告一个 Bug），在开头就描述你的目标，然后才陈述重现你所卡住的特定步骤。 经常寻求技术帮助的人在心中有个更高层次的目标，而他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。 玉伯有句话是这么说的： 提问者选择的路本身就是一条崎岖之路，对于要解决的问题，实际上有更好的方式。这种情况下，描述清楚目标，讲清楚要干什么非常重要。...

今天的文章是来自 medium 的一篇文章，点赞数有将近 1 万 9，所以翻译出来给大家分享一下，有些概念怕大家不了解，所以我放了一些 维基百科的解释。如果有翻译得不是很好的地方，请看原文：https://hackernoon.com/top-12-things-that-destroy-developer-productivity-2ddf0abc190 正文： 很多文章都涉及技术主管和项目经理的角色。我们经常遇到的一个共同主题是如何提高团队的工作效率。但是在你集中精力来提高生产力之前，你可能首先要考虑是什么在摧毁它，以便建立一个可靠的基础。不幸的是，即使 Peopleware 近 30 年前发布，我们也看到许多团队在一些（消极的）显着方式中遭受巨大的生产力损失！ 没有人希望程序员在没有计算机的情况下完成工作，但是有很多公司希望程序员能够在不知情的情况下完成工作。这同样不切实际。 因此，让我们深入探讨我们的 12 个阻止您的开发人员“进入区域”并提高工作效率的事项列表。我将尝试从大多数到最不具影响力的列表中优先考虑此列表。随意评论！ 如果您想知道这一切是否值得投资，只需考虑开发商的工资。生产力提高10％甚至更多！ 中断和会议 在我看来，中断是开发人员的首要生产力杀手。开发人员在中断之前不能轻易回到他们正确的位置。他们需要进入发展的思维模式，然后慢慢追溯到他们离开的地方。这可能需要超过30分钟。中断越多，挫折越多，工作质量越差，错误就越多 - 而且还在继续。 “The more times you trip me up while I’m trying to get started — the longer between each time I’m going to try. If you fill my morning with interruptions — don’t be surprised when the day is unproductive.。” –A developer on Reddit 大概意思就是说，每次被打断都要重新开始，如果你的一天里经常被打断，那么当你一天没有任何成果的时候，不要感到惊讶。 会议怎么样？会议和中断之间的唯一区别是会议是计划中断，这会使情况变得更糟。如果开发人员在处理任务时知道他们会中断，则他们无法完成任务。因此，如果他们在一两个小时内召开会议，他们将无法取得任何进展，因为大多数工程任务需要更多时间。 As Paul Graham wrote, “A single meeting can blow a whole afternoon by breaking it into two pieces, each too small to do anything hard in....

如果你觉得它很快，那么这篇文章可能就是你所缺少的 我经常听到有人在群里，或者在社区里说的一个很严重的错误，那就是说 React 的 Virtual Dom 是以快出名的，比原生 Dom 快多了，啥啥啥的，每次都一两句话说不清楚，所以下次有谁再说 React 是以快出名的，你就把这篇文章丢给他，下面进入正题。 在过去的几年里，你一直在跟踪 JavaScript 社区的发展，你至少听说过 Virtual DOM（React，Vue.js 2，Riot.js，Angular 2等等）。他们承诺（或者更确切地说，他们的宣传）更快的渲染界面，特别是更新，减少麻烦。你很快的上手了使用虚拟DOM的应用程序，这很好。几个月后，您的应用程序现在变得越来越复杂，你可能从用户交互到屏幕更新只需要一两秒钟的更新。你可能会想，这东西很神奇，应该会比 jQuery 快，但是实际上不是这个样子的。 虽然我同意虚拟 DOM 为我们提供了很多便利，但我将解释为什么我认为根据定义，更快的渲染和更快的更新是不正确的。要付出代价，其利益并不是大多数人想象或至少希望的。 要阅读本文，您需要熟悉DOM。理想情况下，您至少可以使用 DOM API。如果你只使用 DOM API 构建东西，你可能不需要这篇文章，但我仍然希望你阅读它并在评论中留下一点评语。 渲染和更新 让我们来看看手动执行 DOM 节点的创建和更新的鸟瞰图。这对于理解虚拟DOM如何工作以及它解决了哪些问题非常重要。 在谈论 JavaScript Web 应用程序时，用户界面的更改通过 DOM 操作发生。这个过程分为两个阶段： JS 部分：定义 JavaScript 世界中的变化 DOM 部分：使用 DOM API 函数和属性执行更改 性能是根据整个过程的速度来衡量的，但了解每部分的速度也很重要，以便了解要优化的内容。 有两种方法可以创建和更新DOM树的各个部分。 ①字符串方式创建 使用字符串既快速又简单，但在更新方面并不是非常精细。对于字符串，JS部分是它如此之快的原因。您可以在几毫秒内创建一段代表5000个节点的HTML。这是一个例子： const userList = document.getElementById("user-list"); // JS 部分 const html = users.map(function (user) { return ` <div id="${user.id}" class=”user”> <h2 class="header">${user....

在知乎上看到这么一个问题，觉得很有意思，以下是原提问者的见解 过去五年前端的发展过程基本上是一个工程化的过程,框架和工程化工具层出不穷。 近两年其实发展已经比较迟滞了。 框架方面:基本就是三大框架鼎立的局面,三大框架都在相互借鉴吸收,而且方向各有侧重,未来短时间内我看格局不可能有什么大变化. 工程化工具:基本上是 webpack 一统江湖的趋势,虽然有 parcel 等来小打小闹,但是生态一旦形成,没有革命性的项目是无法取代 webpack 的,而且 webpack 也在进化. 个人认为前面五年是前端生产力提高的五年,工程化使得前端的生产力得到了极大提升,但是现在也基本上是在已有的格局中修修补补了 我谈谈我对前端未来几年的发展方向的看法。 看未来的发展方向，无非就是看现在的解决方案所存在的痛点。 1. 浏览器的性能问题 做 web 前端的同学都知道，和原生的 App 相比，性能一直一个致命的痛点，如果要追求性能，肯定得用原生 App。那么在性能上，未来几年可能是一个方向。 ①前端代码编译为字节码 浏览器这几年在 Chrome 的带动下，性能飞速发展，但毕竟其核心原理没有变化，性能始终难以达到原生 App 的水平，这部分是很有可能出现大的变化的，一个可能的方向就是浏览器变成虚拟机，前端代码编译为字节码，通过这种方式来将性能提升一个等级，虽然还是难以达到原生App的水平，但已经能够满足绝大部分应用的性能需求，类似于Java对比C/C++一样。 –李运华 因为 js 是边解释边执行的，这肯定是要比编译型语言要慢，为了解决解释器的低效问题，大概在 2008 年的时候，提出了 JIT 的概念，它是使 JavaScript 运行更快的一种手段（JIT，内联缓存和隐藏类）之一，通过监视代码的运行状态，把 hot 代码（重复执行多次的代码）进行优化。通过这种方式，可以使 JavaScript 应用的性能提升很多倍。 但是时至今日，还是觉得不够快，所以各大浏览器厂商开始支持 WebAssembly。WebAssembly 是一种新的字节码格式，主流浏览器都已经支持 WebAssembly。 和 JS 需要解释执行不同的是，WebAssembly 字节码和底层机器码很相似可快速装载运行，因此性能相对于 JS 解释执行大大提升。 也就是说 WebAssembly 并不是一门编程语言，而是一份字节码标准，需要用高级编程语言编译出字节码放到 WebAssembly 虚拟机中才能运行. 他的优点就是： 体积小：由于浏览器运行时只加载编译成的字节码，一样的逻辑比用字符串描述的 JS 文件体积要小很多； 加载快：由于文件体积小，再加上无需解释执行，WebAssembly 能更快的加载并实例化，减少运行前的等待时间； 目前可以编译成为 WebAssembly 字节码有 ：AssemblyScript(语法跟 TS 差不多，)、c\c++、Rust、Kotlin。...

JavaScript ES6 带来了新的语法和新的强大功能，使您的代码更现代，更易读。它允许您编写更少的代码并执行更多操作。 ES6 向我们介绍了许多强大的功能，如箭头函数，模板字符串，对象结构，模块等，让我们来看看。 const and let const 是 ES6 中用于声明变量的新关键字。 const 比 var 更强大。使用后，无法重新分配变量。换句话说，它是一个不可变的变量，除非它与对象一起使用。 这对于定位选择器非常有用。例如，当我们有一个触发事件的按钮时，或者当您想在 JavaScript 中选择 HTML 元素时，请使用 const 而不是 var。这是因为 var 会被提升，当不想重新分配变量时，最好使用 const。 // ES5 var MyBtn = document.getElementId('mybtn'); // ES6 const MyBtn = document.getElementById('mybtn'); 在上面的代码中，const 不会更改，也不能重新分配。如果您尝试为其赋予新值，则会返回错误。 let name = "Said"; name = "Rick"; console.log(name); // Rick let 可以重新分配并获得新的价值。它创建了一个可变变量。 let 与 const 相同，因为两者都是块级作用域，这意味着该变量仅在其块级范围内可用。 箭头函数 箭头函数非常棒，使您的代码更具可读性，更具结构性，并且看起来像现代代码，而不是使用这个： // ES5 function myFunc(name) { return 'Hello ' + name; } console....