Why does TypeScript have be the answer to anything? • Hacker News Board

Re: Why does TypeScript have be the answer to anything?

#11

Post by asher_ » Tue, Oct 02, 2012, 2:53 PM UTC

Me1000 wrote: post #6

nahname wrote: post #5

I have to build my entire project every time I want to update my client side code? That is an enormous tax to charge the developer just to add static typing to your client side code. I can't see this doing anything but slowing a team down.

Anyone building large projects do this anyway, using minifiers to reduce the download size. Sometimes the code has inline documentation which gets built too. A build step is already a reality for many people writing JS today.

This isn't really a fair comparison. You can use unminified, commented javascript in development for testing without a build step, and just build for production.

Even so, a build step can be a single keypress, so its no big deal.

Re: Why does TypeScript have be the answer to anything?

#12

Post by benatkin » Tue, Oct 02, 2012, 2:57 PM UTC

The author ignores the fact that TypeScript is being heavily promoted by Microsoft. TypeScript isn't an experiment, but something Microsoft is trying to sell, along with their IDE. He starts it with a quote from a colleague rather than citing examples of people attacking TypeScript, as if it's a forgone conclusion that people have gone overboard on attacking it. I hate to see an argument for a programming language start with the author's persecution complex.

Re: Why does TypeScript have be the answer to anything?

#13

Post by MatthewPhillips » Tue, Oct 02, 2012, 2:58 PM UTC

asher_ wrote: post #11

Me1000 wrote: post #6

Earlier quoted context omitted.

Anyone building large projects do this anyway, using minifiers to reduce the download size. Sometimes the code has inline documentation which gets built too. A build step is already a reality for many people writing JS today.

This isn't really a fair comparison. You can use unminified, commented javascript in development for testing without a build step, and just build for production. Even so, a build step can be a single keypress, so its no big deal.

I don't know about you, but to me once a code file is larger than say a couple hundred lines it becomes exponentially less readable. So any non-trivial amount of JavaScript already includes a concatenation build step anyways, even for development. As long as the TypeScript compiler is reasonably fast on larger (10k LOC) projects, it wouldn't be any issue at all.

Re: Why does TypeScript have be the answer to anything?

#14

Post by dreamdu5t » Tue, Oct 02, 2012, 3:02 PM UTC

ivanjovanovic wrote: post #2

The way I see it: 1. TypeScript is an answer to the poor state of JavaScript development today and an attempt to get more structure into it. There are other answers as well, and it can be discussed on properties of each of them, but they are competing in the same domain. 2. Since state of JavaScript is as it is, it is obvious that there is a lot of potential benefit in being a leader of the technology in that domain.…

Poor state of JavaScript development? By what measure?

I've been doing "application-scale" development using JavaScript for 5 years... Not once did I think "gee my development process would be better if I had rigid typing." The notion is laughable.

The lack of rigid typing and classes is by design. This is a feature not a bug. I honestly wonder about a programmer's understanding of JavaScript if they say things like "JS lacks classes!" - I'm not sure they understand JavaScript.

Re: Why does TypeScript have be the answer to anything?

#15

Post by grayrest » Tue, Oct 02, 2012, 3:02 PM UTC

MatthewPhillips wrote: post #3

I agree with this. If it's nothing more than a forward-compatible superset of JavaScript, with optional static typing, it has a place in the world of JS target languages.

I'm not sold on forward compat. I'm only an interested observer of TC39 but to my knowledge only arrow lambdas and modules (the cross file ones) are near consensus. The rest of the features added have either been going around for a long time or haven't really gotten a lot of discussion.

Re: Why does TypeScript have be the answer to anything?

#16

Post by Me1000 » Tue, Oct 02, 2012, 3:02 PM UTC

asher_ wrote: post #11

Me1000 wrote: post #6

Earlier quoted context omitted.

Anyone building large projects do this anyway, using minifiers to reduce the download size. Sometimes the code has inline documentation which gets built too. A build step is already a reality for many people writing JS today.

This isn't really a fair comparison. You can use unminified, commented javascript in development for testing without a build step, and just build for production. Even so, a build step can be a single keypress, so its no big deal.

If there doesn't already exist a tool that watches your working directory for file changes and automatically recompiles, it will soon.

There are plenty of people who actively have build steps for web development: SASS, Less, CoffeeScript, CSS.

Re: Why does TypeScript have be the answer to anything?

#17

Post by oinksoft » Tue, Oct 02, 2012, 3:09 PM UTC

MatthewPhillips wrote: post #13

asher_ wrote: post #11

Earlier quoted context omitted.

This isn't really a fair comparison. You can use unminified, commented javascript in development for testing without a build step, and just build for production. Even so, a build step can be a single keypress, so its no big deal.

I don't know about you, but to me once a code file is larger than say a couple hundred lines it becomes exponentially less readable. So any non-trivial amount of JavaScript already includes a concatenation build step anyways, even for development. As long as the TypeScript compiler is reasonably fast on larger (10k LOC) projects, it wouldn't be any issue at all.

This is a moot point. The Closure Compiler supports dependency resolution so that you can unit test your code without building the full project. So, if I am testing foo.bar.Baz, I can create a file that only includes `base.js' and a goog.require('foo.bar.Baz'); call, and `base.js' will include all of its dependencies, in most cases fairly quickly.

Unless you are performing integration tests, there is no reason to compile each time. Doing that is just the legacy of limited build systems.

Re: Why does TypeScript have be the answer to anything?

#18

Post by ajanuary » Tue, Oct 02, 2012, 3:11 PM UTC

dreamdu5t wrote: post #14

ivanjovanovic wrote: post #2

The way I see it: 1. TypeScript is an answer to the poor state of JavaScript development today and an attempt to get more structure into it. There are other answers as well, and it can be discussed on properties of each of them, but they are competing in the same domain. 2. Since state of JavaScript is as it is, it is obvious that there is a lot of potential benefit in being a leader of the technology in that domain.…

Poor state of JavaScript development? By what measure? I've been doing "application-scale" development using JavaScript for 5 years... Not once did I think "gee my development process would be better if I had rigid typing." The notion is laughable. The lack of rigid typing and classes is by design. This is a feature not a bug. I honestly wonder about a programmer's understanding of JavaScript if they say things like…

The type system in TypeScript isn't 'rigid'. It's both optional and structural. These combine to make it a heck of a lot more lightweight than something like C++ or Java.

The classes in TypeScript are a formalisation of a very common design pattern in Javascript, so obviously people do think it's useful. TypeScript takes the common practice and makes it more succinct. (Other than inheritance, which does seem a little un-JSy)

Re: Why does TypeScript have be the answer to anything?

#19

Post by MatthewPhillips » Tue, Oct 02, 2012, 3:15 PM UTC

oinksoft wrote: post #17

MatthewPhillips wrote: post #13

Earlier quoted context omitted.

I don't know about you, but to me once a code file is larger than say a couple hundred lines it becomes exponentially less readable. So any non-trivial amount of JavaScript already includes a concatenation build step anyways, even for development. As long as the TypeScript compiler is reasonably fast on larger (10k LOC) projects, it wouldn't be any issue at all.

This is a moot point. The Closure Compiler supports dependency resolution so that you can unit test your code without building the full project. So, if I am testing foo.bar.Baz, I can create a file that only includes `base.js' and a goog.require('foo.bar.Baz'); call, and `base.js' will include all of its dependencies, in most cases fairly quickly. Unless you are performing integration tests, there is no reason to com…

Does goog.require() resolve at run time or compile time?

Re: Why does TypeScript have be the answer to anything?

#20

Post by oinksoft » Tue, Oct 02, 2012, 3:19 PM UTC

dreamdu5t wrote: post #14

ivanjovanovic wrote: post #2

The way I see it: 1. TypeScript is an answer to the poor state of JavaScript development today and an attempt to get more structure into it. There are other answers as well, and it can be discussed on properties of each of them, but they are competing in the same domain. 2. Since state of JavaScript is as it is, it is obvious that there is a lot of potential benefit in being a leader of the technology in that domain.…

Poor state of JavaScript development? By what measure? I've been doing "application-scale" development using JavaScript for 5 years... Not once did I think "gee my development process would be better if I had rigid typing." The notion is laughable. The lack of rigid typing and classes is by design. This is a feature not a bug. I honestly wonder about a programmer's understanding of JavaScript if they say things like…

Types are not classes! Why do people feel the need to constantly drag out this scarecrow? Having tools to perform static analysis is nothing but a good thing, and you need type data to do a great deal of this. Perhaps your project requirements are such that you never require type checking for your JS, but I can say that it's saved my ass a number of times when working on very large code-bases, and definitely has sped up my development cycle when working on hairy code.

This is a type, not a class, taken from a Closure Compiler docs annotation example:

  /**
   * Enum for tri-state values.
   * @enum {number}
   */
  project.TriState = {
    TRUE: 1,
    FALSE: -1,
    MAYBE: 0
  };

Now I can require this type in my code with standard JSDoc, which is what the compiler uses anyway for type-checking. It makes my code self-documenting (the Closure Linter, should you use it, will complain if you omit descriptions and the like too, if you find yourself getting lazy):

  /**
   * Do something...
   * 
   * @param state {project.TriState} The state ...
   */
  function doSomething(state) {

If you are documenting your code, you already do this. And now you have static analysis out-of-the-box ... not bad!