7 ms·

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 mo

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.

nsonha 5y ago
To be fair this "worse is better" thing permiates all aspects of tech: c++, java, python, wasteful text based protocols...
- ThouYS 5y ago
  in the case of python: "better is better" ;)
  - nine_k 5y ago
    As in "very slow though flexible is better".
    - utunga 5y ago
      I get why you are saying an interpreted language is slow but given that people use python to orchestrate most compute intense (AI) and data-heavy (data science) work, it obviously does a pretty excellent job of being pretty 'fast' in practice - ie offloading the 'slow' bits to dedicated code.
  - nsonha 5y ago
    as it stands right now, python is more complex and has worse type system comparing to typescript. It has all of javascript warts and more (those confusing underscore methods, GIL, pyproject.toml is only now standardized). The good things about python have nothing to do with the language, it's the ecosystem and standard library (which is still not as good as, say, java's). So I'm not quite sure why people say javascript THE LANGUAGE is bad, but python the language is "better".
- PebblesHD 5y ago
  > wasteful text based protocols… 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.
  - KnobbleMcKnees 5y ago
    This sounds like a tools problem though. Bytes and hex aren't readable until you decide then to characters and use a text renderer to display the. I can't imagine this isnt possible with protobuf and the right debugging tools (though it's not my area of expertise)
    - matteotom 5y ago
      Sometimes you just want to dump the bytes that are going over the wire. Sure you could pipe the output to a protobuf parser, but then you'd need to make sure the output of tcpdump or ngrep or whatever is what the parser expects. As an example, I needed to track down why some service traffic was getting misrouted, and I found the problem by tcpdumping the traffic and realizing one service was silently corrupting a header value - I could have added more debug logs to either service, but that would have taken a lot longer to implement and deploy. Personally I'd rather stick with the simpler protocol until someone runs the numbers and finds something more efficient would improve performance or save money by a significant enough amount.
      - nsonha 5y ago
        > until someone runs the numbers and finds something more efficient would improve performance or save money by a significant enough amount This argument must be the ultimate defense in code review. The thing is, we have the field of theoretical computer science and things like big O so that we can reason about code without having to do benchmarks about every little thing, because that's impossible in practice. Regarding protocols, I'd argue that the most important thing for them is to be efficient, at least when IO is still the biggest bottleneck of computing. The other comment already points out debug being a tooling problem.
sfvisser 5y ago
VSCode’s speed and resource usage are not best class, but – on my relatively modern machine – are definitively good enough.
- _zooted 5y ago
  Yeah, with 32GB of RAM I'm not so worried that my text editor is taking up a gig of memory TBH
nine_k 5y ago
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.
- shp0ngle 5y ago
  Yeah. People don’t realize how bad vimscript is. Yet there are still tons of vim plugins. I don’t know about emacs, as I’ve never used it from either side
noduerme 5y ago
> 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.
- cercatrova 5y ago
  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. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... https://youtube.com/watch?v=pBYqen3B2gc https://youtube.com/watch?v=pBYqen3B2gc
  - andrekandre 5y ago
    > 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. honestly, that sounds like retroactive justification... bytecodes where a thing since way before js showed up, and afaik there was no technical reason it couldn't have been like that from the beginning
deleted 5y ago
[deleted]
acdha 5y ago
> 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.
- saagarjha 5y ago
  > 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.
  - acdha 5y ago
    I was just pointing out that VSC is pretty far down the list of things where performance is something I notice unless I'm trying to do a benchmark of some sort. It's not quite as fast as, say, TextMate 2 was but it's pretty close on basic performance (e.g. when I measured keyboard-display latency it was within 20% of Text Edit or Terminal) and at some point the huge amount of additional functionality is a consideration. If the question is “what things slow me down at work”, it's close to the bottom of the list.
- kup0 5y ago
  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.
  - acdha 5y ago
    It takes about a second on my M1, which puts it below the threshold I have for caring about it. The big question is whether you count things like indexing projects against the editor or the toolchain, since things like firing up linters or the JVM is only partially under their control.

nsonha 5y ago

To be fair this "worse is better" thing permiates all aspects of tech: c++, java, python, wasteful text based protocols...

ThouYS 5y ago
in the case of python: "better is better" ;)
- nine_k 5y ago
  As in "very slow though flexible is better".
  - utunga 5y ago
    I get why you are saying an interpreted language is slow but given that people use python to orchestrate most compute intense (AI) and data-heavy (data science) work, it obviously does a pretty excellent job of being pretty 'fast' in practice - ie offloading the 'slow' bits to dedicated code.
- nsonha 5y ago
  as it stands right now, python is more complex and has worse type system comparing to typescript. It has all of javascript warts and more (those confusing underscore methods, GIL, pyproject.toml is only now standardized). The good things about python have nothing to do with the language, it's the ecosystem and standard library (which is still not as good as, say, java's). So I'm not quite sure why people say javascript THE LANGUAGE is bad, but python the language is "better".
PebblesHD 5y ago
> wasteful text based protocols… 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.
- KnobbleMcKnees 5y ago
  This sounds like a tools problem though. Bytes and hex aren't readable until you decide then to characters and use a text renderer to display the. I can't imagine this isnt possible with protobuf and the right debugging tools (though it's not my area of expertise)
  - matteotom 5y ago
    Sometimes you just want to dump the bytes that are going over the wire. Sure you could pipe the output to a protobuf parser, but then you'd need to make sure the output of tcpdump or ngrep or whatever is what the parser expects. As an example, I needed to track down why some service traffic was getting misrouted, and I found the problem by tcpdumping the traffic and realizing one service was silently corrupting a header value - I could have added more debug logs to either service, but that would have taken a lot longer to implement and deploy. Personally I'd rather stick with the simpler protocol until someone runs the numbers and finds something more efficient would improve performance or save money by a significant enough amount.
    - nsonha 5y ago
      > until someone runs the numbers and finds something more efficient would improve performance or save money by a significant enough amount This argument must be the ultimate defense in code review. The thing is, we have the field of theoretical computer science and things like big O so that we can reason about code without having to do benchmarks about every little thing, because that's impossible in practice. Regarding protocols, I'd argue that the most important thing for them is to be efficient, at least when IO is still the biggest bottleneck of computing. The other comment already points out debug being a tooling problem.

sfvisser 5y ago

VSCode’s speed and resource usage are not best class, but – on my relatively modern machine – are definitively good enough.

_zooted 5y ago
Yeah, with 32GB of RAM I'm not so worried that my text editor is taking up a gig of memory TBH

nine_k 5y ago

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.

shp0ngle 5y ago
Yeah. People don’t realize how bad vimscript is. Yet there are still tons of vim plugins. I don’t know about emacs, as I’ve never used it from either side

noduerme 5y ago

> 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.

cercatrova 5y ago
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. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... https://youtube.com/watch?v=pBYqen3B2gc https://youtube.com/watch?v=pBYqen3B2gc
- andrekandre 5y ago
  > 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. honestly, that sounds like retroactive justification... bytecodes where a thing since way before js showed up, and afaik there was no technical reason it couldn't have been like that from the beginning

deleted 5y ago

[deleted]

acdha 5y ago

> 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.

saagarjha 5y ago
> 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.
- acdha 5y ago
  I was just pointing out that VSC is pretty far down the list of things where performance is something I notice unless I'm trying to do a benchmark of some sort. It's not quite as fast as, say, TextMate 2 was but it's pretty close on basic performance (e.g. when I measured keyboard-display latency it was within 20% of Text Edit or Terminal) and at some point the huge amount of additional functionality is a consideration. If the question is “what things slow me down at work”, it's close to the bottom of the list.
kup0 5y ago
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.
- acdha 5y ago
  It takes about a second on my M1, which puts it below the threshold I have for caring about it. The big question is whether you count things like indexing projects against the editor or the toolchain, since things like firing up linters or the JVM is only partially under their control.