7 ms·

I still feel like using web technologies to build an editor was a strange choice. (Though I don't mean to disagree with the reasoning here, which sounds OK to m

I still feel like using web technologies to build an editor was a strange choice. (Though I don't mean to disagree with the reasoning here, which sounds OK to me.)

CJefferson 10y ago
There are some good reasons to think it's a good idea. Let's assume you want to escape from the terminal (which seems like a reasonable idea for lots of reasons -- pictures, icons, variable-sized fonts among others). So, let's assume you don't want to have to implement text / picture rendering yourself from scratch in a multi-OS manner. Where can you get code that has spent years working on the highest performance, dynamic text and picture rendering? Web browsers!
- shakna 10y ago
  Wx, Qt, Tk all also fall into that boundary.
  - msbarnett 10y ago
    Something like Qt wouldn't help much. Even if you provided a scripting bridge so that extension authors could distribute one plugin for all platforms, the extension model is wrong -- if I have to subclass a Qt component to extend it, then my extensions don't compose with everyone else's. You'd need to use Qt to build an extension framework that exposes document contents in a way that all extensions can customize their display simultaneously -- and at this point you're just creating an ad-hoc, less well-understood DOM.
    - kuschku 10y ago
      > You'd need to use Qt to build an extension framework that exposes document contents in a way that all extensions can customize their display simultaneously -- and at this point you're just creating an ad-hoc, less well-understood DOM. QtQuick with QML and their scripting engine? It has a full DOM, scriptability, and extensibility.
      - msbarnett 10y ago
        Sure, you could do that. You're using a less well known DOM, which will probably discourage extension authorship somewhat. AFAIK Qt's "v4" is a v8 fork, so scripting performance is probably a wash. It's hard to imagine that the DOM renderer in QML is really much better performing than Webkit, and anyway it's not really DOM rendering that's the slow part in Atom -- VS Code proves that. I don't know what you'd really hope to gain from this, in other words. "Atom is more-or-less just as slow but has a less well known DOM" doesn't strike me as a compelling engineering decision.
  - adrianN 10y ago
    Whatever happened to Java? It was the "write once, run anywhere" language fifteen years ago. Dynamic class loading makes writing extensions pretty easy as well.
    - shakna 10y ago
      Damn, how could I forget Swing? Its such a breeze to use!
overcast 10y ago
Have a look a Visual Code for the proper way of writing an Atom like editor. Performs just like native.
- vvanders 10y ago
  I would love to see some analysis on this written up. Having used VSCode for a while I'm always incredibly impressed with how snappy it is.
  - spoiler 10y ago
    Is Atom not snappy for you? I've used both and I honestly can't spot the difference on Linux; both are enough snappy for me. I know Atom lags with huge files sometimes, or when I place a lot of multiple cursors and then edit something, but I haven't tried either with VSCode.
    - overcast 10y ago
      Atom is pretty horrendous on both Mac, and Windows, at least from the last time I used it. Which admittedly was months ago. I really, really tried to give it a shot. But it takes forever to start up, and is just overall sluggish on simple stuff. Try VSCode, you'll never use Atom again. It feels pretty damn close to Sublime in responsiveness.
    - rb808 10y ago
      Try opening a 1GB log file.
      - atomi 10y ago
        But why?
        rpeden 10y ago
        Perhaps because it's a use case that many people use a text editor for. For those people, opening such a file makes for a good test to compare the performance of Atom and VSCode...and Vim, and Emacs, and lots of others. For writing code, I find Atom a bit slower to start up than Code, but generally nice and usable afterward. That's on an 8 core, 32GB of RAM system, though, so Atom could very well be more sluggish for others.
msbarnett 10y ago
If they were just trying to build an editor, sure. But they're trying to build an Emacs, so it makes sense to address a major pain-point that Emacs has: drawing, adding to the UI, and radically changing how the contents of a buffer look is at worst hard-to-impossible and at best inflexible and hard to find documentation on. Starting with a well-understood document model that a lot of people have experience with making look however they like has a ton of benefits. You can build things like ink[1] without needing the core editor devs to forsee your need for nestable menu primitives, for instance. [1]https://atom.io/packages/ink https://atom.io/packages/ink
- lpasselin 10y ago
  I really like ink. Is there a similar plugin for vim / nvim?
spoiler 10y ago
I kind of agree with you. On one hand, a lot of things are vastly simplified, some is pretty platform-indifferent, and some became more complicated, but then again I think it would've been similar with any platform, there'd just be different '+/=/-'s.
tdb7893 10y ago
You can write one application which uses tools that most developers are already familiar with to target multiple platforms. Honestly if it works well it seems like a generally better way to create apps.

I still feel like using web technologies to build an editor was a strange choice. (Though I don't mean to disagree with the reasoning here, which sounds OK to me.)

CJefferson 10y ago

There are some good reasons to think it's a good idea. Let's assume you want to escape from the terminal (which seems like a reasonable idea for lots of reasons -- pictures, icons, variable-sized fonts among others). So, let's assume you don't want to have to implement text / picture rendering yourself from scratch in a multi-OS manner. Where can you get code that has spent years working on the highest performance, dynamic text and picture rendering? Web browsers!

shakna 10y ago
Wx, Qt, Tk all also fall into that boundary.
- msbarnett 10y ago
  Something like Qt wouldn't help much. Even if you provided a scripting bridge so that extension authors could distribute one plugin for all platforms, the extension model is wrong -- if I have to subclass a Qt component to extend it, then my extensions don't compose with everyone else's. You'd need to use Qt to build an extension framework that exposes document contents in a way that all extensions can customize their display simultaneously -- and at this point you're just creating an ad-hoc, less well-understood DOM.
  - kuschku 10y ago
    > You'd need to use Qt to build an extension framework that exposes document contents in a way that all extensions can customize their display simultaneously -- and at this point you're just creating an ad-hoc, less well-understood DOM. QtQuick with QML and their scripting engine? It has a full DOM, scriptability, and extensibility.
    - msbarnett 10y ago
      Sure, you could do that. You're using a less well known DOM, which will probably discourage extension authorship somewhat. AFAIK Qt's "v4" is a v8 fork, so scripting performance is probably a wash. It's hard to imagine that the DOM renderer in QML is really much better performing than Webkit, and anyway it's not really DOM rendering that's the slow part in Atom -- VS Code proves that. I don't know what you'd really hope to gain from this, in other words. "Atom is more-or-less just as slow but has a less well known DOM" doesn't strike me as a compelling engineering decision.
- adrianN 10y ago
  Whatever happened to Java? It was the "write once, run anywhere" language fifteen years ago. Dynamic class loading makes writing extensions pretty easy as well.
  - shakna 10y ago
    Damn, how could I forget Swing? Its such a breeze to use!

overcast 10y ago

Have a look a Visual Code for the proper way of writing an Atom like editor. Performs just like native.

vvanders 10y ago
I would love to see some analysis on this written up. Having used VSCode for a while I'm always incredibly impressed with how snappy it is.
- spoiler 10y ago
  Is Atom not snappy for you? I've used both and I honestly can't spot the difference on Linux; both are enough snappy for me. I know Atom lags with huge files sometimes, or when I place a lot of multiple cursors and then edit something, but I haven't tried either with VSCode.
  - overcast 10y ago
    Atom is pretty horrendous on both Mac, and Windows, at least from the last time I used it. Which admittedly was months ago. I really, really tried to give it a shot. But it takes forever to start up, and is just overall sluggish on simple stuff. Try VSCode, you'll never use Atom again. It feels pretty damn close to Sublime in responsiveness.
  - rb808 10y ago
    Try opening a 1GB log file.
    - atomi 10y ago
      But why?
      - rpeden 10y ago
        Perhaps because it's a use case that many people use a text editor for. For those people, opening such a file makes for a good test to compare the performance of Atom and VSCode...and Vim, and Emacs, and lots of others. For writing code, I find Atom a bit slower to start up than Code, but generally nice and usable afterward. That's on an 8 core, 32GB of RAM system, though, so Atom could very well be more sluggish for others.

msbarnett 10y ago

If they were just trying to build an editor, sure. But they're trying to build an Emacs, so it makes sense to address a major pain-point that Emacs has: drawing, adding to the UI, and radically changing how the contents of a buffer look is at worst hard-to-impossible and at best inflexible and hard to find documentation on. Starting with a well-understood document model that a lot of people have experience with making look however they like has a ton of benefits. You can build things like ink[1] without needing the core editor devs to forsee your need for nestable menu primitives, for instance. [1]https://atom.io/packages/ink https://atom.io/packages/ink

lpasselin 10y ago
I really like ink. Is there a similar plugin for vim / nvim?

spoiler 10y ago

I kind of agree with you. On one hand, a lot of things are vastly simplified, some is pretty platform-indifferent, and some became more complicated, but then again I think it would've been similar with any platform, there'd just be different '+/=/-'s.

tdb7893 10y ago

You can write one application which uses tools that most developers are already familiar with to target multiple platforms. Honestly if it works well it seems like a generally better way to create apps.