Must every thread about VSCode and Atom start the same way? It's a trade off: performance for a cross platform JavaScript app development. If that is a tradeoff you don't have to make, don't do it. Atom and VSCode have made that tradeoff. I don't know what rehashing this can possibly accomplish.
>Must every thread about VSCode and Atom start the same way
If many people believe this is the case, why not? All articles get some common types of responses based on the topic, this is just one topic/response combo that you happen to disagree with.
>It's a trade off: performance for a cross platform JavaScript app development.
It's an unnecessary tradeoff.
If a single developer can create ST from scratch for Windows, OS X and Linux, then surely GitHub or Microsoft (for VSCode) can create a cross platform native set of UI components in C or C++, wrap them, and have the rest of the development (plugins etc) happen in JS (to keep the familiar language, easy access to npm modules, etc).
> If a single developer can create ST from scratch for Windows, OS X and Linux,
One of the reasons why some people are switching from ST to Atom/VSCode is the former's tortured development schedule, which has seen months or years go by without an update. Contrast VSC, which reliably delivers a heap of improvements every month. JavaScript is probably responsible for a big portion of this. Again, it's a tradeoff.
> then surely GitHub or Microsoft (for VSCode) can create a cross platform native set of UI components in C or C++,
Maybe they can. Or maybe they can't, and if they tried then they'd have the same slow pace as ST. You don't know.
VS Code's release record is impressive. And didn't it grow out of the Monaco browser-based editor? Microsoft probably wouldn't have funded the hypothetical C++ version.
That said, one of the Atom developers says using web technologies made development harder in many ways.[1] Very few solo developers can match a team with Microsoft's resources, and a monthly release schedule is more about discipline than anything else.
> If many people believe this is the case, why not? All articles get some common types of responses based on the topic, this is just one topic/response combo that you happen to disagree with.
Because such comments tend to be repeats, making them not interesting. They also tend to derail interesting discussion. When there's an article on an interesting detail about X, but the top comment litigates why X should even exist, the interesting part of the article never gets discussed. And when that happens on all threads that involve any aspect of X, it's boring.
If this was truly that simple, don't you think someone would have already done it? Furthermore, is there even an actively maintained, open source, cross platform, development-focused text editor with native UI components?
>If this was truly that simple, don't you think someone would have already done it?
Someone already has done it. An one-man-shop built Sublime Text by himself.
Surely it's not having JS as an extension language as opposed to Python (the only difference between ST and what I propose) that's making it difficult.
>Furthermore, is there even an actively maintained, open source, cross platform, development-focused text editor with native UI components?
There's a "cross platform, development-focused text editor with native UI component" that's working great.
Whether there's an open source editor like that is orthogonal, since what I'm discussing is whether is technically feasible to create such a browser -- and the existence of ST proves that it is (and that's by a single developer: with resources such as that GitHub or even better MS, have, it would be much easier).
The choice of license is just a decision after that.
I don't think anyone is arguing that it's technically impossible to create anything. I was just pointing out that the tradeoffs that Atom accepted aren't simply trivial to solve. Jon has put an amazing amount of work into Sublime Text to get it where it is today; it's not some simple thing to build a great, native text editor. However, it's not like Sublime Text isn't without its own tradeoffs.
How long did it take to build Sublime Text vs. Electron + Atom? Are the original developers in Atom experienced in C++? How easy is it for 3rd party developers to contribute extensions to each? How do the extension catalogs compare, in size?
And yes, there are many Java apps that like to eat memory but I don't believe it's as bad or worse than V8/Electron and I don't believe Java is as inherently memory hungry as V8/Electron.
IntelliJ doesn't use native UI components though. Furthermore, Atom can open a single file in 3s, whereas opening the same file in IntelliJ takes 11s (these numbers are from cold starts). This is with clean installs of both IDEs on a 2016 MacBook Pro.
Using web technology was less about making development easier on us, because in many ways it made it harder. Web technology is about enabling extension authors to use a powerful and familiar technology to achieve their goals.
Could you give some examples of extensions that benefit from Atom being built on Electron instead of just embedding a JavaScript or Python interpreter?
The minimap extension is made easy because they can just throw some HTML in a side pane, the image preview plugin just leverages the image displaying abilities of the browser, custom styling is as easy as throwing some CSS in a file, the extensions which let you preview the web page you are working on right in the browser use the full extent of the browser, the plugin that lets you easily preview markdown just uses a simple markdown->html converter then just displays the HTML/css. Themes are just a set of CSS which targets certain classes. Plugins can move, change, hide, show, do anything.
It also let's plugin authors do things the original developers never imagined possible. 3D object preview using webgl in a custom pane, replacing the whole implementation of tabs with something else, completely redesigning how the sidebar works and looks because it's all just HTML.
And while none of that can ONLY be done in a browser, the fact that a browser is the UI means that it's much easier, much quicker, and much more maintainable.
An embedded scripting language is only part of the story. Think about all of the APIs the browser exposes. For starters there's the DOM... there's no UI toolkit more that's more universally understood. Then there's CSS. Look how many Atom themes there are out there because people can tweak styling with a system they already understand. Then there's the long list of other standardized APIs. WebRTC, fetch, WebGL. Chromium is a very full-featured cross-platform environment that offers us more than embedding a scripting language would. I'm not denying it doesn't come with some negative trade-offs, but I do think those will diminish as Chrome improves and we improve our usage of Chrome... we're also dropping critical components to C++, which Electron makes it easy to do, so over time Atom will evolve into an increasingly "native" application with a cross-platform standards-based interface layer. The overhead of that layer will always be there though.
They could, but they chose not to. Maybe they know something about their organization that you don't. Either way, nothing is stopping anyone from writing a cross platform editor that you describe! If it's really so easy you should team up with all the people who show up to complain about electron in these threads. Until you or someone else makes an editor as good as Atom or VSCode I'll keep going to them as my first choice of text editor.
No they aren't, since when we talk about tradeoffs we are already assuming a specific desired outcome. The tradeoffs are necessary in order for us to achieve it.
But in order to achieve an outcome such as: "an editor that's cross platform and is programmable in JS", using Electron and/or the DOM is not a necessary tradeoff at all.
It's a bit the same issue then something like rails. Easy in the short run, but when you starting doing advance optimization - likw those - you wonder why not rewrite in a more performance oriented language.
Because the whole point of the editor is the web stack.
The fact that it's built on web technologies, and web developers can make plugins easily and quickly and can hack on the core code is the entire reason for it's existence, and why it's so popular.
If you rewrite it in another stack, you basically just created an entirely new editor which isn't compatible in just about every way with atom.
Great comparison. In both cases choosing the language that helps you launch quickly is almost always the right decision. You can always scale later. Better to find out if your app is even going to be a success, first.
I don't really see what the benefit of JavaScript app development is. You don't need to use electron and JavaScript for portability, as far as I'm aware. For example, I know of Qt, and I'm sure there are other toolkits in other similarly mature platforms.
This seems destined to go the way of emacs. This is always what happens when an idealistic perspective wins out over a practical one in a development team.
I hope you're right that this goes the way of emacs. I've been productive in emacs for 30 years, but I'm growing impatient for emacs to get a real programming language with lexical scoping like they were talking about doing with Scheme 20 years ago. Despite its lack of macros, JavaScript is arguably a better Lisp than Emacs Lisp. I've toyed with Atom a couple of times recently and am seriously thinking of switching.
See, I just don't understand why you would want to use emacs over an editor that does all the work for you. Thats why I avoid it, it seems like a big cost that I don't have to pay if I just use a different editor.
How do you think an IDE "does all the work" for you? Somebody working on the editor wrote some code in C++ or Java or whatever that makes it do that, and that code is baked into the IDE.
In emacs, the only missing part is that perhaps nobody has already written the elisp that makes it do whatever task you are asking for.
emacs is a smallish program written mostly in C that defers to a scripting language for nearly everything, and it ships a bunch of code in that scripting language that does all the work of being an editor. You can look at that code using the editor itself, and you can change that code using the editor itself. It's insanely flexible and extensible; see e.g. advice [0], and most modules provide meaningful hooks for you to add your own code.
All the IDE/editor behavior is just code. If it's compiled and baked into your IDE, fixed, unchanging, then if there is any behavior you don't like, you better hope the dev included a knob that lets you tweak it, or you have a lot higher barrier to making your editor work the way you want it to.
Whether an editor needs to be programmable or not depends on what "all the work" is. If you're doing the same exact work as everybody else then certainly a programmable editor is overkill. If your work is different, then programming is how you tell the editor what it means to do all the work for you.
People seem to ridiculously inflate this cost. If you are going to be using a tool for 40 hours a week 50 weeks a year for the next decade then you will be using it for 20,000 hours over the next decade.
Spending a few hours to configure it to your liking. In fact if you start atom and wait 6 seconds for it to start just once a day then twice wait 3 seconds for a new window you will in the same time frame have waited 8 hours for atom to start.
Heres the thing, its a cost you pay for every single project you start and every change you make to your build system. Emacs makes it possible but hard to maneuver, by my reckoning.
There are some really giant projects where that becomes reasonable, but for me thats just not the case. And if I were going to invest time like that, I'd rather invest it into an environment which has a higher ceiling for what it can do (emacs doesnt provide fast/rich/easy autocomplete, for example)
Hilarious. Emacs is one of the most successful programs of all time in my book. If I ever made an editor I'd pray every night that it'd be at least half as successful as Emacs.
I dont seem to have much experience? Based on what? For having a different view than you? Isnt that a little naive?
So as far as actually talking about my point goes, what exactly am I missing? There are small differences but I've never seen a language that I couldn't get up and going in over the course of a week.
How much experience do you think I have? I've used plenty of languages, and I'm well aware that there are nuances.
Not useful to serious programmers? Do you feel the same way about Vim? Just because you haven't gotten used to using something, doesn't mean it's necessarily total shit. There is a reason why people have been using emacs for decades.
I do actually, and I should reword that to "not useful for serious programming." VIM to me is best used for lightweight, quick and short editing tasks. THats how I use it. For any involved work, you're going to want a debugger, you're going to want automated build tools, you're going to want effortless compile/run cycles and so on..
You don't really want to implement all of that in VIM because your work won't be portable.
Do you really conflate suitable to your own tastes with being useful or not? Further in what profession is any tool "all the same" See the blub paradox.