6 ms·

Removing Shadow DOM boundaries from text editor elements

52 points by crbelaus 10y ago

draw_down 10y ago
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.
Someone 10y ago
So, does this mean the shadow DOM is a bad idea, in general, or is there something special about Atom that makes it a bad idea for Atom or maybe even text editors in general? If so, what's the criterion to use to decide whether one should use the shadow DOM?
- spankalee 10y ago
  Seems like the main concern was not being able to extract the editor component to use in other browsers. This could have been solved with the Shadow DOM polyfill, but it has a performance cost to it. Polymer's faster Shady DOM shim wasn't extracted into a standalone library until recently. The issues with themes and shared styles are largely solved by CSS Custom Variables, which inherit through shadow boundaries (much like /deep/), and Shadow DOM v1 (the new spec implemented by Safari and Chrome) which allows <link rel=stylesheet> tags inside shadow roots.
- bwat48 10y ago
  I don't think they're saying it's a bad idea in general, the issue here seems mostly related to the shadow dom making it difficult/complicated for people to theme atom/re-use components etc... I'm not a web developer but I'm sure there are valid use cases for it, as well as use cases such as this one where it's not ideal
  - sametmax 10y ago
    Which is strange given than shadow dom is supposed to make this easier.
- Zikes 10y ago
  In general, the shadow DOM will have positive impacts on performance. Right now when you insert an element on a page it inherits all of the CSS of that page and must be evaluated accordingly, whereas a shadow DOM element can have a very small set of styles associated with it. These benefits won't be realized until the shadow DOM is fully implemented, however.
Hurtak 10y ago
I wonder if there will be any performance benefits from removing Shadow DOM in Atom.
eatonphil 10y ago
So Atom just discovered BEM? To be fair, I only just started getting into it too; it is incredibly useful for organizing CSS.

52 points by crbelaus 10y ago

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.

Someone 10y ago

So, does this mean the shadow DOM is a bad idea, in general, or is there something special about Atom that makes it a bad idea for Atom or maybe even text editors in general? If so, what's the criterion to use to decide whether one should use the shadow DOM?

spankalee 10y ago
Seems like the main concern was not being able to extract the editor component to use in other browsers. This could have been solved with the Shadow DOM polyfill, but it has a performance cost to it. Polymer's faster Shady DOM shim wasn't extracted into a standalone library until recently. The issues with themes and shared styles are largely solved by CSS Custom Variables, which inherit through shadow boundaries (much like /deep/), and Shadow DOM v1 (the new spec implemented by Safari and Chrome) which allows <link rel=stylesheet> tags inside shadow roots.
bwat48 10y ago
I don't think they're saying it's a bad idea in general, the issue here seems mostly related to the shadow dom making it difficult/complicated for people to theme atom/re-use components etc... I'm not a web developer but I'm sure there are valid use cases for it, as well as use cases such as this one where it's not ideal
- sametmax 10y ago
  Which is strange given than shadow dom is supposed to make this easier.
Zikes 10y ago
In general, the shadow DOM will have positive impacts on performance. Right now when you insert an element on a page it inherits all of the CSS of that page and must be evaluated accordingly, whereas a shadow DOM element can have a very small set of styles associated with it. These benefits won't be realized until the shadow DOM is fully implemented, however.

Hurtak 10y ago

I wonder if there will be any performance benefits from removing Shadow DOM in Atom.

eatonphil 10y ago

So Atom just discovered BEM? To be fair, I only just started getting into it too; it is incredibly useful for organizing CSS.