… if you want to use React you’ll need to bring it in as an external dependency.
The only way to ensure that Atom keeps up with the times is to minimize our framework commitments and focus on minimal primitives.
Using the DOM as our official API boundary represents that balance.
Choosing the DOM as the official API represents punting the problem down the line. If atom is slow now, I can only imagine what will happen when my 20 plugins load 20 different front end frameworks. I have friends with 100+ plugins in Vim. A front end framework or two per plugin won’t scale to 100 plugins.
We will probably be adding an a la carte global update scheduling mechanism that different frameworks can adapt to to ensure that DOM reads and writes are correctly batched.
This is insufficient. I expect this will break some libraries, or rather, some libraries aren’t compatible with this model. Similarly, many devs won’t use the scheduler because their atom is fast enough. A scheduler does nothing to address the memory footprint of loading 80 different versions of React (assuming React will one day load 2) nor will it lessen the intellij-like start-up time. Finally, plugins, which work alone, will crash each other at runtime (likely depending on the order in which they are loaded).
which leaves everyone freedom to use what they like…
No, the choice is freedom for plugin devs or stability for end users.
We won’t be forcing people into a particular framework, however, especially when it isn’t even 1.0 yet.
Suppose sometime later you come to agree with me. What good will picking a winner be after atom has a large ecosystem of plugins? There is no returning from the wild west of every plugin for itself.