开源的基于浏览器的代码编辑器

还没有读者喜欢这个。
code editors
图片来源：

Opensource.com

简陋的浏览器。多年来，它的主要用途是提供简单的 HTML 文档，并提供关于您能想到的几乎任何主题的信息。在过去十年中，随着宽带取代拨号上网，网络连接变得越来越快，网站越来越多地提供通常仅限于桌面的应用程序。

随着 HTML、CSS 和 JavaScript 等语言的演变，帮助推动了可能实现的极限，反过来，我们发现它为开放和共享提供了新的机会。这种情况已经发展到几乎没有什么不能在线完成或开放的地步。

一切都在线？

花点时间思考一下。文档编辑、文件共享、图像处理、服务器备份、3D 渲染、音乐制作，以及几乎所有传统上在桌面软件中完成的工作，现在都可以通过 Web 服务来处理。然而，Web 开发一直是最后一个真正跟上这一趋势的领域之一，因为 Web 开发人员自己一直坚持认为，最好离线编写代码，并在发布时将代码推送到在线。

这始终是一种明智的工作方式，并且建立在合理的逻辑和经验之上。离线工作速度很快，您的代码非常安全，而且桌面编辑器通常都非常好。那么为什么要改变呢？嗯，一个新的时代正在悄然兴起，在过去的几年里，基于 Web 的编辑器已经发生了巨大的发展，几乎可以与它们的桌面竞争对手相媲美。今天，它们正迅速被视为可行的编码解决方案，为代码共享和与他人一起开发站点带来了新的可能性。从诸如 jsbin.com 和 jsfiddle.net 等网站上的快速实验，到诸如 codeanywhere.net 和 c9.io 等成熟的编码环境，几乎您想工作的任何级别都有解决方案。

开源编辑器

这个新领域最新的趋势之一是通过开源来共享这些在线代码编辑器和 IDE 本身。

这里的好处是，您可以确切地看到编辑器正在做什么，并且由于它们是用熟悉的语言（如 PHP、Ruby 和 JavaScript）编写的，因此您可以根据自己的喜好自定义它们。不喜欢编辑器的运行方式？更改它。想要将其连接到特定服务？集成它。您很少能找到一个完全符合您要求的桌面编辑器，通常会有一些小的 раздражения 或限制，这意味着您必须使用它们或其他服务，从而花费额外的时间和精力来完成编码工作。

ICEcoder

这就是 ICEcoder 的用武之地。它是一个功能齐全的、基于浏览器的代码编辑器，允许您在 Web 浏览器中在线或离线编码。它包含了您几乎需要的一切，支持多种常用语言，带有一个带有十六进制和 RGB 取色器的图像查看器，完整的 1670 万色选择器，Linux 终端，每 30 分钟备份一次，您可以将文件推送到 Github 和从 Github 拉取文件，启用 Emmet，具有类型增强功能，高级查找和替换，MySQL 管理，JSHint 代码检查，实时编辑等等。

然而，由于它是开源的，您可以拿走它并使其成为您自己的，不再需要与您的编辑器作斗争来完成工作。它可以适应您想要的工作方式，并连接到任何基于 Web 的事物。Web 有效地成为您的工具箱。

开源的未来

拥有像这样的真正开源解决方案似乎正在为更共享和开放的未来铺平道路，在这个未来中，一切都可以集成、混合和重新加工，无论是在我们自己还是在团队中，并且可以安全地知道代码可以回滚，错误可以被跟踪，并且如果出现问题可以从任何地方解决。它允许您在与他人协作工作时轻松共享代码示例和原型，并且在与您将部署的环境相似的环境中进行编码也有助于避免上线和出现新错误引起的头痛。您还有机会随时创建修复程序，并将修复程序从开发服务器推送到生产服务器，所有这些都可以在您舒适的家、当地咖啡馆、海滩或任何您可能在的地方完成。不再局限于办公室。

随着一切最终迁移到云端，基于浏览器的编辑器和 Web IDE 无疑将成为默认的编码方式，我欢迎这个光明的未来。如果您仍然离线编码，为什么不尝试其中一个呢？

标签
编程
Matt Pass
User profile image.
我是一名自由 Web 设计师和开发人员，拥有超过 14 年的商业经验，为世界各地的大型和小型公司创建网站、应用程序和网上商店。我的重点是通过伟大的新解决方案推动 Web 向前发展，让每个人的生活更美好，并找到通过开源解决方案实现这一目标的最佳方法。社区力量 FTW！ :)
更多关于我

7 条评论

Avatar
Stephan Sokolow | 2013 年 5 月 21 日
还没有读者喜欢这个。

<strong>一方面，我总是很高兴看到更多浏览器内文本编辑器的选择。</strong> 它们不仅让像我这样的技术迷看到新玩具时尖叫起来，而且对于那些没有足够的时间来安装自定义工具的用户（例如，几乎每个点击 jsfiddle 链接的人）或尚未足够投入意愿的用户来说，它们也是一个绝佳的选择。

<strong>另一方面，我强烈反对整个“云端”运动，原因有很多。</strong>

<strong>首先，我认为它在人口统计学上是幼稚的。</strong> 我住在加拿大。我们中的许多人仍然不得不在拨号上网和发达世界乃至一些发展中国家最昂贵的 3G 蜂窝服务之间做出选择……我很幸运能住在一个可以获得 5Mbit/800Kbit 连接的地方，据我所知，加拿大贝尔目前没有计划将我们沉睡的小村庄升级到光纤到节点。（这是升级到更快的 DSL 速度所必需的。这里唯一的电视服务是通过卫星，所以没有有线互联网。）

<strong>其次，我认为它过于乐观了。</strong> “云”对于最终用户来说仍然是单点故障，因为我们很少有冗余连接，即使我们有，我们仍然会看到偶尔的 GMail 或 Google Docs 中断。这就是为什么我很高兴发现 git 和 TiddlyWiki。 “离线工作，然后稍后合并”模型提供了这种冗余，同时，如果备份丢失、无用或从未进行备份（正如 2009 年 Ma.gnolia 发现的那样），它允许最终用户透明地成为计划 B 的一部分。

（我对 GMail、Google Docs 和完整的浏览器内 IDE 等事物的首选方法是使用诸如 appcache 清单和 IndexedDB 之类的东西来支持无缝地离线和返回，无论它是从哪个 URL 加载的。）

<strong>第三，云中的数据可移植性尚未解决</strong>，并且公司有足够的空间可以搞恶作剧，让用户承担后果。使用 git 或 TiddlyWiki 之类的工具（或通过运行调用 youtube-dl 的脚本，然后在文件出现后几秒钟内将 MPlayer 指向该文件来观看流媒体视频），权力掌握在您手中。“拥有副本”意味着“拥有副本”，其意义与物理对象相同，而不是“我上次尝试时它工作正常，但有些东西意外地改变了”。

（<strong>这也通常意味着将您的备份信任给单点故障。</strong> 请参阅我对 Ma.gnolia 的评论。）

<strong>第四，这是浪费。</strong> 我有一台 Athlon II X2 270，配备 16GiB 内存（我可以找到的最快的非 Intel 65W TDP 芯片），但我运行 LXDE，并在我旧的 2GHz Celeron 配备 1GiB 内存的电脑上测试我的桌面。唯一运行不顺畅的是浏览器……那么我为什么要在我那漂亮、轻量级的 Vim 中运行本质上会像全功能 x86 模拟器一样减慢它速度的东西呢？我买了一台快速的电脑是因为我想做更多的事情……而不是因为我想以一种更时髦的方式做同样的事情。

（即使已经有限的 GUI API 没有因为我对中和 <em>window.open()</em> 之类的调整而进一步削弱，我仍然坚信，如果一个应用程序本身并不需要重新发明浏览器的 HTML/CSS 渲染器或网络堆栈才能独立编写（并且“零安装”对于预期用例不是绝对必要的），那么在浏览器中编写它就像花 100 美元购买一台笨重、发热、翻新的奔腾 4，因为您已经知道如何位操作并行端口，并且不想学习 Arduino 编程。）

<strong>最后，我个人觉得不舒服。</strong> 我的 Vim 使用了很多插件，我非常习惯 Vim 动作。我使用非 Vim 文本编辑器没有问题，因为我确保训练自己习惯 Vim 风格和 CUA 风格的按键方案，但是基本的、通用的 CUA 对于编码来说太慢且效率低下，而且我的桌面上没有其他任何东西在“Vi 模式”下运行，因为我还没有找到一个应用程序实现了足够的 Vimscript 运行时环境来解析我 .vimrc 中的按键绑定并运行我的所有插件。

<strong>这并不是说我自己不使用浏览器内代码编辑器，</strong> 但我更多地将它们用作轻量级小部件，作为 TinyMCE 的补充，而不是完全成熟的编码环境。Web 上有很多地方需要带有语法突出显示、行号和搜索/替换功能的文本区域。

Avatar
Matt Pass | 2013 年 5 月 21 日
还没有读者喜欢这个。

嗨 Stephan

这里有一些很好的评论，虽然对您的观点有一些回应。ICEcoder 与众不同，因为您可以在线或离线运行它。当然，您会错过连接到 Web 服务或从任何地方编码的好处，但是如果您不想这样做，或者在线工作实际上不切实际，不用担心，它在本地运行得非常愉快。这也意味着您拥有文件的本地副本。

ICEcoder 的另一个关键点是，它并不完全是在云中工作（我相信），因为您不像使用 Google Docs 那样在您的设置帐户中工作，而是在您的 Web 服务器/主机上工作。我听到了您关于依赖性的说法，可能会考虑在您准备好部署时将文件推送到站点/合并到站点。

我不会说这是以一种更时髦的方式工作，而是以一种更聪明的方式工作。此外，如果您打开了许多程序（文本编辑器、数据库软件、图像查看器、图形编辑器、Github 等），您可能会比仅使用 Web 浏览器使用更多的资源（RAM、CPU 等）。

最后，我同意 Vim 和 Emacs 键绑定会很好。开源社区目前正在广泛地研究它们，当它们准备就绪时（希望在未来几周内），它们将进入 ICEcoder。这有望表明，如果您想要它，您可以构建它。开源意味着它具有高度可定制性。另一个例子 - 上周我决定在图像查看器上添加一个取色器工具，在 2-3 小时内编写了它，现在可以立即使用。

可能没有在这些方面说服您，但它有望在一定程度上展示 ICEcoder 如何比其他编辑器更开源和与众不同。

Avatar
Stephan Sokolow | 2013 年 5 月 21 日
还没有读者喜欢这个。

我知道 ICEcoder 可以在本地运行，但这仍然与我关于基于浏览器的应用程序更重的观点相关。

使用 Vim 和 urxvt 之类的工具的全部意义在于它们使我更容易“打开许多程序”。这就是为什么我认为使用 Vim 之类的工具是“更聪明地工作”。我获得了相同的功能，但浪费了更少的 CPU 和 RAM，这意味着更容易做诸如打开 Firefox Aurora、Firefox Stable、Chrome、Opera、Midori (GTKWebKit)、Arora (QtWebKit) 和三四个 http://www.modern.ie/ 测试虚拟机只是为了快速访问测试而坐在后台。

当然，我无法在 2GHz Celeron 上做到这一点，但是，如果我只是变得懒惰并让我的桌面长出啤酒肚，我也可能在双核 Athlon 上遇到麻烦……特别是如果我正在开发和测试的东西本身就是 CPU 和 RAM 密集型的。

（我实际上并没有计划升级到配备 16GiB 内存的 3.4GHz 双核 Athlon II。我对大约 5 年前购买的配备 4GiB 内存的 Athlon64 X2 5000+（2.6GHz，双核，也是 65W TDP）非常满意，但我的旧主板早在 1 月份就坏了。由于我无论如何都要购买新套件，我决定腾出空间一次运行多个 IE 测试虚拟机。）

您似乎也不理解我对 Vim 的观点。即使您实现了 Vim 键绑定，我也不会感兴趣，因为我不使用 Vim 键绑定。我使用 <em>Vim 内的自定义键绑定和插件</em>，并且将我的 <em>.vimrc</em> 和选定的插件移植到 <em>任何</em> 其他应用程序所需的努力根本不值得。

Avatar
Matt Pass | 2013 年 5 月 21 日
还没有读者喜欢这个。

不确定我会同意。在文件大小方面，基于软件的编辑器更重。Sublime (5.3 mb)、Brackets (28.8mb)、Textmate (12.3mb)、Vim (9.1mb) 和更多都远高于 ICEcoder 的 1.1mb。它自然会更轻，因为您需要的大部分内容已经由浏览器提供。它只是建立在已经打开的东西之上，即浏览器。

在资源使用方面也是如此，它在 1-2 秒内启动，几乎不占用 CPU 或 RAM。我在我的 2.6Ghz 配备 4G RAM 的电脑上非常愉快地运行它，并且过去常常在 1.4Ghz 配备 2G RAM 的电脑上运行良好。尝试过太多启动时间很长然后成为资源消耗大户的桌面编辑器。不再有任何这些情况。

我也喜欢 Vim，主要是因为它的键绑定，但它并没有完成我想要的一切。也就是说，浏览器代码编辑器并不适合所有人，但它们正在朝着它们发展的趋势越来越明显。您只需要以适合您的方式工作，听起来 Vim 最适合您。对我来说，它是 ICEcoder。下一个人可能会坚持认为是 Sublime。

无论哪种方式对您有效，都是“正确的”编码方式 :)

Avatar
Stephan Sokolow | 2013 年 5 月 21 日
还没有读者喜欢这个。

没错。我知道浏览器扩展加载和 Chrome 与 Firefox 之间的设计权衡会产生很大的影响。

Chrome 由于其多进程设计而占用大量内存但响应迅速（尽管 <em>window.opener</em> 支持导致多个选项卡共享同一个进程），而且我无法忍受其扩展 API 中的许多设计决策。

Firefox 的单进程性质有助于它轻量级内存，并且它处理扩展的方式使得实现 HTTPS Everywhere 和 RefControl 之类的东西变得容易，但是他们将 Chrome 自然而然地做的许多事情（例如匹配系统原生滚动轮行为以用于选项卡栏）推送到扩展中，因此所说的轻量级有点具有欺骗性……而且我仍在尝试追踪最后一个缓慢的扩展内存泄漏

更糟糕的是，并且与这种情况更相关的是，一个选项卡中的混乱站点可能会拖累所有其他选项卡。

鉴于我发现 Opera 因为是闭源而无法接受，而 Chrome 因为做出各种我不喜欢且无法使用扩展覆盖的设计决策而无法接受，所以我被 Firefox 困住了，这意味着我实际上被 Ye Olde Windows 3.1 协作式多任务处理困住了。

基本上，我必须运行一个单独的 Firefox 或 Chrome 配置文件，只是作为一个应用程序运行时环境，而仅仅为了 ICEcoder 而这样做是不可行的。

也许在未来可以，但我只是不认为 Web 运行时环境（或任何您想用作通用术语的东西）足够成熟以满足我现在的需求。

Avatar
Steve Hamblett | 2013 年 5 月 21 日
还没有读者喜欢这个。

真正决定开发环境的不是代码编辑器，而是使用的 IDE。例如，我根据当时正在从事的项目，使用 VS2012、Netbeans 和 Eclipse 的组合。

诸如 Cloud9 IDE 之类的东西还可以，但在达到上述工具的水平之前还有很长的路要走。

Avatar
Stephan Sokolow | 2013 年 5 月 21 日
还没有读者喜欢这个。

多年来，我尝试使用各种 IDE，但我尝试过的每一个都只会给我带来更多的干扰和麻烦，所以我一直回到像 Vim 这样视觉上极简主义的东西（带有各种用于静态分析的插件等），结合 <em>git gui</em>、用于各种命令行工具的 Quake 风格终端，以及对于 Web 应用程序，类似于 Firebug 或 Chrome 开发人员工具的东西。

我确实理解您的观点。像 Cloud9 这样的工具有点处于一个不舒服的中间地带。对于某些人来说太像 IDE，对于另一些人来说又不够完整。

相关内容

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 3.0 Unported License 获得许可。
© . All rights reserved.