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

Announcing TypeScript 1.0

blogs.msdn.com

Post reply on HN
Print view View original

71–80 of 118 posts

Re: Announcing TypeScript 1.0

#71

Post by anton-107 »

pjmlp wrote: post #55
sytelus wrote: post #54

Having spent quite a bit of my dev life with typed languages and now coding a LOT in pure JavaScript, I'm actually not at all thrilled by TypeScript. Yes, pure JS is bit hard to maintain and it does occasionally pisses me off but at the same time it is liberating. Not having to constantly keep adding types all over, not having to constantly refactor things because I now accept object instead of an int etc is refreshi…

> Even in moderately large project I think pure JavaScript is not only maintainable but also joy to work with compared to typed languages. You will see that joy quickly fade away in enterprise projects.

But isn't it because in the enterprise projects JavaScript code is written by Java/C# developers who think they know JavaScript, while they really don't?

I've seen multiple examples of "enterpisey" web apps, and there was no joy, just because developers didn't know how to build a good application with JavaScript and even more - they didn't care at all.

With a "don't touch anything that works" mindset that lots of enterprise developers have - you write write-only JavaScript code and when it becomes too large - of course, there is no joy in touching this kind of codebase.

Every enterprise project with a in-browser front-end needs a good front-end developer from the start to set up good code, good practices and good attitude to a front-end part of the code, and it will be fine: the joy won't fade away.

Re: Announcing TypeScript 1.0

#72

Post by ajanuary »

toggle wrote: post #6

It'd be great if there was a compiler that would compile TypeScript to asm.js [0]. Adding type-safety in TypeScript is only for the programmer -- when you compile it to Javascript, you don't get any performance increase. But, if you could compile it to asm.js, you'd actually get some performance increase out of it. (Note: I don't know much about TypeScript or asm.js, so if what I just said is completely untrue, I'd l…

You wouldn't be able to compile it to asm.js because of the very different memory models, which means you wouldn't be able to take advantage of any alternative runtime paths the js runtime has for asm.js.

You could, however, use the type annotations part of the asm.js spec to take advantage of the fact most js runtimes are going to be attempting to optimise the heck out of them.

Re: Announcing TypeScript 1.0

#73

Post by benmorris »

radicalbyte wrote: post #51

We've been using TypeScript for 9 months now on a large project. It's fantastic. There's now way I'll go back to pure JavaScript again. The type system just catches so many defects, and they're of the kind that are hard and boring to find (typos). Plus IntelliSense integration (including jsdoc) is great. On the downside, our project takes some time to compile so we had to build a tool to do it incrementally. Plus it…

Typos account for a significant amount of my javascript debugging. To have both intellisense and compile time checking for this would be a huge time saver.

Re: Announcing TypeScript 1.0

#74

Post by aquadrop »

sytelus wrote: post #54

Having spent quite a bit of my dev life with typed languages and now coding a LOT in pure JavaScript, I'm actually not at all thrilled by TypeScript. Yes, pure JS is bit hard to maintain and it does occasionally pisses me off but at the same time it is liberating. Not having to constantly keep adding types all over, not having to constantly refactor things because I now accept object instead of an int etc is refreshi…

TypeScript is the future of JavaScript, since all TS does is trying to introduce ES6 features right now.

Re: Announcing TypeScript 1.0

#75

Post by fractalsea »

camus2 wrote: post #14
fractalsea wrote: post #10

Earlier quoted context omitted.

Care to explain why? To my understanding asm.js is a restricted subset of JS that allows for optimisations to be performed that would not otherwise be possible. In a similar way to how Java bytecode can be interpreted more efficiently compared to a non-compiled language, like Python. With that in mind, sure you could target asm.js with a high level language that requires memory management, but why couldn't you also t…

JS interpreters have this GC component built in already. that you cant use with asmjs. asmjs IS NOT javascript. Mozilla folks may have made you think it is,it is not!!! you'd need to reimplement a gc on top of asmjs... It'd makes no sense.

So what is a feature of asm.js that is not in JS?

Re: Announcing TypeScript 1.0

#76

Post by fractalsea »

azakai wrote: post #19
fractalsea wrote: post #10

Earlier quoted context omitted.

Care to explain why? To my understanding asm.js is a restricted subset of JS that allows for optimisations to be performed that would not otherwise be possible. In a similar way to how Java bytecode can be interpreted more efficiently compared to a non-compiled language, like Python. With that in mind, sure you could target asm.js with a high level language that requires memory management, but why couldn't you also t…

asm.js is a subset of JavaScript, and to be easy to optimize, it removes most of the dynamic stuff from JS and leaves a simple, low-level dialect that is basically equivalent to LLVM IR or to C. You can compile many things to C and LLVM IR, like C++, C#, and so forth. You can compile the VMs of dynamic languages like Python, Lua and Ruby, but compiling them directly would be inefficient - you'd need type checks all o…

OK, so are you saying that compiling the language's runtime environment, including the GC, to asm.js would not be efficient enough? That makes sense.

I guess I was hoping that there may be some way to compile the runtime such that the GC wouldn't need to be compiled, and the GC of whatever is interpreting the asm.js code (e.g. SpiderMonkey) could be used instead.

Re: Announcing TypeScript 1.0

#77

Post by frik »

skrebbel wrote: post #56

Most significant announcement IMHO: > Today, we're announcing that we will begin taking pull requests for the TypeScript compiler and language service. A relatively-flagshippy MS project becomes truly open source. This is awesome!

btw.

license: Apache License 2

Re: Announcing TypeScript 1.0

#78

Post by Kiro »

radicalbyte wrote: post #51

We've been using TypeScript for 9 months now on a large project. It's fantastic. There's now way I'll go back to pure JavaScript again. The type system just catches so many defects, and they're of the kind that are hard and boring to find (typos). Plus IntelliSense integration (including jsdoc) is great. On the downside, our project takes some time to compile so we had to build a tool to do it incrementally. Plus it…

Can you give an example of a defect that the type system catched? You said typos but that's something JSLint would catch as well so not sure if it's a strong argument.

Re: Announcing TypeScript 1.0

#79

Post by rat87 »

fractalsea wrote: post #10
Touche wrote: post #7

Earlier quoted context omitted.

asm.js requires you to manage your own memory. TypesScript doesn't, it's a pretty thin layer on top of JavaScript.

Care to explain why? To my understanding asm.js is a restricted subset of JS that allows for optimisations to be performed that would not otherwise be possible. In a similar way to how Java bytecode can be interpreted more efficiently compared to a non-compiled language, like Python. With that in mind, sure you could target asm.js with a high level language that requires memory management, but why couldn't you also t…

The default python implementation(cpython) compiles to bytecode before interpreting(the default c implementation of ruby also does this as of 1.9, before that it did straight interpretation). The difference between compiling to bytecode ahead of time vs at run time is more of a packaging difference and probably not the biggest cause of the speed gap between the languages, although I suppose the python import mechanism doing strange stuff and hitting filesystem too often could slow things down. The reason the most common java implementation(oracle hotspot/openjdk) is fairly fast(there are other fast implementations) is that it includes a fast interpreter written in assembly(although a c++ backup version exists for non-x86 ports) and a good just in time compiler. It also has a much more advanced gc then python. Another thing that makes a difference is that python has a global interpreter lock that only allows one python thread(c extensions can run several of their own threads) to run at a time(despite the number of cpu cores/max native threads) because python's refcounting gc would cause significantly worse single threaded performance if multiple threads were to be run at the same time.

Re: Announcing TypeScript 1.0

#80

Post by pjmlp »

anton-107 wrote: post #71
pjmlp wrote: post #55

Earlier quoted context omitted.

> Even in moderately large project I think pure JavaScript is not only maintainable but also joy to work with compared to typed languages. You will see that joy quickly fade away in enterprise projects.

But isn't it because in the enterprise projects JavaScript code is written by Java/C# developers who think they know JavaScript, while they really don't? I've seen multiple examples of "enterpisey" web apps, and there was no joy, just because developers didn't know how to build a good application with JavaScript and even more - they didn't care at all. With a "don't touch anything that works" mindset that lots of ent…

> But isn't it because in the enterprise projects JavaScript code is written by Java/C# developers who think they know JavaScript, while they really don't?

No, it is because:

- Unit tests have zero value over new features

- Project development tends to be outsourced to teams with high attrition rates

- Most of the time cheaper developers are what matter

- No one cares about quality, because there are no options to get the software from somewhere else

> Every enterprise project with a in-browser front-end needs a good front-end developer from the start to set up good code, good practices and good attitude to a front-end part of the code, and it will be fine

Oh, the dream enterprise, where can I get a job?

Post reply on HN