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

151–160 of 201 posts

Re: TypeScript at Google

#151

Post by mwcampbell »

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…

Kotlin looks promising. Sure, you can use the whole JVM ecosystem with Kotlin/JS or Kotlin Native. But it looks like JetBrains is trying to bootstrap a JVM-independent Kotlin ecosystem.

So why Kotlin instead of TypeScript?

1. Potentially more static optimization, because Kotlin is designed from the start for static typing. 2. Ability to target other platforms (Android, iOS, desktop) without adding the overhead of a JS runtime.

Why not Scala?

1. Scala's standard library is heavier. For instance, Scala has its own collection classes, whereas Kotlin merely has its own collection interfaces. I assume this is why Scala.js advertises a starting size of 45 KB gzipped for an optimized build. That's not actually very small. 2. On the JVM, Scala fundamentally gets interop wrong in at least one way: Java getters and setters don't automatically become Scala properties, as they do in Kotlin. So idiomatic real-world Scala requires more wrappers.

The one thing that worries me about Kotlin is that it has reflection instead of compile-time metaprogramming (e.g. macros). Wherever reflection is used, it impedes static optimization (e.g. ProGuard, other tree-shaking). Sure, real-world JVM work has to use reflection sometimes, but at least JetBrains should have refrained from providing an API for doing Kotlin-specific reflection, and provided something like macros instead. (Edit: And yes, the Kotlin reflection API is implemented in the JS back-end. That was a mistake.)

Re: TypeScript at Google

#152

Post by leppr »

dvlsg wrote: post #65
Bahamut wrote: post #55

Earlier quoted context omitted.

At this point, I think Flow clearly has a minority mindshare & is looked at more skeptically all around the JS ecosystem, and maybe even the React ecosystem based on what I see talked around. TS does a much better job integrating with existing JS and is much more practical about incremental updates whereas Flow bleeds all too easily into needing to add typing to a significant amount of code in order to add a type. Th…

I didn't have too many problems with typescript and ramda. I occasionally have to explicitly send in types to the first function of a pipe, which is a little annoying, but for the most part it seems to just work for how I use it. What problems have you run into?

Have a look at the typescript declaration for Node's util.promisify (sorry on mobile can't find it right now). It's something like 10 lines long and covers only a handful of cases.

It's not something you'd want to find in the middle of your code, yet you may have to if you want to do generic/functional programming in TS.

Re: TypeScript at Google

#153

Post by [deleted] »

MBCook wrote: post #36
Devagamster wrote: post #33

Earlier quoted context omitted.

For what it's worth typescript is developed by Microsoft. Doesn't get much bigger than that

I know, and that’s a definite plus. I don’t have to worry that it will go away or lose all the main contributors. But is not developed by the same developers/company as React. I will say given what TS is competing against the fact that it so well used is rather compelling. I know all of Angular is also written in TS. It’s clearly very heavily used.

[deleted]

Re: TypeScript at Google

#154

Post by leppr »

egeozcan wrote: post #64
TheAceOfHearts wrote: post #8

Earlier quoted context omitted.

TypeScript was released in 2012, I wouldn't call a 4 year old tool an early release. And if you were already using Webpack picking it up was as easy as adding a loader. IMO, using such early proposals isn't worth the risk in production. Especially for proposals that are so young that they haven't even settled on a clear spec as to its behavior, like the pipeline operator.

Sorry this is self promotion but I think it's relevant if you need something like the pipe operator now: https://github.com/egeozcan/ppipe It's also ironic that I couldn't write this in Typescript because I simply couldn't figure out how. These days when I use my helper, I just use any and cast the result. It sucks but until I figure out how to type proxies and use variadic generic type parameters (if and when these…

The "official" Typescript solution to variadic type parameters is to write a bunch of overloads covering the most frequent cases, e.g. from 1 to 5 parameters.

Re: TypeScript at Google

#155

Post by steadicat »

leppr wrote: post #154
egeozcan wrote: post #64

Earlier quoted context omitted.

Sorry this is self promotion but I think it's relevant if you need something like the pipe operator now: https://github.com/egeozcan/ppipe It's also ironic that I couldn't write this in Typescript because I simply couldn't figure out how. These days when I use my helper, I just use any and cast the result. It sucks but until I figure out how to type proxies and use variadic generic type parameters (if and when these…

The "official" Typescript solution to variadic type parameters is to write a bunch of overloads covering the most frequent cases, e.g. from 1 to 5 parameters.

TypeScript 3.0 fixed this: https://blogs.msdn.microsoft.com/typescript/2018/07/30/annou...

Re: TypeScript at Google

#156

Post by stickfigure »

acemarke wrote: post #140
Bjartr wrote: post #135

Earlier quoted context omitted.

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

I used GWT to build an app in 2011-2012. It was my first web app, and it needed to have a desktop-like feel. GWT + the SmartGWT UI library allowed me to leverage my existing experience with Java, its IDEs and tooling, and various desktop GUI frameworks to build an app that did what I needed. But, over time GWT became a hindrance rather than a help. The DevMode plugin stopped working as of FF27, and I had to keep arou…

I think GWT suffered from being a bit too early. If source maps and Java8 closures existed in the early days, GWT would have been a lot more compelling.

I also did a lot of GWT work about a decade ago and haven't touched it since. But there's a lot of things I miss, and I would be willing to consider a "modernized" GWT if it ever materializes. I especially miss GWT-RPC; statically checked typesafe interfaces are just much faster and safer than hand-coding REST interfaces and hoping the client and server agree.

That said, I do think the train came off the rails when added all that crazy model-blah-blah-presenter pattern stuff. If GWT is ever going to make a comeback, it needs some sort of simple equivalent of Angular or React.

Re: TypeScript at Google

#158

Post by acemarke »

stickfigure wrote: post #156
acemarke wrote: post #140

Earlier quoted context omitted.

I used GWT to build an app in 2011-2012. It was my first web app, and it needed to have a desktop-like feel. GWT + the SmartGWT UI library allowed me to leverage my existing experience with Java, its IDEs and tooling, and various desktop GUI frameworks to build an app that did what I needed. But, over time GWT became a hindrance rather than a help. The DevMode plugin stopped working as of FF27, and I had to keep arou…

I think GWT suffered from being a bit too early. If source maps and Java8 closures existed in the early days, GWT would have been a lot more compelling. I also did a lot of GWT work about a decade ago and haven't touched it since. But there's a lot of things I miss, and I would be willing to consider a "modernized" GWT if it ever materializes. I especially miss GWT-RPC; statically checked typesafe interfaces are just…

Yeah, it's kind of funny when you look at what GWT had vs what modern JS development looks like. Multiple browser targets, using the same language on both client and server, static types, RPC declarations, a dev mode server, etc.

That said, GWT-RPC also went from being nice to a pain. The serialization formats were "proprietary", in the sense that they were GWT-specific and couldn't be reused with any other platform. There were actually two separate formats. Client->server was some kind of custom text format, while server->client was _technically_ JSON, but the contents were still basically opaque. (I found a document that tried to reverse engineer the format, and it was pretty ugly.) That was another pain point, actually - inspecting API calls in a browser's Network tab was useless, because you couldn't interpret anything out of the contents. Also, I'll take promises (and `async/await`) over GWT's ugly `MyRpcInterface/MyRpcInterfaceAsync` definitions and success/failure handlers any day.

When I rebuilt my app, I was lucky enough to be able to re-expose the same internal API endpoint implementations over JSON-RPC. That let me keep my existing backend logic, and build out the new JS client separately while keeping the old one in place until the new one was ready.

Re: TypeScript at Google

#159

Post by EE84M3i »

shadowmint wrote: post #69
EE84M3i wrote: post #23

Earlier quoted context omitted.

Sorry if this is a well known term but what is a "proptype hint" in this context? I can't seem to find any references for '"proptype hint" "javascript"' or any variations that come to mind on Google. Edit - changed previous sentence to "proptype hint". I originally erroneously read the parent as saying "prototype hint" which I couldn't find results for, but even after correcting my reading error my question still sta…

github.com/facebook/prop-types is the 2nd google search result for this term, and is what I was referring to, although the first result (devhints.io/react#property-validation) is arguably a better summary. Ie. ‘lite’ type checking, used in react. (did you perhaps see the results for ‘javascript prop type hint’ as a google autocorrect suggestion or something? This is a well known term, but I’m pretty amazed two second…

Yes I found the prop-types library, but it doesn't include the word "hint" and I couldn't find any documentation that did. I assumed there this was an obscure term of art you were refering to.

Re: TypeScript at Google

#160

Post by stickfigure »

acemarke wrote: post #158
stickfigure wrote: post #156

Earlier quoted context omitted.

I think GWT suffered from being a bit too early. If source maps and Java8 closures existed in the early days, GWT would have been a lot more compelling. I also did a lot of GWT work about a decade ago and haven't touched it since. But there's a lot of things I miss, and I would be willing to consider a "modernized" GWT if it ever materializes. I especially miss GWT-RPC; statically checked typesafe interfaces are just…

Yeah, it's kind of funny when you look at what GWT had vs what modern JS development looks like. Multiple browser targets, using the same language on both client and server, static types, RPC declarations, a dev mode server, etc. That said, GWT-RPC also went from being nice to a pain. The serialization formats were "proprietary", in the sense that they were GWT-specific and couldn't be reused with any other platform.…

I agree the implementation of GWT-RPC could have been better. It was also pretty slow if the payload was a lot of tiny objects. But I'm less enthused with promises than you are; I like GWT-RPC's programming model.

I'm surprised some sort of IDL-based client & server generator for REST services hasn't taken off.

Post reply on HN