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

TypeScript at Google

neugierig.org

Post reply on HN
Print view View original

161–170 of 201 posts

Re: TypeScript at Google

#161

Post by evmar »

sanderjd wrote: post #136
Nitramp wrote: post #124

> The first tempting option is to just abandon this ruined planet and settle a new one that doesn't even involve JavaScript. If only we invested more in GWT (a Google project that compiles Java to JavaScript) or Dart (a Google project that compiles a new language to JavaScript) or WASM or [insert your favorite language here — Clojure? Haxe? Elm?] we wouldn't need to worry about JavaScript at all! I thought about this…

This is a super interesting perspective. It seems to me that another way to strike this very tricky balance is to design a language with it in mind - so that you can choose semantics with the emulation trade-off explicitly taken into account - and invest very heavily in its ecosystem - so that you can catch up on the library, framework, and IDE front. Arguably both Dart and TypeScript (among others) are doing the fir…

Unfortunately, to take this approach you generally need it to be a new language, so it doesn't have existing ecosystem baggage to carry along, which means it is less likely to win on another axis you often care about: developer familiarity.

This is why the candidates in this space are only the upcoming ones like Dart, Elm, and maybe Kotlin. The other "compile to web" approaches that use more established languages (like emscripten for C++ or GWT for Java) tend to produce larger binaries due to carrying along their ecosystem.

This is restating GP's point, but to say it again, this tradeoff is kind of inevitable -- half the reason to want to transpile is to reuse knowledge and libraries, but then by reusing those libraries you kill your binary size.

(This dynamic reminds me of all the people who hoped they'd be able to reuse their existing web apps on mobile but ended up with bad mobile apps. I think it's possible to make a good web-based app work on mobile but it's often a rewrite from an existing web site, at which point you're often rewriting anyway and might as well use a mobile-native language.)

Re: TypeScript at Google

#162

Post by gspetr »

sureaboutthis wrote: post #133
mattferderer wrote: post #5

I'm hesitant to work in any JavaScript code base that isn't using TypeScript at this point. Two years ago, it was painful to use as any early release is but the benefits were obvious. My biggest wish for TypeScript is that it was easier to use experimental flavors that supported JS features currently being considered, such as the pipeline operator proposal.

The vast majority of web development is done using JavaScript without TypeScript despite headlines on HN and reddit.

The vast majority of web development was also done without jQuery in 2007 despite headlines on HN and reddit.

That did not mean jQuery wasn't better than the ugly ad-hoc kludges in vanilla JS most web developers used at the time.

Re: TypeScript at Google

#163

Post by STRiDEX »

jpswade wrote: post #68

I think the most fascinating thing here is that Google are turning to a language developed and maintained by Microsoft.

They forked it for a while, called AtScript [0] and then later merged efforts. So don't think they didn't try. There's things like Tsickle [1] that converts typescript for their closure compiler

[0] https://en.wikipedia.org/wiki/AtScript

[1] https://github.com/angular/tsickle

Re: TypeScript at Google

#164

Post by steveklabnik »

52-6F-62 wrote: post #138
pdelgallego wrote: post #114

Earlier quoted context omitted.

I am looking forward to see some production ready versions of RY latest project Deno "A secure TypeScript runtime on V8" https://github.com/denoland/deno

Written in Go rather than C++ no less. Edit: wait it looks like they’ve changed to all Rust with C++ for the libraries. I haven’t looked at the codebase since the spring. Am I crazy that i could have sworn it was written in Go previously?

It was in Go, but in Ryan’s announcement, he said he was considering switching, and has since done so.

Re: TypeScript at Google

#165

Post by munificent »

esrauch wrote: post #146
delusional wrote: post #137

Earlier quoted context omitted.

Could these very same arguments not be applied to Javascript itself? JS is "transpiled" to bytecode, a language with vastly different semantics and a totally different ecosystem. It end up being wildly inefficient, but consumers don't seem to mind. The description of Dart is also wrong. My understanding is that they are aiming at REPLACING JS in the browser, not compile to it. Compilation to JS is a stopgap to make t…

That was their initial goal, but it's been years since they backed off of Dartium at this point.

For what it's worth, almost no one on the Dart team ever believed that Dart would "replace" JavaScript. The memo that claimed that wasn't written by anyone on the Dart team.

Re: TypeScript at Google

#166

Post by qudat »

theprotocol wrote: post #61

I haven't used it in a while. Does it play nice with plain-JavaScript libraries from npm yet? I quit using it a few years back because it was a _nightmare_ having to write d.ts files for everything or be unable to use noImplictAny for your own files. `AllowJs` wasn't even a thing when I started using it, but even after its addition, this problem continued to be absolutely disastrous for my project. I remember being v…

There are very few libraries that I need to write type definitions for. However, they do not always get them right and sometimes can prove to be annoying when the typedefs do not keep up with latest versions of the third-party library. Any library I write now is done with typescript so typedefs are automatic which is fantastic.

Re: TypeScript at Google

#167

Post by munificent »

> If only we invested more in GWT (a Google project that compiles Java to JavaScript) or Dart (a Google project that compiles a new language to JavaScript) or WASM or [insert your favorite language here — Clojure? Haxe? Elm?] we wouldn't need to worry about JavaScript at all!

I'm on the Dart team. I don't know if the author intended this, but you could read this as saying that Google isn't investing much in Dart, which isn't true.

Flutter and Fuchsia are the high profile projects that use Dart. AdWords is also built in Dart. The Dart team itself is as large as its ever been and growing. (I'd give more precise numbers, but Google generally shies away from publicly stating personnel details.) We have a ton of internal and external code written in Dart, and it's growing at a nice clip.

Different projects have different needs. If you have a large existing JS corpus that's providing a lot of value for you, then an incremental migration to TypeScript makes sense.

If you're looking to rewrite a lot of code and pay off technical debt anyway, then moving to a new language that doesn't have all of JavaScript's baggage can be a smarter choice. Dart has a cleaner object model and fewer warts like "===", etc. Making a bigger break from JS means that Dart's type system can be simpler than TypeScript's and is sound. That in turn means the compiler can rely on types for optimization and minification.

Re: TypeScript at Google

#168

Post by Zalastax »

underwater wrote: post #90
markn951 wrote: post #7

We’re going through a similar process at my company - how do we refactor the decade old startup-style JS without 1) spending a year rewriting everything from scratch generating little business value and potentially introducing regressions in the process 2) continuing to build stuff on that shaky house of cards. It looks like the solution we’ve kind of settled on has also been TypeScript. At this point it’s probably s…

Have you looked into Flow? This is the type of project it’s suited for (gradual typing). Facebook were in a very similar position when they created it. You can add a Flow pragma to a file and immediately get useful feedback based on Flow’s type inference.

TypeScript supports doing that as well :) https://github.com/Microsoft/TypeScript/wiki/Type-Checking-J...

Re: TypeScript at Google

#169

Post by alangpierce »

davnicwil wrote: post #150
AriaMinaei wrote: post #126

Earlier quoted context omitted.

That's what I did. I switched to TypeScript after two years of being both heavily invested in Flow and advocating it. The reason I initially chose Flow was the fact that their goals were more ambitious (trying to build a sound type system for example). And there were features that Flow had and TypeScript didn't (tagged unions for example). The reason I ultimately switched to TypeScript was that after a couple of year…

> much better tooling If you have the time, would you mind commenting specifically on this? I'm using Flow, rather than TS, for a bunch of reasons you are probably familiar with, but over time I'm just wondering more and more if switching to TS might be worth it just for the tooling. With Flow in VS Code (via the flow-for-vscode plugin), whilst things have slowly and steadily improved over the last 2 years it is stil…

If you're already using VS Code, I expect you'll find TypeScript support to be much, much nicer, since VS Code is the not-quite-official editor for TypeScript programming. VS Code is written in TypeScript, and I believe the TypeScript and VS Code teams (both at Microsoft) collaborate with each other to improve the developer experience of the two used in combination. For example, here are some TypeScript release notes showing the improvements to the TS language service and how they manifest in VS Code:

https://blogs.msdn.microsoft.com/typescript/2018/05/31/annou...

TypeScript has a nice architecture that provides a language service that can be used by any editor, but my impression is that VS Code is the "flagship" editor that gets these features first.

I personally use WebStorm, and I find its TypeScript support much better than its Flow support in various ways (though I haven't tried Flow in a while). Imports get added automatically, autocomplete is fast and has better results, navigation just works, etc. Part of this is historical: WebStorm supported TypeScript first, and was hesitant to support Flow during the long period of time when Flow didn't work on Windows. It now has Flow support, but I think it's just not as polished, and I don't see it come up as much in the release notes.

Re: TypeScript at Google

#170

Post by justinsaccount »

52-6F-62 wrote: post #138
pdelgallego wrote: post #114

Earlier quoted context omitted.

I am looking forward to see some production ready versions of RY latest project Deno "A secure TypeScript runtime on V8" https://github.com/denoland/deno

Written in Go rather than C++ no less. Edit: wait it looks like they’ve changed to all Rust with C++ for the libraries. I haven’t looked at the codebase since the spring. Am I crazy that i could have sworn it was written in Go previously?

https://github.com/denoland/deno/commit/86354a29a40fb97e334f...

https://github.com/denoland/deno/pull/276

Post reply on HN