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

「在线工具秘籍」 Github 开源地址: https://github.com/zhaoolee/OnlineToolsBook 欢迎 Star, 收到第一手更新信息～

有点意思

……理想的工具不是应该避免依赖浏览器这种玩意儿么。

@PTLin 在 Linux 里面, 软件比较少的时候, 就显得非常有用

@FrankHB 浏览器只是媒介, 目前最中立的媒介可能也就是浏览器了

打开速度也很重要，，要用的时候等那一两秒很蛋疼。

赞 已 star

@zhaoolee 那道不至于，我用 Linux 基本没什么工具找不到

@PTLin Linux 免安装工具的诱惑力!

@zhaoolee 就你实现工具的目的来说，浏览器只能说是差强人意，是实现成本上的偷懒妥协罢了。
要说理想，漏洞实在过于明显。光是一个资源占用导致可移植性限制就能让人疯掉，于是不把工具做的做够重量级，用浏览器看上去就比较浪费，对用户来说就是鸡肋。技术上这种问题很大程度可以避免，即便非要复用类似浏览器的技术实现这样的工具，需要的也不是整个浏览器，而是更灵活的运行时。更关键的是，这里的案例中纯粹的浏览器的缺陷虽然还没明显到不可接受，但又不得不承认也就当前是这样——你不负责自己维护一个浏览器的实现，就没法保证哪天突然就因为你完全不能控制的客观因素体验烂到忍不了了。这时候就不止对用户来讲是鸡肋的问题了。
很遗憾，实际主导这些问题的浏览器厂商在这里基本上是开○车……（炒肉末一桶浆糊、Mozilla 砍掉 XUL 之类。）

@Ultraman 未来网络会越来越快, 未来秒开不是梦; 这里面有些网站是墙外的, 或许这是慢的主要原因

@FrankHB 你说的是对的, 工具也有生命周期, 需要定时维护,才能长久使用

对于一些工具类的 app 如果有网站个人还是偏向网站，即用即走

理想的工具是……不用联网，双击就能用，内存占用极低，执行速度超快……
除非是那种几乎用不到，偶尔只用一次的那种，才会去用网页版（这个时候要是没网就很抓狂了）。
文中推荐的 9 我更喜欢直接本地 you-get 和 youtube-dl，5 我会用本地部署的 drow.io （虽然也是浏览器，但是可以离线用），2 我用 ffmpeg 直接转，1 的话还是习惯 PS、GIMP。
我不喜欢在线工具是因为他们不稳定，说不定哪天就没了，或者是被广告淹没，或者是给你的东西里夹带私货，或者是收集你处理的文件……
以前，我的浏览器收藏夹里也存了一堆工具链接，但是现在好多都不能用了，要么是功能不正常了没人维护，要么是 welcome nginx，要么是 DNS 解析失败，要么是域名出售，要么是变成了澳门首家线上……
所以，我更喜欢本地的开源产品，特别是日常使用的软件，不可能用线上的……

当然，我只是现在自己的角度来看的，不排除也有很多人喜欢线上工具……

@hyserendipity 哈哈,我也是这样认为的, 所以我精挑细选一些工具类网站,放到这个「在线工具秘籍」里面，还为每个工具写了独立的说明书

理想工具：联网可用浏览器，断网可用客户端

当然，有些工具的确是适合服务端直接提供的，用浏览器和不用浏览器的差距因此会小一点，而更接近“理想”情况。这个意义上，直接在整个生命周期中只提供在线部署的版本，也未必不合理。
不过，这方面仍然有老生常谈，然而绝大多数用户大概还是没有思考过的问题：
https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html
简而言之，因为满足的需求的特点不同，并不是所有的工具天然地适合以在线服务的形式使用。使用在线版本替代应用，用户可能需要承担原本不必要的风险，得具体分析（像转存之类本来就要用远程资源的就是合理的，但预期结果一定要下载后才有意义的应用就未必了）。提供更多的选择原则上是好事，前提是用户有能力清楚这些选择确实是合适的。

draw.io ，抱歉，打错

@Whsiqi 比如上文中的第一个 Photopea, 离线也可用, 非常优秀; 第二个在线转换 GIF 到 MP4 就不太行, 因为需要与服务端交互数据;

@FrankHB 我非常喜欢第一个工具 Phtopea, 离线可用, 功能强大, 而且足够稳定, 开发者自己用 Js 几乎完整实现了 Adobe Photoshop,真的是强大!

在线运行，无需安装，跟我做在线工具的初衷一样。上面推荐的工具不错，总能满足部分人群的需要。

离线环境下？

@unicloud 好用的工具,能收到大多数人的青睐

@chiu 有些可以离线, 比如第一个 Photopea, 有些不可以离线, 比如第二个, Gif 转 Mp4

建立数据库连接时出错

@mxm145 大家太热情,Doker 的数据库挂了一下, 现在已经恢复了, 感谢提醒

不错，赞一个

我做的截图拼接工具，也是离线可用 http://join-screenshots.zhanghai.me/

@37Y37 哈哈, 欢迎使用~

@dreamingincode 这个很不错诶, 我好像以前用过!

如果 github 中 gif 图片显示不全 可以进入 https://www.v2fy.com/onlinetoolsbook/ 查看

以收藏！

哈哈, 在线工具还是香啊~

我要给 star

@melonzzz 哈哈,感谢, 会持续更新的

理想工具的必要条件：终端下可以使用。

赞，如果做成 PWA 或者 Extension 之类的，更好。离线可以用。

@KDr2 终端下使用的工具, 门槛还是有点高了

@WispZhan 确实可以把一些不需要联网的工具爬下来, 做出工具包,我也做了尝试, Photopea 是没问题的

@jinliming2 所以线上工具的列表也需要有人长期维护

@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