Live data from Hacker News

I Was Wrong About TypeScript

triplet.fi

141–150 of 194 posts

Re: I Was Wrong About TypeScript

#141
post #19
post #7

I prefer frameworks that focus on pure javascript because the ones that don't tend to allow you too use javascript but have sparse documentation on how to use it effectively, instead focusing on typescript. When I first tried Angular 2 their javascript "hello world" example wouldn't even work, it was some bug in their site. I already need to use all sorts of other tools and abstraction layers when building websites/a…

3rd party libraries / frameworks written with non-JavaScript languages is worth another blog post and discussion. I agree completely with you that libraries / -most- frameworks should be written in plain old JS. The reason is simple, contributing and reading the project source code should not start by learning a programming language. It is a different scenario when a team in a company has decided to learn and write t…

(this won't be quite true after TS 2.0, but..) TypeScript doesn't support everything ES6 or even everything Babel does, and some of the stuff it does support are not matching the standard, in subtle ways. Then you're missing out on the Babel plugin ecosystem. You can use TS and Babel together for SOME of that (but not all of it, syntax parser and all).

It may still be a slam dunk to you, but it's not as "obvious" an answer as you make it sound.

Re: I Was Wrong About TypeScript

#142
post #129

Earlier quoted context omitted.

Could you give links about moving types to npm? Are there any issues in a tracker or a blog?

I don't know about moving all of the current typings to beneath an NPM org, but TypeScript can look for the `typings` field in a package's package.json file. https://github.com/ihsw/toxiproxy-node-client/blob/master/pa... An NPM package will be typed and you won't have to download typings separately. It may be improper to publish typings with your code instead of letting the user install them separately, but at that…

TypeScript 1.8x already looks for "typings" in package.json

Re: I Was Wrong About TypeScript

#143

> I have written tests in TypeScript, compiled to JavaScript, and then used Mocha, for example, to run tests. I would like to hear your thoughts on this. We use ts-node to run our mocha tests without ever compiling: https://github.com/TypeStrong/ts-node

ts-node has some issues with source maps unfortunately. When your project gets big enough you might want to move back to ts->js then running mocha.

Re: I Was Wrong About TypeScript

#145
post #114
post #110

Earlier quoted context omitted.

Angular blew a loooooot of my trust in Google, who in the past always put out the highest quality stuff. I built an entire app in the damn thing only to realize as it got bigger that it wouldn't scale. Sure you can use less HTML templates, but that's the whole point so that it's easier for designers to approach / fix. Sure I should have checked it out but the documentation didn't exactly highlight it (at the time any…

o.O i love angular 1. and probably would like 2 as well, havent started any new major projects lately though

+1

In the last 4 months I've built a large angular1.5 app in ES5 using the new component facade and d3.js, and it's been pretty smooth.

Re: I Was Wrong About TypeScript

#146

Earlier quoted context omitted.

I was just about to complain how TS fails totally for typechecking backbone models or immutablejs datastructures: both situations where obj.get("foo") and obj.get("bar") return a particular type but there's no way of having TS handle that except defining them as any. But it turns out string literal types in 1.8 will make that work. And this was out since February! I should reevaluate TS for my omniscient project.

IIRC there is no ergonomic way to define typed records for Immutable.js ?

I've been playing with https://github.com/danielearwicker/doop

Re: I Was Wrong About TypeScript

#147

Earlier quoted context omitted.

The two things coming in 2.0 that most excite me are - moving types to npm (despite the great work of Blake on typings, managing type definitions is still out of band) - npm install @types/somelib will be great. - AST transforms, which will open up some interesting options for bundling and optimizations, sort of like babel's plugin ecosystem.

Could you give links about moving types to npm? Are there any issues in a tracker or a blog?

see https://github.com/Microsoft/TypeScript/issues/8275

Re: I Was Wrong About TypeScript

#148
post #45

Earlier quoted context omitted.

TypeScript 1.8 already has unions and custom type guards! You can use them today. Woohoo! (Looking forward to those non-nullable types, though.)

I was just about to complain how TS fails totally for typechecking backbone models or immutablejs datastructures: both situations where obj.get("foo") and obj.get("bar") return a particular type but there's no way of having TS handle that except defining them as any. But it turns out string literal types in 1.8 will make that work. And this was out since February! I should reevaluate TS for my omniscient project.

The example you give has been supported since day 1. Example: document.createElement("canvas") returns HTMLCanvasElement. A limited form of string literal types has always been supported specifically for overloading return types. The newer support added in 1.8 is a way more powerful generalisation.

Re: I Was Wrong About TypeScript

#149
post #70

Earlier quoted context omitted.

> As a Scala developer Interesting, choosing TypeScript over Scala.js; what does TS offer vs. working directly in Scala across the board?

I think the biggest advantage is that typescript emits code that is good JavaScript. This means if I decide to stop using typescript, I can just use the generated JavaScript. It also means that there transpiled file is smaller. Using scala.js for a small project wouldn't make sense if you cared about file size at all. It could be worth it more as your project grows, but your then you are that much more commited. Ther…

I remember hearing the same argument in the early 80s for the benefit of C vs Assembly. And it actually was a good argument. A lot of people, myself included, learned "real programming" (ie assembly) by using C as training wheels. But a funny thing happened on the way to the forum - C became real programming and nobody remembered or learned assembly - myself included. Then the same thing happened ten years later with the transition from C to C++.

Re: I Was Wrong About TypeScript

#150
post #9

Earlier quoted context omitted.

You're absolutely right. Flow seems to be a very good alternative. One thing I would like to add regarding the .js files, TypeScript 1.8 added a flag --allowJs which makes some sanity checks to the plain old .js files.

It sounds like --allowJs alleviates the need to create TypeScript definitions for everything? So if you have an existing project based entirely on JavaScript, you can gradually convert each file to .ts without having to do anything else?

Definitely an aim of TS to make it easier to continue using JS for those who prefer a half-way house, see: https://github.com/Microsoft/TypeScript/issues/4789
Post reply on HN