Live data from Hacker News

TypeScript and the Road to 1.0

blogs.msdn.com

71–80 of 93 posts

Re: TypeScript and the Road to 1.0

#71
post #53

Earlier quoted context omitted.

CS also saves keystrokes and makes code more readable by offering things such as: Reducing boilerplate for loop code: CS: for el, index in arr el.doThing(index) JS: for(var index=0; index Better iteration over objects: CS: for own k, v of obj console.log "#{k} is #{v}" JS: for(k in obj) { if(!obj.hasOwnProperty(k)) continue; console.log(k + " is " + obj[k]); } Default function params: CS: foobar = (foo = "default", b…

For kicks, here's Dart versions of those: Reducing boilerplate for loop code: var index = 0; for (var el in arr) { el.doThing(index++); } Dart hasn't really optimizing for iterating over a collection with indices since we don't find that very common in real-world code. Better iteration over objects: obj.forEach((k, v) => print("$k is $v")); Here, obj is a map data structure, not a random object since Dart distinguish…

Does Dart compile that for loop down to a regular for loop instead of the JS for..in loop? Or are there any safeguards against someone adding a property to an array (not that they should)?

    a = [1,2,3];
    a.prop = "oops";
    for(el in a)
      console.log(el);
    // > 0
    // > 1
    // > 2
    // > oops

Re: TypeScript and the Road to 1.0

#72
post #66
post #63

Earlier quoted context omitted.

> That sounds like an IDE/editor feature, not a language feature. Being toolable is a language feature. You can't do these things with JS or CS, because your tools don't have a clue what's going on. You can only do some guessing.

By "autocomplete" you mean when you're writing code in an editor and you can type "fu", hit and it'll complete to "function() {}", for example? If that's the case, autocompletion exists for JS and CS for most of the editors that I've used (Notepad++, Vim, SublimeText, TextMate). CS is a better JS, but doesn't enforce any design decisions like static typing, or OOP (with interfaces apparently?). I like CS, because I l…

> By "autocomplete" you mean [...]

All the fields and methods are known. If I write "someObject.", then I'll get a calltip which lists all fields/methods from this particular class and I can auto complete them. You can conveniently browse around like this to find the right method.

If I write "foo.bar" and "foo" as no "bar" field, I'll get a squiggly line (and of course I also wouldn't have been able to auto-complete "bar").

It's similar to writing C#, AS3, or Java with a good IDE. If you have never experience any of that, maybe you should give it a try.

> It's possible to build scalable systems in JS/CS without what TS/Dart offers.

Sure. It just requires more time and money.

You can, for example, also chop down a tree by using an axe instead of a chainsaw. There is always a more difficult more time consuming way to do something.

Re: TypeScript and the Road to 1.0

#73
post #72
post #66

Earlier quoted context omitted.

By "autocomplete" you mean when you're writing code in an editor and you can type "fu", hit and it'll complete to "function() {}", for example? If that's the case, autocompletion exists for JS and CS for most of the editors that I've used (Notepad++, Vim, SublimeText, TextMate). CS is a better JS, but doesn't enforce any design decisions like static typing, or OOP (with interfaces apparently?). I like CS, because I l…

> By "autocomplete" you mean [...] All the fields and methods are known. If I write "someObject.", then I'll get a calltip which lists all fields/methods from this particular class and I can auto complete them. You can conveniently browse around like this to find the right method. If I write "foo.bar" and "foo" as no "bar" field, I'll get a squiggly line (and of course I also wouldn't have been able to auto-complete…

Right, but that's about a certain IDE not the language itself, regardless of whether it's TS or JS. Sublime text does that for any JS file, as does Vim with the right plugin. I bet whatever IDE you're using will do that with bare JS. It's not "guessing" with JS completion any more than it is with TS. Again, autocompletion has nothing to do with the language.

> Sure. It just requires more time and money.

Care to back that up? I'll wait over here. Oh, unless you meant that it would take more time and money for you. Then sure, I agree.

Re: TypeScript and the Road to 1.0

#74
post #48

Earlier quoted context omitted.

Nope, and incidentally its not the same thing you originally said at all productively You missed the most important word. As someone who has spent quite some time on Javascript codebases its amazing how quickly things break down when you get developers of different levels working on the same codebase. Optional typing allows a whole batch of problems to be caught way before weird errors/exceptions client-side. Product…

You're wrong, it can be done productively, the evidence is the thousands (tens of thousands?) of such apps that exist on the web, most of which were written in regular JavaScript.

Out of how many of the big ones are using scripting tools/language-to-language translation though? Hint: much more than you seem to be aware of/think.

Whether its Google Web Toolkit/Java/C#-to-Javascript generators, Closure templating, Haskell/Clojure/etc. mini-languages, TypeScript, etc. (Job Ad Requirements are one of the great ways to see all this stuff)

When you start working on big applications (e.g. I worked for 5 years on a huge electronic HR application covering everything from timesheets to recruitment to content management to CRM with multi-country, multi-language, multi-regulatory, multi-company, multi-site, multi-thousand users requirements) you realise JavaScript has serious shortcomings...although I still really like the language the tooling and knowledge advances have really, really helped.

Re: TypeScript and the Road to 1.0

#75
post #60

Earlier quoted context omitted.

You don't know how productive those developers were on those projects, nor do you know if TS would have made those developers more productive. Granted, the original claim wasn't comparative, but that's the point I'll make anyway.

Interesting theory, let's see how it plays out in the marketplace. If typed languages are indeed more productive we should see them start to win out in, say NPM, right? Today the overwhelming majority of NPM modules are JavaScript, but if the same modules can be written more productively in TypeScript or Dart or another typed alternative, you should start to see those modules win out. Fewer bugs, more able to concent…

Indeed over the long term modules isn't a bad idea as the interface requirements and discoverability would benefit massively from better tooling, a la optional typing.

Re: TypeScript and the Road to 1.0

#76
post #67
post #64

Earlier quoted context omitted.

> [JS generated from CS] runs faster [than JS generated from Dart] There are cases where output from dart2js outperforms handwritten JS. Nowadays, the performance of the generated JS is generally pretty good. > it runs faster thus has its strength in scaling "Scaling" as in: more developers, more files, more lines of code. Bigger projects. CS doesn't help with that one bit. It's just as difficult to handle as JS. Thi…

> "Scaling" as in: more developers, more files, more lines of code. Bigger projects. CS doesn't help with that one bit. It's just as difficult to handle as JS. Right, and that's why we have modular design patterns that use the single responsibility principle, and AMDs like Require.js or CommonJS. It's testable, maintainable, can support a large codebase with multiple developers, and doesn't need static typing or othe…

> AMDs like Require.js or CommonJS

That stuff is terrible to use. There is quite a bit of boiler plate involved and there is lots of overhead in general.

Secondly, there are about 10 somewhat popular module formats and they aren't compatible which each other.

I rather do this stuff declaratively. If it's baked into the language, your tools will understand what's going on and there also won't be any compatibility issues. Naturally, it's also way more convenient to use. You just import something. Done.

> doesn't need static typing or other features from TS/Dart

You also don't need a seat belt or airbags. If you don't make any mistakes, you'll be fine.

However, from a pragmatic point of view, these static checks are very handy. If you rewrite some parts of your code, the analyzer will tell you if you screwed something obviously up. It catches all the stupid mistakes, which means you can fully focus on the logical ones.

With JavaScript/Python/etc you have to run the code and actually hit that particular branch to trigger some sort of error/exception which will eventually help you to identify the actual issue.

You should just give it a try. Try any language/IDE combination which offers good tooling. Tooling can remove a lot of friction. There really is a point to all of this.

Re: TypeScript and the Road to 1.0

#77
post #76
post #67

Earlier quoted context omitted.

> "Scaling" as in: more developers, more files, more lines of code. Bigger projects. CS doesn't help with that one bit. It's just as difficult to handle as JS. Right, and that's why we have modular design patterns that use the single responsibility principle, and AMDs like Require.js or CommonJS. It's testable, maintainable, can support a large codebase with multiple developers, and doesn't need static typing or othe…

> AMDs like Require.js or CommonJS That stuff is terrible to use. There is quite a bit of boiler plate involved and there is lots of overhead in general. Secondly, there are about 10 somewhat popular module formats and they aren't compatible which each other. I rather do this stuff declaratively. If it's baked into the language, your tools will understand what's going on and there also won't be any compatibility issu…

Don't get me wrong, I agree that the overall experience is important - the best language in the world would be shit if you had to use notepad.exe to develop in it.

You like your IDEs and static typing and tooling, and it works for you (and for many others). I like my CoffeeScript, my AMD/CJS modules, and testing, and it works for me (and for many others).

Your experiences and assertions are wildly different than mine. I've never found AMD modules a problem. I have found overwrought and verbose code to be a problem. File headers? Interfaces? Java-style OOP in my JS? No thanks.

I think we're both just stating subjective opinions without substantiation, so I'm done here.

Re: TypeScript and the Road to 1.0

#78
post #73
post #72

Earlier quoted context omitted.

> By "autocomplete" you mean [...] All the fields and methods are known. If I write "someObject.", then I'll get a calltip which lists all fields/methods from this particular class and I can auto complete them. You can conveniently browse around like this to find the right method. If I write "foo.bar" and "foo" as no "bar" field, I'll get a squiggly line (and of course I also wouldn't have been able to auto-complete…

Right, but that's about a certain IDE not the language itself, regardless of whether it's TS or JS. Sublime text does that for any JS file, as does Vim with the right plugin. I bet whatever IDE you're using will do that with bare JS. It's not "guessing" with JS completion any more than it is with TS. Again, autocompletion has nothing to do with the language. > Sure. It just requires more time and money. Care to back…

> that's about a certain IDE not the language itself

This stuff is only possible if you can analyze the code statically.

With JS, which is running in a browser, you don't know anything. You don't know what other kinds of scripts are running on that page. You don't know which globals these introduce or which built-ins they modify.

E.g.:

    Math.round(5).length
You don't know if Number has a length property. You don't know if "round" takes a Number as argument. You don't know what this "round" function returns. You don't know if the "round" function exists. You don't know if a "Math" global exists.

For tools, this is a big problem.

In Dart, the analyzer knows about all these things. If the function is annotated, I'll get all the tooling and checks.

> Care to back that up?

No. You can't even imagine what good tooling is like. Naturally, you're blind to the friction which is caused by a lack of good tooling.

Re: TypeScript and the Road to 1.0

#79
post #36

Earlier quoted context omitted.

I use CoffeeScript in my day job for the last 2 years. I've been using TypeScript in my startup the last 6 months. They are definitely not the same. TypeScript is JavaScript + types, whereas CoffeeScript is a new language, a mashup of Ruby and JS. (For example, you can take any JS on the web, paste it in a TypeScript file, and it will compile. But you absolutely cannot do this in CoffeeScript.) CoffeeScript tries to…

I've used both extensively and I'd disagree with you on almost every point. > For example, you can take any JS on the web, paste it in a TypeScript file, and it will compile. This myth won't die. False. Typescript will choke on most JavaScript files from the web. Because you will need to include definition files for any external library calls. If you use jQuery, for example, the compiler won't like your $('.class').d…

TypeScript appears to compile even in the face of undefined variables.

Just went to the playground and dropped a random jQuery sample in: http://www.typescriptlang.org/Playground/#src=%24(%20documen...

You get squiggles yes, but you also get valid javascript. So it looks like you can paste random javascript into TypeScript and get it to compile. I went and tried with the actual compiler (to make sure it's not some artifact of the playground website), and confirmed you get a proper .js file out (and 2 messages, about $ being undefined).

Quick google makes it sound like getting rid of the squiggles / messages is pretty easy: http://stackoverflow.com/a/12755602/80572

I'm not sold on TypeScript yet (or any of the transpiled javascript languages, honestly), but this:

> False. Typescript will choke on most JavaScript files from the web.

Seems to be the actual false statement in this thread.

Re: TypeScript and the Road to 1.0

#80
post #77
post #76

Earlier quoted context omitted.

> AMDs like Require.js or CommonJS That stuff is terrible to use. There is quite a bit of boiler plate involved and there is lots of overhead in general. Secondly, there are about 10 somewhat popular module formats and they aren't compatible which each other. I rather do this stuff declaratively. If it's baked into the language, your tools will understand what's going on and there also won't be any compatibility issu…

Don't get me wrong, I agree that the overall experience is important - the best language in the world would be shit if you had to use notepad.exe to develop in it. You like your IDEs and static typing and tooling, and it works for you (and for many others). I like my CoffeeScript, my AMD/CJS modules, and testing, and it works for me (and for many others). Your experiences and assertions are wildly different than mine…

> File headers?

No.

> Interfaces?

Implicit interfaces. It's kinda handy.

> Java-style OOP in my JS?

I'm not sure what qualifies as "Java-style" OOP. Is the stuff from ES7 also "Java-style"? How about the stuff from CS?

Well, you don't have to use classes. You can do everything with functions if you want.

> I think we're both just stating subjective opinions [...]

The difference is that I actually tried it.

Post reply on HN