Atom Editor is the new shit.

当你看到这篇文章的时候, 下面的内容可能已经过时了, 所以如果你觉得你使用的Atom可爱动人, 那么很可能Atom已经解决了这些旧疾.

我上一个反的Editor是Adobe主导开发的Brackets, 我记得当时我大概说过这样一句话:

再用这玩意我就是傻逼.

现在Brackets还静静的躺在我的硬盘里, 留着它显然是因为我会用到它, 好吧, 我承认我是个傻逼.

Brackets在某些方面已经足够糟糕, 但还在可以接受的范围, 这次反的Atom, 它比Brackets更糟, 糟到令我不好承受了, 我相信我在它变得更成熟之前是不会再用它了, 问题的严重性已经足以让我专门写一篇新的文章来说明这个事情, 也请看到这篇文章的读者不要轻易品尝它.

下面便是那些令我的悲伤逆流成河的Atom问题:

优先OS X并区别对待不同平台

很奇怪, 一个编辑器最先放出的竟然是OS X版本的二进制程序, 其他平台都需要自己编译. 这个现象持续了很长时间, 直到后来才出现Windows和Linux的二进制程序.

由于OS X是最先放出的, 导致一些用于扩展Atom功能的Package也是针对OS X设计的, 这使得一些Package在Windows和Linux上无法运行, Atom的版本升级会变动API, 而中间又没有做足够的抽象, API提供的也有限, 开发者很难配合Atom的步调来开发一些涉及Atom底层细节的Package.

像极了Java的Package设计

把JavaScript写成Java是一件愚蠢的事, JavaScript已经够糟, 为何要变成Java让它变得更糟?

我完全相信设计API的人原来是写Java的, 之前给过我同样感觉的是AngularJS, 不过AngularJS实现得更加彻底一些, 使得一些地方完全不像JavaScript, 反而更好接受一点, 而Atom里的, 就像是Java和JavaScript的混合体, 臭不可言.

确切的说, 我指的是Generate Package自动添加的那些Java一样的JavaScript代码, 它很难不让我联想到Android开发时的情景.

下载速度奇慢

不怪Github, 全都怪AWS, 国内访问真的太慢了, Atom的更新功能在这种网络下直接变成了鸡肋, 如果你愿意每次更新都开着全局代理或者VPN的话, 才能多少享受些Atom带来的甜头. 事实上最近的两次升级, 我都是从官网下载新的安装包才搞定的, 毕竟很多时候开启全局代理和VPN的代价太大了.

另外, Atom可以通过基于PowerShell的包管理器Chocolatey在Windows上安装, 这点很不错, 虽然我并不看好Chocolatey.

npm是个好方案!

使用CoffeeScript而不是拥抱ES6

我完全相信使用CoffeeScript并不是因为CoffeeScript很酷, 而是因为部分开发人员真的不熟JavaScript, 他们更倾向于去学习一个新的语言, 可惜的是不熟JavaScript的开发人员们不知道这个新语言本身也是基于充满了陷阱的旧语言被设计出来的, 甚至抛弃了旧语言的很多好处, 创造了一个新的陷阱, 这一点在无数使用CoffeeScript的开发者身上得到了证实.

最后他们逼得所有人都去用CoffeeScript, 随之而来的是放弃了一大片ES6特性. 事实是Atom自带的一些Package是用Vanilla JS写的, 这真是很棒, 但官网文档还是让你用CoffeeScript.

更糟的一点是, Atom的CoffeeScript是1.8, 而不是新的1.9, 我不知道是出于什么考量这么设计的, 也许只是忘了更新版本(真的不应该在package.json里把版本号锁死). 在CofeeScript 1.9里, 在邪道上越走越远最后覆水难收的CofeeScript终于有第一个有关ES6的语法——Generator Function. 由于我的代码里用到了这一特性, 我不得不手动修改package.json升级了CoffeeScript的版本, 这是一个Dirty Patch.

没有本地化

是的, 没有. Atom竟然没有做任何有关本地化的努力, 甚至在Roadmap上也没有, 得知这一点后我很是震惊.

目前唯一能在网上找到的”本地化”方案是一个叫做Atom-Localization的Package, 由于大家都不着急的开源基因的缘故, 这个项目在Master的代码是不能在Windows和Linux上正常使用的, 原因是Atom在三个平台上做了不同的菜单配置文件, 导致基于替换的脚本不能找到正确的被替换内容, 以至于我在Windows上把这个Package每次安装完后, 还要照着Pull Requests里把代码改成Windows可以运行的样子. 另外, 这个项目的CoffeeScript代码写得实在蹩脚, 可以想象贡献代码的人也不太熟CoffeeScript, 可见强制CoffeeScript的设计之罪.

这之后我自己尝试开发了一个Package暴力替换汉化补丁, 这个Package已经接近完成, 结果遇到了下一个问题, 我被迫弃用Atom, 所以这个补丁应该永远不会被我发布了.

稳定性差

最糟的事莫过于你发现Atom它坏了, 却不知道坏在了哪里.

上一次让我差点崩溃的是Developer Tool, 它打不开, 无论我重启还是卸掉重装, 都无法打开它. 显然是在哪里的配置出了问题, 而我却查不到问题在哪.

在我尝试重新安装的时候, 如果不先卸载Atom, 那么连安装程序也只会显示一个载入界面然后自己关闭.

便携性差

这是大多数使用Chromium的桌面程序的通病了, 由于配置文件像Chromium那样被放在了Atom安装目录之外的地方, 如果你要把这个Atom打包带走, 事情就会变得有些麻烦了.

另一个Chromium带来的通病是Atom卸载时不会删除配置文件, 造成文件残留, 如果你的Atom在配置文件上出了问题, 通过简单的卸载重装不能解决问题.

没有走出Sublime Text的设计阴影

Atom太像Sublime Text了, 那个叫做Minimap的Package更是加重了这一点, 似乎Atom就是作为另一个ST出生的, 但备胎至今仍为备胎, 还没看出转正的动静.

ST作为Editor界的毒瘤, 影响了一代Editor, 但现在很多Editor都走出了Sublime Text的阴影, 有了自己的风格, 而Atom显然还没有自己的风格, 这一点真不如同期的Brackets(Atom比Brackets开发得还早一些).

该抄的自动打开上一次关闭时的tab功能没有被默认配置上, 让Atom low了不止一个等级.

还有一些不知哪来的古怪特性, 比如通过drag来open folder会变成new window + open folder, 用起来令人不舒服.

响应速度慢

JavaScript在V8里的性能我记得仅亚于Lua, 但Atom的速度是不令人满意的, 或许跟用了大量的Java设计有关, 或许跟Chromium的DOM性能有关. BTW, Brackets也很慢.

曾经尝试遍历过atom对象, 需要花上5分钟左右才能遍历完, 我不知道这算是一个怎样的速度, 可以肯定的是Atom很臃肿.

仅支持编辑最大2MB容量的文件

Brackets的极限是16MB, 而且它是为Web Developer设计的, 作为面向全语言的Editor而言, Atom只能打开2MB的文件, 令人汗颜.

不过这也不是什么大问题, 因为2MB以上的源代码也并不常见, 通常我们也只有在有编辑SQL文件或其他纯文本数据文件时才会遇到这个问题, 通常用vim打开是最好的解决方案, 不过2MB设定得也确实太小, 容易让人怀疑Atom的能力, 无论是作为效率上的不足还是心理上的坎, 都令人很不爽.

喷了这么多, 自我安慰一下: 也许Atom并不差, 只是不符合我的心理预期罢了.

现在很想买一台Chromebook, 然后在Chrome OS上写程序, 也许能作为Chrome OS一部分的Editor才是我真心想要的吧.