It's been bugging me for a while now as I can't find the video but the Vs code team made a demo where they were able to jump to a dependencies source code on github inside the editor. Looked pretty amazing and would definitely solve the problems you mentioned.

It might have been --declarationMap, part of Typescript 2.9

https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...

Jumping to definition works with typescript projects correctly when this is turned on, but it's still not a solution for JS projects with definition files

Oh yeah.. In VS Code, where I wanted to go to the definition, and it took me to the Typescript file.. It's just insanely frustrating.

Your right it is the absolute worst possible behavior.

I get that information when I hover over the method/class/whatever.. I am looking up the definition because I want to see how this works.

...10x more frustrating when you see that there are >1 y old bug reports about this but it's always delegated as lower priority than smth else and after (I think, not sure anymore...) someone fixed some underlying functionality that was supposed to make this possible, the actual functionality of usable jump-to-implementation is still not fully implemented!

And I'm not saying that the devs don't care or not doing wonderful work... just that they've ended up with a codebase where something like this is genuinely hard to do.

And when they'll finally get it will still be frustrating as hell because >50% of the time it would jump to some unreadable transpiled code because there's no actual standardized way to jump to the original source the final js got transpiled from. In an ideal world, if some React component was written in OCaml mixed with Clojure and transpiled to JS, I'd want to be able to jump to the implementation into that actual original OCaml or Clojure code. But I get it, whoever would be smart enough to get that working reliably would probably make better use of their time trying to cure cancer or solve climate issues or go to Mars etc.

  </rant>

I'm not sure if this is positive or negative. But somehow more or less encouraged JavaScript community move towards:

1. Minimal interfaces 2. Better documentation

Say like React although the codebase is more or less difficult to read. But the most useful surface-level APIs are quite minimal and intuitive. There are more minimal libraries follow this pattern.

And for the documentation -- probably because of the minimal interfaces, successful JavaScript libraries tend to have better documentation over most of the languages. A lot of documentation with both quick start guide and great higher level design or motivation explanation, instead of just generating doc from comments.

I think that's why this community is moving fast forward because people trying to be communicative, and constantly trying to simplify and introducing new ideas. It's very hard for people just read the code to understand some brand new concepts without a good understanding of the high-level constructs.

..that's like saying: "We're proud to have the best the anti-suicide-by-jumping building meshes system and workplace psychiatric counseling in the world! The world record rate of suicide amongst our employees prompted us to implement and perfect this measures to such a high degree, that now we're considering to pivot our entire business model towards selling 'employee suicide prevention consulting services', since nobody has more experience than us with this!"

(But jokes aside, yeah, you're right, there's lots of JS libs with much nicer interfaces and docs than Python ones, I agree...)

This is a rather tasteless joke.

In retrospect I'd delete it if I could. I was imagining it inside a Dilbert cartoon in my head and it seemed funnier than it was. Again, I'm sorry for it, mental health issues are not a joke, I should know that. And I should also know that the tech community finds them less funny than others do, and for valid reasons.

(...hanging out with ppl from the healthcare field made me too used to cruel/gross/insensitive/politically-incorrect/borderline-sadistic jokes, always forget that the rest of the world is less desensitized to death and suffering than us :P)

This is so true. Written documentation explaining the intent of 3rd party libraries is crucial. Comments as documentation is horrible to work with!

That's a strong argument against using front-end frameworks and other things that require you to run a build on your front-end code.

There are plenty of options to build fast, modern front ends without having to deal with any of that.

And you're right about IDEs too. Given the choice between a full-blown VS.NET + ReSharper versus VSCode + $1,000 in my pocket, it's just no contest. No matter your bill rate, you still break even in single digit hours of productivity gain.

As a solo entrepreneur, it's even more of a no brainer, since it's my free time that I'm gaining by working with better tools.

> a strong argument against [...] things that require you to run a build on your front-end code

Not really, if it's your own code that requires a build step, then you control that build step and the tools and all and you can have nice auto-reload and fully working source maps and integration with all your other tools...

Do whatever exotic build and transpilation makes you more productive when developing your application's code. But libraries and frameworks... it's not OK to have a large part of the ecosystem dependent on such build tools and at the same time have no usable tooling standardization to easily implement something as basic as "jump to implementation in original source".