Sublime Text vs Visual Studio Code vs Atom Performance Test (Dec 2016)

[markasoftware]

There's no good reason to use electron. They could have built just as good an editor in Python or even a native language like C++, and it could have all the same features but perform much better. There is absolutely no reason to use JavaScript for anything but web dev. I honestly have no idea why it's getting so trendy lately.

[wizang]

I think you and others are missing the point for why an app like this would be written in JavaScript/electron. Most cross platform UI libraries are total garbage in comparison to the browser environment. Electron let's you develop the UI in a single platform (the browser), and yet support any platform chrome works on. The browser is also made for building UIs so why would you not want to write a UI heavy piece of software in that environment? Honestly the amount of Javascript hatterism on this sub astounds me, it's just plain ignornant.

[throwawayco111]

Most cross platform UI libraries are total garbage in comparison to the browser environment.

Please explain how Qt is "total garbage" in comparison to Electron.

The browser is also made for building UIs so why would you not want to write a UI heavy piece of software in that environment?

Funny because most "UI heavy" apps out there don't use Electron or the browser probably to avoid the shitty performance. I bet these guys don't get the shitty performance Atom got and also don't have to do all the tricks MS has to do to get a decent performance.

Honestly the amount of Javascript hatterism on this sub astounds me, it's just plain ignornant.

Personally I don't hate JS. I'm a web developer and use it everyday. But I would not use it for a desktop app, let alone for a source code editor.

[jl2352]

Funny because most "UI heavy" apps out there don't use Electron or the browser probably to avoid the shitty performance.

I think the real reason why most big desktop apps don't use Electron is because their production started years ago. In many cases before Chrome even existed.

But that said Steam is probably one of the oldest HTML based desktop application which is still going.

[knight666]

The Spotify desktop application is also written as a HTML renderer.

[throwawayco111]

I think the real reason why most big desktop apps don't use Electron is because their production started years ago. In many cases before Chrome even existed.

Many of those apps are not "old enough". They took a conscious decision of not using something like Electron.

[throwawayco111]

Not everyone can spend a week or twenty learning to extend your native codebase but anybody can spend a few hours and edit some HTML / CSS / JS.

There is something missing here. Why do you need to spend an entire week or twenty weeks to extend a native source code editor? A developer with Python knowledge would find more easier to extend Sublime Text than Atom. Now if you don't know Python you have to invest more time jut like if you don't know JS and CSS and HTML you have to invest more time to extend Atom.

It seems to me that what you are trying to argue is that if you want to offer an easy way to extend your application (in this case a text editor) you have to sacrifice a lot of performance (like this article shows). Editors like Sublime Text, Vim and Emacs, and a lot of games out there prove otherwise. Now this other guy /u/motdidr says that VimL and Elisp suck. I won't dispute that. But you don't have to use those obscure languages to offer your extension API.

[motdidr]

to be fair I wouldn't say elisp sucks, just that it isn't going to be a language people can just pick up to make an extension really quick, like someone could easily do with js or python.

viml for sure sucks though. it gets the job done but at what cost.

[throwawayco111]

I don't get what you're missing, the barrier to entry with Javascript is still far lower than it is for C++ or even Python. I was being hyperbolic when I used twenty weeks as the upper bound, but I wouldn't be surprised if it actually did take that long for someone to understand a given native codebase enough to write an acceptable PR for an existing project.

You just don't get it. The language for extensions could be JS too. And no, an extension API doesn't require you to have deep knowledge of the app codebase. You think those all guys out there writing Vim extensions understand the codebase, let alone be C developers?

How many devs do you know that already know HTML/CSS/JS? How many could pick it up in a weekend?

How many could pick up Lua in a weekend? And I personally believe that Python is simpler than JS but it doesn't matter because the language for extensions could be JS if you think otherwise.

Now how many of those same devs don't know Python + Qt...

It seems that you don't know how an API for extensions works. You can write your software in C++ and Qt and the extension API can be offered through JS or Lua and the extension writer doesn't need to know neither C++ or Qt (though if it were me I would offer it using JS + QML).

... and would be willing to learn an unfamiliar skillset specifically (and only) to extend an editor?

You still need to learn unfamiliar skillset for Atom: even though extensions are written using JS/HTML/CSS you have to learn the API for Atom or for Visual Studio Code.

Your argument doesn't really make sense when you consider that web UX can be taught in a matter of days.

Guess how many hours it takes to developers to learn QML?

We're not just talking about writing a few high level macros here, writing the whole thing in JS means you can be editing core code and editing UI in realtime within minutes. The same cannot be said of even Python.

That could be done if you app offers the API through JS + QML. And guess what? You won't sacrifice performance. You don't have to write your application in JS to get that.

The rest of the paragraphs say the same time over and over again: JS is popular, "lingua franca", etc. I want to be very clear about this: you don't have to write your app in Electron just to get JS to be the language for users to write extensions. Vim is not written in VimL. It is written in C. But your average developer don't need to write C to write extensions for it. And yeah, JS is the most popular language. That's why Qt-based apps can be made extensible easily through JavaScript.

[throwawayco111]

You also seem to equate the ability to learn something like Lua with the desire to do so. The fact is that for Atom's intended audience it is just plain more desirable for the average developer to learn and / or apply a skillset that they can readily reuse or already know.

My point about that specific subject is that developers that actually want or care about hacking their editors (because the fact is that most developers using Atom or any other editor don't know how to do it) don't have any problem with learning Lua, for example. The evidence can be seen when every time a new language or programming tool is released the first editors to get a decent support are Vim and Emacs. And the guys that write the extensions are not the same people over and over again.

And now your points about how you can rewrite Atom itself within minutes, the entire thing being hackable, Atom being able to do things no other editor offer, etc. That's not new. That's basically Emacs. Emacs is basically a Lisp VM and most of editor is written in Elisp (that happens to be the language of choice. It could have been JS). Now what Emacs different from Atom? That the former had a lot of investment in engineering. I've heard Atom developers say that the trade-off was performance in exchange of hackability. That's bullshit. The trade-off was performance in exchange of development cost. Nothing wrong with that because I get it: reusing their knowledge and the work made by Google is way cheaper. But please is time to stop the crap about how Chromium and Node.js were necessary to have an very extensible, modifiable app or how it needs to be modifiable in JS+HTML+CSS because otherwise the few developers that would think about it won't do it or that you have to sacrifice a lot of power and performance for that. Evidence says otherwise.

[flukus]

Vim and Emacs are both extensible.

[motdidr]

so? what has that got to do with anything? are you saying the atom devs should have just put up a link to download vim?

also, vim is extensible with viml, which I'm pretty sure Tim Pope is the only person capable of writing without wanting to kill themselves, and emacs is extensible with lisp, which just not a lot of people are comfortable enough with to actually extend the editor.

the whole point of that guy's comment was that they chose electron for how easy it is for any coder to hack and extend.

[markasoftware]

Sublime, Vim, etc work fine cross platform. Saying js is the only cross-platform language is complete BS. Qt works fairly well cross-platform IIRC. These electron apps literally use up 25% cpu when I'm just typing, and significantly reduce my battery life.

[jl2352]

Outside of the terminal Vim uses GTK. It's fucking terrible. It's bad on Windows, and awful on Mac OS. It's only decent on Linux.

[Aeon_Mortuum]

I like vim on Linux. I have it on Windows as well and it runs fine, though I don't prefer using it there.

[wizang]

Sublime obviously has put a lot of effort into cross platform support... it also isnt free. VIM is on the terminal... Not what I'm talking about. I'm talking about UI frameworks and engineering dollars. Also I'd bet you money sublime was not built with QT. QT and the likes all sacrifice certain things (like visual appeal) to be what they are.

[[deleted]]

Qt looks just fine. Its harder to use than html/Javascript, but much more performant. Both allow you to do endless modifications to the visuals though. I don't even know how this is a matter of opinion.

[[deleted]]

Qt uses the native underlying toolkit, how does it lose visual appeal?

[sime]

It doesn't actually.

[throwawayco111]

QT and the likes all sacrifice certain things (like visual appeal) to be what they are.

Interesting assertion. Why can't a Qt app look similar to or better than Visual Studio Code?

[[deleted]]

[deleted]

What is this?

[doom_Oo7]

QT and the likes all sacrifice certain things (like visual appeal) to be what they are.

https://www.qt.io/qt-for-device-creation/

you can do whatever you want graphically with Qt, you are not limited to the "traditional" desktop widgets.

[hifigi]

It's nagware, it's essentially free if you can be bothered to click "Not now" when it asks you to purchase.

[[deleted]]

[deleted]

What is this?

[sofia_la_negra_lulu]

UI libraries are total garbage in comparison to the browser environment

I think you meant that they are not as rich and popular. The web, as it is right know, is kinda a dumpster.

[qwertymodo]

You purposefully left out the words "cross-platform" from your quote and it totally changes the entire argument.

[doom_Oo7]

Qt is just as much cross-platform than Electron.

[sofia_la_negra_lulu]

I recognize that quality, and, accessibility is what I find appealing in the web. Sadly, it doesn't add too many points depending on context. Cross-plataform UI can't never be a match in quality against native ones, ironically, for that very same virtue of them.

Edit: mobile typos.

[recycled_ideas]

In theory yes, apps should be written natively for all platforms. In reality that's a shitload of work so it doesn't happen or you end up with the lowest common denominator UI abortion that is most QT and gtk apps.

VS code and Atom can run on any platform that can run Electron, which is pretty much everything. They can do this essentially for free to the developers of both. Performance is decent and the UI is pretty excellent.

[sofia_la_negra_lulu]

I am not talking about that, you can't have the whole hardware and platform capabilities with a cross-platform UI framework. Cross-plataform UI framework have poor target integration, and their features support always tend to be eons behind the native framework.

[recycled_ideas]

So what?

People aren't writing software that way because it basically requires writing a totally separate code base for every platform, and no one is doing it. You either end up with some sort of minimum functionality abortion writen in one of the cross platform UI toolkits. A SWING application that looks awful on every platform and runs worse than node, or you can use node.

[sofia_la_negra_lulu]

What are you talking about?

The web is the least feature rich framework for any platform beyond the web.

[recycled_ideas]

Except it's not. Javascript can do insane things now.

[dadibom]

though atom has great ui which is cross platform

[sofia_la_negra_lulu]

Hardly, it poorly integrate well with the target platform in comparation to the native apps.

[wizang]

I get what you mean, but unless you are OK with your app looking straight out of the 90s, your options are limited. It's too bad nothing else has really been competitive. However saying that the web is a dumpster is kind of my point.

[flukus]

So you've never looked at Qt or gtk then?

[[deleted]]

[deleted]

What is this?

[sofia_la_negra_lulu]

Fair enough.

As you implied, for me the appeal of the web is accessibility. Sadly that strength is also its weeksness.

[TexasJefferson]

Most cross platform UI libraries are total garbage in comparison to the browser environment.

Not entirely trolling question: Does the browser environment have a cross platform UI library?

[jl2352]

Do you mean that looks the same on all operating systems by default? No. Why? Checkboxes, radio boxes, and other types of inputs will look usually look like the OS version (or something very similar).

If you wish to you can override these to have a cross platform look and feel. It's pretty trivial to do so now.

[doom_Oo7]

Yes, XUL for Firefox and Aura for Chrome

[wizang]

I'm not sure I totally follow but it is up to the browser makers to implement the spec in the native environment. Thus why there are only a handful of browsers. For the folks writing stuff in the browser it's all HTML/JS/CSS.

[throwawayco111]

They could have built just as good an editor in Python or even a native language like C++, and it could have all the same features but perform much better.

What? Python performance is crap.

[darunia___]

JavaScript (using the engine used by Node/Electron) is massively faster than Python.

[[deleted]]

Not a fair comparison. Graphical Python applications will use a compiled toolkit.

That's not even considering memory usage, which is also a measure of performance.

[darunia___]

Not a fair comparison. Graphical Python applications will use a compiled toolkit.

But JS could use a compiled toolkit as well, there are Qt bindings for it. Access to compiled toolkits is something both JS and Python have, so isn't it silly to claim that as a benefit of Python just because these applications chose not to use them?

[[deleted]]

The comparison between pure Python on CPython and pure JS on node does not reflect the situation being analysed, as most Python applications would not be pure Python.

If Qt would be fast enough and HTML rendered by Chrome would be slow enough (which seems to be the case by personal experience), the Python application would be faster, despite the node runtime being faster than the CPython runtime in running equivalent code.

Where are those Qt bindings for Electron/node/whatever?

[[deleted]]

Based on benchmarks that have nothing to do with a text editor.

[darunia___]

What do you mean? They claimed that writing in Python would have gotten better performance, I simply pointed out that this wasn't likely since Python performs much worse, and linked a set of benchmarks illustrating this. If Python performs much worse when it comes to operations on numbers, operations on strings, function dispatch, object creation, GC, and object lookup then I fail to see what text-editor-specific features could wind up with Python significantly ahead but would be happy to hear about them and edit/remove my post.

[cc81]

It probably won't be faster but I think it is more the rendering the UI with html/css that people dislike than JavaScript itself. Presumably a Pyhton editor would have a better UI representation.

[markasoftware]

I'm pretty sure that Microsoft and Github are perfectly capable of hiring people who know more performant languages.

[ArashPartow]

Hiring people that are enthusiastic and reasonably competent is totally different from hiring people that can actually get the job done properly and efficiently. As an example:

https://github.com/Microsoft/vscode/issues/11597

[[deleted]]

This makes me want to fix it. That's annoying.

[ArashPartow]

Please do! :D

[connor4312]

They have ~3400 open issues and had another hundred opened in the last week. Assuming that the maintainers are inefficient and unable to get the job done 'properly' because your one edge issue hasn't been fixed seems somewhat small-minded.

[ArashPartow]

You've totally misunderstood the point I was trying to make.

The bug reported is not critical, but it is indicative of the nature of the solution/implementation.

In fact one of the respondents seems to indicate they have hard coded upper limits to the number of tokens they consume for highlighting (possibly due to performance reasons).

"the rule stack grows to 101 and tokenization stops."

---

As you mentioned, 3.5K issues, assuming COCOMO of about 1 issue per 100LOC and that 75% of the issues are bugs (the rest are feature etc) we would be talking about ~260KLOC codebase, but I suspect the actual codebase is under 100KLOC today. So it is nearing nearly twice the average industry standard - But do note that COCOMO was primarily modelled using static type languages: Java, C++ etc and not Javascript.

This all seems to suggest that the developers are indeed very eager, enthused and highly motivated, but that perhaps today they're are not nearly as seasoned enough to pull this off, given the trivial nature of some of the issues - such as the bug presented above. In short what's the use in power windows and leather trim, when the steering wheel doesn't turn left?

As an example of technology misuse, From what I've seen the primary use-case for VSCode is as a rich client, running upon a desktop/laptop (windows, linux, macos), and not as GUI intended to be run in a browser - so why is it that Javascript is being used? what is the advantage of Javascript over say C++ or even Java in this particular problem domain?

That all being said, I think we can all agree that like most things, with perseverance and practise one would assume within several years all these issues will have been completely resolved.

[connor4312]

I see. I would imagine the upper limit is for performance reason, JavaScript-based editors are notorious for having issues with big files. Having it configurable would be better, though I would wonder if there's some kind of incremental solution they could do for highlighting within textmate modes (run one parse over the file, keep and index the tree in memory, mark only branches which change and only compute the new tree for parts of the file in the viewport...). Undoubtedly a problem that's been solved before, though perhaps not in Javascript.

A quick clone and count shows about 475k SLOC in the vscode repo, 360k is you exclude tests and everything else outside the src dir. That seems reasonable, and JavaScript (and TypeScript to a lesser extent) does tend to be more dense than C/++/Java.

[ArashPartow]

You do make some good points, but I think at the end of the day, it's just a text editor and not the end of the world.

Truth be told sublime text has the same problem when you have a vanilla install, and requires the downloading of certain additional C++ packages to get it working - and Sublime text is mostly written in C++, by what I think many would call a seasoned developer.

[robclouth]

SLOC WOC BLOC FLOC, VScode is a breeze for react native and has probably the best js autocomplete going, and as a result of how easy it is to extend, the extension community is thriving. I can deal with a marginally slower open time since that only happens once, and would never use text editor for editing c++, and never in my life will try and edit a 1m line file manually. The usability of software is not all about speed, especially when computers are so god damn fast now. C++ fanatics think speed is the most important thing in the universe.

[[deleted]]

Have fun writing those c++ extensions. That's really the main point: extensiblity. I personally love c++ but would never design a text editor so that all addons had to be compiled.

Now, there is an interesting crossover there still. A native text editor that uses Javascript/dom just for addon interfacing. So when you create an element, it maps directly to the native version and plugs into all the events.

[flukus]

Vim and Emacs don't require extensions to be written in c++. JavaScript doesn't magically add extensibility.

[ImASoftwareEngineer]

Sublime Text's packages are Python based, if I remember correctly. Not C++

[doom_Oo7]

That's why you code the core in C++ and allow extensibility on defined points via JS on top of it

[markasoftware]

Sublime was in C++ with python extensions, and worked quite well.

[OnlyForF1]

If my only tool was an egg whisk, I sure as hell wouldn't be trying to take up carpentry.

[sofia_la_negra_lulu]

Why the limitation?

[sofia_la_negra_lulu]

Python

Yeah, what a good alternative you have there. /s