0

I'm watching a tutorial on TS. A few points the speaker said that I have questions about:

1) Mentioned that with TS you can now use Class Based Objects, weren't classes always available in JS? Besides not having to deal with prototypes in TS, what is the difference?

2) Used tsc <filename> and converted the TS file into the corresponding JS file, is this necessary for me to do for every TS file? Or is this just showing me what happens when it is converted?

mflow
  • 1
  • 5
  • 1) No, classes are NOT part of JavaScript and never have been. The difference is that having a `class` facade makes it easier for other programmers to use prototypal inheritance by abstracting away the details they don't care to know about. 2) TS is not understood by any JavaScript runtime engine. So yes, TS must be transpiled into JavaScript in order to work. – Randy Casburn Jul 02 '19 at 21:47
  • @RandyCasburn so me being able to define a `class Car { }` with a constructor doesn't count as a class in JS? – mflow Jul 02 '19 at 21:51
  • Nope! All that does is tell JavaScript to rewrite that bit of code into a normal constructor function with an assigned prototype. If you use the `extends` key word with your "_class_", it will create a prototype chain that includes the definition of the base "_class_". Make sense? – Randy Casburn Jul 02 '19 at 21:53
  • Hm I guess so, so defining a class in TS or in JS looks the same, just in TS, it's actually part of it and in JS it's not? – mflow Jul 02 '19 at 21:55
  • And for the 2) do I have to manually `tsc filename` each ts file to js before I can launch everything? – mflow Jul 02 '19 at 21:56
  • The way one "writes a class" in TypeScript is different than in JavaScript. TS allows member variables to be created outside the constructor function, where JS does not. Please read my comment to you on Mu-Tsun's answer below. That will help. – Randy Casburn Jul 02 '19 at 22:00
  • `tsc` is rarely used on a file-by-file basis for other than development purposes. Everyone relies on a build system to combine and package our source files together into a distribution bundle or package. So the `tsc` part is most often an automated process. – Randy Casburn Jul 02 '19 at 22:01
  • @RandyCasburn gotcha, makes sense, so this is more for my purpose and later when I'm ready to deploy, there's something that will transpile everything then – mflow Jul 02 '19 at 22:07
  • Exactly, and you'll have plenty of choices to help you package everything together. Focus more on the higher order tools like frameworks and libraries you want to use. They each will have their own way of buiding/packaging they will provide. – Randy Casburn Jul 02 '19 at 22:10

1 Answers1

1
  1. TS originally targets ES3, which doesn't have classes. Only ES6 and above have Class syntax, and still, those are not real classes in the sense of classical inheritance, but syntax bed sheet on top of prototypal inheritance. You can find more details in this question and this page.
  2. You must transpile TS into JS for it tor run; you can use the --outFile option to specify that you want to combine the output into just one file. See the official docs for more information.
Mu-Tsun Tsai
  • 2,348
  • 1
  • 12
  • 25
  • I'm not sure what you mean by that, I have seen in tutorials that TS is compatible with ES6 – mflow Jul 02 '19 at 21:51
  • @mflow - TypeScript is an extension to the JavaScript language. In this way, it enhances JavaScript with features the base language does not have. In this regard, TypeScript is no different that jQuery. But, since some of the features augment or change the structure of the language, it first must be transpiled back in the base language to work. – Randy Casburn Jul 02 '19 at 21:58
  • "those are not real classes" --- what is the officially accepted definition of the "real class"? – zerkms Jul 03 '19 at 04:12
  • @zerkms - split hairs? [The spec section on Objects](https://www.ecma-international.org/ecma-262/8.0/#sec-objects) pretty much takes care of that in terms of comparing to other OO constructs. Don't get too hung up on the word "real". Additionally, if you scan down to the definitions section you will not find the term "Class" defined in the spec. – Randy Casburn Jul 03 '19 at 05:17
  • 1
    @zerkms Let me rephrase that again; see if it's better now. – Mu-Tsun Tsai Jul 03 '19 at 05:20
  • "those are not real classes in the sense of classical inheritance" --- those are surely _real_ classes, it does not matter what mechanism is used under the hood, what matters is how you design your application using the tools you have. – zerkms Jul 03 '19 at 07:03
  • @RandyCasburn the `class` language construct semantics is defined at https://www.ecma-international.org/ecma-262/9.0/index.html#sec-class-definitions It says it's a class. It does not say it's "real" or "unreal" or "not real" or "not classical". It's a class. I'm using ES2015 since it was not even released, I've read the spec way too many times, and I **never** needed to refer to prototypal nature of JS classes implementations: design matters, not nit picking. Those who call "classes are not real" make harm to the JS development community. – zerkms Jul 03 '19 at 07:05
  • @zerkms - appreciate your passion on the subject. I agree with you, that from a 50,000 foot view, it sounds like a class is a class. Unfortunately, the implementation details tell a different story. – Randy Casburn Jul 03 '19 at 14:10
  • @zerkms - A "_class in the sense of classical inheritance_" is an in-memory construct that is placed into operation as a functional unit of software (that normally carries the functions on behalf of the instances). The classes are instantiated into objects that carry state while the class retains the functionality. In JavaScript, this does not exist. In JavaScript the source code (semantics you mention) is reformulated into constructor functions with all features being placed into an object (a function object specifically) prior to use. – Randy Casburn Jul 03 '19 at 14:11
  • @RandyCasburn why does it matter? For the last 5 years (I've been using ES2015 since it was draft) I **NEVER** needed to focus on its prototypal construct: for me it's a building block with functions, fields and that might be inherited. Why anything else matters to you? – zerkms Jul 03 '19 at 23:04
  • 1
    It doesn't to me - it matters to the question askers - the students who have professors asking them to learn the technical differences - the job interviewee who anticipates questions about the technical implementation details associated with these things. I am very pragmatic (as it sounds you are too) - from that perspective it is just a means to an end - I agree. But I don't believe we should live within the boundaries of our own assumptions. – Randy Casburn Jul 03 '19 at 23:07
  • @RandyCasburn this is an awesome comment, really :-) – zerkms Jul 03 '19 at 23:09