Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VS Code Roadmap 2018

github.com

Post reply on HN
Print view View original

121–130 of 236 posts

Re: VS Code Roadmap 2018

#121

Post by pc86 »

davedx wrote: post #31
veidr wrote: post #5

Earlier quoted context omitted.

I upvoted you to try to offset the misguided downvotes. That is indeed the worst thing about VS Code. I have my computer configured so that most file types open in Sublime Text for that reason. For projects with a lot of TypeScript I'll open a project folder in VSCode, and then just leave it open indefinitely. Because that part is annoyingly slow, as you say. I find it less annoying than Slack, though — seems to me t…

Why do people use desktop Slack? I always run it my browser, I just don't see the value proposition of a native application?

> native application

Since when is Electron running a web view a native application?

Re: VS Code Roadmap 2018

#122

Post by barrkel »

throwaway613834 wrote: post #56
barrkel wrote: post #50

Earlier quoted context omitted.

Commit size isn't the most important number either. You can commit large chunks of memory and if you don't touch it, Windows won't allocate it; not in physical memory nor in page file. Here's another article with more recent details: http://blogs.microsoft.co.il/sasha/2016/01/05/windows-proces...

> Commit size isn't the most important number either. You can commit large chunks of memory and if you don't touch it, Windows won't allocate it; not in physical memory nor in page file. No. Short response: Try committing 1 TiB of memory without touching it and tell me how successful you are. Long response: Unlike Linux, Windows doesn't overcommit. It is completely irrelevant whether physical pages have been actually…

> It is completely irrelevant whether physical pages have been actually allocated to back the the virtual pages that are committed

It is in fact the only relevant thing with memory; physical memory is the constrained resource. If you're constrained on swap space, you're going to spend the rest of the year swapping.

Overcommitting is neither here nor there; a failure to have a backing store for memory (whether in physical memory or page file) will result in OOM, but nobody is actually worried about OOM. Editors and systems lose responsiveness long before then. The failure mode from apps using too much memory is swapping, not OOM.

Part of the reason measuring memory usage from a process stats perspective is so hard is because some memory is more important than others; in particular, access patterns matter. If a process is starting to swap, whether you see a cliff edge in performance, or a more gradual decline, comes down to the access pattern. The working set concept approximates the "frequently used" quantity of memory, which is why Task Manager uses it by default, but it's subtle since it's not a simple function of allocation.

Re: VS Code Roadmap 2018

#123

Post by dbmikus »

dotancohen wrote: post #85
manyxcxi wrote: post #76

Earlier quoted context omitted.

> I’m not monogamous with my code editors I’ve always wondered why some people seem so married to a single editor. Based on the file type or context I might bounce between a number of them. I used to use Sublime Text a lot, but that’s been completely replaced for me by VSCode. I use IntelliJ IDEA predominantly for Java, Groovy, Python, Kotlin, PHP. I’m not a fan of its type hinting for JS or suggestions for HTML/SASS…

> I’ve always wondered why some people seem so married to a single editor. Familiarity, such as keyboard shortcuts. Especially for VI(M) or Emacs users, using anything else is an absolute nightmare. If you haven't been spoiled by VIM, then there really isn't much difference between "all those other editors". :wq

I use Emacs, VIM, VS Code, and Eclipse, but they all need to have a VIM mode enabled or I'm outta there! VS Code can actually use an embedded neovim instance in its VIM mode for EX commands, which is pretty neat.

Re: VS Code Roadmap 2018

#124

Post by OldSchoolJohnny »

neogodless wrote: post #105
dmitriid wrote: post #99

Earlier quoted context omitted.

For some reason people still consider startup time a metric worth paying attention to

Engineers like to optimize everything, including how they use their time. If you've got something in your head that you want to fix or write, you want to spend time doing just that, not staring at your screen waiting and maybe losing some of your mental model.

If you think a second or two matters when loading an editor you need to cut back on the coffee.

Re: VS Code Roadmap 2018

#125

Post by metamet »

Sir_Cmpwn wrote: post #112
Fuzzy_Logic wrote: post #93

Earlier quoted context omitted.

VSCode and the dotnet cli tooling fill this role on Linux. The tools are consistent across all three platforms.

I've had no end of trouble using .NET on Linux in the past couple of years. Most of my existing projects are broken, too.

Were you using Mono or .NET Core/Standard?

Re: VS Code Roadmap 2018

#126

Post by merlish »

manyxcxi wrote: post #76
veidr wrote: post #2

VS Code is such an excellent open-source project, and also such a great tool despite the obvious and much-bemoaned inherent disadvantages (aka "tradeoffs") that come with being an Electron-based app that it, along with its cousin TypeScript, fundamentally changed my perception of Microsoft. I'm not monogamous with my code editors and typically have a few of them open. These days, I notice VSCode is very likely to be…

> I’m not monogamous with my code editors I’ve always wondered why some people seem so married to a single editor. Based on the file type or context I might bounce between a number of them. I used to use Sublime Text a lot, but that’s been completely replaced for me by VSCode. I use IntelliJ IDEA predominantly for Java, Groovy, Python, Kotlin, PHP. I’m not a fan of its type hinting for JS or suggestions for HTML/SASS…

Re. a single editor: The constant, never-ending search for The Perfect Editor :)

Re: VS Code Roadmap 2018

#127

Post by jclay »

Is anyone aware of an article detailing how the VS Code team was able to realize so much performance out of Electron? VS Code is one of the most native-feeling, lightweight Electron products I've used (as compared to say, Slack) and I wonder how they got there.

Re: VS Code Roadmap 2018

#128

Post by Sir_Cmpwn »

metamet wrote: post #125
Sir_Cmpwn wrote: post #112

Earlier quoted context omitted.

I've had no end of trouble using .NET on Linux in the past couple of years. Most of my existing projects are broken, too.

Were you using Mono or .NET Core/Standard?

Both at different times. My Mono projects started breaking and getting .NET Core/Standard running on anything but their blessed distros is difficult.

Re: VS Code Roadmap 2018

#129

Post by merlish »

spinningarrow wrote: post #7
ssijak wrote: post #3

As much as I wanted to like and use VS Code, Electron base still ruined it for me. If it was some other app where I do not expect instant snappiness and lower memory usage, for example, Slack (also Electron app), I would swallow it, but for an editor, I can`t.

I don’t think Electron is entirely to blame e.g. I tried the Discord app and it was amazingly snappy (just install both Slack and Discord and you can feel the difference).

I actually really want to know how Discord does it. Do they actually use the DOM, or just draw everything themselves?

Honestly, anyone who hasn't used Discord, I'd recommend installing it just to try it, especially if you're a SPA web developer or you work with Electron. The performance beats native apps, even dealing with very long sections of text that need to be swapped in and out as you scroll.

However they're doing it is probably the way we should be building Electron applications industry-wide.

Re: VS Code Roadmap 2018

#130

Post by reificator »

baldfat wrote: post #65
carlsborg wrote: post #30

This is a great python IDE for Linux.

I wouldn't say its an IDE it just a really powerful editor and the RUN plugin is awesome.

You've got an editor, a task runner to handle builds, a debugger, code completion, what else do you need to call it an IDE?
Post reply on HN