不仅面试题。。当年我们考 OS 的时候最后一题就这个。。

@Arthur2e5 那这个就是 sublime 或者我装的某个插件的锅了， dm 没这个问题，但现在基本上都用 sublime

给你提几点改进意见
1. 缺乏一个显眼的 logo ，告诉用户我在访问你的网站而不是不小心点到了一个奇怪的地方。我不知道前两个 card 是置顶的还是如何，如果你把这作为你网站的“标志”在我看来是失败的
2. 搜索框的位子很奇怪，而且在 safari 下某些样式不兼容(至少我这里是)
3. 没有很好匹配 responsive design
4. 简洁不代表没有东西，或者“内容稀疏”，否则造成效率低下(个人觉得这是大部分 MD 的通病，大面积留白，建议你好好体体会一下)，其中比如 continue reading 那一栏你可以放文章的 description(highlight)，然后再加 continue reading
5. 你每张 card 都有作者和时间，问题这就是你的 blog ，没有别人了，显得多余。如果想体现“你是作者”，可以用其他方式表达，比如在网站 logo 或者网站介绍上加以阐述
6. side nav *不要* 中英文混搭，写个 js 判断系统语言也就几分钟的事

我的鼠标垫是退役了的 iPad mini 。。。

@Arthur2e5 实现有误? 不知道你说的是哪一点， detail pls

1. 知道，但自己平时用的时候一般都加""， disable 或者比如用一些 css libaray 的时候按照他提供的 doc 走
2. 知道，问题是有些编辑器（比如 sublime ）你 img 后面不加 / 会给你报 non-closing ，虽然不影响但为了顺眼起见就加上吧
3. 知道，同 2
4. 不知道，学习了

谣言不谣言我不知道，没听人这样说过，也就是以前上课或则自己学习的时候看的资料不同罢了

除去上面已经提到的前后端分离，还有性能的影响，现在前端很少直接写整个 html 的了，而且现在“需要”返回 html 的情况非常少吧，除非你说要替换大部分 dom ，有点类似潜入 iframe 的感觉，但这是有具体需求的情况下才会这样用（比如防止 js/css 污染等，绝大多数在线 code 编辑器都是用的 iframe ）

@helloccav 并没有理解你所说代码复用是什么情况， html 作为 view 本来就是复用的，但这和返回 json 并不冲突啊， html(layout 不变) + json(数据动态变化) -> 完整页面

对那种连鼠标移动或者 scroll 都不顺畅的网站没有好感(我是不是把用 angular 的网站全部排除了...)
不管你动画效果多么华丽，只要你让我风扇起飞，我只有一个反应 -> 直接关掉

因为如果你决定了要用比如 bootstrap 之类的 css 库，前端的工作就从原创代码变成修改代码，你引用 bootstrap 基本上不会去动它本身的代码，而是通过 overwrite css 或者通过写 js 来控制

@vghdjgh 或者说很多做后端的根本就不会写 css ，直接做成 js 然后填参数的方式就非常好理解

@Gem let 一般是作为 temp 用的，用完就扔不污染。用 const 定义不需要改变的东西，剩下的用 var ，这几个开销不一样，最好酌情使用

搜索引擎好像不会去抓你动态生成的 query words 吧？

那些必须重名的你在 CSS 里面加 !important ，就我所知除了 iframe 之外暂时没有一个能完美解决的方法

做前端的，表示 RESTful 这个东西应该是为了前端方便而来的。你可以说它是风格，但我觉得 RESTful 作为不是硬性的“标准”可能更加适合，因为我肯定希望后端全部按照这套东西来写 api ，这样前端可以用 js 根据不同的 code 做相应的反馈，状态码都是固定现成的，一套 js 只需要稍作修改就可以用在其他地方

create(post) - return 201 / 409
delete(delete) - return 200 / 404
edit(patch) - return 200 / 204 /404
read(get) - return 200 / 404
replace(put) - return 200 / 204 / 409

这一套可以应付大多数情况了，而且 201/204/409 的使用显然比单纯用 200/404 来得人性化

我看楼上有人举『移动到文件夹 X 』的例子，很明显这个已经超出了 RESTful 所定义的范畴，你强上 RESTful 肯定不合适，但比如你 增删改查 设计成符合 RESTful 的架构，然后其他的再自定义这完全 OK 啊

1. ios 基本是每更新一个大版本都会开放一波新的 API ，开发者用到的也会越来越多，所以对系统资源的消耗肯定是增加的，系统本身一样的道理

2. 一个 app 刚出的时候满足的是最基础功能性的需求，之后的更新一般只会往上加功能，加复杂度，只要没有达到功能性的上限，优化性能肯定不是第一优先级，而且“做好”比“做出来”难上好几个量级，也和开发者自身素质有关

3. 不然你以为坏块是哪来的

SCSS 路过。。

去 package 里面看，找大的文件，表情全部被存下来了，几百 M ，自己删掉就好

com.tencent.xinWeChat/Data/Library/Application Support/com.tencent.xinWeChat/2.0b4.0.9/xxx/Stickers

com.tencent.xinWeChat/Data/Library/Application Support/Wechat/1.2/xxx/Emoticon01/File

其实我觉得四强如果是 Navi, SK, Astralis, VP 比较妥，当前版本的 Fnatic 不够水准，可惜 Navi QF 就和 Astralis 撞上了，然后 SK 输给 VP 不应该。当前世界排名而言我觉得 Astralis 、 Navi 、 SK 应该三分，看 map pool 各有输赢，但 SK 相比于其他的发挥更稳定。 NA 各队直接 gg ，法国也 gg ，瑞典更佳 gg 。。

OctoberCMS

@learnshare @kanezeng 所以我后面说这样比不是很公平，但你也不能说锅都是标准的问题