Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript: a language for application-scale JavaScript development

typescriptlang.org

Post reply on HN
Print view View original

61–70 of 316 posts

Re: TypeScript: a language for application-scale JavaScript development

#61

Post by Permit »

tlrobinson wrote: post #33

This looks great, but the IDE seems to be one of the key features, so we're going to need something other than Visual Studio. EDIT: they've got syntax highlighting for some other editors, but full completion and error reporting is still needed http://blogs.msdn.com/b/interoperability/archive/2012/10/01/...

I can't imagine it'll be too tough for other IDEs to support.

There's a pretty impressive demo here: http://www.typescriptlang.org/Playground/

It even has auto-complete if you press "Ctr-Space" while typing a word. Considering the source for all this stuff is freely available, I don't think it'll be too long before other IDEs support it.

Re: TypeScript: a language for application-scale JavaScript development

#62

Post by jakejake »

koops wrote: post #15

I've written a lot of JavaScript, including large-scale projects, and never once have thought, "Gee, I wish I had type checking." Haven't we come to a consensus that types are more trouble than they're worth? They hurt clarity and catch few bugs.

I have a theory about this - how you feel about static typing is related to whether you see the compiler as your friend or as your enemy.

If you see the compiler as your friend then you tend to like type checking because it blocks certain bugs and typos. It won't let you run your code until they're fixed. If you see the compiler as your enemy, as a barricade that you need to get past, then you tend to not like static types. The compiler prevents you from seeing your code running immediately.

Obviously there's other benefits to each system but I feel like this is the more "gut reaction."

Re: TypeScript: a language for application-scale JavaScript development

#63

Post by baltcode »

untog wrote: post #37
tlack wrote: post #14

Weird that I didn't spot a friendly list of features.. seems to have some cool ones, like a shortened function expression (from the doc PDF): (x) => { return Math.sin(x); } and modules, which are implemented using the immediately invoked function expression pattern: module M { var s = "hello"; export function f() { return s; } } Syntax seems more clear than CoffeeScript and tool chain will probably shape up better. L…

I like the shortened function form. I played around with CS for a while before going back to JS, but I do miss being able to do something like: var names = people.map((p) -> return p.name); (or something along those lines). Funnily enough, it reminds me of C#'s LINQ: var names = people.Select(p => p.name);

It's actually even shorter:

      names = people.map((p) -> p.name)

Re: TypeScript: a language for application-scale JavaScript development

#64

Post by thedufer »

camus wrote: post #57
arturadib wrote: post #49

All of these compile-to-JS efforts are great, and as much as I love things like CoffeeScript I have to say I definitely worry about language fragmentation. JavaScript is full of flaws, but its monopoly in the browser space has brought about one intriguing and welcome side-effect: a VERY efficient market for both employers and employees. It's easy to overlook how important this common denominator has been for everyone…

Javascript is dreadfull , and its flaws are counter productive and intolerable. It has good things like closures and first class functions , and that's it. Most of js developpers hate javascript , but are forced to work with it. So they dont care what they use as client language provided it gets the job done. few people cares about Javascript. most of the devs hate it. But the browser as dev plateform is a fact.

That is a sweeping condemnation of JavaScript that I've honestly never heard support for. JavaScript has quirks that people don't like, but it can be rather enjoyable to work with.

Re: TypeScript: a language for application-scale JavaScript development

#65

Post by alexanderh »

What about debugging? Thats my biggest problem with coffeescript

How do they map errors thrown in the browser, to TypeScript code? If this has things like classes and such, the relationship isnt always going to be 1:1 and debugging can become a nightmare. Part of what makes javascript so great is how easy it is to debug. All these "superset" languages that compile to javascript fail hard @ debug support usually

Re: TypeScript: a language for application-scale JavaScript development

#66

Post by andrewla »

On a tangent, does anyone know anything about the in-browser editor they are using for the playground? It seems really slick. The javascript references something called "monaco" and the directories are all prefixed with "vs".

The code is hosted on their demo site; /Script/vs/editor/editor.main.js appears to be the main js file and has this notice:

    /*!
        © Microsoft. All rights reserved.

        This library is supported for use in Windows Store apps only.

        Build: 1.0.8514.0.win8_rtm.120711-1900
  
        Version: Microsoft.WinJS.1.0
    */

Re: TypeScript: a language for application-scale JavaScript development

#67

Post by niggler »

camus wrote: post #57
arturadib wrote: post #49

All of these compile-to-JS efforts are great, and as much as I love things like CoffeeScript I have to say I definitely worry about language fragmentation. JavaScript is full of flaws, but its monopoly in the browser space has brought about one intriguing and welcome side-effect: a VERY efficient market for both employers and employees. It's easy to overlook how important this common denominator has been for everyone…

Javascript is dreadfull , and its flaws are counter productive and intolerable. It has good things like closures and first class functions , and that's it. Most of js developpers hate javascript , but are forced to work with it. So they dont care what they use as client language provided it gets the job done. few people cares about Javascript. most of the devs hate it. But the browser as dev plateform is a fact.

I've only started playing with it recently, but I've been doing some heavy stuff and wonder whether the criticism stems from deficiencies in the language (for which there are workarounds within the language) or a fundamental lack of understanding of the javascript model.

Re: TypeScript: a language for application-scale JavaScript development

#69

Post by eddieplan9 »

arturadib wrote: post #49

All of these compile-to-JS efforts are great, and as much as I love things like CoffeeScript I have to say I definitely worry about language fragmentation. JavaScript is full of flaws, but its monopoly in the browser space has brought about one intriguing and welcome side-effect: a VERY efficient market for both employers and employees. It's easy to overlook how important this common denominator has been for everyone…

I think you were referring to the JavaScript syntax when you said JavaScript is full of flaws, because IMHO the language itself - except the syntax component - is actually very good. Someone on Quora said[1] it very well:

JavaScript is a wonderful language, deep down: It's Lisp-y, yet imperative. Its lack of support for threads has turned out to be a strength on the server side. And recent implementations have made it very fast.

People favoring node.js and compile-to-JS languages like Iced CoffeeScript to other server-side languages supports the fact that JavaScript itself is actually quite decent. At the end of the day, a language too broken could not easily be fixed with any thin compile-to-* effort, and most of the compile-to-JS efforts (with the notable exception of emscripten, whose goal is not to fix JavaScript) are quite quite thin.

[1] http://www.quora.com/CoffeeScript/What-are-disadvantages-of-...

Re: TypeScript: a language for application-scale JavaScript development

#70

Post by wingspan »

spicyj wrote: post #26

This looks nice. I love the fact that there's no runtime that needs to be included or any overhead when the compiled JS runs. It'd be 100% more useful if it was more aware of nullable types -- as it is, it appears that null * 7 compiles without any error messages. If they add a "nullable number" type distinct from "number", I'll be a lot more likely to use it. It also appears that some other things compile that perha…

`7[2]` is valid Javascript, so it is also valid TypeScript (fetching the '2' member of the `7` object).

Detecting null expressions at compile time might help. There are "nullable" types, but afaik only in signatures:

  foo(x?) {
      alert(x);
  }
If `x` is not passed in, it will be `undefined`.
Post reply on HN