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

191–200 of 201 posts

Re: TypeScript at Google

#191

Post by stolsvik »

Bjartr wrote: post #135
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…

Technically GWT is still an active project. They're (slowly) working towards a 3.0 release. I use GWT in my day job.

Tried Vaadin? It's a different take on the "write Java rich client code and run it in browser"-idea. It uses GWT as its "backend". They switched to GWT several years ago - too bad if they have to switch again due to GWT dying.

Re: TypeScript at Google

#192

Post by Karupan »

smt88 wrote: post #22
Karupan wrote: post #12

I love typescript as a JavaScript developer, but having used go for personal projects, I find the type system complex (maybe necessarily so). Having said that, I cannot thank TS enough for how it’s made life easier when working on and refactoring large codebases.

I don't know what you find complex about the type system, but I actually find it slightly limiting. They keep improving it, so it can express about 95% of what I want, but I still hit situations where I can't tell the compiler everything.

My comment was in the context of having used Golang. It maybe a personal experience as I primarily come from dynamic, weakly typed languages, and TypeScript and Golang are my first serious foray into typed languages.

Re: TypeScript at Google

#193

Post by aggre »

I switched from Flow to TypeScript. Flow has some type-declared libraries, but it's fewer than TypeScript type-declared libraries. The excellence of VSCode also helps me.

Re: TypeScript at Google

#194

Post by 52-6F-62 »

steveklabnik wrote: post #164
52-6F-62 wrote: post #138

Earlier quoted context omitted.

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.

Cheers, Steve. I missed that.

Re: TypeScript at Google

#195

Post by neop1x »

Web shouldn't end up this way. Web was designed for sharing documents. Webs and webapps now are sluggish and take soooo much RAM. I have a pretty fast computer with 16GB RAM but running all these webapps with Megabytes of javascript is bringing back -5years experience and can fill up my RAM. I know it is still improving but webapp developers are also quick with abusing every performance gain often for unwanted and unneded functionality. For example CSS animations for every mouse over, material clicking highlights are terrible, terrible design decisions which occassionally even spin up my laptop fan.

Re: TypeScript at Google

#196

Post by munificent »

jadbox wrote: post #173
munificent wrote: post #167

> 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, whi…

I mostly know Typescript, but I'd like to learn more about Dart... particularly where the type system differs in theory. Do you have a good recommended article on that? The other question is the community one: if Dart requires type bindings (like TS .d.ts files) to the large community of JS projects, how does it plan to solve the kickstart problem. It's taken TS community many years to over just the popular js librar…

> Do you have a good recommended article on that?

I don't, but I agree it would be useful. We're not where I wish we were in terms of docs right now.

> if Dart requires type bindings (like TS .d.ts files) to the large community of JS projects, how does it plan to solve the kickstart problem.

We actually have a tool that will generate the proper Dart interop bindings given a TypeScript .d.ts file:

https://github.com/dart-lang/js_facade_gen

> It's taken TS community many years to over just the popular js libraries out there.

Dart is different from TypeScript in that we are deliberately a more batteries-included system. We wrote and maintain a full set of core libraries (collections, async, etc.) and Google has a well-funded team to ship and maintain a full-featured web framework (AngularDart).

So we aren't as stuck needing to rely on the JS ecosystem as TypeScript is. There is still tons of useful functionality that's available in JS and not yet Dart, which is why interop is important, but we have a lot of customers that can get by without needing much or any JS interop.

Re: TypeScript at Google

#197

Post by underwater »

Zalastax wrote: post #168
underwater wrote: post #90

Earlier quoted context omitted.

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...

In theory Flow has a stronger inference engine than TypeScript, which means it's more suited to incremental adoption.

TypeScript is based on an AST; which means it's inferences are limited. For example it requires you to type the parameters to a function. If the return type is derived from untyped parameters then TypeScript falls back to typing the return type as 'any'.

Flow maps the flow (hence the name) of types throughout an application, which means that it can derive the signature of a function based on the types that are passed into it. That should mean that it's a little easier to add to an existing project.

Here's an example of Flow finding an error without any type annotations: https://flow.org/try/#0PTAEAEDMBsHsHcBQBjWA7AzgF1AQwCb4BMoAv...

And TypeScript missing the same error: http://www.typescriptlang.org/play/#src=const%20add2%20%3D%2....

Re: TypeScript at Google

#198

Post by candiodari »

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…

> The problem with (b) is that you typically opt into a large ecosystem that was originally written for a very different environment. This was a big issue with GWT: people would pull Java libraries, but those libraries, amazing as many are, were not written for the web or with code size in mind. This meant using a common library like Guava required a lot of engineering effort to keep code size in check. This also applies to WASM, possibly even more so.

Didn't GWT-RPC solve most of this ? You could simply run them on the server, which was another nice property of Java. You could actually link nearly any java library together with any app and use it, even with isolation if necessary.

Re: TypeScript at Google

#199

Post by Zalastax »

underwater wrote: post #197
Zalastax wrote: post #168

Earlier quoted context omitted.

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

In theory Flow has a stronger inference engine than TypeScript, which means it's more suited to incremental adoption. TypeScript is based on an AST; which means it's inferences are limited. For example it requires you to type the parameters to a function. If the return type is derived from untyped parameters then TypeScript falls back to typing the return type as 'any'. Flow maps the flow (hence the name) of types th…

Thanks, I did not know that!

TypeScript can do type refinements based on the flow (e.g. a null check refines a type with null to one without) but can't do what you just showed. Are there any tools that can emit the inferred types to source code? I just now got a vision of using flow style type inference to gradually augment a project with either flow or TS types with very little work.

Re: TypeScript at Google

#200

Post by underwater »

Zalastax wrote: post #199
underwater wrote: post #197

Earlier quoted context omitted.

In theory Flow has a stronger inference engine than TypeScript, which means it's more suited to incremental adoption. TypeScript is based on an AST; which means it's inferences are limited. For example it requires you to type the parameters to a function. If the return type is derived from untyped parameters then TypeScript falls back to typing the return type as 'any'. Flow maps the flow (hence the name) of types th…

Thanks, I did not know that! TypeScript can do type refinements based on the flow (e.g. a null check refines a type with null to one without) but can't do what you just showed. Are there any tools that can emit the inferred types to source code? I just now got a vision of using flow style type inference to gradually augment a project with either flow or TS types with very little work.

Flow has an API that can expose its inferences. There are Flow to TypeScript conversion tools that might bake the types into definitions.

Ironically, we’re considering switching to TypeScript and in my team the lack of inference is seen as an advantage. It forces people to consider their types as part of the design of their interfaces.

Post reply on HN