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

121–130 of 316 posts

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

#121

Post by webjprgm »

zemo wrote: post #109
eddieplan9 wrote: post #69

Earlier quoted context omitted.

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

>Its lack of support for threads has turned out to be a strength on the server side. ummmm, can someone elaborate? I don't understand that statement.

E.g. node.js + socket.io. The event-driven concurrency model makes it easier to write servers without worrying about race conditions and thread locks while also having less overhead from a heavy thread implementation. For some applications this has been quite good. The downside is that it can be a bit tricky to scale node.js larger but it's not too hard to run multiple processes or do other load balancing. It's not good for all applications, but very good for some.

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

#122

Post by sciolistse »

wingspan wrote: post #99
spicyj wrote: post #82

Earlier quoted context omitted.

Have you used the popular library Underscore.js http://underscorejs.org/ ? The equivalent to your code in Underscore would be: _.chain([1,2,3]).map(n => n * n).filter(n => n >= 2).value()

I did look at underscore when figuring out how to design the library, along with many JS LINQ variants ( http://ianobermiller.com/blog/2012/09/19/linq-for-javascript... ). It should be pretty straightforward to provide Underscore bindings for TypeScript. One big difference in the library I was working on is that it is lazy, and modeled after .NETs IEnumerable. Whether this is a good thing or not, I'm not yet sure.

I've made a lazy linq-like library for javascript in the past..

The problem i had was that the native array methods are rather fast while function calls (for moveNext) are quite slow, so i couldn't get a whole lot of speed out of it.

Newer javascript engines might be sufficient to offset that though.

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

#124

Post by PabloOsinaga »

nigma wrote: post #12
cek wrote: post #4

Say what you want about whether this is a good idea or not, it is clear at least part of MS is really serious about open source. * TypeScript is under the Apache 2.0 license [1] * Source is available via git on Codeplex [2] * Installation is as easy as npm install -g typescript [3] Extra bonus coolness: They've provided an online playground like jsfiddle! [4]. [1] http://typescript.codeplex.com/license [2] http://typ…

The online playground can do live syntax and type checking as well as provide function call hints. That's pretty cool.

and you can also see in realtime the typescript -> javascript compilation as you type your typescript code. pretty cool.

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

#125

Post by aaronblohowiak »

eddieplan9 wrote: post #69
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 i…

The language itself is broken, especially when it comes to equality, type coercion, `arguments`, and Date processing.

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

#126

Post by georgemcbay »

jonknee wrote: post #71
camus wrote: post #57

Earlier quoted context omitted.

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.

> Most of js developpers hate javascript I don't know of any JS developers that hate JS. I know a lot that hate some browser implementations of JS though.

I've done quite a lot of JavaScript development, enough that I guess I'm a "JavaScript developer" (though thankfully that isn't my current day to day job) and I hate it. So now you know of at least one.

I agree with everything camus said. Yes JavaScript has some cool stuff in it, but taken as a whole it is a pretty shitty language. This has less to do with the creation of JavaScript than it does the practical reality that JavaScript cannot really be changed in fundamental ways without immense amounts of politics. Pretty much the entire time JavaScript has existed it was due to be fixed in a couple of years, but then political fiasco after political fiasco (eg. EcmaScript 4) delays this.

JavaScript as you can use it today sucks pretty much as much as it always has, and is only tolerable now because there are some good libraries that hide the shittiness of the language from you. Wouldn't it be better to have a web language without such a shitty core, that didn't require 100k libraries to hide you from the terrible bits?

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

#127

Post by wingspan »

sciolistse wrote: post #122
wingspan wrote: post #99

Earlier quoted context omitted.

I did look at underscore when figuring out how to design the library, along with many JS LINQ variants ( http://ianobermiller.com/blog/2012/09/19/linq-for-javascript... ). It should be pretty straightforward to provide Underscore bindings for TypeScript. One big difference in the library I was working on is that it is lazy, and modeled after .NETs IEnumerable. Whether this is a good thing or not, I'm not yet sure.

I've made a lazy linq-like library for javascript in the past.. The problem i had was that the native array methods are rather fast while function calls (for moveNext) are quite slow, so i couldn't get a whole lot of speed out of it. Newer javascript engines might be sufficient to offset that though.

I tried to get around this by creating overloads of almost all methods when you are operating on an array. `each` for instance, has a standard implementation using moveNext, and then an array implementation using a fast for loop. In some cases you could even drop down to native function calls.

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

#128

Post by winteriscomming »

iamleppert wrote: post #100

Why does everyone want to take all the nice features of javascript, it being so loose and freeform and turn it into Java? I don't need interfaces and classes built into the language. That's why it's so powerful and lightweight. Prototypical! People keep making the same mistakes, if you let them. No thanks.

Because these "loose and freeform" attributes make your life hell building large applications with large teams.

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

#129

Post by colin_jack »

samspot wrote: post #104
erichocean wrote: post #48

Earlier quoted context omitted.

I've been writing large-scale JS applications with SproutCore since 2007, and not once have I been bitten by a bug that would have been caught by static typing. Same with Objective-C and my iOS and Cocoa development (since the OpenStep days). I do use Scala on the server side though, and it helps there. But application development is, IMO, hindered by static typing. It's a lot more work to set up, and provides essent…

I noticed you mentioned scala on the server side. Does your comment about static typing being a hindrance apply to scala? I would also argue that static typing provides a self-documenting benefit that is easy to forget, making it easier for someone unfamiliar with the codebase to understand what is going on. When I'm doing maintenance work I often start at the point of failure and work backwards, and it is very helpf…

"I would also argue that static typing provides a self-documenting benefit that is easy to forget"

Ditto. For me that's by some way the biggest advantage of typing, with refactoring/navigation being the next biggest.

I do wonder if some of these newer languages are going to make the self-documenting aspect even stronger though. I'm speaking here of optional typing and/or implicit implementation (Greeter implements IGreeter if it has the correct methods). For me this will let me put type information and abstractions (interfaces etc) only where they make sense.

Compare that with what you get in current static languages, where projects I've worked on that also use IoC have so many interface-implementation pairs that it becomes difficult to spot the important abstractions.

Interesting times ahead I think.

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

#130

Post by munificent »

alexanderh wrote: post #65

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

Source maps[1] should help with this.

[1]: http://www.html5rocks.com/en/tutorials/developertools/source...

Post reply on HN