Live data from Hacker News

TypeScript and the Road to 1.0

blogs.msdn.com

81–90 of 93 posts

Re: TypeScript and the Road to 1.0

#81
post #80
post #77

Earlier quoted context omitted.

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.

So have I, chief.

I've used heavy IDEs before with Java, and I much prefer a simpler text editor like Vim or Sublime. I tried out TS a while back. All the examples I've seen were overweight, much like classical enterprise Java. Too much cruft.

Anyway, enjoy TS.

Re: TypeScript and the Road to 1.0

#82

Earlier quoted context omitted.

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 ar…

Thanks for trying that out the jQuery example. They look to be making the compiler (or the playground site) more permissive lately. This didn't work in May when I last tried it out.

I've used the typescript compiler on a randomly-chosen JS library (typeface.js http://typeface.neocracy.org/typeface-0.15.js ) and it had dozens of compiler errors for me to fix before it would compile. The playground is now accepting them for some odd reason. This seems to be recent behavior or perhaps the node.js version of the compiler behaves differently?

Re: TypeScript and the Road to 1.0

#83
post #28

I actually want to commend Microsoft here for releasing an open-source (and permissively-licensed!) compiler that doesn't run exclusively on its own proprietary platform. The language itself seems like a winner as well. Its conservative design makes it the perennial dark horse of the compiled-to-JS language family, but that's also what makes it most attractive to me. It's a thin-enough skin over the underlying langua…

I can't speak for CoffeeScript or ClojureScript, but Evan Czaplicky does get paid to work on Elm: http://elm-lang.org/blog/announce/Elm-and-Prezi.elm

Re: TypeScript and the Road to 1.0

#84

Earlier quoted context omitted.

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 ar…

Thanks for trying that out the jQuery example. They look to be making the compiler (or the playground site) more permissive lately. This didn't work in May when I last tried it out. I've used the typescript compiler on a randomly-chosen JS library (typeface.js http://typeface.neocracy.org/typeface-0.15.js ) and it had dozens of compiler errors for me to fix before it would compile. The playground is now accepting the…

The title of the article is "...the Road to 1.0", you can imagine that they are continuously improving it to get there.

Re: TypeScript and the Road to 1.0

#85
post #64
post #61

Earlier quoted context omitted.

Language is part of the tooling. For example, if you have a language that compiles to js which always passes JSLint, then you don't need JSLint any more. Removing the need of a tool is even better than developing a tool. CoffeeScript generates less code than Dart, it runs faster thus has its strength in scaling. In fact, you can already do operator overloading in Javascript using valueOf and side effects. It's a bit…

> [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…

You "scaling" is just a syntactic sugar to the underlying package/module solution. In js/coffee the syntax just don't care about it, and you use package/module with a library.

Most of the semantics or environment stuff are translated into function calls at last. Then the difference becomes the syntax again: how to use that function? Call it directly or translate a syntax?

I like coffee because it is practical scripting: Need code completion? Don't repeat yourself. Can't code without IDE? Make the language easier to use then you ain't gonna need it. Some people just can't believe a language can be that good without IDE, but remember: you interact with IDE through a language on keyboard/mouse too.

Re: TypeScript and the Road to 1.0

#86
post #41

Earlier quoted context omitted.

So if you used Q or a similar library: Q.async(function*() { var ra = yield opA(); var rb = yield opB(ra); yield opC(ra, rb); })().done(); Are you wishing for the other syntax or something that you can't achieve with generators/promises today?

Fortunately, with a bit of hacking, this style of syntax is possible without generators :) (I'm hoping to open source a library I wrote that works all the way back to IE6) Here's your example rewritten in the 'monads' library (I probably need a better name): monads(function() { var ra = opA.defer(); var rb = opB.defer(); var result = opC(ra(), rb()); });

Is that open source? I'd be interested in taking a look.

Re: TypeScript and the Road to 1.0

#87
post #68

I think the one think that TypeScript needs to get it going is modularity. If another project like [harp]( https://github.com/sintaxi/harp ) could use TypeScript as a library and could compile the code without having to result to system commands would be a great thing. However, I think if someone came up with a system to add optional typing through the use of string literals it would be awesome. That way we can have…

The TypeScript compiler can be used as a library, I believe.

The Closure Compiler has a whole type system that lives in doc comments:

https://developers.google.com/closure/compiler/docs/js-for-c...

and I believe there's a command line option for doing type checking. Alas, Closure Compiler is written in Java rather than JavaScript so you can't use it quite as seamlessly as TypeScript's compiler.

Re: TypeScript and the Road to 1.0

#88
post #44

Earlier quoted context omitted.

> TypeScript is more of a way for Microsoft to develop large scale JavaScript apps productively, This implies that you can't develop large scale apps without type checking, which obviously isn't true. What's more likely is that Microsoft hires a lot of developers that know the "VS way" of coding, which is using intellisense and type checking, and they made a language that conformed to that. Which is the same thing as…

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…

>> (Part of me still wishes Haskell was an option for web scripting but I can dream)

You're not the only one: http://www.di.unipi.it/didadoc/lfc/OtherPapers/Iteroperabili...

(n.b, this is from 1999)

Re: TypeScript and the Road to 1.0

#89

Earlier quoted context omitted.

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 ar…

Thanks for trying that out the jQuery example. They look to be making the compiler (or the playground site) more permissive lately. This didn't work in May when I last tried it out. I've used the typescript compiler on a randomly-chosen JS library (typeface.js http://typeface.neocracy.org/typeface-0.15.js ) and it had dozens of compiler errors for me to fix before it would compile. The playground is now accepting the…

One thing that threw me off initially is the fact that typescript will complain about errors, but still do the translation of TS -> JS. For example:

    var s = 'hello';
    s.toExponential();
Typescript tells you about the obvious error that there's no property 'toExponential' on strings, but it also merrily produces yourfilename.js.

In my experience so long as you don't have any syntax errors, tsc will give you back javascript. This is partly because the translation from typescript to javascript is incredibly straightforwards and ignores the types completely. Writing a nonvalidating, dumb but super fast ts -> js transpiler is about an afternoon's worth of work, especially if you bootstrapped from the typescript parser and tests.

Re: TypeScript and the Road to 1.0

#90
Sorry if this comes across as somewhat tangential, but I'm still wondering if/when we'll have JavaScript runtimes (V8, Chakra, SpiderMonkey, whatever) that can export runtime type information, even if only enabled in a 'debug' mode?

I love the idea of optional typing being supported (whether in the base language or TypeScript/Closure/etc) but it's maddening to think of trying to have to add the type information manually to existing code, especially code with lots of good test coverage, knowing that the JavaScript runtime seems to have to figure it out anyway (at least based on talks about V8 from the past).

This kind of functionality seems even more important for projects like DefinitelyTyped, where people are trying to track the public API's for projects that sometimes have a lot of churn. Having runtimes export their runtime type information (which seems to have sufficient mapping to source based on existing debugger experiences in Chrome, IE10+, etc) and allowing the creation of tooling that can populate/check/etc the type information in source seems like a big potential win.

Anders asking the Chakra team for this to (massively, AFAICT) help TypeScript adoption among existing projects seems reasonable, but TypeScript type information seems to still be 'add it yourself' for now?

Am I just missing something that makes this far more complex/difficult/intractable than I realize?

Post reply on HN