但是按道理来说，终端应该会自动载入啊

来描述一下你原话中的“道理”是什么，描述清楚了你的问题就解决了。

1. 离开 Rails 的人通常不会否认 Rails 的成熟，真正的动因大多都是因为 Rails（或者说 Ruby）的短板在可见的未来里没有提升的可能（或者可能性微弱，又或者是即使有所改善也就聊胜于无）。

2. 惯例优于配置并不能降低成为“优秀程序员”的门槛，它只能拉高“普通程序员”的底线。对于真正的优秀程序员来说，惯例优于配置是一种“品德”，然而即便身处于“没有惯例”或者“惯例崩坏”的场合，优秀的程序员依然优秀，而普通的程序员则会原形毕露，坠入深渊。如果一个普通的程序员可以进化成优秀的程序员，那么即便他不知道什么叫“惯例优于配置”也不会阻碍他的进化的。

3. 前后端分离是一种工程实践，而不是一种意识形态；不能理解到这一点的，对它的评价最终也会归于意识形态批判的范畴，变得没有价值可言。

总结：你认为对你合适的，且在今天也确实适合你的，那就是你的选择；至于你怎么看自己的明天，那是你的自由。

Rust 用的是 ace 做的在线编辑器（前端部分），也算是一个老牌云编辑器了。https://github.com/ajaxorg/ace

没啥不可能的，混合范式的 JavaScript 都有借鉴的成品了：https://github.com/poteto/ember-changeset

如果 Rails 想做一样可以做，这大概不是一个能不能或者会不会的问题，而是愿不愿意或者接不接受的问题吧。

真有意思，那请问如果你英语学得很不错那又能怎样呢？难道会对你有害处吗？今天你搞不定 man 的文档，找到了 tldr 来帮你简化它，可明天你遇到 tldr 没有覆盖到的文档呢？tldr 的条目其实很多也是其他人贡献的，你觉得这些贡献者会看不懂原始文档吗？

这个项目的目的是为了让查阅命令的用法变得更加方便，而不是为了取代 man。这原本是一件锦上添花的事情。什么叫锦上添花？就是有了会很好，但是没有也不妨碍罢了。如果你本身英语就过硬的话，有没有这个锦上添花又有什么关系呢？更重要的是锦上添花并不能替代事物的本源，举个例子，看这个问题的答案：https://segmentfault.com/q/1010000000430426 你试试看只用 tldr 查出来的文档能不能回答这么清楚？我也不是闲的没事干天天把文档当小说看，这些都是因为工作中遇到了实际的问题而不得不深入文档才得到的答案。

在你的原帖里，问题的关键是你有没有主动去寻找答案，而不是你寻找的答案是不是足够简易到让你能看懂，这是两个性质不同的问题。如果你只是想要更加方便的工具来帮你看懂，那我相信大家会给你推荐各种辅助工具的，比如你自己提到的这个，或者是这个：https://www.explainshell.com/ 等等。可问题是你原文是那个意思？不，你不是在寻求帮助，你是在抱怨。

我跟你无仇无怨，并不会专门为了挤兑你而说你英语不过关。仅就个人而言，你英语过不过关对我来说又能怎么样呢？你埋怨别人说话冷漠刻薄，那我还觉得你不识好歹呢？就这个帖子而言，我其实根本没必要回复这些，若是你觉得我斤斤计较，小肚鸡肠，那便随你吧，言尽于此了。

很感兴趣现在有多少前端有开发 dapp 的经验的，好招不？

在这里说的是爬虫，又不是 DOM Manipulation，除了选择器语法之外，你还指望 Nokogiri 哪里要做到和 jQuery 一样呢？

早在 2011 年，我第一次尝试 nokogiri 的时候就感叹：“我擦，这玩意儿用起来感觉和 jQuery 一样……”，结果到今天还能看到你抱怨没人封装一个 jQuery 选择语法的。可见之前我对你的评论并没有任何偏颇。

什么是 SPA？Single Page Application 其核心特点就是通过浏览器提供的 History API（或 fallback 到 hash）来实现非重载且能够持久状态的路由系统，从而达到只需要加载一个静态 HTML 页面就可以作出不限数量的“页面”（确切地说是“视图”）的应用形态。只要能够满足这种形态的，无论其是否是分离架构，也无论其使用了什么框架（或者完全不用框架），更无论其使用的视图渲染技术……它们都是 SPA。

再说虚拟 DOM，这已经快被说烂了还要被拿来继续嚼。首先，用不用虚拟 DOM 跟是不是 SPA 没有丝毫关系！其次，虚拟 DOM 的诞生不是为了比传统操作 DOM 快（尽管很多场景下它的确比传统方式快，不过这个“快”的幅度是要取决于实现的人的），而是为了给越来越复杂的客户端状态管理与视图渲染的同步问题找到一个新的解决方案。如果你认为像 QQ 邮箱的状态管理就能称之为“复杂”，那你得是多没有见识？不要因为那些初心者总是拿框架搞点博客和 Todo 就觉得这些框架就是用来干这些事情的。

虚拟dom是只要一个元素变化，整个区域都重新渲染

请不要总是活在几年前，技术总是在进步的，如今的主流渲染机制都能做到精确的节点（DOM NODE）更新了。

不知道你是蠢还是坏，我看到你讲别的技术话题的时候还是有可取之处的，但一说到前端框架和 SPA 就好像跟别人有杀夫夺妻之恨一样。肆意的发泄和传播不尽不实的讯息并不能让你看起来更睿智。就用你说的邮箱来举范例好了，gmail 就是比 QQ 邮箱的状态管理复杂得多的同类应用，而它恰恰就是用了一个 SPA 框架辅以操作 DOM 为视图管理主要机制的框架。若你一定要杠说前者的 UX 没有后者好，那也随你了，本来这就是一个主观性的东西，却拿来评价某种技术的适用性和优缺点，你说是蠢还是坏？

再者说了，就算你这么说鹅厂的人听了也不会给你点赞的，QQ 邮箱不用新的技术栈又不是因为人家不会用或者用不好，而是它的产品形态太稳定了，压根没必要重新实现一遍，让你说的好像同门微信疯狂搞小程序框架就是离经叛道一样。

格局大一点，不甚了解就别总是大放厥词。

hopscotch 和 shades-of-purplt 不都是 theme 么？