注意::
- 由于制作缓慢的缓存系统,Atom在使用大文件时经常会丢失数据。
它已经被证明了很多次。
除了先前答案的要点之外,从它们的开发选择的角度来澄清这两种产品之间的差异是值得的。
Sublime是为平台编译的二进制文件。它的核心是用C / C ++编写的,它的许多功能都是用Python实现的,它也是用于扩展它的语言。 Atom是用Node.js / Coffeescript编写的,在webkit下运行,Coffeescript是扩展语言。虽然UI和UX类似,但Sublime的性能明显优于Atom,尤其是在“繁重的工作”中,例如处理大文件,复杂的SnR或对文件/缓冲区进行大量处理的插件。虽然我希望Atom在成熟时有所改进,但设计与实现相同。平台选择限制了性能。
Sublime的“封闭”部分包括API和UI。除了皮肤/主题和颜色,API目前很难修改UI的其他方面。例如,Sublime插件不能与侧边栏交互,控制或绘制在编辑区域上(除了以某种有限的方式,例如在排水沟中)或操纵状态栏超出基本文本。 Atom的“封闭”部分目前尚不清楚,但我觉得它更小。 Atom拥有更丰富的API(尽管目前记录不完整),其设计目标是允许更好地控制其UI。与webkit紧密结合,为Sublime目前无法实现的UI功能增强提供了许多功能。但是,Sublime的扩展更接近原生,因此那些在大型缓冲区中执行计算密集型,高度重复性或复杂文本操作的扩展在Sublime中是可行的。
由于更多Atom将开放, Github于5月6日开源Atom。因此,支持和发展速度可能很快。相比之下,Sublime的发展最近显着放缓 - 的 但它并没有死 强> 。特别是有一些错误,许多是非常微不足道的,没有被开发人员修复。没有一个是showstopping imo,但是如果你想通过常规的bug修复和增强来快速开发,Sublime会让人感到沮丧。那说, 适用于Windows和Linux的可安装Atom软件包尚未发布 根据Github的统计数据,代码库上的活动似乎在宣布之前和之后的几周内已经降温。
就IDE功能而言,从webdev的角度来看,Atom将允许扩展到接近像Webstorm这样的产品,尽管还没有出现过。由于编辑本身感觉迟钝,Atom将如何执行这种“重”扩展还有待观察。由于API的限制和缺乏底层webkit,Sublime将不允许这种级别的UI自定义,尽管开发人员可能会扩展API以支持此类功能。同样,Sublime的基本性能允许涉及计算咕噜声的事情; ST3的符号索引是一个即使在大型项目中表现良好的例子。虽然Atom的用户界面肯定是以Sublime为蓝本的,但是一些改进明显缺失,比如Sublime的学习面板和制表符完整的弹出窗口,它们根据你最常用的那些加权默认值。
我认为这些产品是互补的。他们共享相似的视觉效果和击键的事实只会增加事实。在某些情况下,使用任何一种都有优势。目前,Sublime是一款成熟的产品,在所有三个平台上都具有功能平等,并提供丰富的插件。原子是一个新的孩子,其特征将迅速增长;它还没有感觉到生产准备就绪,并且在性能方面存在顾虑。
[更新/编辑:2015年5月18日]
关于自编写上述内容以来对这两位编辑的改进的说明。
除了错误修正和对其核心的改进之外,Atom还经历了第三方扩展的快速增长,自动完成加成为标准Atom发行版的一部分。扩展质量差异很大,特别恼人的是不稳定的第三方软件包可能导致编辑器崩溃的频率。在去年,由于性能原因,Atom已经开始使用React将回流/重绘活动转移到GPU,从而显着提高了UI对典型编辑操作(滚动,光标移动等)的响应能力。虽然这显着改善了编辑的感觉,但仍然感觉如此如上所述,CPU密集型任务很麻烦,并且在启动时仍然很慢。除了性能改进之外,Atom感觉全面稳定。
自2015年1月以来,Sublime的开发再次出现,包括错误修正,一些小的新功能(工具提示API,构建系统改进)以及基于yaml的.sublime语法定义(以最终取代旧版本)形式的主要开发xml .tmLanguage)。与替代Onigurama的自定义正则表达式引擎一起,新系统为精确的正则表达式匹配提供了更多潜力,显着更快(高达4倍)并且可以并行执行多个匹配。除了着色语法之外,Sublime还使用这些组件进行符号索引(goto定义等)和其他语言感知功能。除了进一步加速Sublime之外,特别是对于大型文件,此功能应该开辟了高性能语言特性的潜力,例如代码重构等。进一步的“重大发展”得到承诺,尽管作者仍然如此,紧紧抓住他们。
的 以下是两者之间的一些差异: 强>
*虽然APM是一个独立的工具,但它与Atom捆绑并自动安装
原子 是开源的 (现在已经持续了几个小时),而Sublime Text却没有。
我今天刚收到我的测试版邀请,并立即尝试了Atom。 GUI感觉像Sublime,是的,有一些从Sublime采用的快捷方式。
除了上面提到的一切,这里有一些我到目前为止注意到的差异:
Vim模式不如Sublime上的Vintage模式(这也不是一个功能齐全的vim),因为vim包处于开发的早期阶段。看到 https://atom.io/packages/vim-mode 细节。
正如James所说,Atom是使用Web工具编写的,因此您可以访问文本编辑器的样式表(styles.less)来使用CSS执行您想要的任何外观更改。还可以选择更改启动CoffeeScript。
同样,由于Atom仍处于测试阶段,Sublime拥有更多的原生插件包。但是,由于Atom是用Node.js编写的,Atom官方网站称你可以“从Node的软件包库中选择超过5万个”。 (因为我不是Node.js专业版,但我没有考虑过这个功能)
Atom有更好的Github支持开箱即用,但Sublime有几个Git包。
Sublime是付费申请无限期评估期。 Atom在beta阶段是免费的,但我们不知道Github是否想要收费。
因此,底线是Atom是一个在测试阶段使用网络技术构建的文本编辑器。相比之下,Sublime已经通过许多不同的迭代进化而来。 Atom仍然缺少Sublime支持的很多软件包,所以问题是Atom会赶上Sublime还是变得更好?由于其流行的底层技术,Github似乎对此文本编辑的未来充满信心,从长远来看,Atom可能是Sublime的一个很好的替代品。
Atom是使用Node.js,CoffeeScript和LESS编写的。然后将其包装在WebKit包装器中,该包装器最初仅适用于OSX,尽管现在还有Windows版本可用。 (Linux版本必须从源代码构建,但Ubuntu用户有一个PPA。)
Sublime Text已经复制了许多体系结构和功能,因为它们经过了尝试和测试。插件系统的工作方式几乎相同,但通过公开新的API也开辟了许多新功能和潜力。
我相信由于肌肉记忆,快捷方式基本保持不变 - 人们会记住它们并且能够立即点击Atom。
可以使用GUI控制首选项,而不是直接编辑JSON,这可能会降低让人们开始使用Atom的入门门槛。 由于“首选项”中没有搜索功能,我自己发现很难导航它们。
您可以注册邀请 ##原子邀请 IRC频道或注册到他们的网站并添加您的电子邮件。第一轮邀请来得很快。
另一个区别是Sublime文本是一个封闭的源项目,而Atom源代码是/将公开可用 - 尽管Github不打算将其作为一个真正的开源项目发布。他们希望提供对代码的访问权限,而无需将其打开。
Github将代码公之于众: http://blog.atom.io/2014/05/06/atom-is-now-open-source.html
一个主要的区别是支持“印度字体”又名南亚脚本(包括东南亚语言,如高棉语,老挝语,缅甸语和泰语)。此外,还有更好的东亚语言支持(中文,日文,韩文)。这些已知的错误(实际上是评价最高的错误)已经持续多年(认为似乎东亚语言支持过去工作得更好但现在变得难以使用):
Atom仍然处于测试阶段(我正在写这篇文章时为0.123),但它正在快速发展。比Sublime更快的方式。新版本每周发布一次,有时甚至在同一周内发布一些。在其短暂的生命周期中,它拥有比Sublime更多的版本,这需要数月才能发布新功能或修复bug。以下是回顾Atom自推出测试版以来所采取的路径的更新内容:
Sublime比Atom具有更好的性能。仅仅因为它是用C ++编写的。另一方面,Atom是一个基于网络的桌面应用程序,建立在Chromium之上,虽然它们的性能接近于心脏,但是达到相同的速度和响应速度将非常困难甚至不可能。去年7月Atom开始使用React,它给了它一个不错的性能提升,但你仍然可以感受到它的不同。除此之外,如果Atom的性能问题不会推动用户离开 - Sublime可以更好地加快发布周期,简化其小型UX调整,并考虑让更多的贡献者,因为这是Atom获胜的地方。
Atom的软件包生态系统也在快速增长,它现在可能没有Sublime那么大,但我有一种感觉,GitHub在它的背后它会继续增长得更快。它可能有你想到的大多数类似IDE的插件。现在的一个主要区别是它无法处理大于2MB的文件,因此需要牢记这一点。
你首先要注意的一件事是Sublime迷你地图消失了!除此之外,第一印象是Atom与Sublime看起来几乎相同。我在这里写了一篇更深入的比较 博客文章 。
没有简单直接的方式来移植您的Sublime配置,软件包等,据我所知。
我在极端的环境中工作;编辑安装在我的笔记本电脑上的远程文件系统(外部网络,通过ssh(aka .sshfs))上的文件。无论我为什么这样做,虽然它的响应速度很繁琐,但是当我使用Sublime Text 2时,它是相当可食用的。
我在读完这篇文章后尝试了Atom,但事实证明这对我来说有些痛苦; Atom似乎没有如此高效地缓存目录结构。每次我在树视图上展开文件夹时,UI都会冻结很短的时间,2~3秒,可能会获取文件系统信息。是的,这是因为我正在使用远程文件系统。但Sublime处理这个效率更高,至少每次扩展文件夹时它都不会冻结,所以不那么痛苦。
我认为Atom是免费的地狱,我的故事是微不足道的,有一天可能会有所增强,但这对当时的人来说会有所帮助。
-
的 新增2014年8月26日 强>
最近,我将我的笔记本电脑从Macbook Air 2010后期改为Macbook Pro 13“2013年末。它的CPU速度提高了4倍,性能也有了很大提升。我想提一下我的意见是关于你何时安装远程文件系统的情况。 (使用 的 OS X Mavericks 强> ,最新版本的Atom,FUSE 2.7.3 / OSXFUSE 2.6.4 / sshfs 2.5.0,远程系统是Ubuntu服务器)最终,UI冻结变得非常短,但它仍然存在。具体来说,要打开包含许多文件夹/文件的文件夹并对其进行索引,则需要一定的时间。此外,如果您展开一个文件夹,它只是步履蹒跚。 (折叠文件夹时,它没有)
根据@EliDuenisch的说法,似乎没有发生在Linux Mint上。我不确定,但它可能来自操作系统之间的差异。当然,如果你在本地文件系统上工作,你根本不必关心这个问题。
到目前为止,没有人指出的一个主要区别是,对于某些人来说可能很重要的是(至少在Windows上)Atom并不完全支持其他键盘布局而不是美国。有一个错误报告,有几百个帖子已开放超过一年( https://github.com/atom/atom-keymap/issues/35 )。
选择编辑时可能会有用。