8 ms·

Isn’t step 1 of “modern JavaScript” to install TypeScript? :)

by cgrealy 6y ago

halfmatthalfcat 6y ago
Amazing how many JS devs I meet (or work with) that are against the very idea of Typescript.
- DrScientist 6y ago
  Because it fails to meet the 'it's the platform stupid' maxim. ie languages aren't nearly quite so important as the platform. Stuff wasn't written in js because early js was a brilliant language - it was because the platform - the web - was brilliant. Many have written 'better' languages that compile to js - https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffeescript/wiki/List-of-langu... and while typescript is one of the better, more supported ones, isn't it just another one? Surely in the end it just adds complexity and fragmentation of the ecosystem?
  - rictic 6y ago
    Unlike other languages, typescript adds zero runtime overhead, and the APIs that one writes in TS are trivially consumable from JS. Consuming JS from TS is also made as easy as possible, including the option to set types aside entirely for some parts of your code using the "any" type, which means "don't type check this, just trust me that it works". TS really is different from other compile-to-js languages in this respect.
    - vorpalhex 6y ago
      It adds in developer overhead and for someone writing in JS that is often what you are trying to minimize.
      - the_af 6y ago
        Doesn't plain JS add developer overhead in the form of bugs and code the team doesn't understand a few weeks or months later?
      - com2kid 6y ago
        It adds overhead on initial write, saves massive overhead every day after that. There is JS code I deal with once a month where the manipulation of types is so complex I probably burn ~30 minutes every time I have to touch it. If that was was transformed into TS (which is going to happen eventually) that'd be 30 minutes saved per month, on this one particular flow of data. I've done refactorings that were only possible because TS existed. A lot of JS unit tests consist of "ensure these fields exist on this object after it has been called by these functions." Typescript removes the need for those tests. And it removes the need to update those tests every time the code changes (just change the declarations appropriately!). And it removes the need to run those tests on every commit. That said, the overall code/compile/run time savings is possibly not in TS's favor due to how slow the compiler is. :/
      - throw_m239339 6y ago
        > It adds in developer overhead and for someone writing in JS that is often what you are trying to minimize. Typescript compiler supports (some) JS DOC https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported... So you can use the compiler as a static analysis tool without buying into the language itself completely, which I do and just stick type definitions to comments when needed.
    - DrScientist 6y ago
      As I said, it's not a bad attempt, and it's presence has probably given renewed impetus to js lang improvements. Though the attempts at close compatibility mean it's not properly type safe despite it's name. In the end, it's still a 'splitter' to quote Monty Python.
      - rictic 6y ago
        > Though the attempts at close compatibility mean it's not properly type safe despite its name. Every type checked language I've used, from Haskell to Java to Idris to C++ to Rust has ways to override the type checker (and either do the type checking at runtime, or, as C++ is often want to do, just YOLO it). It's not just the language but the codebase and the norms it and its dependencies use. Some TypeScript codebases, the types are usually accurate, but not enough to rely on them, so you still need to do runtime checks in many places. In others, if something says (string|null) then you know with confidence that it is either a string or the null value, nothing more and nothing less.
  - hn_throwaway_99 6y ago
    > Surely in the end it just adds complexity and fragmentation of the ecosystem? Lol. I switched to TS from pure JS a couple years ago and could never imagine going back. I am so much more productive in TS than JS: 1. Typeahead is crucial, and even when just working on my own projects it makes me much faster. 2. Refactoring is a scary nightmare in pure JS, but so much easier with TS. 3. I have yet to see any sizable, multi-person pure JS project not become an incomprehensible nightmare after a couple years. TS makes large codebases much easier to maintain. There are other reasons. If anything, the consolidation onto TS from previous competing type systems for JS (e.g. I think Flow is dead for all intents and purposes, and I've seen a number of projects migrate onto TS from Flow) results in less fragmentation.
    - DrScientist 6y ago
      I understand the power of types - I just wonder why the heck you are writing so much JS/TS code? Are you doing server stuff with it? You could argue here there are much better languages and platforms for that.
      - halfmatthalfcat 6y ago
        Have you seen the size of frontend codebases? Even modest SPAs reach into the tens of thousands of lines. Or the size of large Express.js driven backends? A huge portion of the web is driven by JS/TS.
        at-fates-hands 6y ago
        >> Even modest SPAs reach into the tens of thousands of lines. I still don't get how we got from fifty lines of code for a form with simple client side validation to a React/Vue/Angular/Next version that needs 100 different modules and a thousand lines of code to replicate. Why do people see this as a huge advancement in front-end development?
        halfmatthalfcat 6y ago
  - Ankintol 6y ago
    I think many JS developers are also somewhat blind to the breadth of types of sites that are written, and so don't understand how valuable a type system can be on the web. Most websites are what I'd call "broad and shallow". For any individual action the corresponding code path is small. Most code in these sites is easy to write and easy to debug in vanilla JS. Typescript adds boilerplate and compiler times for type safety the development team was doing fine without. However there are some sites, usually very complex SPAs, that are necessarily "deep". Even small user actions absolutely must cause >10k lines of code to run. Type systems are often very valuable for the development of such sites. It's my experience that some developers who've only ever worked on "broad and shallow" sites fail to appreciate what a time saver a type system can be for the right "deep" website.
    - DrScientist 6y ago
      I'd guess I'd have to question why you need 10K lines of code for a single web page - perhaps you need to break up your SPA?
      - jefftk 6y ago
        Do you think the Zoom web client should have fewer than 10k lines? Or be broken up? What about Google Docs?
        DrScientist 6y ago
        Aren't those the exception and not the rule. Hence the statement modern web = ts is wrong. Personally I used the zoom native client and not the web one. I spend most of my time in offline office and not the web version
        jefftk 6y ago
        > I used the zoom native client and not the web one You might want to reconsider that; they have a pretty bad security track record: https://www.securemac.com/news/zoom-security-flaw-puts-you-at-risk-even-after-you-uninstall https://www.securemac.com/news/zoom-security-flaw-puts-you-a... https://talosintelligence.com/vulnerability_reports/TALOS-2020-1055 https://talosintelligence.com/vulnerability_reports/TALOS-20... https://talosintelligence.com/vulnerability_reports/TALOS-2020-1056 https://talosintelligence.com/vulnerability_reports/TALOS-20... https://blog.0patch.com/2020/07/remote-code-execution-vulnerability-in.html https://blog.0patch.com/2020/07/remote-code-execution-vulner...
  - eyelidlessness 6y ago
    Hardly just another one, and hardly fragmenting. It’s absorbed the vast majority of effort previously dedicated to Flow (the fragment in its own target space), and has continually gained in the JS community proper. It’s not just (or intended to be) a “compile to JS” language, it’s (almost) just annotated JS where the annotations provide additional tooling value. The resistance in the JS community isn’t to “yet another language”, it’s to the perceived complexity of TS strictness/appeasing the compiler. I’m saying this not based on polling so obviously take it with a grain of salt, but I routinely search Twitter, GitHub and rando blogs for TS content and that sentiment represents nearly 100% of the anti-TS content I encounter. And largely I find that in React-focused communities. Which having spent the last several years using TS on Node in production, and the last couple months working on a web project in React, it’s not remotely surprising. React and many libraries built on it have ridiculously complex types. That’s not because of TS but interacting with and satisfying those types at compile time is extremely frustrating even to me as a seasoned TS dev who has built libraries that take advantage of many advanced features in the type system (I just don’t expose that complexity to the API consumer).
    - pault 6y ago
      Front end library type definitions are a nightmare because they are usually retrofitted onto code that uses JavaScript idioms that take heavy advantage of metaprogramming and it's dynamic nature. It's also compounded (in my opinion) by developers that insist on making everything inferable instead of just putting a few generic parameters here and there and saving an enormous amount of complexities. Native typescript libraries are generally extremely easy to work with, however.
- auganov 6y ago
  Pretty annoyed with Typescript too. Mostly because of its popularity. Before Typescript most compile-to-js languages existed in their own world. You might have not liked them. But you'd never have to deal with them. Typescript has become so popular that many top javascript libraries use it too. Whatever you think of it, sooner or later you'll be working with Typescript code.
  - sundarurfriend 6y ago
    This is pretty much how I feel about Javascript itself.
  - DenverCode 6y ago
    You mean you didn't love Coffeescript? (I'm joking)
  - Existenceblinks 6y ago
    Related. I'm dealing a lib that says Typescript is optional, but we give you lots of boilerplate if you don't use it.
- vorpalhex 6y ago
  It's terrible. The amazing issues that TS can introduce to a codebase are terrifying, and TS has breaking releases on a regular cadence. As someone who has to do maintenance on a legacy TS platform it was miserable and literally involved flipping through TS versions to find one that worked. My issues are not with strongly typed languages, they're specifically with TS.
  - deleted 6y ago
    [deleted]
  - names_are_hard 6y ago
    What issues does TS introduce into a codebase that weren't already there? This sounds kinda like arguing that if we write fewer tests we'll have fewer bugs.
    - moron4hire 6y ago
      Getting a configuration together that consumes all your dependencies and generates code without crapping a ton of meaningless warnings about duplicate type definitions in its own type mappings for runtime types is non-trivial and requires setting more than a few non-default compiler options, none of which are named anything that means anything. I still don't know how it's possible to safely, cleanly make a library that other projects can consume comfortably with just TypeScript.
    - fogetti 6y ago
      In our case: 1) slow and long transpilation times, 2) although not that common these days but missing typings used to cause some head scratch 3) overly permissive/overly restrictive type definitions 4) wrongly configured sourcemaps 5) unreadable type definitions/declarations... The list is long but these are off the top of my head
- _greim_ 6y ago
  I've been thinking a lot about why this is, and I think one reason is because TS adds mental overhead to the language, while simultaneously removing other mental overhead. However, for JS programmers, worrying about types is habitual. Offloading that task to a robot is great, but it doesn't mean the habit will just disappear. Thus to them, TS seems to mainly add overhead.
  - letitbeirie 6y ago
    > for JS programmers, worrying about types is habitual Couldn't the same be said for COBOL programmes and GOTOs?
    - _greim_ 6y ago
      Yeah I guess I'd generalize it as programming having two kinds of learning. First is memorization of syntax and semantics of the language. Second is a kind of shadow learning, or "street smarts" for survival in the language; which parts of town to avoid and which paths avoid dark alleys, etc. These habits are hard to quantify, and beginner programmers especially tend to apply the "street smarts" from their first language to every future language, which creates problems.
- tambourine_man 6y ago
  Hi there.
- tenaciousDaniel 6y ago
  I've spent enough time converting nearly illegible coffee script back to JS that I didn't want to do it again. I believe TS has its has benefits, I just don't care.
- heavyset_go 6y ago
  I get CoffeeScript vibes from TypeScript, and look at where CoffeScript is now.
  - sanderjd 6y ago
    I don't get this. What do you mean by coffeescript vibes? They are super different languages...
    - heavyset_go 6y ago
      In that JavaScript only needs to adopt a few of its features for the benefits of welding yet another compiles-to-JS toolchain on to projects to dwindle in comparison to writing ES8+.
      - Vinnl 6y ago
        The difference between CoffeeScript and TypeScript was that CoffeeScript offered syntax that people preferred, whereas TypeScript provides write-time checking of errors. It is more similar to ESLint in that regard, and is better understood as a linter than as a separate language like CoffeeScript. Even if TS's type annotations would be added to the language (like it practically almost has been, through Babel supporting it), you'd still want to run a tool as you write it to actually check that those annotations are adhered to, rather than having your code crash on the user when they are not. TypeScript is that tool.
      - z3t4 6y ago
        Adding optional type annotations to JS would be interesting. It might help with VM optimization.
        heavyset_go 6y ago
        Python already does type annotations, and I have no use for Mypy other than using it for type checking in my editors via LSP. I don't import it or use it as a dependency at all in projects. I feel like JavaScript adopting type annotations in a similar manner will make TypeScript look the same as Mypy in many regards: nice to have, but not necessary most of the time because the parent language ships with most of its features.
- jedimastert 6y ago
  I'm not against the idea of typescript as I'd just rather not have a compile step.
brundolf 6y ago
For real projects, but for someone just getting started I think it makes a lot of sense to start with core language fundamentals (I notice that, at least from the table of contents, there was no mention of build systems or frameworks either). Lots of newly-minted JS devs today know relatively little about what it means to use plain JS, which means they don't have as much perspective on what their TypeScript and JSX actually turn into, which has a meaningful effect on informing decisions.
jerrygoyal 6y ago
and step 2: install prettier, step 3: eslint plugins.
bob1029 6y ago
I was half expecting the first page to explain what nodejs is and how to install it. Pleasantly surprised by most of this.

Isn’t step 1 of “modern JavaScript” to install TypeScript? :)

halfmatthalfcat 6y ago

Amazing how many JS devs I meet (or work with) that are against the very idea of Typescript.

DrScientist 6y ago
Because it fails to meet the 'it's the platform stupid' maxim. ie languages aren't nearly quite so important as the platform. Stuff wasn't written in js because early js was a brilliant language - it was because the platform - the web - was brilliant. Many have written 'better' languages that compile to js - https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffeescript/wiki/List-of-langu... and while typescript is one of the better, more supported ones, isn't it just another one? Surely in the end it just adds complexity and fragmentation of the ecosystem?
- rictic 6y ago
  Unlike other languages, typescript adds zero runtime overhead, and the APIs that one writes in TS are trivially consumable from JS. Consuming JS from TS is also made as easy as possible, including the option to set types aside entirely for some parts of your code using the "any" type, which means "don't type check this, just trust me that it works". TS really is different from other compile-to-js languages in this respect.
  - vorpalhex 6y ago
    It adds in developer overhead and for someone writing in JS that is often what you are trying to minimize.
    - the_af 6y ago
      Doesn't plain JS add developer overhead in the form of bugs and code the team doesn't understand a few weeks or months later?
    - com2kid 6y ago
      It adds overhead on initial write, saves massive overhead every day after that. There is JS code I deal with once a month where the manipulation of types is so complex I probably burn ~30 minutes every time I have to touch it. If that was was transformed into TS (which is going to happen eventually) that'd be 30 minutes saved per month, on this one particular flow of data. I've done refactorings that were only possible because TS existed. A lot of JS unit tests consist of "ensure these fields exist on this object after it has been called by these functions." Typescript removes the need for those tests. And it removes the need to update those tests every time the code changes (just change the declarations appropriately!). And it removes the need to run those tests on every commit. That said, the overall code/compile/run time savings is possibly not in TS's favor due to how slow the compiler is. :/
    - throw_m239339 6y ago
      > It adds in developer overhead and for someone writing in JS that is often what you are trying to minimize. Typescript compiler supports (some) JS DOC https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported... So you can use the compiler as a static analysis tool without buying into the language itself completely, which I do and just stick type definitions to comments when needed.
  - DrScientist 6y ago
    As I said, it's not a bad attempt, and it's presence has probably given renewed impetus to js lang improvements. Though the attempts at close compatibility mean it's not properly type safe despite it's name. In the end, it's still a 'splitter' to quote Monty Python.
    - rictic 6y ago
      > Though the attempts at close compatibility mean it's not properly type safe despite its name. Every type checked language I've used, from Haskell to Java to Idris to C++ to Rust has ways to override the type checker (and either do the type checking at runtime, or, as C++ is often want to do, just YOLO it). It's not just the language but the codebase and the norms it and its dependencies use. Some TypeScript codebases, the types are usually accurate, but not enough to rely on them, so you still need to do runtime checks in many places. In others, if something says (string|null) then you know with confidence that it is either a string or the null value, nothing more and nothing less.
- hn_throwaway_99 6y ago
  > Surely in the end it just adds complexity and fragmentation of the ecosystem? Lol. I switched to TS from pure JS a couple years ago and could never imagine going back. I am so much more productive in TS than JS: 1. Typeahead is crucial, and even when just working on my own projects it makes me much faster. 2. Refactoring is a scary nightmare in pure JS, but so much easier with TS. 3. I have yet to see any sizable, multi-person pure JS project not become an incomprehensible nightmare after a couple years. TS makes large codebases much easier to maintain. There are other reasons. If anything, the consolidation onto TS from previous competing type systems for JS (e.g. I think Flow is dead for all intents and purposes, and I've seen a number of projects migrate onto TS from Flow) results in less fragmentation.
  - DrScientist 6y ago
    I understand the power of types - I just wonder why the heck you are writing so much JS/TS code? Are you doing server stuff with it? You could argue here there are much better languages and platforms for that.
    - halfmatthalfcat 6y ago
      Have you seen the size of frontend codebases? Even modest SPAs reach into the tens of thousands of lines. Or the size of large Express.js driven backends? A huge portion of the web is driven by JS/TS.
      - at-fates-hands 6y ago
        >> Even modest SPAs reach into the tens of thousands of lines. I still don't get how we got from fifty lines of code for a form with simple client side validation to a React/Vue/Angular/Next version that needs 100 different modules and a thousand lines of code to replicate. Why do people see this as a huge advancement in front-end development?
        halfmatthalfcat 6y ago
- Ankintol 6y ago
  I think many JS developers are also somewhat blind to the breadth of types of sites that are written, and so don't understand how valuable a type system can be on the web. Most websites are what I'd call "broad and shallow". For any individual action the corresponding code path is small. Most code in these sites is easy to write and easy to debug in vanilla JS. Typescript adds boilerplate and compiler times for type safety the development team was doing fine without. However there are some sites, usually very complex SPAs, that are necessarily "deep". Even small user actions absolutely must cause >10k lines of code to run. Type systems are often very valuable for the development of such sites. It's my experience that some developers who've only ever worked on "broad and shallow" sites fail to appreciate what a time saver a type system can be for the right "deep" website.
  - DrScientist 6y ago
    I'd guess I'd have to question why you need 10K lines of code for a single web page - perhaps you need to break up your SPA?
    - jefftk 6y ago
      Do you think the Zoom web client should have fewer than 10k lines? Or be broken up? What about Google Docs?
      - DrScientist 6y ago
        Aren't those the exception and not the rule. Hence the statement modern web = ts is wrong. Personally I used the zoom native client and not the web one. I spend most of my time in offline office and not the web version
        jefftk 6y ago
        > I used the zoom native client and not the web one You might want to reconsider that; they have a pretty bad security track record: https://www.securemac.com/news/zoom-security-flaw-puts-you-at-risk-even-after-you-uninstall https://www.securemac.com/news/zoom-security-flaw-puts-you-a... https://talosintelligence.com/vulnerability_reports/TALOS-2020-1055 https://talosintelligence.com/vulnerability_reports/TALOS-20... https://talosintelligence.com/vulnerability_reports/TALOS-2020-1056 https://talosintelligence.com/vulnerability_reports/TALOS-20... https://blog.0patch.com/2020/07/remote-code-execution-vulnerability-in.html https://blog.0patch.com/2020/07/remote-code-execution-vulner...
- eyelidlessness 6y ago
  Hardly just another one, and hardly fragmenting. It’s absorbed the vast majority of effort previously dedicated to Flow (the fragment in its own target space), and has continually gained in the JS community proper. It’s not just (or intended to be) a “compile to JS” language, it’s (almost) just annotated JS where the annotations provide additional tooling value. The resistance in the JS community isn’t to “yet another language”, it’s to the perceived complexity of TS strictness/appeasing the compiler. I’m saying this not based on polling so obviously take it with a grain of salt, but I routinely search Twitter, GitHub and rando blogs for TS content and that sentiment represents nearly 100% of the anti-TS content I encounter. And largely I find that in React-focused communities. Which having spent the last several years using TS on Node in production, and the last couple months working on a web project in React, it’s not remotely surprising. React and many libraries built on it have ridiculously complex types. That’s not because of TS but interacting with and satisfying those types at compile time is extremely frustrating even to me as a seasoned TS dev who has built libraries that take advantage of many advanced features in the type system (I just don’t expose that complexity to the API consumer).
  - pault 6y ago
    Front end library type definitions are a nightmare because they are usually retrofitted onto code that uses JavaScript idioms that take heavy advantage of metaprogramming and it's dynamic nature. It's also compounded (in my opinion) by developers that insist on making everything inferable instead of just putting a few generic parameters here and there and saving an enormous amount of complexities. Native typescript libraries are generally extremely easy to work with, however.
auganov 6y ago
Pretty annoyed with Typescript too. Mostly because of its popularity. Before Typescript most compile-to-js languages existed in their own world. You might have not liked them. But you'd never have to deal with them. Typescript has become so popular that many top javascript libraries use it too. Whatever you think of it, sooner or later you'll be working with Typescript code.
- sundarurfriend 6y ago
  This is pretty much how I feel about Javascript itself.
- DenverCode 6y ago
  You mean you didn't love Coffeescript? (I'm joking)
- Existenceblinks 6y ago
  Related. I'm dealing a lib that says Typescript is optional, but we give you lots of boilerplate if you don't use it.
vorpalhex 6y ago
It's terrible. The amazing issues that TS can introduce to a codebase are terrifying, and TS has breaking releases on a regular cadence. As someone who has to do maintenance on a legacy TS platform it was miserable and literally involved flipping through TS versions to find one that worked. My issues are not with strongly typed languages, they're specifically with TS.
- deleted 6y ago
  [deleted]
- names_are_hard 6y ago
  What issues does TS introduce into a codebase that weren't already there? This sounds kinda like arguing that if we write fewer tests we'll have fewer bugs.
  - moron4hire 6y ago
    Getting a configuration together that consumes all your dependencies and generates code without crapping a ton of meaningless warnings about duplicate type definitions in its own type mappings for runtime types is non-trivial and requires setting more than a few non-default compiler options, none of which are named anything that means anything. I still don't know how it's possible to safely, cleanly make a library that other projects can consume comfortably with just TypeScript.
  - fogetti 6y ago
    In our case: 1) slow and long transpilation times, 2) although not that common these days but missing typings used to cause some head scratch 3) overly permissive/overly restrictive type definitions 4) wrongly configured sourcemaps 5) unreadable type definitions/declarations... The list is long but these are off the top of my head
_greim_ 6y ago
I've been thinking a lot about why this is, and I think one reason is because TS adds mental overhead to the language, while simultaneously removing other mental overhead. However, for JS programmers, worrying about types is habitual. Offloading that task to a robot is great, but it doesn't mean the habit will just disappear. Thus to them, TS seems to mainly add overhead.
- letitbeirie 6y ago
  > for JS programmers, worrying about types is habitual Couldn't the same be said for COBOL programmes and GOTOs?
  - _greim_ 6y ago
    Yeah I guess I'd generalize it as programming having two kinds of learning. First is memorization of syntax and semantics of the language. Second is a kind of shadow learning, or "street smarts" for survival in the language; which parts of town to avoid and which paths avoid dark alleys, etc. These habits are hard to quantify, and beginner programmers especially tend to apply the "street smarts" from their first language to every future language, which creates problems.
tambourine_man 6y ago
Hi there.
tenaciousDaniel 6y ago
I've spent enough time converting nearly illegible coffee script back to JS that I didn't want to do it again. I believe TS has its has benefits, I just don't care.
heavyset_go 6y ago
I get CoffeeScript vibes from TypeScript, and look at where CoffeScript is now.
- sanderjd 6y ago
  I don't get this. What do you mean by coffeescript vibes? They are super different languages...
  - heavyset_go 6y ago
    In that JavaScript only needs to adopt a few of its features for the benefits of welding yet another compiles-to-JS toolchain on to projects to dwindle in comparison to writing ES8+.
    - Vinnl 6y ago
      The difference between CoffeeScript and TypeScript was that CoffeeScript offered syntax that people preferred, whereas TypeScript provides write-time checking of errors. It is more similar to ESLint in that regard, and is better understood as a linter than as a separate language like CoffeeScript. Even if TS's type annotations would be added to the language (like it practically almost has been, through Babel supporting it), you'd still want to run a tool as you write it to actually check that those annotations are adhered to, rather than having your code crash on the user when they are not. TypeScript is that tool.
    - z3t4 6y ago
      Adding optional type annotations to JS would be interesting. It might help with VM optimization.
      - heavyset_go 6y ago
        Python already does type annotations, and I have no use for Mypy other than using it for type checking in my editors via LSP. I don't import it or use it as a dependency at all in projects. I feel like JavaScript adopting type annotations in a similar manner will make TypeScript look the same as Mypy in many regards: nice to have, but not necessary most of the time because the parent language ships with most of its features.
jedimastert 6y ago
I'm not against the idea of typescript as I'd just rather not have a compile step.

brundolf 6y ago

For real projects, but for someone just getting started I think it makes a lot of sense to start with core language fundamentals (I notice that, at least from the table of contents, there was no mention of build systems or frameworks either). Lots of newly-minted JS devs today know relatively little about what it means to use plain JS, which means they don't have as much perspective on what their TypeScript and JSX actually turn into, which has a meaningful effect on informing decisions.

jerrygoyal 6y ago

and step 2: install prettier, step 3: eslint plugins.

bob1029 6y ago

I was half expecting the first page to explain what nodejs is and how to install it. Pleasantly surprised by most of this.