But Sublime doesn't do all of that. It does some things better, and others worse (and still others not at all).

I couldn't write a plugin for Sublime to embed a web browser. I couldn't write a plugin for Sublime to display images inline by fetching their URL if found in the source.

Those kinds of features might not be important to you, and that's fine, but they are indispensable for me.

>I couldn't write a plugin for Sublime to embed a web browser.

Yes - that is true. and, with atom basically being a web browser, it is trivial for them to do it.

>I couldn't write a plugin for Sublime to display images inline by fetching their URL if found in the source

I actually think that is now possible in ST3. With the new "Phantom" plugin API it can certainly inject a subset of html (including <img/> tags) into the view.

>with atom basically being a web browser, it is trivial for them to do it.

Which was the point of them making it in a web browser. Leverage that as a platform to make extensions/plugins easier to write and maintain and allow them to do more.

Atom is a more capable "IDE" than any other IDE i've ever used, and it's easier to create and manage plugins for. Yeah, there are still some rough edges and things that I hate about it (honestly the whole "hanging for 30+ seconds because you accidentally opened a compiled file" shit really needs to get dealt with somehow, every release they chip a bit off of it, but it is still annoying), but it's by far the editor i'm the most productive with (by quite a large margin).

Now, I haven't worked on web in a while, but what advantages does having an in IDE browser of a random provenance (it trails Chromium by 2-3 weeks) vs using a known version in a separate window beside it?

edit: spelling

The same benefits that having multiple tabs of code windows is better than multiple separate windows.

When i'm debugging/developing/whatevering code that is going to run the same in all supported browsers, doing it in the editor directly allows me to switch tabs back and forth quicker and easier than having them as separate windows.

When i'm working on my laptop without any additional screens, being able to keep the view of the page on the same screen at the same time as the code is hugely beneficial.

When i'm at home I still tend to use a separate instance of the browser to "preview", but I still drop into the embedded one because the keybinding is so fast and easy to take a quick look then close the tab.

Plus being able to open bookmarks to random documentation websites and see the docs in the most up to date format in their "correct" formatting right in the editor is a huge bonus too.

> When i'm debugging/developing/whatevering code that is going to run the same in all supported browsers, (...).

Completely off-topic remark: I always find it funny that Web is hailed as the Write Once, Run Everywhere there is a browser, but then words "supported", or "compatible" start cropping up.

Write Once, Run Everywhere != every line is 100% compatible with every platform.

Really any more the only things that aren't "cross-platform" are bugs, and very new stuff.

> Atom is a more capable "IDE" than any other IDE i've ever used

That says more about you than it does about atom.

You should check out the IDEA line of IDEs sometimes.

I can literally hear when my coworkers have IntelliJ open. People are here griping about Atom's memory use, but using 1GB of memory is an order of magnitude better than obliterating my battery by pegging my CPUs. No thanks.

To be fair, Atom isn't to friendly to the CPU either, especially when it's loaded to the brim with plugins!

When does IDEA do that?

I use it every day and not experienced what you are describing.

I own a license and use IntelliJ's tools a lot still. Whenever I jump into Java code they are the gold standard! But when I'm working on web code, Atom runs circles around WebStorm.

> Atom runs circles around WebStorm.

Because it can show you a preview of the page? Because, as far as code indexing is concerned, Atom doesn't do a very good job at all.

Well yeah, and all the other things that I like about it.

And as for code indexing, Atom doesn't do much of it at all out of the box. Everything is in plugins (by design). So it can use the full abilities of TypeScript or Flow if you add those plugins, or it can just use TernJS, or it can offer simple string-matching autocomplete.

It does as good of a job as what you plug into it does, as all it really does at the core is display text, and give a plugin interface.

Sublime has minihtml, just in case:

https://www.sublimetext.com/docs/3/minihtml.html

It is a bit different from when you are using a browser trying to look like a text editor, but still.

Which is fantastic for some use cases, but not for the use case where I want a fully featured browser window in my editor to preview my page i'm currently working on as I'm working on it.

Why not have one's actual web-browser as an adjacent window, with livereload?

I think it's an anti-pattern for the primary application in use to be reflexively maximised and lay claim to the whole screen, meaning everything must be inside it.

If i'm working on a laptop with only one screen, an adjacent window starts to crowd the UI pretty heavily. Having it in a tab is easier for me.

You can call it an anti-pattern, but for me the anti-pattern is alt+tabbing back and forth to see if my changes look good, or cramping the browser to 1/2 the screen and the whole editor (with sidebar, file tree, and other crap) cramped in the other half, or needing to navigate to localhost:3000 every time I want to look at something VS having a keybinding to open to the exact page i'm working on.

Having a web browser embedded in your editor somehow increases your screen real estate? How do you change from editing to viewing in a different tab that is any different from changing from editing to viewing in a different window?

True.

Still doesn't change the fact that you can open the page in a normal browser and autoreload it with some pluging in other text editors, but you can't have the same performance in Atom ¯\_(ツ)_/¯

Sublime has frustratingly bad CJK support which someone from those countries would have fixed by now if it were open source.

I got a plugin to get the IME working on Ubuntu but it could be so, so much easier.

I wanted to agree with you and write a snide remark about Atom, but then I checked RAM usage of an empty Sublime Text 3 instance on 64 bit Linux, and it was at about 136 MB, so there's that.

Sure - there will always be an overhead for window compositing, etc.

But the point of the article is the bloat as you open larger files, which gets much larger when you use a DOM to do syntax highlighting.

I have (and unfortunately still have to from time to time) open massive log files - in sublime / vi / nano they open fine (even with syntax highlighting), but even on my workstation Atom and Code fall over.

Maybe the virtual DOM should be an actual virtual DOM instead of an additional DOM that doubles the materialized DOM (like desktop application's virtualized list and tree views since 20 - 30 decades).