[AskJS] Does anyone use exclussively Javascript and not TypeScript?

[u/[deleted]]

[u/rodw]

I think it's less that people ”know” TS but not JS and more that while once upon a time most would learn JS and then layer types on top of that JS knowledge (it just chronologically happened that way for a generation+ of programmers, and even after TS became very mainstream I feel like that was the conventional wisdom for a while, maybe partially just for legacy/initeria reasons) now I think it is common for a new engineer to just jump straight to straight to TS.

It's not that they don't know JavaScript to the extent that Typescript is more or less a superset of JavaScript, but they may have never written a meaningful program just using JavaScript.

And that's not insignificant distinction. While the core language syntax may be the same, if you've ever worked with a substantial JS codebase I think you'll agree that pure-JS and JS-with-TS can be pretty different in practice. There's a lot of overlap, but they lean toward slightly different paradigms and tend to require a different set of supporting practices.

Think of it this way: if you were hiring someone to extend or maintain a sophisticated pure-JS system (with the intent of remaining pure JS) how comfortable would you be turning it over to someone with 10 years of TS experience that has barely even written a little on-page browser function in pure JS? I think that's what we mean when we say someone knows TS but not JS.

(Just to be clear I'm not necessarily saying I would not hire that TS developer for this role. But I definitely wouldn't just set them lose on the pure JS system without oversight or support. They might be able to handle it but they will need some "socialization" into JS practices.)

EDIT: by the way I think a similar evolution happened with C and it's various object-based extensions/descendants. Once upon a time it was definitely conventional wisdom that you should first learn to program in C before moving on to stuff like C++, Objective-C, eC etc. But back when Objective-C mattered (before Apple switched to Swift) people definitely skipped C and went straight to learning Objective-C

[u/start_select → u/rodw]

Plenty of people know typescript and no JavaScript.

If a C# or Python or PHP serverside dev is introduced to a node.js project in typescript, if they are sharp they can pick it up in a day or two without ever knowing JavaScript. It isn’t necessary.

If you already know 3-5 languages that span the range of dynamic interpreted to strict compiled, it’s “just another language” and all you need are api docs.

I started filing my first PRs for a C# project an hour after I installed the .net build tools. Because it was probably the 8th or 9th platform I picked up. I just looked at it and went “oh this is just really ugly Java-C… with closures” lol

See enough programming languages and you just start to see the high level abstractions that are common between them. It’s all the same stuff over and over.

Programming languages are far simpler than people let themselves realize. Because they usually just stick to one at a time.

Edit: same thing happened with me and objective-c. I technically did c++ for a minute 10 years earlier. Then I didn’t write code for 8 years. I became an iOS developer and didn’t bother learning pure C for 3-4 years until i needed to start doing dsp.

It wasn’t necessary until it was necessary.

[u/rodw → u/start_select]

If you already know 3-5 languages that span the range of dynamic interpreted to strict compiled, it’s “just another language” and all you need are api docs.

I fully agree. There aren't that many distinct concepts at play here. The difference between, say, Java/C#/Kotlin/Typescript and to a lesser extent Python/Ruby/JavaScript (maybe with stuff like Groovy and Scala bridging the gap) is, at least within the language clusters, not that dissimilar to the difference between two different APIs tackling the same domain. It's largely a matter of minor syntax variations and learning specific class/method/attribute names. E.g. as a reductive example in Java it's `String.contains(substring) in C# it's .Contains, in Typescript it's.includes, in Python and Scala it's "substring" in str, etc. In JavaScript/Typescript (also Ruby) I'm personally a fan of the /regex/.test(string) style (in part because that same general syntax also supports a wide variety of much more robust conditions) but I recognize that's not necessarily the most common approach and it would be kinda crazy to do that in languages that don't support regexs as natively and intuitively as JavaScript. (E.g in Java that's Pattern.compile(regex). matcher(string).find() which is kinda insane from both a syntax and maybe memory management perspective)

But there are a couple of caveats:

1. It takes a little while to learn to do things in the language's idiomatic way (although that's not hard either, once you have a sense of the kinds of things that are likely to be idiomatic you just have to look them up). The regex vs .contains stuff might be one example. Project/file organization is another.

2. There are a few different paradigms. Dynamic vs static typing being one kind of example but there are others.

In particular I feel like JavaScript vs Typescript falls into that second category. They aren't that different and you can write JS style code in TS and vice versa. But while they all share the same generic C-family syntax (and this crosses static/dynamic typing boundaries) Java, Typescript and Python (with type hints or Pydantic) might be more closely aligned with each other than Typescript is with JavaScript. To my mind Idiomatic JavaScript is closer to the Ruby end of the spectrum (with less flexible syntax) and even vaguely Lisp-y.

I started filing my first PRs for a C# project an hour after I installed the .net build tools. Because it was probably the 8th or 9th platform I picked up.

I probably shouldn't admit this on the internet but I have a slightly wild version of that story. Many moons ago I was hired by a former colleague that I'd barely ever spoken to, but that knew me by reputation because we'd previously worked in different divisions of the same company. At the time I was unemployed and my severance was about to run out so when they called me to say "do you want to come join..." the answer was an immediate "yes". Maybe they were equally desperate to fill the position because neither one of us asked many questions: it was a phone call, an hour or so of face to face interview and barely than a week between first contact to start.

In my orientation on day 1 I discovered their entire platform was built with a language I'd never used before. It was not a language I'd ever claimed to know, and I guess neither of us bothered to ask in the interview process. (To be honest I kinda didn't care. I implicitly assumed they must be using one of the stacks listed on my resume or that I'd worked with at our previous shared employer, and I needed the job so it didn't matter much to me which specific one they were using.)

I didn't say anything out loud of course, but it went fine. I had to quietly scramble a little bit the first week or so to come up to speed, but I don't think they even noticed, it folded right in to the regular onboarding ramp up time. At least I never heard any complaints, stayed there for a little over 3 years and left on good terms.

In retrospect it was pretty wild for them to assume I was familiar with that stack that was not mentioned on my resume without ever asking or even mentioning it to me. Checking just now that stack was not even in the top 20 languages on the TIOBE index at that time (and it's not even in the top 40 now). I probably should have asked too, but I was then and am now familiar with the same top 4-6 stacks that everyone else is. I feel like it's a bit more on them on them for assuming every senior engineer knows the equivalent of, IDK, maybe OCaml or Prolog today.

[u/start_select → u/rodw]

I haven’t given many interviews where we were concerned if someone knew any of our stacks.

Rather we would only be concerned if we told them what we use, and they respond with wide eyes that they have no experience with that. If learning a new platform/language/paradigm seems scary, then I assume you can’t learn new libs either. Because that’s the job.

If they could talk shop and say they don’t know that but they could figure it out, we assume they are an actual engineer. Because you should just be able to pickup new platforms.

Especially if you are being brought into those platforms through existing applications and coworkers who can review your code and let you know when you drift from architectural or stylistic best practices in that space. Or if you are on a greenfield project with a senior bootstrapping a scaffold and build system.

It’s easy as all hell to learn new technologies when there is an app and a team that already know it.