@skylancer 我说贵是说官方转换器，这个要卖 149 的。
非官方的不知道是不是 MFi 的不大放心……

@moonkiller 没错。毕竟没有线折来折去的啊。

其实其他 MFi 的线都比苹果自家的好用……

但苹果家的转接头太贵了……
不知道有没有 MFi 认证的第三方转接头卖……

什么！半年！！

为什么我觉得 C++需要用半生去学……

C++11 之前要学的东西就已经够多了， C++11 之后的代码我再也看不懂了……

好棒！

@ecloud 我说产品背锅不是说背收购前端技术公司这种锅，而是对自己产品定义上的锅。不管收购了什么前端技术公司，只要能清晰定义出以扩展性为第一优先，所有技术都围绕如何方便和安全地扩展来开发，也能达到满足第三方扩展的需求。

只是这对于大公司来说太难了。

比如我司，也和 IBM 差不多，部门结构庞杂，部门做事主要要 show 给老板看，老板做事主要要 show 给更大的老板看，结果最容易受重视的就是看起来好看的东西（不仅仅是指视觉上），至于扩展性啦什么的，总以为以后慢慢加……但架构都定死了加什么加……

这么说来也不是产品这个职务的锅，主要还是回到产品原始定义上去，本来就定义成好看但不易扩展的产品，那自然就很难做出方便二次开发的产品。然而不幸的是，一般原始定义产品的时候，大佬们都只想着花三分钱办五分事，尽快把东西弄出来（毕竟人家的 KPI 是这个），而不是为以后真的推向市场的时候的扩展性来花十分功夫打基础。

用用 es2015+co 体验也差不多吧……有必要上 await 吗

@ecloud 这是产品要背锅的。如果有大量二次开发的需求，那么在第一时间就要考虑到二次开发怎么做，甚至把自己团队降低到第三方一样的高度来先搞好二次开发框架（其实也没有二次开发框架了，就是一样的开发）。
但这难度太大了，以 KPI 论的大商务软件公司真的很难搞（比如我司）。

这个是发短视频的吧，和 google 家以前的产品不一样。
现在 Google 只要 Android 强推就可以了，应该不愁没人用……

简而言之就是一句话：做个小网站架构不要太复杂。

TM 简直废话。

另一句话，做大系统必须要复杂但清晰、耦合度低的架构，就被标题“ Web 开发不应该这么复杂”吃掉了。

拜托 Web 开发不仅仅是做个 2 ， 3 个人日工作量的小网站好不好！

base64 编码的资源加载确实要比直接加载资源要慢，这有人做过 benchmark 的。不过就这点速度差异在 base64 资源使用不是很多的情况下也不严重。应该远远不及拖慢性能的程度。

对于字体内联 base64 其实还是个挺不错的解决方案的。字体的加载和 css 不同，不会阻塞渲染。 html 引入了 CSS 的话，在 CSS 加载结束之前页面不会 render （要不用户就会看到错误的页面，也加重 render 器重新 render 的负担），但 css 里面的字体就不会阻塞渲染，然后用户就会观察到，页面显示一种字体渲染，然后过了一会又变成另一种字体，我觉得这样反而体验很糟。内联 base64 之后，相当于 font 的加载是阻塞的，用户一看到界面就是正确渲染的界面了。

本来觉得挺好玩的准备看看源码学习一下 rust ，结果一看居然是 python ……吐血……

秒针走动方式不一样都能被人发现，佩服……

我就是线下支付从支付宝转微信的。

以前习惯支付宝，觉得支付宝管钱更放心点，微信社交就好。后来发现了这样一个问题：我支付宝对商家支付完成之后，这个商家的公众号就自动加进我的关注里去了！删掉之后再支付一次又加了进去！我并不想做一次顾客就永远被骚扰啊……然后就认真试了一下微信，第一次支付也会自动加公众号，不过下面有个 checkbox 勾掉就永远不加了……高下立判啊……

从此之后凡是能微信支付的场景我就不再打开支付宝了……

严格来说不仅仅是 windows 的渲染机制，而是字体设计方式大不相同， windows 下的字体比如雅黑，会为特定点阵做优化，把横向笔画移到像素显示的位置（纵向不知道移不移，以前可以用次像素优化所以纵向不动，现在屏幕可横可竖就不大方便了）,所以在点阵下字体虽然会有一定变形，但线条更清晰。 Mac 没做任何优化，矢量字体缩小了笔画不在一个像素上太正常了……

简单来说就是无解。因为实在不舒服我一般把界面设置成英文。

这贴不错，没听说过 Cache Storage 查了一下长见识了……

看起来像是废柴前端和废柴后端写的东西。

为什么这么说？以为一个工程师要能 精通前端的时候还能把后端也掌握到精通（或者反过来）？

呵呵。