4 ms·

The most important word in the title is "class". It only does this properly for JS code inside an explicit ES6 class, and, after some cursory testing, doesn't w

The most important word in the title is "class". It only does this properly for JS code inside an explicit ES6 class, and, after some cursory testing, doesn't work too well if you bind things to the class at runtime/outside of the main class block. VS code doesn't autocomplete "this" for "old-school" (function-provided "this" objects and manual prototype inheritance etc.) object-orientish JS; it doesn't compute it properly or at all for re-bound "this" (e.g. apply()/bind()). Making autocompletion analysis work for non-straightforward non-ES6 OO javascript is a very hard (maybe impossible even without any "eval"ed code, though I'm not sure) thing to do, so this isn't a ding on VS code: any autocompletion is better than none. That said, if the only way to get good OO-code autocompletion is to reduce the subset of the language/OO models usable to basically "what you could have in Java/C#", it might be a good opportunity to re-evaluate your choice of language. Transpilers for more easily-statically-analyzable languages do exist, after all.

paulgb 9y ago
> ...it might be a good opportunity to re-evaluate your choice of language. Transpilers for more easily-statically-analyzable languages do exist, after all. I find TypeScript does a pretty good job of allowing as much static analysis as you want without preventing you from using all the features of JS that break it if you wish. In an ideal world I'd work in a fully static language that transpiles to JS but the reality is it's usually necessary to deal with legacy JS libraries. I haven't seen a fully static transpiled language deal with that gracefully, but I'd love to be wrong about that!
- zbentley 9y ago
  With regards to static-analysis capability as an aid to developer productivity, I agree with you: find the compromise that best suits your preference. With regards to static-analysis capability as a means of ensuring code reliability, I don't agree. Some people (I'm not characterizing you here since I am unsure if this is your position) consider static analyzability to be equivalent to a strong type system or various safety guarantees with regards to making code's behavior verifiable and/or predictable. If you subscribe to that belief, having an 'escape hatch' that lets you use features of a platform that violate the analyzability guarantees is a virtual guarantee of trouble. I'm put in mind of Rust's "unsafe" areas (there are many other examples of this phenomenon): not only do people routinely overuse them (out of ignorance or misplaced, incorrect, and unverified assertions of "elegance" or "performance"), but their existence at all compromises the ability to verify even small subparts of the greater program: https://news.ycombinator.com/item?id=15146330 https://news.ycombinator.com/item?id=15146330 Having analyzability/guarantees with an escape hatch is better than having none at all, but a lot of people don't understand the tradeoff there.
  - paulgb 9y ago
    That's a good distinction, I agree with you. I hope that some day it's practical write code for browsers that is statically analyzable. I feel like the programming community was quick to give up static typing when CPUs got fast enough that the performance hit was irrelevant (for many uses), and now we are starting to realize that types were a good idea for correctness too.
- sjrd 9y ago
  > I haven't seen a fully static transpiled language deal with that gracefully, but I'd love to be wrong about that! Scala.js is specifically designed to be very good at this. You might want to give a shot, if you haven't already ;) Usually you would stay within the type-safe Scala code, or even talk to JavaScript libraries in a type-safe way. But it will always let you do anything you could do in JavaScript (it is one of its core language design decisions). If you want to do something especially weird, the syntax to do so might be pretty awkward, but in most cases it will feel very natural.
  - paulgb 9y ago
    Thanks, I'll take a look. I do like Scala. Do you recommend a particular editor?
  - kbp 9y ago
    In ReasonML, most of your code is just Reason (which is just OCaml), but you can easily provide type declarations and use Javascript code in a typesafe way, or you can just drop to raw JS at any point in a Reason file.
fancyfacebook 9y ago
Autocompletion for JS libs has been around for at least 12 years in various tools. It's not that hard of a problem to solve for a standard library if you follow a convention or two.

paulgb 9y ago

> ...it might be a good opportunity to re-evaluate your choice of language. Transpilers for more easily-statically-analyzable languages do exist, after all. I find TypeScript does a pretty good job of allowing as much static analysis as you want without preventing you from using all the features of JS that break it if you wish. In an ideal world I'd work in a fully static language that transpiles to JS but the reality is it's usually necessary to deal with legacy JS libraries. I haven't seen a fully static transpiled language deal with that gracefully, but I'd love to be wrong about that!

zbentley 9y ago
With regards to static-analysis capability as an aid to developer productivity, I agree with you: find the compromise that best suits your preference. With regards to static-analysis capability as a means of ensuring code reliability, I don't agree. Some people (I'm not characterizing you here since I am unsure if this is your position) consider static analyzability to be equivalent to a strong type system or various safety guarantees with regards to making code's behavior verifiable and/or predictable. If you subscribe to that belief, having an 'escape hatch' that lets you use features of a platform that violate the analyzability guarantees is a virtual guarantee of trouble. I'm put in mind of Rust's "unsafe" areas (there are many other examples of this phenomenon): not only do people routinely overuse them (out of ignorance or misplaced, incorrect, and unverified assertions of "elegance" or "performance"), but their existence at all compromises the ability to verify even small subparts of the greater program: https://news.ycombinator.com/item?id=15146330 https://news.ycombinator.com/item?id=15146330 Having analyzability/guarantees with an escape hatch is better than having none at all, but a lot of people don't understand the tradeoff there.
- paulgb 9y ago
  That's a good distinction, I agree with you. I hope that some day it's practical write code for browsers that is statically analyzable. I feel like the programming community was quick to give up static typing when CPUs got fast enough that the performance hit was irrelevant (for many uses), and now we are starting to realize that types were a good idea for correctness too.
sjrd 9y ago
> I haven't seen a fully static transpiled language deal with that gracefully, but I'd love to be wrong about that! Scala.js is specifically designed to be very good at this. You might want to give a shot, if you haven't already ;) Usually you would stay within the type-safe Scala code, or even talk to JavaScript libraries in a type-safe way. But it will always let you do anything you could do in JavaScript (it is one of its core language design decisions). If you want to do something especially weird, the syntax to do so might be pretty awkward, but in most cases it will feel very natural.
- paulgb 9y ago
  Thanks, I'll take a look. I do like Scala. Do you recommend a particular editor?
- kbp 9y ago
  In ReasonML, most of your code is just Reason (which is just OCaml), but you can easily provide type declarations and use Javascript code in a typesafe way, or you can just drop to raw JS at any point in a Reason file.

fancyfacebook 9y ago

Autocompletion for JS libs has been around for at least 12 years in various tools. It's not that hard of a problem to solve for a standard library if you follow a convention or two.