「理想的工具应该是无需安装, 打开浏览器即可使用」「在线工具秘籍」，为在线工具写一本优质说明书,让在线工具造福人类~ 开源地址: https://github.com/zhaoolee/OnlineToolsBook

@FrankHB 浏览器天生跨端，你理想的工具应该具备哪些标准？

马克一下。将 100MB 以内的 gif 图片转换为 MP4。有这样的 gif 么？？？

@RouJiANG14 录的时间长点儿能达到 100

@ishowman 实现上我很难给出精确的具体标准。
但对适合“项目”维护和运营的基准，首先可以有一些普适的基本原则。
评价工具的理想程度，可以通过作为项目的主要产出而间接地适用。

* 尊重用户。
* 明确服务的对象和应该解决的问题。不要让非目标用户浪费时间去了解本不需要解决的问题。
* 预测并权衡新用户和已有用户的冲突。避免突然改变目的。
* 尊重用户对自身需求的理解。避免让用户无原则地变蠢。
* 支持用户选择的自由。如果可能，遵循公开的惯例，包括公开的技术规范和事实标准。避免不必要的路径依赖（尤其是 vendor lock-in ）。
* 避免介入用户的主观立场。避免制造无谓的社区争端。
* 从设计开始，做正确的事（ MIT approach ）。
* 在可行的前提下，明确设计的正确性先于简单性。正确性蕴含完整性和一致性。
* 设计者应当为设计决策承担风险和失败后果。避免归咎错误的选择到用户。
* 设计者应当明确清楚，有些东西是妥协，即便被忍受，从用户反馈上一时看不出来，也迟早需要改进。
* 设计者应当清楚形势。避免缺乏技术理由支撑的主观阵营判断。避免以一时的市场占有、流行趋势和垄断地位来提升项目和项目产出的质量的评价。
* 设计和实现者应当在用户接口以下层次的实现上同等重视地保持质量。注意，这不只是技术问题，因为一般意义上，开发者和维护者也是用户。越是有生命力的项目的可维护性越重要的，特别是对有能力定制和二次开发的用户而言， 金玉其外败絮其中是最浪费的做法。

基于这些原则，能衍生一些稍加具体的理想目标：

* 尊重变化的自由。在明确需求的前提下，尽可能保证对现状按需进行改变的可行性和便利性。
* 避免不必要付出的代价。尽可能消除对满足需求无意义的代价，减少影响需求实现的整体成本。
* 最小接口原则。（最小特权原则、最小依赖原则、……）
* 关注点分离原则。……
* 避免抽象泄漏。……
* ……

注意，不理想并非是指不符合用户预期。不经过具体分析，很难说用户看到的非预期情况就一定算得上不理想——可能是用户自己偶然没用对，而不能算到工具的问题。
但追溯原因仍然是困难的。
而说到底，为什么难以直接界定什么是理想的工具？不说界定什么叫理想的困难，光是因为“不理想”的情况太多，就足够成为障碍。
反过来，从现有的不理想属性来推断，倒是容易一些。根本问题总是能归结到缺少对原则的一贯遵循，虽然具体原因有多个（违反了多条原则）。不过这也只是相对容易一点。

这类不理想属性中，比较容易分析的是实现可用性缺陷。例如，一个工具用起来被用户发现内存占用太高了而用不了。可能有这样几个原因：

* 因为已知的技术限制，这个工具在这个场景下确实就应该用那么高的内存，否则根本不可行。但设计者没有成功让用户注意到最小的资源配置。
* 实际上内存就不应该占用那么多（没有可行性问题），这就是产品缺陷。造成这样的缺陷的原因有……
* 可能设计的质量太差，因为设计者根本就没考虑有这个问题，或者没能力在设计中解决这个问题。
* 可能有总体设计，但详细设计选型太差，实现效果不好。
* 可能设计预期使用某种优化方案，但实现根本没用上。
* 可能有正确的设计，也都实现了，但是单纯实现得太蠢。
* 可能设计和实现都是符合预期的，但测试不充分，刚好就在这个场景下不可预测地那么差，也没有变通。
* 可能什么都能做对，但就是来不及做，先赶鸭子上架交付原型再说。
* ……

可以看到即便对这样的具体问题，也需要根据具体情况调整应对，都没有万能的做法来避免重蹈覆辙。

需求决策上的问题则远远更难，因为很可能涉及不同用户群体之间的博弈和对有限资源的争用。

如果所有原则性的选择都根本做对了，不管是容易分析的问题，还是更困难的问题，翻车的可能性都会大大减少。
想要总体上理想，不可能靠枚举避免不理想的情况，头痛医头脚痛医脚地回避原则问题。方法论上这里就没有其它可行的选择。

就这里之前讨论的问题举例讲，“是否依赖浏览器”是需求决策和实现策略的混合问题。（是否依赖浏览器的决策已经影响到筛选最终用户群体了。）
不过，在实现的意义上，浏览器具有的恶劣质量名声在外，想要辨明风险反倒不那么困难了——凡是能不用浏览器容易实现却还是用浏览器实现了的供单用户使用的工具，通常不会好到哪去，太容易找到只会在浏览器上发现的毛病，离“理想”总是差得远。

这样的毛病具体有很多：

* 要求用户具有打开浏览器使用一般应用的习惯，不管这样的应用是否在逻辑和实现质量上都和浏览器匹配得够好。
* 运行时用户体验问题。
* 不必要的资源占用，以及因此导致的延迟问题。
* 冷启动慢。
* 即便原则上可以跨平台，仍然不能避免兼容性问题。开发者可以减少兼容性问题，但一般会让作为非开发者的用户更麻烦。
* 考虑到用户没有浏览器的情形，部署方案会更复杂。

有的用户可能不在乎这些毛病，但不是所有的用户都乐意接受。（至少用户体验的问题很难被无视。）这是筛选用户的直接表现。

光是因为一些技术演进上原因，浏览器可用性差在可预见的未来就会是业界共识。除非你是能改变技术困难现状的业界大手子，最好不要去指望这个状况容易变化。

至于为啥有时候明明不需要用浏览器实现的方案，用浏览器看起来为啥好用呢……说来惭愧，主要真是因为友商衬托。
现代浏览器本身就是一个复杂的本机运行时解决方案——类比 Emacs 是 ELisp 运行时，基本上浏览器就是个捆绑了一大票专有扩展的 JS 运行时。
而其它本机框架虽然可能根本上更正确（例如，不强行钦定一个要求 GC 的运行时而本质上更适合强调响应的 GUI 程序），因为投入的资源的关系，实现的质量未必有浏览器好，效果可能也真不咋地。
（这个意义上我要再次 diss 各大浏览器厂商。明明它们有这个资源和经验做得更好——至少能出个不捆绑只适合当浏览器的扩展的运行时——却非得在毒害业界生态半吊子的复杂方案上走得越来越远，也是醉了。）
还有，一人项目还好说，否则从开发商和运营的角度，你会不得不考虑是不是找得到开发者……
开发基于浏览器的应用使用的技术栈本身就相当具有 vendor lockin 的风险，浏览器应用越流行，其它方案的开发资源选择余地就越小。（具体来讲，现在找桌面开发者都很麻烦了。这当然不能都说是 Web 开发的问题，但开发浏览器应用会让这里更加麻烦。）
既然浏览器不可能面面俱到到取代其它技术（搞得再复杂，想当操作系统仍然是做梦），这对整个市场就是有害的。

缩进乱了……算了还是转 md 吧： https://gist.github.com/FrankHB/11d3d3e2fdab0bc773c2ece954c641aa