5 ms·

> The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it. For y

> The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it. For your information: in VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. Edit and disclaimer: Not sure why I'm getting downvoted, my comment doesn't contradict parent message. I personally type my code too (with Flow), it's an amazing tool for static code analysis and avoid errors at the runtime. I would suggest everyone give it a try (with TypeScript, Flow or whatever).

stcredzero 10y ago
VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. With good coding practice, references, "senders" and "implementers," and renaming worked well in Smalltalk. Where I missed types was during refactoring, and that also worked well about 99% of the time without types. It was that one last thing that we couldn't be 100% sure of that blocked the big refactoring we all wanted to do badly -- that's when I missed types!
johnfn 10y ago
> For your information: in VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. I didn't downvote, but this seems incorrect to me. I'm sure that it works in small code bases, but once your code gets large enough (and dynamic enough) it's going to have to start missing things.
- ggregoire 10y ago
  Why would their algorithm stop to work if your code gets large? It's not some kind of magic. :) My current project has 10,000 LOC and 130 files. If I use "Rename symbol" on something imported in different files of my project, the editor will open all the files, edit all the names and just wait for me to save the changes.
  - 13years 10y ago
    Doesn't work at all for me. My project has about 500k+ LOC. I suspect though it isn't the size of project, but certain patterns of design that work or don't work in non typed JS. However Brackets does better at finding method definitions. Even in my mess of a project with non typed JS, Brackets can always find the method definition or at least give me possible choices.
  - johnfn 10y ago
    > Why would their algorithm stop to work if your code gets large? It's not some kind of magic. :) Their algorithm always fails on certain cases. If your code base is larger, it's more likely to contain those cases. Example case that will always fail: const x = { foo: () => {} } x["f" + "oo"](); Now rename foo to bar. Yes, this is a contrived case, but we had similar code in production at my last job.
billti 10y ago
If the code isn't typed, then you can't find all references accurately. For example, in the below, you've no idea if the "a" inside the function is the same is as on "foo". ```javascript var foo = { a: true, // Find all references on "a" here... b: "hello" }; foo.a = false; bar(foo); function bar(obj) { obj.a = false; // Won't find this "a". } ``` Call site inference can follow this sometimes. However with types it can be certain, e.g. ```typescript interface Foo { a: boolean; b: string; }; var foo: Foo = { a: true, // Find all references on "a" here... b: "hello" }; foo.a = false; bar(foo); function bar(obj: Foo) { obj.a = false; // Will be found, renamed if refactored, etc.. } ``` Note that the JavaScript in VS Code is powered by the same engine as the TypeScript, so it's using the same inference, it just can't infer untyped parameters. There is some support for JsDoc in the engine, so code like the below will work: ```javascript /** @typedef {{a: boolean, b: string}} Foo */ /** @type {Foo} */ var foo = { b: "hello" }; foo.a = false; // Find all refs here bar(foo); /** * @param {Foo} obj - Some object */ function bar(obj) { obj.a = false; // will find this one } ``` Full disclaimer: I work on these tools.
- ggregoire 10y ago
  Nice catch! Yeah, that makes sense. As you work on this, do you know if the refactoring tools would fully work with my code typed with Flow instead of TypeScript? (I use the official flow-for-vscode extenstion, idk if it's relevant) Edit: Ok I just tried and it works, even with the extension disabled. type Foo = { a: boolean, b: string, } var foo: Foo = { a: true, // Find all references on "a" here... b: "hello" }; foo.a = false; bar(foo); function bar(obj: Foo) { obj.a = false; // Found it. }
  - billti 10y ago
    I don't know, but generally call-site inference has a couple of notable issues: - If you don't have any calls to the function yet (i.e. "bar(foo)" wasn't there above), then there is nothing to infer from, so you have no idea what the type is at this point (other than by the use of the parameter inside the function). - Is your call-site wrong? If the parameter type is explicit, this is easily checked. If not, then again you can only go by what the function does with it. (Which may not be much help if it's something like "RestAPI.post(JSON.stringify(theParamInQuestion))" ).
xiaoma 10y ago
VSCode has become a mind-blowingly good editor. It's closing in on the power of heavy-weight IDEs with much better performance than some code editors (e.g. Atom), even.
- dotancohen 10y ago
  Both VSCode and Atom are based on Electron, which is slow and battery-intensive as it is based on NodeJS. Are you saying that recent VSCode versions are as performant as, say, a C++ based editor or even (shudder) a Java based editor such as Jetbrains (Webstorm, etc.)? I last looked as VSCode (on a KDE 4 CentOS 7 desktop) about half a year ago, and it was terribly slow, even without extensions.
  - tomduncalf 10y ago
    I would say VS Code is far more performant than the Jetbrains editors in my experience on a 2013 MBP. It may be that the Jetbrains editors are "doing more", but I always found them frustratingly sluggish - maybe a worthwhile trade off when using something like Scala but I personally couldn't deal with it for Javascript. I'd really recommend trying it again. On a performant machine, VS Code feels like a native app to me aside from a slightly slower start up time, whereas Atom is noticeably slow. On my bottom spec 12" Macbook the difference is more noticeable, but everything feels slow on there.
  - xiaoma 10y ago
    VSCode runs circles around Atom and Jetbrains both.

stcredzero 10y ago

VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. With good coding practice, references, "senders" and "implementers," and renaming worked well in Smalltalk. Where I missed types was during refactoring, and that also worked well about 99% of the time without types. It was that one last thing that we couldn't be 100% sure of that blocked the big refactoring we all wanted to do badly -- that's when I missed types!

johnfn 10y ago

> For your information: in VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. I didn't downvote, but this seems incorrect to me. I'm sure that it works in small code bases, but once your code gets large enough (and dynamic enough) it's going to have to start missing things.

ggregoire 10y ago
Why would their algorithm stop to work if your code gets large? It's not some kind of magic. :) My current project has 10,000 LOC and 130 files. If I use "Rename symbol" on something imported in different files of my project, the editor will open all the files, edit all the names and just wait for me to save the changes.
- 13years 10y ago
  Doesn't work at all for me. My project has about 500k+ LOC. I suspect though it isn't the size of project, but certain patterns of design that work or don't work in non typed JS. However Brackets does better at finding method definitions. Even in my mess of a project with non typed JS, Brackets can always find the method definition or at least give me possible choices.
- johnfn 10y ago
  > Why would their algorithm stop to work if your code gets large? It's not some kind of magic. :) Their algorithm always fails on certain cases. If your code base is larger, it's more likely to contain those cases. Example case that will always fail: const x = { foo: () => {} } x["f" + "oo"](); Now rename foo to bar. Yes, this is a contrived case, but we had similar code in production at my last job.

billti 10y ago

If the code isn't typed, then you can't find all references accurately. For example, in the below, you've no idea if the "a" inside the function is the same is as on "foo". ```javascript var foo = { a: true, // Find all references on "a" here... b: "hello" }; foo.a = false; bar(foo); function bar(obj) { obj.a = false; // Won't find this "a". } ``` Call site inference can follow this sometimes. However with types it can be certain, e.g. ```typescript interface Foo { a: boolean; b: string; }; var foo: Foo = { a: true, // Find all references on "a" here... b: "hello" }; foo.a = false; bar(foo); function bar(obj: Foo) { obj.a = false; // Will be found, renamed if refactored, etc.. } ``` Note that the JavaScript in VS Code is powered by the same engine as the TypeScript, so it's using the same inference, it just can't infer untyped parameters. There is some support for JsDoc in the engine, so code like the below will work: ```javascript /** @typedef {{a: boolean, b: string}} Foo */ /** @type {Foo} */ var foo = { b: "hello" }; foo.a = false; // Find all refs here bar(foo); /** * @param {Foo} obj - Some object */ function bar(obj) { obj.a = false; // will find this one } ``` Full disclaimer: I work on these tools.

ggregoire 10y ago
Nice catch! Yeah, that makes sense. As you work on this, do you know if the refactoring tools would fully work with my code typed with Flow instead of TypeScript? (I use the official flow-for-vscode extenstion, idk if it's relevant) Edit: Ok I just tried and it works, even with the extension disabled. type Foo = { a: boolean, b: string, } var foo: Foo = { a: true, // Find all references on "a" here... b: "hello" }; foo.a = false; bar(foo); function bar(obj: Foo) { obj.a = false; // Found it. }
- billti 10y ago
  I don't know, but generally call-site inference has a couple of notable issues: - If you don't have any calls to the function yet (i.e. "bar(foo)" wasn't there above), then there is nothing to infer from, so you have no idea what the type is at this point (other than by the use of the parameter inside the function). - Is your call-site wrong? If the parameter type is explicit, this is easily checked. If not, then again you can only go by what the function does with it. (Which may not be much help if it's something like "RestAPI.post(JSON.stringify(theParamInQuestion))" ).

xiaoma 10y ago

VSCode has become a mind-blowingly good editor. It's closing in on the power of heavy-weight IDEs with much better performance than some code editors (e.g. Atom), even.

dotancohen 10y ago
Both VSCode and Atom are based on Electron, which is slow and battery-intensive as it is based on NodeJS. Are you saying that recent VSCode versions are as performant as, say, a C++ based editor or even (shudder) a Java based editor such as Jetbrains (Webstorm, etc.)? I last looked as VSCode (on a KDE 4 CentOS 7 desktop) about half a year ago, and it was terribly slow, even without extensions.
- tomduncalf 10y ago
  I would say VS Code is far more performant than the Jetbrains editors in my experience on a 2013 MBP. It may be that the Jetbrains editors are "doing more", but I always found them frustratingly sluggish - maybe a worthwhile trade off when using something like Scala but I personally couldn't deal with it for Javascript. I'd really recommend trying it again. On a performant machine, VS Code feels like a native app to me aside from a slightly slower start up time, whereas Atom is noticeably slow. On my bottom spec 12" Macbook the difference is more noticeable, but everything feels slow on there.
- xiaoma 10y ago
  VSCode runs circles around Atom and Jetbrains both.