I tried this out some months ago and had really mixed feelings, but I will give it another shot because generally speaking, Panic is awesome!
My main complaints at the time were a confusing extensions ecosystem; difficulty rolling your own; and the sense that (as with Coda) "programmer" means a person hand-coding web sites with HTML+CSS and maybe Javascript or PHP. Seemed like they weren't trying to convince anybody who already used VSCode et al.
That said, I have had some difficulty adjusting to Sublime's way of doing things, and VS never felt right to me, so maybe I'm just picky.
In any case I am happy to see another opinionated text editor in the mix!
[Edit: And right out of the box now, no support for Go files, not even syntax coloring, and it thinks go.mod is a media file and won't display its text. Searching extensions for "go" gets me three different extensions and no way to tell which is better/more-popular; and also shows me six totally unrelated extensions, three of which have "go" in their titles e.g. "django" and three of which do not. So... still not really shooting for the programmer market, but I will keep trying!]
[Edit2: Similar results for Rust. And extensions have to be written in Javascript, and the boilerplate is all for published extensions which maybe makes sense, but I really want an easy way to pipe ($BUFFER|$CLIPBOARD) to an arbitrary program and put the result in ($BUFFER|CLIPBOARD) with a pop-up on failure, and I find it really weird that there is so much shell integration but not that. OK shutting up now, playing with editor...]
> And right out of the box now, no support for Go files, not even syntax coloring, and it thinks go.mod is a media file and won't display its text.
I just had a similar experience, no Go or Swift (ok understandable maybe) support out of the box. But I paid for it it anyway since I like what they’re going for and have admired the company for a long time.
I wouldn't mind not having support for any given $POPULAR_LANGUAGE out of the box -- maybe there are license issues with that -- as long as there is a good extension and it was super easy to find.
Easy to find means if I open a .go file or relevant directory, the app should ask me if I want to install support for Go files. And it should have One Approved Extension, the others should be available on request (as all are now).
If there's no good extension for a common language, I think it's on Panic to convince the community to make one, or make one themselves. One way of convincing the community would be to make it easy! (A quick look at the comments in the extension READMEs strongly implies Panic has not made it easy. The updates to the Go extensions are ~ 6 months old.)
So what's a common language? You could probably use GitHub to figure that out. If Go doesn't qualify then OK, I'll go back to my cave, but I think baking in CoffeeScript instead is pretty arbitrary.
Interestingly, when I first saw this thread I thought Nova was an alternative to XCode. An actual native alternative for writing Swift -- Panic seems like in the best position to do that. But no, webdev it is.
>I tried this out some months ago and had really mixed feelings, but I will give it another shot because generally speaking, Panic is awesome!
Are they? They have a long history of getting bored with projects and cancelling them or letting them languish. Not the best assurance for a long term commitment like an editor...
That at some point they have to sunset tools that are not used by people any more (Like the Newsnet client, from what I remember) makes sense to me. It doesn't feel like they are just abandoning projects because there's something new and shiny to work on.
I'd say yes, Panic are definitely awesome. The software they build is always high quality and their forays into games and hardware has been great. Part of the reason I like them is they are small (compared to Microsoft at least) and independent, so I suppose there is always the chance that they will have to abandon a project to be able to stay afloat.
With regards to writing extensions, I wrote one [1] to integrate the Luacheck analyzer for Lua code which pipes the buffer to an arbitrary program. It doesn't put the result in a pop-up (for that I think you can use Workspace.showInformativeMessage() [2] and its siblings, though I haven't tried it) but it does show how the output of the program can be fetched and parsed. Feel free to shoot me an email if you have any questions I might be able to help with. The dev forums [3] are useful too even though they use that godawful Discourse forum system.
I share this experience. I come back and check on it every few months. It continues to baffle me what their priorities are. VIM support but extensions can't even BUILD or RUN.
I love the idea of a native macOS IDE, but it seems like this will never be something I can actually use productively or ever recommend to anyone. Would happy to be proven wrong.
I really wanted to like Nova. I paid for it (and used it) for a year.
In the end, though... I switched back to VS Code. Native apps like this are much faster than such things, but I had too many use cases for the plugins.
Kind of the same experience as Sublime Text. It's _really fast_, but I just rely too much on plugins when the experience requires something more than vim.
I had a similar experience, but -- possibly counter-intuitively! -- ended up going mostly all-in back on BBEdit 14 when it was released with LSP support which has proven to be a lot less, well, flaky than Nova. I like VS Code a lot and may yet return to it as my main coding editor if I go back to a big project, but BBEdit has always been my old warhorse when it comes to my technical writing because it's just such a Swiss Army Knife for text processing. And BBEdit with Intelephense for PHP or with my own Elixir package for (surprise) Elixir has worked really well.
Nova is pretty, and I'm impressed that they've added a Vim mode, although I haven't been able to really give it a try (my year expired before that was added!). But for me, it wasn't just a lack of plugins, it was that functionality I wanted wasn't there and the functionality that was front and center, like integrated Transmit and Terminal tabs, just wasn't that important to me.
Sounds like we really did have a similar experience - Nova is _great_, but not what we need.
I have very specific and weird needs. For example, I need syntax highlighting for LaTeX, but in a non-mathematic-but-programmatic-control-of-layout way.
VS Code supports that, oddly enough. No other text editor does.
About a year ago I decided it was time to finally modernize my Python coding setup.
I really, really wanted to use Nova, would have paid full price no problem, but for some reason the one main Python plugin was extremely flaky for me. Linter highlighting would sometimes work and sometimes not, unaffected by the plugin settings, and the primary Python plugin I was using was based on somebody’s github repro that hadn’t been touched in a year or two.
I spent a bunch of time but couldn’t figure it out. So I ended up going to VS Code. It works well. The Python plugins work well. It’s a pain in the behind to configure, and it’s not the prettiest thing to look at. But I can grind out working code fast, partially because those plugins catch problems almost as fast as I can type them.
I would try Nova again in a heartbeat if the Python support improves.
Is there a reason you didn't go with PyCharm? I tried vscode, and it works out of the box for particular things, but Pycharm is just a breeze on latger projects.
I'd encourage you (or anyone) that likes Sublime Text and says "but it [small problem]" to give it another go. _Really fast_ is an amazing feature: I am never waiting on my text editor. The incidental features and details that make a bigger IDE more compelling are all there: you just need to find them if they're native or install a plugin if they're not.
Once you've got it set up and then committed your process to muscle memory, the speed makes the software recede and your work the focus.
(_The Pragmatic Programmer_, a book I highly recommend, advised me to "use a single editor well" and that has really made a huge difference in my career. I don't look for new tools until the current ones go unsupported or perform poorly—looking at you jEdit and TextMate—and my work flows are ingrained.)
After trying Nova and looking at other paid editors, I ended up using these funds to make donations to authors of my favourite VSCode and Emacs plugins instead.
I've admired Panic for the entirety of my career, they're always doing really nice work, and I'm glad they're still going strong in a time where native desktop apps aren't really the du jour.
The problem with doing that is that you've now created a substantial dependency for your commercial product, and not a dependency that's merely the "requires npm package foo" kind of dependency. Because Nova is not VSCode, being compatible with Code's extensions API means:
- committing to implementing every new documented Code API function as quickly, completely, and transparently as possible, because if you don't, extensions will break;
- resolving mismatches between how Electron apps do things and how AppKit apps do things, which may be easier said than done;
- possibly choosing not to support functionality in extensions that Code doesn't have;
- putting control of your flagship product in someone else's hands.
So I'm not really surprised Panic hasn't done that. If there were a way to create a basic converter that takes a Code extension as input and spits out a likely-needs-work Nova extension, kind of like there's a converter for TextMate syntax definition files to Code's format, that would be great, although that would almost certainly be easier said than done.
The fact of the matter is that VSCode's market share is massive, and expecting developers to port extensions solely because "it's a native macOS app" is not really a good pitch in 2020-2022. I would rather Panic suck it up and do the work to interop with the existing (massive) ecosystem so that those of us who like to run native apps can do so without it being a step down on just about anything else.
Something like this needs ecosystem buy in, and as far as I can tell right now, it doesn't have it. I wish it did.
The selling point of Nova is being a native Mac citizen rather than a Electron wrapper. The VSCode Extension API heavily relies on the flexibility provided by the browser runtime which native apps like Nova cannot give.
I tried Nova when it first launched and again recently, and I switched back to VSCode due to the numerous plugins and prodigious output of its creators every month.
In my opinion, Nova (through its lack) shows the true power of network effects, even in code editors, because even though VSCode is an inferior product in many respects, like speed and resource usage, it still wins due to its sheer popularity and extensibility. In a way, it is the story of JavaScript itself: a bad language that only works due to its popularity; as one uses JS, one continues to use JS as others do too, creating a virtuous cycle.
> it is the story of JavaScript itself: a bad language that only works due to its popularity
This is a profound observation that gets to the heart of the matter with both VSCode and Javascript, both of which I resisted as long as humanly possible. What gives them the greatest utility is that they're immensely popular, in spite of not being the best tool for the job. I came to VS from 10+ years in Eclipse, and to Javascript as a main cross-platform client language only with the demise of Air/Flash.
But the "network effects" or, let's say, the value of the community-driven ecosystem, is undeniable. In 2008 if you wanted to build 3D games for web, you pretty much had to use Flash - and there was a sizable community maintaining libraries. The environment was imperfect for its own reasons, although certainly no worse than cross-platform JS is right now.
Maybe another way to state it is: If you get enough good coders around even the junkiest tooling, they'll make good code.
But I can't think of any other industry that really works this way, that gathers around a bad standard like buffalo around a waterhole in the desert. I think it's a major flaw in software development in the 2010s-2020s that in order to dance between these walled gardens, independent developers so often have to use tooling that wasn't made for the job. Flash/Air was a breach in all their walls, and that was a reason it had to be made an example out of.
I've heard a hypothesis saying that JS endures because it's bad, otherwise it would've been subsumed by other languages and we never would've been fed up with it to create Webassembly, which is more optimized for its use case than what the other languages we might've used instead of JS.
In other words, feeling the pain of JS over 20 years led to the creation of WASM that might not have been as needed had we had good languages on the web present.
Before VSCode, same effects were conspicuously at work in Emacs and Vim. While JS has some warts here and there, vimscript is truly terrible. Nevertheless, a lot of advanced Vim plugins were built, drawing even more people to Vim, thus incentivizing more plugins, etc.
> VSCode is an inferior product in many respects, like speed and resource usage
This is a rote complaint but how often do you really notice it? Even on my ancient spare 2010 MacBook Air, VSC is responsive and it uses less RAM than other apps like Teams or Skype, or simply loading Gmail in Chrome. Yes, vim uses less RAM but it also has like 5% of the functionality.
Is it possible that this is specific to particular plugins or languages? I mostly use Python, JavaScript, Terraform, and Rust but I did notice that Java is, as always, a lot more demanding.
> Even on my ancient spare 2010 MacBook Air, VSC is responsive and it uses less RAM than other apps like Teams or Skype, or simply loading Gmail in Chrome. Yes, vim uses less RAM but it also has like 5% of the functionality.
Well, you specifically picked the most heavyweight experiences. The comparison was obviously against native text editors.
The place I notice it most is when launching it. I don't keep it open all day, I open it periodically to work on this or that and close it when done.
Opening it feels like it takes forever (5-10s) compared to something like Sublime Text (<1s) and when there are a lot of launches throughout the day, that adds up.
Until you’re the unfortunate person trying to debug an API deployment where the team behind the API decided to use ‘much more efficient protobuffs’ making them entirely unreadable and impossible to troubleshoot. Modern processors and networks are fast enough to allow us to spend a few extra bytes making protocols easy to work with as well as ‘efficient’, and I’d argue that at scale, those ‘efficient’ protocols waste probably 100x more developer time troubleshooting than their text based counterparts. YMMV.
I don't understand why every editor these days come with a minimap, and many of them turn it on by default. I know Sublime introduced it but what does it do exactly? Why is everyone copying it? It just shows you the shapes of blocks of texts of a long file from ten meters away. It doesn't tell you what they are or what they do, or even how to get there. Every IDE since at least the early 2000s gave you an index or a tree menu or something for navigation, VS Code has a breadcrumb IN ADDITION TO the minimap, possibly because Microsoft realizes its gimmick nature. Why not just get rid of it to free up more screen real estate for actually useful things?
> Why not just get rid of it to free up more screen real estate for actually useful things?
Like? I have an 80 column width by default. To not let my code run the entire length of screen for obvious reasons. Also, it is code smell IMHO if you have to write that much code in a single line.
> I know Sublime introduced it but what does it do exactly? Why is everyone copying it? It just shows you the shapes of blocks of texts of a long file from ten meters away
Visual cues. I can immediately know if my linter finds something wrong. It highlights it in red. Without a minimap I'll have to scroll (or if you are using vim you would still need to ctrl+D till you find the problematic line).
If I am editing a Git repo, I can easily make out the additions/removals in the file. Additions in green and removals in red.
> VS Code has a breadcrumb IN ADDITION TO the minimap, possibly because Microsoft realizes its gimmick nature
I sometimes hide my Sidebar in vscode while working in Zen mode. I can then access the directory structure through the breadcrumbs. Especially useful when I don't remember the name of the file ahead of time to use it in command palette search.
Clicking on the filename in the breadcrumb gives me access to all the symbols defined within the file. Quick way to navigate between declared top-level variables/functions.
I definitively do not want to critique your workflow, that would be pretty dumb by me, just two comments to your points that I don't agree with in full.
> Like? I have an 80 column width by default. To not let my code run the entire length of the screen for obvious reasons. Also, it is code smell IMHO if you have to write that much of code in a single line.
What about a split view? I'd be far less productive if my screen wouldn't have space for 4 split view's for >> 80 columns in my editor + a small terminal split by terminal multiplexer.
> Visual cues. I can immediately know if my linter finds something wrong.
Hmm, while there are a few things like renames of variables/functions/... or (type) signature changes for that to happen outside the view one is currently editing in, it's only solving part of the problem — as other files can have those issues too and require changes, so one needs to run a check/lint test or build anyway.
> Like? I have an 80 column width by default. To not let my code run the entire length of screen for obvious reasons. Also, it is code smell IMHO if you have to write that much code in a single line.
There are many useful things your editor can render on screen other than code. If you've used any IDE at all, you wouldn't be saying this. File browsers, syntax tree index, class hierarchies etc. Let you imagination run wild.
> Visual cues. I can immediately know if my linter finds something wrong. It highlights it in red. Without a minimap I'll have to scroll.
Again, lack of imagination here. You only need a red icon on a status bar or something to know if your linter has found something wrong, and a counter next to it to tell you how many. If you want to go to an error, you jump from the keyboard, not use your mouse to scroll.
> or if you are using vim you would still need to ctrl+D till you find the problematic line
As an Emacs user who's seen plenty of fancy vim configs of my colleagues, I suspect you didn't even bother configuring your vim at all.
> If I am editing a Git repo, I can easily make out the additions/removals in the file. Additions in green and removals in red.
LOL. Any reasonable editor has a diff mode and allows you to zoom in and out with something like cmd +/-.
As to the breadcrumb, I wasn't saying breadcrumb was a gimmick, I was saying the minimap is a gimmick, therefore Microsoft has to introduce breadcrumb to aid navigation because the minimap just takes up space.
Over time you learn what the various shapes in the minimap represent. It helps you generate an intuitive awareness of your location and what kind of content or data precedes and follows it--which in turn gives you more of an idea of what you're currently looking at.
You don't edit more than one file? Why would the shape meanings in one file carry over to another? Generally, the only signal that may carry over is the indentation levels. For the intuitive sense you speak of to develop, your file structures have to be highly regular across the board. TBH, I haven't even seen conventional Ruby on Rails code bases that can give me that.
I thought I hated the minimap, but it turns out it was just too … large. The same signals I get from it can be compressed into the width of the scrollbar, and I find them incredibly useful. Navigating problems is either very mouse-heavy in a very mouse target dense area, or requires learning more non-standard keyboard shortcuts/chords, or just “click near the part of the scrollbar where the colors look wrong”. And it takes no additional screen real estate at all. (Which I’m not trying to conserve for pixel density, I run a comically large screen daily; but I try to keep things smaller to stay focused)
Its mostly useful to me if I’m scanning a longer file for merge conflicts. By clicking the minimap I can get to an error easily enough. It’s also a literal bird’s eye view when I’m reverse engineering something. YMMV
The minimap does help in passively locating where things are in a file, as "this is before/after this". It also gives a signature of which file you're editing just by glancing at the shape.
Not only the position in a source file is relevant for many languages, but if you're jumping to references/definitions blindly from another source, you can tell which source file it is and where you are in a single shot without looking at the rest.
That being said, I don't use the minimap. I did try to use it though to see what's the fuss around it. For me it takes too much horizontal space. I can have another vertical split pane instead of having minimaps showing. Heck, I'm not even using scrollbars.
Having an indicator of which function your cursor is currently inside provides very similar benefits to me. Not as immediate as a minimap I have to say, but more useful if you take the time to read it. This is a tradeoff people will argue on forever.
With my workflows, I really don't need that inch of my editor. The minimap is useful because it lets me instantly go anywhere in the file using visual cues. Some minimaps show you details when you hover or click and drag. Anyway, I have a hard time being productive without it.
In xcode if you put your mouse over a function it highlights the function, and puts a tooltip with its name next to your mouse. It's sometimes useful to quickly see what a given class contains and see how complicated it is (based on lines of code and number of indentations).
You could argue it's highly situational, but IMO it's nice to always be able to see how complicated your codebase is getting, tech debt is no joke
You are bothered by useless... Why did every new editor adopt the Visual Studio asinine default of fuzzy autocompleting (not only the new part) on enter or space? It's a stupid idea, with absolutely no upsides.
I didn't try this one (I'm not on a mac), but I fully expect it to do that too. All of them do. (I'll be glad if somebody tells me it doesn't.)
Came here to say this. In VSCode there’s the Outline panel that does the same thing. I find it incredibly more useful than the minimal. But hey, to each their own, I just disable the minimal and that’s it.
It can be very useful when the work you're doing requires jumping between 2-3 different parts of a file. Yes, you can probably do the same with ctrl-f, but for many people it's more intuitive to have the visual representation.
I've found minimaps to be useful when you're also using linters or compilers - you can quickly jump to the next error by looking at the little red dots or lines on the minimap.
Nothing to do with the IDE but I just want to point out that the homepage design is sick. The 3D space in the background did not affect the scroll performance and it adds a really good vibe without affecting the UX. Love it!
There was a design like that for another news yesterday or the day before. I wonder if we're headed back into the 80s with web design. It happened with clothes a few years ago (very high waist jeans.) There was no web in the 80s but there were arcade games and that front page looks like the start screen of some game back at the time. We'll see if it trends.
My main complaints at the time were a confusing extensions ecosystem; difficulty rolling your own; and the sense that (as with Coda) "programmer" means a person hand-coding web sites with HTML+CSS and maybe Javascript or PHP. Seemed like they weren't trying to convince anybody who already used VSCode et al.
That said, I have had some difficulty adjusting to Sublime's way of doing things, and VS never felt right to me, so maybe I'm just picky.
In any case I am happy to see another opinionated text editor in the mix!
[Edit: And right out of the box now, no support for Go files, not even syntax coloring, and it thinks go.mod is a media file and won't display its text. Searching extensions for "go" gets me three different extensions and no way to tell which is better/more-popular; and also shows me six totally unrelated extensions, three of which have "go" in their titles e.g. "django" and three of which do not. So... still not really shooting for the programmer market, but I will keep trying!]
[Edit2: Similar results for Rust. And extensions have to be written in Javascript, and the boilerplate is all for published extensions which maybe makes sense, but I really want an easy way to pipe ($BUFFER|$CLIPBOARD) to an arbitrary program and put the result in ($BUFFER|CLIPBOARD) with a pop-up on failure, and I find it really weird that there is so much shell integration but not that. OK shutting up now, playing with editor...]
I just had a similar experience, no Go or Swift (ok understandable maybe) support out of the box. But I paid for it it anyway since I like what they’re going for and have admired the company for a long time.
Easy to find means if I open a .go file or relevant directory, the app should ask me if I want to install support for Go files. And it should have One Approved Extension, the others should be available on request (as all are now).
If there's no good extension for a common language, I think it's on Panic to convince the community to make one, or make one themselves. One way of convincing the community would be to make it easy! (A quick look at the comments in the extension READMEs strongly implies Panic has not made it easy. The updates to the Go extensions are ~ 6 months old.)
So what's a common language? You could probably use GitHub to figure that out. If Go doesn't qualify then OK, I'll go back to my cave, but I think baking in CoffeeScript instead is pretty arbitrary.
Deleted Comment
Are they? They have a long history of getting bored with projects and cancelling them or letting them languish. Not the best assurance for a long term commitment like an editor...
That at some point they have to sunset tools that are not used by people any more (Like the Newsnet client, from what I remember) makes sense to me. It doesn't feel like they are just abandoning projects because there's something new and shiny to work on.
1: https://github.com/GarrettAlbright/Luacheck.novaextension/bl...
2: https://docs.nova.app/api-reference/workspace/#showinformati...
3: https://devforum.nova.app
I love the idea of a native macOS IDE, but it seems like this will never be something I can actually use productively or ever recommend to anyone. Would happy to be proven wrong.
In the end, though... I switched back to VS Code. Native apps like this are much faster than such things, but I had too many use cases for the plugins.
Kind of the same experience as Sublime Text. It's _really fast_, but I just rely too much on plugins when the experience requires something more than vim.
Nova is pretty, and I'm impressed that they've added a Vim mode, although I haven't been able to really give it a try (my year expired before that was added!). But for me, it wasn't just a lack of plugins, it was that functionality I wanted wasn't there and the functionality that was front and center, like integrated Transmit and Terminal tabs, just wasn't that important to me.
I have very specific and weird needs. For example, I need syntax highlighting for LaTeX, but in a non-mathematic-but-programmatic-control-of-layout way.
VS Code supports that, oddly enough. No other text editor does.
Maybe they're really targeting a different audience.
[0] https://open-vsx.org/
I really, really wanted to use Nova, would have paid full price no problem, but for some reason the one main Python plugin was extremely flaky for me. Linter highlighting would sometimes work and sometimes not, unaffected by the plugin settings, and the primary Python plugin I was using was based on somebody’s github repro that hadn’t been touched in a year or two.
I spent a bunch of time but couldn’t figure it out. So I ended up going to VS Code. It works well. The Python plugins work well. It’s a pain in the behind to configure, and it’s not the prettiest thing to look at. But I can grind out working code fast, partially because those plugins catch problems almost as fast as I can type them.
I would try Nova again in a heartbeat if the Python support improves.
Once you've got it set up and then committed your process to muscle memory, the speed makes the software recede and your work the focus.
(_The Pragmatic Programmer_, a book I highly recommend, advised me to "use a single editor well" and that has really made a huge difference in my career. I don't look for new tools until the current ones go unsupported or perform poorly—looking at you jEdit and TextMate—and my work flows are ingrained.)
Dead Comment
- committing to implementing every new documented Code API function as quickly, completely, and transparently as possible, because if you don't, extensions will break;
- resolving mismatches between how Electron apps do things and how AppKit apps do things, which may be easier said than done;
- possibly choosing not to support functionality in extensions that Code doesn't have;
- putting control of your flagship product in someone else's hands.
So I'm not really surprised Panic hasn't done that. If there were a way to create a basic converter that takes a Code extension as input and spits out a likely-needs-work Nova extension, kind of like there's a converter for TextMate syntax definition files to Code's format, that would be great, although that would almost certainly be easier said than done.
The fact of the matter is that VSCode's market share is massive, and expecting developers to port extensions solely because "it's a native macOS app" is not really a good pitch in 2020-2022. I would rather Panic suck it up and do the work to interop with the existing (massive) ecosystem so that those of us who like to run native apps can do so without it being a step down on just about anything else.
Something like this needs ecosystem buy in, and as far as I can tell right now, it doesn't have it. I wish it did.
Got a link for that? I was looking for a TextMate grammar to Monarch converter and couldn’t find anything that works
In my opinion, Nova (through its lack) shows the true power of network effects, even in code editors, because even though VSCode is an inferior product in many respects, like speed and resource usage, it still wins due to its sheer popularity and extensibility. In a way, it is the story of JavaScript itself: a bad language that only works due to its popularity; as one uses JS, one continues to use JS as others do too, creating a virtuous cycle.
This is a profound observation that gets to the heart of the matter with both VSCode and Javascript, both of which I resisted as long as humanly possible. What gives them the greatest utility is that they're immensely popular, in spite of not being the best tool for the job. I came to VS from 10+ years in Eclipse, and to Javascript as a main cross-platform client language only with the demise of Air/Flash.
But the "network effects" or, let's say, the value of the community-driven ecosystem, is undeniable. In 2008 if you wanted to build 3D games for web, you pretty much had to use Flash - and there was a sizable community maintaining libraries. The environment was imperfect for its own reasons, although certainly no worse than cross-platform JS is right now.
Maybe another way to state it is: If you get enough good coders around even the junkiest tooling, they'll make good code.
But I can't think of any other industry that really works this way, that gathers around a bad standard like buffalo around a waterhole in the desert. I think it's a major flaw in software development in the 2010s-2020s that in order to dance between these walled gardens, independent developers so often have to use tooling that wasn't made for the job. Flash/Air was a breach in all their walls, and that was a reason it had to be made an example out of.
In other words, feeling the pain of JS over 20 years led to the creation of WASM that might not have been as needed had we had good languages on the web present.
https://www.destroyallsoftware.com/talks/the-birth-and-death...
https://youtube.com/watch?v=pBYqen3B2gc
I don’t know about emacs, as I’ve never used it from either side
This is a rote complaint but how often do you really notice it? Even on my ancient spare 2010 MacBook Air, VSC is responsive and it uses less RAM than other apps like Teams or Skype, or simply loading Gmail in Chrome. Yes, vim uses less RAM but it also has like 5% of the functionality.
Is it possible that this is specific to particular plugins or languages? I mostly use Python, JavaScript, Terraform, and Rust but I did notice that Java is, as always, a lot more demanding.
Well, you specifically picked the most heavyweight experiences. The comparison was obviously against native text editors.
Opening it feels like it takes forever (5-10s) compared to something like Sublime Text (<1s) and when there are a lot of launches throughout the day, that adds up.
It is well optimized for what it is though, so the tradeoff of performance for functionality generally isn't a question.
Until you’re the unfortunate person trying to debug an API deployment where the team behind the API decided to use ‘much more efficient protobuffs’ making them entirely unreadable and impossible to troubleshoot. Modern processors and networks are fast enough to allow us to spend a few extra bytes making protocols easy to work with as well as ‘efficient’, and I’d argue that at scale, those ‘efficient’ protocols waste probably 100x more developer time troubleshooting than their text based counterparts. YMMV.
Deleted Comment
Like? I have an 80 column width by default. To not let my code run the entire length of screen for obvious reasons. Also, it is code smell IMHO if you have to write that much code in a single line.
> I know Sublime introduced it but what does it do exactly? Why is everyone copying it? It just shows you the shapes of blocks of texts of a long file from ten meters away
Visual cues. I can immediately know if my linter finds something wrong. It highlights it in red. Without a minimap I'll have to scroll (or if you are using vim you would still need to ctrl+D till you find the problematic line).
If I am editing a Git repo, I can easily make out the additions/removals in the file. Additions in green and removals in red.
> VS Code has a breadcrumb IN ADDITION TO the minimap, possibly because Microsoft realizes its gimmick nature
I sometimes hide my Sidebar in vscode while working in Zen mode. I can then access the directory structure through the breadcrumbs. Especially useful when I don't remember the name of the file ahead of time to use it in command palette search.
Clicking on the filename in the breadcrumb gives me access to all the symbols defined within the file. Quick way to navigate between declared top-level variables/functions.
> Like? I have an 80 column width by default. To not let my code run the entire length of the screen for obvious reasons. Also, it is code smell IMHO if you have to write that much of code in a single line.
What about a split view? I'd be far less productive if my screen wouldn't have space for 4 split view's for >> 80 columns in my editor + a small terminal split by terminal multiplexer.
> Visual cues. I can immediately know if my linter finds something wrong.
Hmm, while there are a few things like renames of variables/functions/... or (type) signature changes for that to happen outside the view one is currently editing in, it's only solving part of the problem — as other files can have those issues too and require changes, so one needs to run a check/lint test or build anyway.
There are many useful things your editor can render on screen other than code. If you've used any IDE at all, you wouldn't be saying this. File browsers, syntax tree index, class hierarchies etc. Let you imagination run wild.
> Visual cues. I can immediately know if my linter finds something wrong. It highlights it in red. Without a minimap I'll have to scroll.
Again, lack of imagination here. You only need a red icon on a status bar or something to know if your linter has found something wrong, and a counter next to it to tell you how many. If you want to go to an error, you jump from the keyboard, not use your mouse to scroll.
> or if you are using vim you would still need to ctrl+D till you find the problematic line
As an Emacs user who's seen plenty of fancy vim configs of my colleagues, I suspect you didn't even bother configuring your vim at all.
> If I am editing a Git repo, I can easily make out the additions/removals in the file. Additions in green and removals in red.
LOL. Any reasonable editor has a diff mode and allows you to zoom in and out with something like cmd +/-.
As to the breadcrumb, I wasn't saying breadcrumb was a gimmick, I was saying the minimap is a gimmick, therefore Microsoft has to introduce breadcrumb to aid navigation because the minimap just takes up space.
Not only the position in a source file is relevant for many languages, but if you're jumping to references/definitions blindly from another source, you can tell which source file it is and where you are in a single shot without looking at the rest.
That being said, I don't use the minimap. I did try to use it though to see what's the fuss around it. For me it takes too much horizontal space. I can have another vertical split pane instead of having minimaps showing. Heck, I'm not even using scrollbars.
Having an indicator of which function your cursor is currently inside provides very similar benefits to me. Not as immediate as a minimap I have to say, but more useful if you take the time to read it. This is a tradeoff people will argue on forever.
You could argue it's highly situational, but IMO it's nice to always be able to see how complicated your codebase is getting, tech debt is no joke
I didn't try this one (I'm not on a mac), but I fully expect it to do that too. All of them do. (I'll be glad if somebody tells me it doesn't.)
Deleted Comment
https://docs.nova.app/api-reference/language-client/#languag...