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

TypeScript Won

medium.com

Post reply on HN
Print view View original

111–120 of 128 posts

Re: TypeScript Won

#111

Post by WorldMaker »

softawre wrote: post #86
d1plo1d wrote: post #38

Earlier quoted context omitted.

Personally, I'm more excited about Flow because it introduces a modern type system into ES6/ESNext without me having to sacrifice Babel. With regards to types: TypeScript has only recently added support for any kind of Algebraic Data Types whereas Flow was built upon Unions and Intersections from day one. That to me speaks to their priorities.

Unions were added in TS 1.4, over a year ago. https://blogs.msdn.microsoft.com/typescript/2015/01/16/annou...

Also, Intersections were added in TS 1.6, last year:

https://blogs.msdn.microsoft.com/typescript/2015/09/16/annou...

They seem to be moving at a decent, agile pace to improving/expanding upon the algebraic sides of the type system.

Re: TypeScript Won

#112

Post by WorldMaker »

ryan-allen wrote: post #18
corysama wrote: post #12

Earlier quoted context omitted.

The only complaint I've heard is that TS makes JS feel more like C#. Lots of people would say that's a good thing. But, some people really appreciate the dynamic nature of JS.

In typescript the types are optional, so if you omit types it'll look very much like ES6. You can mix and match dynamic stuff with Typescript, depending on your compiler options, it'll treat non-typed things as if you were writing regular JS. I always turned on 'do not allow 'any' types' because I wanted everything typed. As far as C#... there are enough minor differences for it to be rather annoying if you have to j…

Furthermore you can give Typescript the allowJS: true compiler option in recent versions and literally mix and match pure JS files and Typescript files in the same "project".

Re: TypeScript Won

#113

Post by WorldMaker »

jdmichal wrote: post #110
emodendroket wrote: post #84

Earlier quoted context omitted.

Isn't this kind of inherent to the JS model? I mean I guess you could rewrite the names of types at compilation but that would create other problems

No, because I'm shadowing the type, not overwriting it. JS doesn't have namespace scoping, and therefore everything has to be explicitly scoped. So if I create `my.awesome.Date`, just `Date` means JavaScript's `Date`, and I have to put `my.awesome.Date` to get the new type. Typescript adds namespaces and scoping rules, so that anything in the `my.awesome` namespace or any namespace below it will see `Date` as `my.awe…

Typescript's following the usual JS scope closure rules: the namespace syntax is sugar for the usual sort of JS "IIFE" object pattern, which you should be able to plainly see in the transpiled output.

Because Date is a data type, not every browser may attach `Date` to the global `window` object. I can't think of one that does not, but it's one of those cases where JS has always been ambiguous.

That said, Typescript is more than happy to let you `(window).Date` assert your way to that global. Or if you feel particularly strongly about this, you could in increasing order of strength of opinion: 1) add .d.ts file somewhere augment window yourself with Date, 2) fork the lib.d.ts and use your own instead of the default, 3) send a PR to Typescript adding it to the default lib.d.ts and see if they have a stronger reason for it not being there beyond it just being ambiguous in the JS language/spec/library.

Re: TypeScript Won

#114

Post by ratbeard »

mordocai wrote: post #45
knowtheory wrote: post #21

I could quibble with the conflation of correlation w/ causation for a lot of the comments this post makes about es6/babel or coffeescript. But each time i re-read this post, the cohesive point that pops out most is that this post is basically a Donald Trump speech about Typescript. The claim is that it's bigger, it's better, and everyone else is a bit sad. It disingenuously claims that it's not about about competitio…

On point 2, I don't think an optional type checker has any real downsides that I can think of (optional because with typescript you don't have to add type annotations to your code). It helps with debugging and possibly performance but you can choose not to use it. The rest of your comment I agree with.

A downside is everyone on your team has to learn how to use it.

Re: TypeScript Won

#115

Post by Touche »

nathancahill wrote: post #108
Touche wrote: post #102

Earlier quoted context omitted.

No they didn't, it's still under active development, last release 4 days ago. Ditto for Closure which is actively developed (and is among the best libraries in ES6 features) but also lost the hype cycle to Uglify.

Uglify? Webpack would have been the better comparison if we're talking straight hype factor.

You must be young. There was a time when Closure was the most used library for minification. Before that it was the YUI Compressor. Anyways, Node came out and Uglify worked with Node and Closure didn't and even though Closure had some benefits like dead code elimination (which was eventually added to Uglify but not sure if as good or not - regardless it wasn't there at first) Uglify still won out.

Re: TypeScript Won

#116

Post by jdmichal »

WorldMaker wrote: post #113
jdmichal wrote: post #110

Earlier quoted context omitted.

No, because I'm shadowing the type, not overwriting it. JS doesn't have namespace scoping, and therefore everything has to be explicitly scoped. So if I create `my.awesome.Date`, just `Date` means JavaScript's `Date`, and I have to put `my.awesome.Date` to get the new type. Typescript adds namespaces and scoping rules, so that anything in the `my.awesome` namespace or any namespace below it will see `Date` as `my.awe…

Typescript's following the usual JS scope closure rules: the namespace syntax is sugar for the usual sort of JS "IIFE" object pattern, which you should be able to plainly see in the transpiled output. Because Date is a data type, not every browser may attach `Date` to the global `window` object. I can't think of one that does not, but it's one of those cases where JS has always been ambiguous. That said, Typescript i…

> Typescript's following the usual JS scope closure rules: the namespace syntax is sugar for the usual sort of JS "IIFE" object pattern, which you should be able to plainly see in the transpiled output.

Yes, and in the transpiled output I will see `Date` turned into `my.awesome.Date` for files within the namespace scope. As I said, JavaScript is always explicitly scoped, so unless you shadow it with a local variable or overwrite the original, you can always access it. So I could easily write `my.awesome.Date` in JavaScript without shadowing the native `Date`, but I cannot do that in TypeScript because of the namespace scoping rules it adds. Which, pains of using TypeScript being the original prompt, seemed quite relevant.

Re: TypeScript Won

#117

Post by shrugger »

nathancahill wrote: post #101
shrugger wrote: post #5

I love the piegonhole arguments that always 'exclude' Dart from these types of discussions. Class-based vs prototype-based, classes will always win. JS is terrible, TypeScript is only very slightly better. Dart's core team is absolutely world class, and the language is already highly capable.

JS has classes.

JS has a syntactic sugar keyword class. Objects are still prototypes.

Re: TypeScript Won

#118

Post by kowdermeister »

nathancahill wrote: post #99
kowdermeister wrote: post #81

If I absolutely must choose a "winner" (what does that even mean?) then I would give the golden medal to the one that has a standard behind it. I think it's a very pointless thing to pick a winner. It's not a popularity contest. You will be able to tell that some technology is "lost" or is over, when the popularity will be declined to the 0.0.1 alpha release state.

The standard doesn't keep up fast enough with the pace of development in the JS ecosystem. That's why Babel's plugin architecture is so great. It allows super fast paced experimentation with new language features, without having to get buy-in from browser vendors or even JS family languages.

That's true and experimentation is good thing, just look at CoffeeScript, although I never liked it.

However I always bet on technologies that are standardized rather than maintained by a company. Not a fail safe approach, I know, but that's the way I minimize risk.

Re: TypeScript Won

#119

Post by SonicSoul »

chimeracoder wrote: post #63
doodpants wrote: post #53

Earlier quoted context omitted.

I have no experience with TypeScript, but in general the downside of optional language features is when you're working with a team, and different people end up using different dialects of the language.

That doesn't really apply here, because type annotations have no runtime effect. They're effectively comments.

you could say that about any high level language. i.e. that it's effectively metadata few levels above metal ignored at runtime. But it is relevant here because the relevant part is working with application code within a team half of which may choose to use optional features

Re: TypeScript Won

#120

Post by WorldMaker »

Touche wrote: post #107
WorldMaker wrote: post #104

Earlier quoted context omitted.

In dev workflows you can deal with the extra few milliseconds of transpilation time just like you deal with the extra few milliseconds of overhead from any of your other dev tools. Plus, even a bunch of dev workflows are increasingly using tools like gulp-watch in the background of their refresh cycle (for whatever reasons), and Typescript's watch support has gotten very good.

You can "deal with" a lot of things, but that doesn't make them desirable. It's not like the community has evolved towards build scripts because build scripts are great, it evolved in that direction because the ecosystem has changed faster than the web has been able to keep up. Once the web catches up on the module front you'll definitely see the refresh workflow regain some lost popularity.

Maybe? There's always an "ES Next" in the evergreen world. There's always some feature you might want to use today that a build tool makes accessible that otherwise you'd wait months/years for browser support to "catch up". The goal posts will keep moving, especially now that TC39 is working on an "agile" yearly spec release cycle.

After modules there's async/await and after that there's plenty more future to discover...

Post reply on HN