4 ms·

This is my favorite book about JS, and I always recommend it to people. It occurs to me for the first time that the lack of TypeScript might be a problem, becau

by dcre 3y ago

This is my favorite book about JS, and I always recommend it to people. It occurs to me for the first time that the lack of TypeScript might be a problem, because if I’m making recommendations to someone learning, I am definitely going to recommend they write TS instead of JS. On the other hand it may actually be helpful to learn the concepts in this book without the additional syntax overhead of type annotations, plus the more webby content doesn’t really have much to do with types anyway.

OmarShehata 3y ago
I very much concur that it is better NOT to introduce TS when explaining JS fundamentals. I've seen smart engineers with a C++ background get tripped up on and very confused working with TS, because it's not clear to them what concepts are "language fundamentals" and what concepts are "the TS transpiler". (Like expecting that just because you declared something as type X, that it guarantees at runtime it will always be type X, but it won't. You may get data from an API that _says_ it returns type X but the contents don't match. That can be valid code that compiles and has weird runtime behavior)
- lost_womble 3y ago
  Agree. I wish tools like zod/valibot were first class in typescript.
  - epolanski 3y ago
    Also effect schema if you're looking for something much more powerful and in effect-land.
- ayuhito 3y ago
  I wholeheartedly agree. At most, I introduce JSDoc[1] to newer developers as standardising how parameters and whatnot are commented at least gets you better documentation and some safety without adding any TS knowledge overhead. [1] https://jsdoc.app/ https://jsdoc.app/
- DarkNova6 3y ago
  What helped me understand the Runtime behaviour of TS is to understand that TS doesn't actually have strong typing. If it was named "LintScript", its name would be much closer to the truth.
  - steve_rambo 3y ago
    Do you mean runtime type checking? Coming from compiled type safe languages, it was difficult to wrap my head around full type erasure too. Your name would have definitely helped.
  - epolanski 3y ago
    This statement is quite questionable starting from the fact that there is no definition for what strong typing is. Care to provide what you mean? Strict TS won't compile pretty much any type-unsafe operation. It's not perfect, the standard libraries are a bit too unsafe type wise, exceptions are untyped and need Either/Result-like data types to be handled but it's an extremely powerful language if you know it and it's ecosystem. Most people though don't even bother reading the docs and can't tell you what a mapped type is or what is a disjointed union, etc.
    - DarkNova6 3y ago
      If you are in a completely self-defined world, then yes you can trust the compiler. But I once built a react component which was called from library code and it simply did not adhere to the method signature (this was for a material UI table extension). As soon as you have third party code calling your methods all bets are off. It could be JS calling your methods, or there simply is a hidden cast somewhere. This is the moment that you realize that type annotations really are just a compile-time fiction, much like Python. At least in my definition, this is weak typing as the variable is physically capable of changing to any type at runtime, despite its type annotations.
      - Shog9 3y ago
        TBF, this can also be true in C++, C#, probably most languages that can interoperate with other systems not written 100% in the same language + same runtime. After a while, you just get used to not trusting anything at the boundary - types are for your convenience and your internal logic, nothing more.
- myvoiceismypass 3y ago
  It is (or should be) common practice to parse/validate any external data you depend on. You should be doing this for Javascript too. I find that the library https://zod.dev/ https://zod.dev/ is quite helpful for this
- samtho 3y ago
  > I've seen smart engineers with a C++ background get tripped up on and very confused working with TS, because it's not clear to them what concepts are "language fundamentals" and what concepts are "the TS transpiler". This is exactly why I never recommend TypeScript to new developers. A similar problem (that used to be worse) with people learning JavaScript is the lack of separation between JavaScript and the DOM + browser APIs. 10+ years ago, people have told me how much they hated JavaScript and when probed about it further, would admit that it’s actually the DOM or new/inconsistent browser APIs that have caused issued. JS has a number of its own flaws and quirks, yes, but there are two fundamental issues that make it harder to approach as a new learner (as opposed to, to say, Python) are how tightly coupled it has historically been to it’s primarily application case and how high or low level is this language?
- preommr 3y ago
  > I've seen smart engineers with a C++ background get tripped up on and very confused working with TS, The idea that someone is good at another language so they'll automatically be good at another is a common misconception. In fact, they're likely to be worse because they're less likely to spend time trying to learn things from the ground up and less likely to write idiomatic code. It's especially bad with js/ts because of it's popularity (so lots of new programmers that complain about how NaN doesn't equal itself), and because it's the defacto web language so lots of people are forced to use it as a secondary language that don't want to spend time learning it.
  - pletnes 3y ago
    NaN doesn’t equal itself in any language I’m aware of, fwiw.
diggan 3y ago
> I am definitely going to recommend they write TS instead of JS Why is that? If you want them to learn JS, teach/recommend them to learn JS? Compile-to-JavaScript languages come and go, but JavaScript has remained. First learning vanilla JavaScript makes sense, and then add TS on top if you really have to. At the very least they'll be prepared for when TypeScript goes out of favor.
- epolanski 3y ago
  Because TypeScript is the de facto standard way of writing JavaScript for most of the industry and it has killed all of the other compile-to-js languages. The chances of it going out of favour are very slim, there's a giant ecosystem built on it and the language is very well loved by devs (should be second only to Rust). Microsoft has 50 people on payroll working only on TS. Any competitor needs a gargantuan investment.
  - whiterknight 3y ago
    And JavaScript has a bigger ecosystem and more entrenchment, not to mention an international standard.
    - epolanski 3y ago
      Not sure how's that relevant. Any valid JavaScript is valid TypeScript and you're gonna write and read TS anyway in the industry. They aren't in competition, but coming back to the first comment it sounds reasonable to start directly with TS for many users.
      - whiterknight 3y ago
        Your experience is not the industry. JS is widely used, almost certainly more than TS.
        epolanski 3y ago
        My experience may not, but the annual JS dev survey points that TS is the main way to write JS from years.
irrational 3y ago
It is useful to know vanilla JS. Right now I am learning an integration platform that uses JS for its scripting language, but you cannot use TS.
- synergy20 3y ago
  ts-node with ts can do script the same as node with js? surprised why TS can not be used as it's 'safer' for scripting.
deleted 3y ago
[deleted]
rglover 3y ago
It's better if they learn the core language and then graduate to TypeScript (if at all, as there's active discussion of adding type annotations to the core language [1]). An anecdote: I was sold a similar story on CoffeeScript back in the day, stressed myself out learning it, only to discard it a couple years later. TS won't have an identical fate as its shepherded by Microsoft, but eventually it will go the way of the dodo (whereas core JS will still be humming along). [1] https://youtu.be/SdV9Xy0E4CM?feature=shared&t=380 https://youtu.be/SdV9Xy0E4CM?feature=shared&t=380
- cdme 3y ago
  This was the approach one of my first mentors recommended and it's served me well. Learn the core language and its features and then add tools/frameworks as needed. Lately it feels like we're teaching new devs popular frameworks and completely ignoring the fundamentals.
  - linhns 3y ago
    Yep. But business requirements dictate what happens and these frameworks are the fastest way to achieve business goals, which sucks as when the frameworks lose their appeal, those devs are gonna struggle to transfer their skills to something else.

by dcre 3y ago

OmarShehata 3y ago

I very much concur that it is better NOT to introduce TS when explaining JS fundamentals. I've seen smart engineers with a C++ background get tripped up on and very confused working with TS, because it's not clear to them what concepts are "language fundamentals" and what concepts are "the TS transpiler". (Like expecting that just because you declared something as type X, that it guarantees at runtime it will always be type X, but it won't. You may get data from an API that _says_ it returns type X but the contents don't match. That can be valid code that compiles and has weird runtime behavior)

lost_womble 3y ago
Agree. I wish tools like zod/valibot were first class in typescript.
- epolanski 3y ago
  Also effect schema if you're looking for something much more powerful and in effect-land.
ayuhito 3y ago
I wholeheartedly agree. At most, I introduce JSDoc[1] to newer developers as standardising how parameters and whatnot are commented at least gets you better documentation and some safety without adding any TS knowledge overhead. [1] https://jsdoc.app/ https://jsdoc.app/
DarkNova6 3y ago
What helped me understand the Runtime behaviour of TS is to understand that TS doesn't actually have strong typing. If it was named "LintScript", its name would be much closer to the truth.
- steve_rambo 3y ago
  Do you mean runtime type checking? Coming from compiled type safe languages, it was difficult to wrap my head around full type erasure too. Your name would have definitely helped.
- epolanski 3y ago
  This statement is quite questionable starting from the fact that there is no definition for what strong typing is. Care to provide what you mean? Strict TS won't compile pretty much any type-unsafe operation. It's not perfect, the standard libraries are a bit too unsafe type wise, exceptions are untyped and need Either/Result-like data types to be handled but it's an extremely powerful language if you know it and it's ecosystem. Most people though don't even bother reading the docs and can't tell you what a mapped type is or what is a disjointed union, etc.
  - DarkNova6 3y ago
    If you are in a completely self-defined world, then yes you can trust the compiler. But I once built a react component which was called from library code and it simply did not adhere to the method signature (this was for a material UI table extension). As soon as you have third party code calling your methods all bets are off. It could be JS calling your methods, or there simply is a hidden cast somewhere. This is the moment that you realize that type annotations really are just a compile-time fiction, much like Python. At least in my definition, this is weak typing as the variable is physically capable of changing to any type at runtime, despite its type annotations.
    - Shog9 3y ago
      TBF, this can also be true in C++, C#, probably most languages that can interoperate with other systems not written 100% in the same language + same runtime. After a while, you just get used to not trusting anything at the boundary - types are for your convenience and your internal logic, nothing more.
myvoiceismypass 3y ago
It is (or should be) common practice to parse/validate any external data you depend on. You should be doing this for Javascript too. I find that the library https://zod.dev/ https://zod.dev/ is quite helpful for this
samtho 3y ago
> I've seen smart engineers with a C++ background get tripped up on and very confused working with TS, because it's not clear to them what concepts are "language fundamentals" and what concepts are "the TS transpiler". This is exactly why I never recommend TypeScript to new developers. A similar problem (that used to be worse) with people learning JavaScript is the lack of separation between JavaScript and the DOM + browser APIs. 10+ years ago, people have told me how much they hated JavaScript and when probed about it further, would admit that it’s actually the DOM or new/inconsistent browser APIs that have caused issued. JS has a number of its own flaws and quirks, yes, but there are two fundamental issues that make it harder to approach as a new learner (as opposed to, to say, Python) are how tightly coupled it has historically been to it’s primarily application case and how high or low level is this language?
preommr 3y ago
> I've seen smart engineers with a C++ background get tripped up on and very confused working with TS, The idea that someone is good at another language so they'll automatically be good at another is a common misconception. In fact, they're likely to be worse because they're less likely to spend time trying to learn things from the ground up and less likely to write idiomatic code. It's especially bad with js/ts because of it's popularity (so lots of new programmers that complain about how NaN doesn't equal itself), and because it's the defacto web language so lots of people are forced to use it as a secondary language that don't want to spend time learning it.
- pletnes 3y ago
  NaN doesn’t equal itself in any language I’m aware of, fwiw.

diggan 3y ago

> I am definitely going to recommend they write TS instead of JS Why is that? If you want them to learn JS, teach/recommend them to learn JS? Compile-to-JavaScript languages come and go, but JavaScript has remained. First learning vanilla JavaScript makes sense, and then add TS on top if you really have to. At the very least they'll be prepared for when TypeScript goes out of favor.

epolanski 3y ago
Because TypeScript is the de facto standard way of writing JavaScript for most of the industry and it has killed all of the other compile-to-js languages. The chances of it going out of favour are very slim, there's a giant ecosystem built on it and the language is very well loved by devs (should be second only to Rust). Microsoft has 50 people on payroll working only on TS. Any competitor needs a gargantuan investment.
- whiterknight 3y ago
  And JavaScript has a bigger ecosystem and more entrenchment, not to mention an international standard.
  - epolanski 3y ago
    Not sure how's that relevant. Any valid JavaScript is valid TypeScript and you're gonna write and read TS anyway in the industry. They aren't in competition, but coming back to the first comment it sounds reasonable to start directly with TS for many users.
    - whiterknight 3y ago
      Your experience is not the industry. JS is widely used, almost certainly more than TS.
      - epolanski 3y ago
        My experience may not, but the annual JS dev survey points that TS is the main way to write JS from years.

irrational 3y ago

It is useful to know vanilla JS. Right now I am learning an integration platform that uses JS for its scripting language, but you cannot use TS.

synergy20 3y ago
ts-node with ts can do script the same as node with js? surprised why TS can not be used as it's 'safer' for scripting.

deleted 3y ago

[deleted]

rglover 3y ago

It's better if they learn the core language and then graduate to TypeScript (if at all, as there's active discussion of adding type annotations to the core language [1]). An anecdote: I was sold a similar story on CoffeeScript back in the day, stressed myself out learning it, only to discard it a couple years later. TS won't have an identical fate as its shepherded by Microsoft, but eventually it will go the way of the dodo (whereas core JS will still be humming along). [1] https://youtu.be/SdV9Xy0E4CM?feature=shared&t=380 https://youtu.be/SdV9Xy0E4CM?feature=shared&t=380

cdme 3y ago
This was the approach one of my first mentors recommended and it's served me well. Learn the core language and its features and then add tools/frameworks as needed. Lately it feels like we're teaching new devs popular frameworks and completely ignoring the fundamentals.
- linhns 3y ago
  Yep. But business requirements dictate what happens and these frameworks are the fastest way to achieve business goals, which sucks as when the frameworks lose their appeal, those devs are gonna struggle to transfer their skills to something else.