5 ms·
Personally I think that trotting out this argument in every single post about VSCode/Atom/Electron/etc. serves absolutely no good purpose at this point (other t
by mercer 10y ago
Personally I think that trotting out this argument in every single post about VSCode/Atom/Electron/etc. serves absolutely no good purpose at this point (other than upvotes or the pleasure of expressing an opinion, perhaps), but I'm happy to be corrected.
That said, I'm also still using Sublime Text / vim primarily because they do feel faster on startup and handle big files well.
But I think rationally it would make sense for me to move to VSCode, because 1) my code editor is almost always open, and 2) I rarely need to edit really large files, and 3) VSCode is plenty fast for pretty much all other use cases and offers a whole bunch of advantages over ST.
Atom I'm less sure of. It seems to get faster every few months that I give it a spin, but it still feels 'laggier' even in normal use, which is definitely a problem for me.
- nottorp 10y agoWell, the main question is still "why oh why?". It's not like Microsoft can't afford to pay developers to do something native. Also, calling it Visual Studio is very deceptive. Most devs know VS to mean something completely different.
- mercer 10y ago> Well, the main question is still "why oh why?". It's not like Microsoft can't afford to pay developers to do something native. Yeah I do share that question with you and would love an answer from the team! > Also, calling it Visual Studio is very deceptive. Most devs know VS to mean something completely different. Could you clarify what you mean with that? Accusing me of being 'deceptive' seems a bit unwarranted and disproportionately antagonistic, considering that as far as I can tell I've made a clear distinction between VSCode and VS (meaning Visual Studio proper), and considering that I can't think of any reason why I would choose to deceive in this matter. Where did I go wrong?
- TeMPOraL 10y agoI think the parent didn't mean to accuse you, but Microsoft, for re-using the "Visual Studio" brand in a product so completely different that it deserves a distinct name. Reminds me of how pissed I was with Amazon calling their line of regular Android tablets "Kindle Fire". I don't know what the sales teams there think, but for customers, the "Kindle" brand was literally synonymous with "that e-ink screen thing".
- tracker1 10y agoThe editor "Monaco" was already written... it was for VS Online. They took the already written editor, Electron (Atom Core, etc) from the Atom project (another editor) and grafted the two together. Atom's editor at the time was horribly slow... Electron + Monaco actually worked well. They've spent the time since then working on actual features... while they'd probably have just barely released anything if they had to do it all in C++, and wouldn't have nearly the depth of extensions they do.
- simooooo 10y agoProbably to not have to write a cross platform UI library and encourage contributions by using a wildly popular language
- taude 10y agoAs a VSCOde user on both Mac and Windows, I'm not sure they needed to do anything native. Seems like wasted work, when what they've ended up with is plenty fast and looks good in both environments. I'm not using VSCode to edit one-off files from my terminal. The use case is for your folder-based projects. I generally open it once/week or reboot, etc, and finds it loads, mounts my folder and I'm done in the amount of time it takes me to grab a sip of coffee. I think too many people base speed because they're used to one-off editing files directly from their filesytem. At this point in time, I only do this when editing config on remote servers and such. EDIT: I just went and opened VSCode from my terminal and it took about 3.5 seconds to load up an entire React Native project on a three year old 11" MacBook Air.
- jeremy_wiebe 10y agoThey have done something native...for many, many years. It's called Visual Studio. VSCode has found a place in my workflow now and I don't care what language or platform they've used. It's proven to be more full-featured than competing editors and they are improving it much faster than other editors (based on my completely non-scientific, possibly biased observations).
- tracker1 10y agoYeah, "Visual Studio" is a big, slow, bloated mess, that when working on a typical project, especially web projects will just freeze out regularly and plugins will stop the world, doing who knows what. VS Code actually loads faster, doesn't freeze as much, and in general runs faster than any IDE I've ever used. And I've used a few. There are faster code editors, but VS Code is a bit more than most of them, but less than a full IDE typically is.
- criddell 10y agoPeople invest quite a bit of time into their tools. When something new comes along and gains traction, it threatens that investment. Maybe VSCode gets so popular that $EDITOR stops getting updated? Otherwise, there really isn't any reason why I should care what tools you use.
- blub 10y agoIt serves a very important point: showing that mediocrity will not be silently tolerated. I understand that productivity is important and a significant number of web developers can't seem to learn anything else except JavaScript or worse, don't want to, but such things as professional pride, craftsmanship and excellence do exist and are very appreciated. Those things represent the opposite of building software applications in JavaScript. I don't know why others criticize such apps, but that's why I do it: they are normalizing flawed software and a lousy experience and mixing it with extreme arrogance. I've had this deep disagreement with various people ever since web apps were invented. The best of the best of these apps sucked then and they still suck now and are a waste of everybody's time.
- pcwalton 10y agoCome on. There are lots of JS developers who care a lot about "professional pride, craftsmanship and excellence".
- blub 10y agoBuilding desktop (or mobile) apps in JS is not compatible with craftsmanship, nor is it compatible with excellence. To those that truly care about excellence and don't merely pay lip service to it, there is only one way of building: using that platform's native toolkit. For project or ideological reasons one can make a compromise and use something like Qt, Xamarin or wxWidgets, etc. This leaves JS native-like apps for those that care about doing things fast by only using the knowledge they already have. That would perhaps be understandable, if they admitted that it's a big quality and performance compromise. Yes, we tried our best, but this is the only thing we could do with this budget/team/whatever. Totally fine. Instead we get uppity devs claiming that desktop apps will be killed and bragging about how they're delivering the best experiences. It's this toxic cocktail of arrogance and lack of ability that is intolerable.
- pcwalton 10y ago> To those that truly care about excellence and don't merely pay lip service to it, there is only one way of building: using that platform's native toolkit. Since you are clearly an expert here, can you explain to me how an immediate-mode API from the 1980s in which all painting is done via the painter's algorithm and context switches to kernel mode on every operation is superior to a declarative model that allows for global optimizations to minimize state changes and batch draw, in addition to using hardware Z-buffers to minimize overdraw?
- city41 10y agoHow large of a file are you talking? I just opened a 9.75mb JavaScript file in VS Code and it edits it quite well. It syntax highlights the top of the file immediately, and it does take quite a while for the highlighting to work its way down the file (I'd say about 20 seconds). But as far as editing goes, you can jump anywhere in the file and edit without any hesitation, instantly.