内部人员私下维护的……

收 6.66 支出 1w+

@uolcano 弹幕堆得，为了播放器不卡，从一开始页面的特效我已经尽量从简了。

electron 还解决了和一些浏览器做不到的系统调用问题。。。你真的有所误解

8G 的话 估计几个稍大项目 webpack watch hot loader 卡到怀疑人生

除夕加班到初三……

这么说吧，有些东西迟早会变得无用，但你现在因为一些缘由又不得不做— ssr 就是这样的一种东西，而 nextjs 就是一种 react 的 ssr 同构框架。

对于应届生，项目经验积累不错了，如果是还有氛围的 B 站（半年以前）挺想给你内推的，现在就算了吧。
可以试试 BAT，不过基础知识（ JS、CSS、HTTP 协议）这些没怎么看到描述，这个还是挺重要的，大厂面试都会细问。

简历来看就是广度够了，深度看不太出来（除了基础知识，还有 React 源码、MVC/MVVM 原理、RXJS 使用场景和深度这些东西），面试的时候可能会被抓重点。
顺便那个 H5 网页可视化编辑工具可以重点写出来吧，感觉会是个加分项。

这叫螺旋上升，条件有了，以前做不好的就可以做好了

至于理念么，工程界玩的大都是学界上个阶段的东西，没什么好说的，很多年翻来覆去也很正常

需求才是一切，需要什么用什么

游戏引擎

Error Correction

One of the most hotly contested religious wars in the JS community (besides tabs vs. spaces) is whether to rely heavily/exclusively on ASI or not.

Most, but not all, semicolons are optional, but the two ;s in the for ( .. ) .. loop header are required.

On the pro side of this debate, many developers believe that ASI is a useful mechanism that allows them to write more terse (and more "beautiful") code by omitting all but the strictly required ;s (which are very few). It is often asserted that ASI makes many ;s optional, so a correctly written program without them is no different than a correctly written program with them.

On the con side of the debate, many other developers will assert that there are too many places that can be accidental gotchas, especially for newer, less experienced developers, where unintended ;s being magically inserted change the meaning. Similarly, some developers will argue that if they omit a semicolon, it's a flat-out mistake, and they want their tools (linters, etc.) to catch it before the JS engine corrects the mistake under the covers.

Let me just share my perspective. A strict reading of the spec implies that ASI is an "error correction" routine. What kind of error, you may ask? Specifically, a parser error. In other words, in an attempt to have the parser fail less, ASI lets it be more tolerant.

But tolerant of what? In my view, the only way a parser error occurs is if it's given an incorrect/errored program to parse. So, while ASI is strictly correcting parser errors, the only way it can get such errors is if there were first program authoring errors -- omitting semicolons where the grammar rules require them.

So, to put it more bluntly, when I hear someone claim that they want to omit "optional semicolons," my brain translates that claim to "I want to write the most parser-broken program I can that will still work."

I find that to be a ludicrous position to take and the arguments of saving keystrokes and having more "beautiful code" to be weak at best.

Furthermore, I don't agree that this is the same thing as the spaces vs tabs debate -- that it's purely cosmetic -- but rather I believe it's a fundamental question of writing code that adheres to grammar requirements vs. code that relies on grammar exceptions to just barely skate through.

Another way of looking at it is that relying on ASI is essentially considering newlines to be significant "whitespace." Other languages like Python have true significant whitespace. But is it really appropriate to think of JavaScript as having significant newlines as it stands today?

My take: use semicolons wherever you know they are "required," and limit your assumptions about ASI to a minimum.

这种事吧，咋说呢，喜欢你的不会因为这点介意，自己不邋遢干散就行了
在下穿衣风格属于突变型的，夏天 COSPA 彩色宅 T，冬天全身休闲正装+衬衫，妹子也没说什么（逃

@xwhxbg 这两个都是可以逆向的，只是相对安全点罢了

@bombless 那你试试 rust 的 yew 吧 2333

@zhouheyang0919
嗯，昨儿有人提了个 issue，我早上加到说明里了

Now, rustc supports another method to generate pure wasm file, please see here for resolution: [Rust for the Web]( https://www.hellorust.com/setup/wasm-target/):

```bash
rustc --target wasm32-unknown-unknown yourCode.rs -o yourCode.wasm
```

For reducing the size of file, your need to install **wasm-gc**:

```bash
cargo install --git https://github.com/alexcrichton/wasm-gc
wasm-gc yourCode.wasm small-yourCode.wasm
```

2017: open shit
2018: opeb source

webcv 有可能不？