Removing Shadow DOM boundaries from text editor elements | Hacker News Reader

Removing Shadow DOM boundaries from text editor elements

blog.atom.io

52 pointscrbelaus33 comments

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?

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.

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

Which is strange given than shadow dom is supposed to make this easier.

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.

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.)

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!

Wx, Qt, Tk all also fall into that boundary.

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.

> 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.

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.

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.

Damn, how could I forget Swing? Its such a breeze to use!

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

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.

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.

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.

Try opening a 1GB log file.

But why?

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.

But a text editor to open a file you won't ever edit is maybe also not the best idea. A pure text viewer can use different data structures that don't have to anticipate edits to the text and likely be faster. Or, on the other hand, a text editor trying to optimise the use case where people open large files without editing them (or only editing tiny portions of it), will likely grow a lot more complex.

Irony here is, I just opened a 290k file in vim... and... well, let's just say it was about 30 seconds before I could do anything. So I thought, "let me open this in Atom". Almost immediately it appeared, AND I could scroll through it! (with vim-mode obviously)

Eh, when this happens to me I just hit ^C, since it's likely trying to apply syntax to the whole thing. At least I can do something in the editor immediately after.

Perhaps it's TypeScript making the difference?

TypeScript generates some code that's unlike what a person would write directly in JavaScript, which probably does impact performance to some degree. Enums can become integers where a human might decide strings are good enough and more readable than magic numbers. And if you're only using TypeScript, you can avoid writing some run-time sanity checks. But it also emits a lot of boilerplate for modules and classes and such. Not sure if the net effect would be a gain or loss.

When targeting an ES6/ES2015 compatible runtime like node or electron (which VS Code runs on), typescript essentially just strips away the type information. It only generates boilerplate when the underlying runtime doesn't support the parts of the Javascript you use.

It does not, it is still about 5 times slower than Sublime (just random measurement of how long it takes to start editor & initialize workspace on my machine). But speed is good enough that VS Code became my main editor.

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

I really like ink.

Is there a similar plugin for vim / nvim?

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.

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 wonder if there will be any performance benefits from removing Shadow DOM in Atom.

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

Reply on news.ycombinator.com