Jump to content

VS Code or Xcode?

Go to solution Solved by Sauron,

VSCode is going to perform about the same on macOS as it does on Windows, XCode is a native app so in theory it should be faster but it's possible the feature difference will negate that advantage. You shouldn't be able to tell the difference in everyday use anyway.

3 minutes ago, Dat Guy said:

For computers: yep.

For humans: nope.

 

If you speak colons, brackets and quotation marks fluently, you might be a bot ... :D

We might want to agree that this is a matter of personal taste here.

It's definitely a matter of familiarity more than taste

3 minutes ago, Dat Guy said:

You keep mixing up the application's performance (which is what I talk about) with the user's performance. Please don't do that.

I'm not. OP asked about performance, in a general sense. If you're talking about application performance, sure, noone can argue that LISP is not more performant than JS, but the time to adopt is very different performance metric that VSCode is better at than LISP; see my above points if you want to disagree.

3 minutes ago, Dat Guy said:

And because you disagree, this cannot be true?

(I mean: Ugh, Vim... but here we are, talking about taste again.)

Mate, I'm not saying that Emacs isn't great, but there is a learning curve to it. When compared to VSCode, which has a nearly nonexistent learning code (and when OP has stated that they've used it before, this learning curve is pretty damn flat)

3 minutes ago, Dat Guy said:

Browsers are arguably the number one backdoor for malware. Lisp runtimes are not.

That's because Browsers are used, and LISP runtimes are used for programs < 1% of computer users use ( not a real statistic here, because I know you LIPSers are very literal ), so there's clear bias against one being less "secure" than another

3 minutes ago, Dat Guy said:

All Electron-based apps are affected by all of Chrome's security problems with the additional issue that most Electron apps don't silently update themselves in the background, keeping the holes open for a longer time than you'd like them to. Anyway, JavaScript runtimes allow very different problems than Lisp runtimes, notably some like this.

Yes, a dynamic rendering engine is susceptible to those sorts of issues. SQL was also susceptible to SQLi issues, but no sane person said not to use SQL because it could have security issues. And this is not a JS specific issue, there's nothing special about LISP that would prevent it from being vulnerable to this sort of issue, if it was implemented in LISP

3 minutes ago, Dat Guy said:

It depends on the implementation. Now I haven't dug into the Electron implementation, so I cannot determine which one is the case here.

So a "text editor" that allocates half a gigabyte of RAM while being idle is not "bloatware" for you?

This is an OS issue, not an application issue.

RAM usage is a pretty irrelevant metric most of the time, especially when something does as much as VSCode can do

3 minutes ago, Dat Guy said:

Let me answer with a question: What is the difference between Visual Studio and Visual Studio Code?

(Hint: VS Code can use an IDE's toolset, like linkers, debuggers and compilers - but it relies on actual IDEs to provide them.)

How does it rely on an actual "IDE" to do this ? I can run my VSCode Java plugins without having Eclipse running, so you're clearly misinformed on this topic

3 minutes ago, Dat Guy said:

Emacs does not need external applications to provide more functionality in less resource hogging.

If you can get Emacs to the same level of convenience, ability to adjust to new languages/workflows as quickly as VSCode does, then sure, VSCode's "resource hogging" is unnecessary. But most people won't get used to Emacs as conveniently, so the resource utilization is pretty justifiable for the convenience 

Link to comment
Share on other sites

Link to post
Share on other sites

4 minutes ago, fake_brogrammer said:

It's definitely a matter of familiarity more than taste

Not sure about that. I'm quite familiar with JSON and I still don't want to write my configuration files in it... :)

 

5 minutes ago, fake_brogrammer said:

When compared to VSCode, which has a nearly nonexistent learning code (and when OP has stated that they've used it before, this learning curve is pretty damn flat)

I agree that, as long as you're happy with the OOTB experience, VSCode might be less unusual if you're a CUA user anyway. The relevant question might be how far it will scale.

 

7 minutes ago, fake_brogrammer said:

there's clear bias against one being less "secure" than another

How should a non-interactive non-web-facing software like GNU Emacs be able to even remotely catch the same malware as VSCode (which is, as we agree, basically an artificially castrated V8 browser) when an attacker leads you to a malicious website and you open it inside your "text editor"? The web is not a friendly place, and GNU Emacs generously keeps most of its annoyances out of its core whole VS Code relies on them.

 

GNU Emacs's own web browsers are not much more than lynx (or w3m) with a nicer user interface. Don't tell me that they are just as risky for malware attacks as a 2020 JavaScript runtime.

 

13 minutes ago, fake_brogrammer said:

RAM usage is a pretty irrelevant metric most of the time, especially when something does as much as VSCode can do

Sure, if you have several terabytes of RAM anyway...

The relevant word is "can" here. Right after the start when VS Code does not even have any file in its cache/buffer/whatever, it still hogs half a gigabyte of RAM for doing nothing. That's half a gigabyte more than a text editor would technically require. GNU Emacs can do a lot too - but it won't blow up my RAM without any action on my part.

 

15 minutes ago, fake_brogrammer said:

I can run my VSCode Java plugins without having Eclipse running, so you're clearly misinformed on this topic

So being able to run external development tools automatically turns a text editor into an IDE? So vi, ex, ed and sam are actually IDEs as well, and there have been almost no text editors which aren't IDEs in the history of computing (for example, ed dates from the mid-60s)?

 

Are you sure that I am the one who is misinformed? ;) 

 

In my opinion [citation needed], VS Code is not an IDE because it can access development tools, but it does not come with any development tools. Visual Studio is an IDE because you don't need anything except Visual Studio for everything you need.

 

19 minutes ago, fake_brogrammer said:

most people won't get used to Emacs as conveniently

I would assume that most people who use GNU Emacs for a certain time span will inadvertently fiddle with their config ... :D  

Write in C.

Link to comment
Share on other sites

Link to post
Share on other sites

Once again, please keep in mind what I'm saying is in regard to OP's original query; is XCode better than VSCode for web development.

11 minutes ago, Dat Guy said:

Not sure about that. I'm quite familiar with JSON and I still don't want to write my configuration files in it... :)

Sure, but when you're working with JSON constantly, it's easier to configure in it

11 minutes ago, Dat Guy said:

I agree that, as long as you're happy with the OOTB experience, VSCode might be less unusual if you're a CUA user anyway. The relevant question might be how far it will scale.

Which is my point, VSCode is better for instant adoptability. 

11 minutes ago, Dat Guy said:

How should a non-interactive non-web-facing software like GNU Emacs be able to even remotely catch the same malware as VSCode (which is, as we agree, basically an artificially castrated V8 browser) when an attacker leads you to a malicious website and you open it inside your "text editor"? The web is not a friendly place, and GNU Emacs generously keeps most of its annoyances out of its core whole VS Code relies on them.

Buffer overflows, Stack overflows, LFI and RCE issues are language and program agnostic (mostly. a program that doesn't access the FS isn't vulnerable to LFI in conventional means). Please don't act as though VSCode is just a browser, that just shows an ignorance to the technical achievements MSFT made when developing VSCode, given the Electron base

11 minutes ago, Dat Guy said:

GNU Emacs's own web browsers are not much more than lynx (or w3m) with a nicer user interface. Don't tell me that they are just as risky for malware attacks as a 2020 JavaScript runtime.

Sure, being a HTML and CSS rendering engine is definitely comparable to an actual web browser, with an embedded language runtime.

11 minutes ago, Dat Guy said:

Sure, if you have several terabytes of RAM anyway...

The relevant word is "can" here. Right after the start when VS Code does not even have any file in its cache/buffer/whatever, it still hogs half a gigabyte of RAM for doing nothing. That's half a gigabyte more than a text editor would technically require. GNU Emacs can do a lot too - but it won't blow up my RAM without any action on my part.

You're seriously misinformed here. VSCode does not take up half a gig of memory once started (especially on a default install), and even if it did, you've not shown a reason why this would be an issue, other than the one I started before - a hardware limit. Modern software should not be restricted to the memory constraints you find favourable .

11 minutes ago, Dat Guy said:

So being able to run external development tools automatically turns a text editor into an IDE? So vi, ex, ed and sam are actually IDEs as well, and there have been almost no text editors which aren't IDEs in the history of computing (for example, ed dates from the mid-60s)?

No, clearly there's a difference between running an external program and being an IDE. An IDE has embedded tooling, that's what make's it an IDE. 

11 minutes ago, Dat Guy said:

In my opinion [citation needed], VS Code is not an IDE because it can access development tools, but it does not come with any development tools. Visual Studio is an IDE because you don't need anything except Visual Studio for everything you need.

Why do you bring this up ? It doesn't have any standing on the original question. 

11 minutes ago, Dat Guy said:

I would assume that most people who use GNU Emacs for a certain time span will inadvertently fiddle with their config ... :D  

Great, but most people can use VSCode without ever touching the config. Understand that is both a point towards and against each editor

Link to comment
Share on other sites

Link to post
Share on other sites

Ah, this forum sometimes refuses to inform me of replies...

 

To keep this short: I admit that I have diverged from the OP's question quite a bit. :) 

Two remarks though:

 

On 5/22/2020 at 8:46 PM, fake_brogrammer said:

You're seriously misinformed here. VSCode does not take up half a gig of memory once started (especially on a default install)

This is VS Code (freshly installed because I don't use it - just for checking your claims) with only one of my code files open:

 

291482696_Bildschirmfoto2020-05-24um10_44_29.thumb.png.b4f70f98f2a56431dd2f641d287cacc4.png

 

I think we can agree that this can be seen as "half a gig of memory".

 

This is GNU Emacs (heavily configured with a lot of plug-ins) with the same of my code files open:

 

1507062646_Bildschirmfoto2020-05-24um10_48_55.thumb.png.653d4725576f803f30c00a4ed5374716.png

 

The Activity Monitor must be seriously misinformed here. 🤔

 

(Comparing that to Xcode - which I didn't try - would be misleading as Apple can probably trick-optimize their own software rather well.)

 

On 5/22/2020 at 8:46 PM, fake_brogrammer said:

Modern software should not be restricted to the memory constraints you find favourable .

Modern software should not eat large chunks of my memory. Chances are that I prefer running more than just a web browser and an IDE at the same time. Good luck running Android Studio and (e.g.) Firefox on a 2010 computer in 2020 and still trying to do anything else while the former is compiling. (Let me guess: You buy a new computer every three years anyway? I wish everyone had your money!)

 

On 5/22/2020 at 8:46 PM, fake_brogrammer said:

An IDE has embedded tooling, that's what make's it an IDE. 

And VS Code does not embed "tooling". It relies on external applications for that.

Write in C.

Link to comment
Share on other sites

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×