Hacker News Reader

> I'm sure there's a VSC plugin for that

This part of your comments nails 100% why, for me (web developer, 90% in typescript these days), it's nearly impossible to justify paying for an IDE.

Visual Studio code has almost everything that I need, and what it's not baked in, is easily done with a plug-in, which in the worst case I can write myself. But that's really a worst case scenario, since to this date it has never materialized as all my needs are covered by existing, and excellent, plugins.

I almost agree; but in my experience, JetBrains IDEs are worth every cent. I am more productive on them than in Visual Studio Code, even for "simple" tasks, like raw HTML/CSS/JS editing.

Weird, I can't stand them. Mine falls over on a moderately sized project and it feels like it's always melting while re-indexing-- which also totally blocks inspection operations.

In my experience, indexing takes longer, but after that the autocomplete is actually instant, as opposed to VS code’s ‘lets wait 10 seconds to show you the hint you might want to automatically import this’.

I’m flipping between Jetbrains and VS code a bit, but Jetbrains is by far the superior experience.

The proactive indexing sure does require a decent CPU and a good bunch of RAM, but most developers have both these days. I've noticed on Windows that anti-virus is a major bottleneck for Jetbrains editors, even with a decent CPU and plenty of RAM.

In my experience, the lazy autocomplete takes less resources at start but the result is that autocomplete suggestions are loaded in as files are being parsed. The larger projects grow, the slower this process is.

I suppose slower CPUs like the i3 series and low i5 series Intel chips will probably have a lot of trouble with the indexing. You need a laptop with a decent sustained core speed to do the work (which can be a major deal breaker in cheap Windows laptops and the lower tier Macbooks), but the few seconds wait you get on a professional machine when a project gets loaded in is well worth the wait to me.

That sounds like a hardware issue.

If you're going to roll Jetbrains then the more RAM the better and a good CPU also helps.

Obviously, this means MacBooks that aren't fully kitted out are bad picks.

JetBrain products (in my experience) are a ram eater, much more than any other IDE I've ever used, but in that similar vain no other IDE is as powerful as IntelliJ is for me.

I default to WebStorm and sometimes CLion and Idea. I recently tried Rider as a Visual Studio Community replacement, and holy smokes, it's really fast compared to VS+R#, looks really good, and has all the other JetBrains stuff.

R# left a bad taste in my mouth. It quintupled start-up time for my solution (which has dozens of projects, to be fair), and destabilized VS. VS and R# ways of doing things would often conflict, and IntelliSense would frequently break. Input latency was abysmal.

VS has now mostly caught up with their feature set, and the only thing I miss is namespace refactoring (which I could implement myself with Roslyn.)

Is R# just an exception, perf-wise, to their track record?

I guess it's how they have to implement it on VS. I tell you, CLion with Resharper++ or Rider with R# compared to VS is like night and day. Visual Studio takes 1 min woth R# to start and analyze a Unity project and the UI lags. Rider OTOH does it very fast and there's no noticeable lag with background tasks.

I tried WebStorm and made myself use it for 2 months. I went back to VSCode. WebStorm had its positives. I realized how much I hate setting up debugging environments in VSCode and how well they work in WebStorm, especially Node. I really liked the refactoring. But in the end, I preferred VSCode. I had performance issues (the team was fixing them and fixed some), scroll wasn't as nice, it ran worse on large files, the extensions weren't as nice in my opinion. Maybe I'll try it again in a few years.

I totally agree. It took me a while to changeover but after my entire development team did, I took notice. It's for sure better.

100% agree. Honestly at this point, I find disagreement that it's objectively better for professional development a great developer maturity index.

Shitting on tools because you read a couple disgruntled comments about indexing without honestly evaluating the tool yourself says a lot.

> it's nearly impossible to justify paying for an IDE.

The reason I pay for IntelliJ IDEA is exactly the fact that I don't have to install any plugins, or fiddle with config settings, or really do much of anything; the product works extremely well out of the box with all of the IDE features I would ever want (and then some). The last time I seriously tried VS Code[0], I felt like I was constantly trying different plugins and changing various settings in order to get it working the way I want, and many of them weren't quite as polished as what I get immediately with IntelliJ.

[0]: Admittedly, this was over a year ago, so it's possible things have improved. But I'd rather pay $89/year than spend the time to find out.

I’m a heavy pycharm user and have found there are plugins that handle gaps in the IDE.

Some of them are for minor customization like hot keys to move tabs. But the product doesn’t support Environment Variable configuration very well.

For example, Pycharm can’t injest a .env file. The devs point at a plug-in, but that doesn’t cover runtime and terminal / python shell.

I used Emacs for 10 years. When I started writing JS almost exclusively at my current job, I switched finally to VSCode (albeit with emacs keybindings).

The plugin/extension experience between emacs and vscode is, of course, almost an apples to oranges comparison. But VSCode is much better in that regard in my opinion.

I want yak-free IDE. After ten years my Emacs config is a herd of beautifully shaved yaks. VSCode is yak-free, for me, right now.

The problem I've had with VSCode - and also Sublime, as it happens - is that on a moderately large JS project it's something of a CPU hog. Both editors seem to do a lot of indexing, and this is even with loads of ignore folders configured.

The irony is that this has driven me to try emacs. I am being driven nearly to distraction by the fact that every single operation seems to almost glory in using a different key combination than any other editor I've ever used. Even TAB can't be used for indentation because emacs is "opinionated" (or, as I prefer to call it, "a twat") about it in most modes, but you can get what you want with M-i.

The thing it absolutely seems to nail is performance. I'm getting zero CPU thrashing on the same project, and auto-complete-mode, whilst not quite as good as VSCode's autocomplete, is much better than Sublime's. For one thing it seems to work well across files, even when using ES5 with no typing hints.

The payoff in a cooler laptop and longer battery life is worth the sometimes seething frustration in the meantime.

(Of course, at the moment I'm squandering most of that extra battery life looking up keyboard shortcuts, but that will pass.)

> The thing it absolutely seems to nail is performance. I'm getting zero CPU thrashing on the same project, and auto-complete-mode, whilst not quite as good as VSCode's autocomplete, is much better than Sublime's. For one thing it seems to work well across files, even when using ES5 with no typing hints.

Speaking of ironic, yeah. Emacs used to be the massive resource hog, compared to it's competition (BSD vi?) back in the day -- the joke was that EMACS stood for "eight megs and constantly swapping", back when 8MB of RAM was a lot. It's just that, after that, they failed to keep up with Wirth's law.

Ha! I remember that. The joke had started to come unstuck a bit by the time I first used emacs in 1999/2000 (my own machine had 128MB, quickly upgraded to 256MB of RAM), and we weren't making much use of the multi-user aspects of UNIX, but it still had some currency amongst older hands in the department (and in my first job or two).

Do you use it with lsp-mode or similar?

One would imagine that most CPU load because of rescanning would happen in the language server, and those should be the same between VS Code and Emacs.

Yeah I tried to use Emacs, but the LSP had way worse performance than in VSCode and was very glitchy. I was disappointed because I really enjoyed Emacs in other ways, but I couldn't get that to work reliably. Maybe I was doing something weird.

When was that?

Emacs 27 (released recently) with native JSON support was reportedly a huge improvement.

The `native-comp` branch on master is receiving great feedback too.

I was a big Jetbrains person for a while, Emacs with LSP mode has been a bit hit-or-miss but Typescript has been _very good_ in that front.

It really depends on you wanting to use something like Emacs, of course.

What does yak refer to? Is it a reference to gnu?

It refers to yak-shaving, which often manifests as pointless tinkering with meaningless config files.

https://seths.blog/2005/03/dont_shave_that/

I'm guessing https://en.wiktionary.org/wiki/yak_shaving

Someone please port org mode to vscode

There's actually a couple of decent ports already!

In saying that, it's astonishing how much the the smart IDE features are better in Visual Studio/C# compared to VSCode/Typescript.

The text editor in VSCode is better than VS (multi cursor support isnt great in VS). I would love to see VSCode get the smart refactor features from Visual Studio, working with Typescript.

I would hazard a guess that this is more to do with the soundness of C# relative to TypeScript, which had to make many sacrifices to stay compatible with decade old JavaScript conventions.

> I genuinely think it'll be years before they can charge for this with a straight face.

Well, I payed for it a few days ago, and I don’t remember seeing any crooked faces. I very much enjoy it so far. Considering the scope of the project and the high quality of the design in every nook and cranny of the app, I think it’s a bit of a miracle that something like it even exists. Not even Apple makes Mac apps of this caliber anymore.

I agree that the competition they’re up against is fierce, but criticizing a 1.0 for a few hiccups and a small ecosystem seems misguided. They are offering something no one else is.

If it’s just a few hiccups why not leave it in the oven for another month before charging?

To encourage continued development, for one?

If I were them, I think I would try really hard to build a low-effort conversion process for VSCode extensions. If they can do that in such a way that the top XXX VSCode extensions could be used with a good experience in Nova and fix the couple of non-plugin gripes you mention, I think they've probably bested the VSCode experience for enough people to make it profitable.

I am not sure if I am pessimistic enough to call that "years" once they've got that migration path planned. If they're not planning something like it, though, then I think I agree with you.

Microsoft has opened the protocol with which most extensions are written: https://microsoft.github.io/language-server-protocol/

It's a really high quality protocol, and supporting it gets you 95% of the way to supporting dozens of languages (only remaining work is coordinating launching the language server and connecting it to the editor, usually <100 lines of code).

LSP isn’t “most plugins” though. There are tens of thousands of useful plugins, and only a tiny subset of those add support for new languages.

True... But weighted by importance and effort, LSP-powered plugins are likely above-average, probably by a healthy margin.

Highly disagree. Having support for “python” is good, but useless without support for the ecosystem (poetry, pipenv, requirements.txt, virtualenvs, pytest, a REPL, Django-specific stuff, etc).

Languages are important, but I wouldn’t say they are ahead by a large degree.

Nova supports LSP, actually. As orf notes in the other reply to you, that only covers, well, plugins that involve language servers. :)

How does it? I wanted to try it for Python but I don't see how I can just configure it to talk to a language server.

That is somewhat above my pay grade, so to speak, but I imagine that you would need to write a plugin that talks to a language server (I think this is true for Code and other LSP-aware editors, too). You'd probably start by checking "show extension development items in the Extensions menu," then select "Create New Extension..." in that menu and choose "Language Server Extension" in the pane that comes up next. That looks like it creates a skeleton extension for you with the basic details filled in.

I was impressed with the way that oni2 did this, any vscode extension is a valid oni2 extension. I ended up sticking with neovim for the time being but I feel something similar could work for nova’s benefit.

> The default editing experience is lightweight, and that's a good thing. But the plugin story is dire. Plugins like ESLint and Prettier crash constantly, requiring an app restart. Prettier has a format-on-save behaviour that seems to format after save on some file types. Typescript cmd-click definitions are broken, cmd-click import filepaths are broken.

This is all fair. I've been using the beta on and off, and so far it hasn't compelled me to switch from VS Code yet. But this is a 1.0, and Panic has a pretty great stellar track record — I can see them closing the gap pretty quickly.

I hope so and I do root for them. But I remember Coda development felt sluggish compared to the pace we see in VS Code. And this 1.0 is something they feel is good enough to sell for $100, which IMO is wild.

Yeah, I kind of wonder if it might have been savvier for them to do something like "$29 for new users until the end of September and $49 until 1.1 ships." I appreciate that'd be a scary proposition revenue-wise, but I suspect the difference between "surprise hit" and "also ran" is going to depend almost entirely on how quickly they can get their extension ecosystem up to speed.

I like Panic’s products a lot, particularly Transmit, but for something I use day in and day out to write code, munge datasets to solve production incidents, build and run code, etc., I can’t imagine improving upon a terminal with vim and standard Unix utils. I’m not a total console-chauvinist, I use a GUI email client. But every time I’ve tried any IDE or graphical editor like this, no matter how customizable it is, it still falls short in comparison. At best they only begin to approach what I can do with Unix, but require tedious mouse aiming and typically introduce much greater feedback latency.

Have you tired IDEA (or siblings)? They focus on keyboard shortcuts and offer much more than vi can offer (full, integrated static analysis across with numerous languages and numerous context-sensitive tools like SSH, SCP, DB connectivity, etc).

I use IDEA and feel absolutely crippled and useless in vi. It's largely because I never use vi and don't care to learn it. I'm very impressed with the IDEA tooling. There's a vi plugin for it if you want to get a head start.

IDEA has the lead on raw features (and integration, since all the core plugins are made in-house), but at least on macOS the editor performs like trash. There are hundreds of milliseconds' latency for nearly every interaction, and that's despite spinning up the fans and impacting the rest of the system. I'm not a latency-buff; I happily used Atom until VSCode came along. But IDEA is unbearable in my experience (again, I've only used it on macOS so YMMV).

There are known issues with scaled resolutions on macOS and JetBrains IDEs. If that is the case for you, using a tool like resolutionator to scale instead of the native macOS scaler, should solve the performance issues.

I wonder what makes the scaling in macOS difficult. For years Firefox would eat through my battery in no time if scaling was enabled.

It’s due to the Retina displays. The scaled resolutions don’t map in a clean way to pixels. The renderer renders everything at the native resolution of the panel and then has to downscale it to the scaled resolutions. For the “native” Retina view, it’s just /2, so it’s easy and pixel perfect. The others are more like /1.523134... and there’s more work to figure out what color each pixel should be.

I do use phpStorm for its interactive debugger during the rare instances that I need to. In any other language I would set a breakpoint and navigate the code from whatever terminal was running the code, but PHP is so awful that I can’t do that.

As far as IDEs go, I’ll give it 4 stars, but it still pales in comparison to writing VIM macros on the fly, jump-to movement keys, setting and jumping back to markers, being able to select lines in visual mode, pipe them out to any process I want and pipe the results back into my buffer, etc.

Running build tasks via clumsily configured toolbar buttons is absolutely horrid in comparison to make or any other CLI-driven build system that I’ve used (except maybe all the JS ones).

I think that depends what language you're using. IDEA is a must for Java, but vim with ccls works great for me on C/C++ projects and clion doesn't seem to do more there.

That's why I'm surprised they bother with the bathrooom sink. Everyone will use the code editor. Not everyone will use terminal/git. Make the editor first.

Have you tried VS Code in Remote Development mode?

I’ve only just read about it thanks to your comment, but I’m wondering what advantage it has over just mounting a file system to share between your VM And host OS and just running commands via SSH.

I think the plugins run on the VM, and then e.g. a remote C++ plugin is actually aware of the linux environment on the host and can pick up the correct includes/symbols there.

Whereas if you have things locally the tooling assumes that you are developing for the local machine. There are obviously some ways to fix that - e.g. by pointing to a remote sysroot and overriding flags - but it's not a very straightforward process.

That's a shame. I love the vibe of this project and the VSCode monoculture gives me a vague sense of unease, but sadly it's really hard to compete with a tech giant that's putting all their effort into a free product.

> I like the default rainbow indentation, though I'm sure there's a VSC plugin for that.

I've enjoyed it for years now! https://marketplace.visualstudio.com/items?itemName=oderwat....

For me the lack of auto-complete that _I_ prompt (ctrl+space / otherwise known as intellisense) is a deal breaker, and TypeScript story is completely broken. Cmd+Click (goto definition) doesn't work across files (though I do like they've implemented 3D touch as an alternative to Cmd+Click).

Update: looks like if you context click on a path > Typescript > Goto definition works; Weird that it is not unified with the editor's concept of goto def though.

Agree with parent that it's a valiant effort, just way too immature w/ no compelling features over VSCode at this point.

Edit: Native editor is compelling for battery, but not at the expense of developer experience - and even then, it's been quite a while since VSCode has felt slow to me.

I also had the beta for a few months and work exclusively on TS development for work.

Nova is a great editor but the hard thing is taking a step back and realizing that Microsoft has clearly designed VS Code to be the Typescript Dev tool in the same way that XCode is the Swift/SwiftUI development tool.

The leaps and bounds in features JUST for TS is incredibly hard to replicate mostly because it’s almost Microsoft’s exclusive goal with VSCode development.

I imagine if one doesn’t work in TS that Nova is far more competitive, it is not a bad IDE at all when judged on what IDEs prior to VSCode meant.