3 ms·

As with most things when it comes to software engineering, it's just a trade-off, and depending on your use case, you may fall on either side of it. They sacrif

As with most things when it comes to software engineering, it's just a trade-off, and depending on your use case, you may fall on either side of it. They sacrifice memory usage for development pace. Using Javascript/CSS allows them to not only get some of the most powerful pre-existing tools, but also allows the 3rd party community to move at a much faster pace too. Atom already has twice the number of packages as Sublime Text while being half the age.

pjmlp 9y ago
> Atom already has twice the number of packages as Sublime Text while being half the age. Somehow I think it has more to do with developers not wanting to pay for software than anything else. XAML coupled with Blend studio is a powerful UI design tool, or stuff like Adobe XD. HTML/CSS not really.
klibertp 9y ago
> They sacrifice memory usage for development pace. This is a false dichotomy. Vanilla Emacs needs 38Mb on my machine, and it has all the tools you'd ever need to develop plugins for it. Visual debugger, byte-compiler, object inspector, jump to definition (including straight to C implementation when needed), visual font pickers, color palette, documentation browser & docstring viewer for symbol at point, you name it - it's all there. Browser engines are not optimized for handling text editing. They are optimized for basically everything else but text editing. You can make them into kind-of OK text editors, but you have to put a lot of effort just to get to where text-editing frameworks are already[1]. And 200Mb of unnecessary code doesn't make getting there any easier. To my mind, developing a text editor with a web browser is a bad technical decision. It may pay off in the number of devs available and eager to help - it may be worth it, I don't know, it's for the projects' leads to decide. Technically, though, these projects would be much better off with a text-editing framework. [1] LightTable is a good example here. Well-funded, motivated team worked on it for a couple of years - and still failed to provide anything more than Emacs with plugins. Well, it looked a bit better.
- ahtu123 9y ago
  The DOM is about the worst structure for text editing I can think of..
  - klibertp 9y ago
    Yeah, reminds me of this post: https://ecc-comp.blogspot.com/2015/05/a-brief-glance-at-how-5-text-editors.html https://ecc-comp.blogspot.com/2015/05/a-brief-glance-at-how-... There's a simple array of lines, a gap buffer, a BTree... No DOM, though. I wonder why... :)
    - ahtu123 9y ago
      When all you have is JavaScript, everything looks like a... browser?

pjmlp 9y ago

> Atom already has twice the number of packages as Sublime Text while being half the age. Somehow I think it has more to do with developers not wanting to pay for software than anything else. XAML coupled with Blend studio is a powerful UI design tool, or stuff like Adobe XD. HTML/CSS not really.

klibertp 9y ago

> They sacrifice memory usage for development pace. This is a false dichotomy. Vanilla Emacs needs 38Mb on my machine, and it has all the tools you'd ever need to develop plugins for it. Visual debugger, byte-compiler, object inspector, jump to definition (including straight to C implementation when needed), visual font pickers, color palette, documentation browser & docstring viewer for symbol at point, you name it - it's all there. Browser engines are not optimized for handling text editing. They are optimized for basically everything else but text editing. You can make them into kind-of OK text editors, but you have to put a lot of effort just to get to where text-editing frameworks are already[1]. And 200Mb of unnecessary code doesn't make getting there any easier. To my mind, developing a text editor with a web browser is a bad technical decision. It may pay off in the number of devs available and eager to help - it may be worth it, I don't know, it's for the projects' leads to decide. Technically, though, these projects would be much better off with a text-editing framework. [1] LightTable is a good example here. Well-funded, motivated team worked on it for a couple of years - and still failed to provide anything more than Emacs with plugins. Well, it looked a bit better.

ahtu123 9y ago
The DOM is about the worst structure for text editing I can think of..
- klibertp 9y ago
  Yeah, reminds me of this post: https://ecc-comp.blogspot.com/2015/05/a-brief-glance-at-how-5-text-editors.html https://ecc-comp.blogspot.com/2015/05/a-brief-glance-at-how-... There's a simple array of lines, a gap buffer, a BTree... No DOM, though. I wonder why... :)
  - ahtu123 9y ago
    When all you have is JavaScript, everything looks like a... browser?