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

131–140 of 201 posts

Re: TypeScript at Google

#131

Post by davedx »

a_humean wrote: post #88
conover wrote: post #21

Earlier quoted context omitted.

The codebase powering www.twitch.tv utilizes TypeScript and I can’t imagine working on a project of any significant size without leveraging it going forward.

So I know you also use React extensively at twitch, so how are you finding react and typescript working together? I've been using the two together recently and its been great. Like you I don't think I could ever go back to not using typescript for anything but the smallest projects. However, often times I've found some common react patterns to be difficult to express in typescript. Namely default props and high order…

My pet peeve with TypeScript and React isn't with React but some parts of the ecosystem, like redux-saga: there are subtle issues with using the saga operators that mean that although the compiler makes it look like type inference is working, you've actually lost the type being ``taken`` from redux with redux-saga. To maintain type safety, you need to do funny things like "typeof sagaFunction".

Little things like this can add up to subtle bugs and tech debt if you're not careful.

Re: TypeScript at Google

#132

Post by markn951 »

martin_drapeau wrote: post #116
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…

In my experience old JS code suffers from lack of structure and discipline much more than type safety. Can you provide an example where that isn't the case in your codebase?

Nope, that’s absolutely the issue. But we figure we can do both at the same time, and type safety hasn’t hurt anything.

Re: TypeScript at Google

#133

Post by sureaboutthis »

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.

Re: TypeScript at Google

#134

Post by pmoleri »

Raphael wrote: post #85
Vinnl wrote: post #72

Earlier quoted context omitted.

Although it's clear that Facebook's libraries, among which React, favour Flow, there's strong community demand for TypeScript even around React. Thus, the type definitions that are available for React are excellent, Redux even includes its type definitions natively, and most of the large tools in the React ecosystem work pretty well with TypeScript. The main large project you're likely to use that does not really pla…

Create React App is the first link that TS gives you in "getting started". Is there something wrong with it? https://github.com/Microsoft/TypeScript-React-Starter#typesc...

CRA is a set of packages, among which the most important is react-scripts (contains all build and publish commands). For Typescript you use rect-scripts-ts, a fork that usually is some versions behind the main one.

It does work fine, but sometimes you don't get some of the gooddies that you get in the latest js version.

Re: TypeScript at Google

#135

Post by Bjartr »

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.

Re: TypeScript at Google

#136

Post by sanderjd »

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 first part of that, but only TypeScript is doing the second part. I guess there's a third important part too: choosing a really good set of semantics based on that trade-off. I think TypeScript has really nailed that one. I like Dart and Elm too, but TS is definitely in the sweet spot for me.

Re: TypeScript at Google

#137

Post by delusional »

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…

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 the language useful while it's left unimplemented in Google's very own browser (A fact that never ceases to entertain me). The next web language shouldn't compile to JS, it should replace JS.

As JS becomes the asm of the web, TypeScript is going to become the C of the web. Just enough abstraction to make it possible to write, but still not enough to tank performance.

Re: TypeScript at Google

#138

Post by 52-6F-62 »

pdelgallego wrote: post #114
kylecordes wrote: post #14

Earlier quoted context omitted.

I'm really eager to see availability of some extra features via this new pathway. But I am less excited about projects containing TypeScript plus the large number of transitive dependencies from a typical Babel set up; I've been greatly enjoying TypeScript instead of that.

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?

Re: TypeScript at Google

#139

Post by evmar »

modernerd wrote: post #74

The author says they contemplated an “abandon this ruined planet” option, mentioning Haxe/Clojure/Elm as alternatives. I'd love to read their follow-up post to learn what kept them on planet JavaScript/TypeScript. The alternatives to TypeScript seem increasingly compelling to me. It was good to see Haxe mentioned even in passing; I really enjoy using it and — as others have noted[1] — it feels like a “better” TypeScr…

The mastermind behind our TypeScript project commented on this topic here:

https://news.ycombinator.com/item?id=17896925

I used to tinker a lot with OCaml around 13 years(!) ago. It's neat to see people are still working on fixing some of its problems. It would be fun to find a reason to use it again.

Re: TypeScript at Google

#140

Post by acemarke »

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.

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 around a copy of FF24 just to debug the client. The entire app had to be recompiled every time I made an edit and refreshed the page, wrapping JS libs to expose them to the Java code was a pain, and no one else on the team I moved to had ever worked with GWT. The discussion around this notional "GWT 3.0" didn't help either - it sounded as if half of the technologies around GWT would be removed, like GWT-RPC, but at the same time all the threads about it have been saying "well, J2CL is still internal to Google, we'll get it out eventually". Really uncertain future there.

I spent the next couple years working on a JS app, introduced Backbone+Marionette, and became comfortable with JS. In mid-2015, I began exploring the idea of rebuilding my app's client with a modern JS stack, and decided to try these "React" and "Redux" things I was reading about. Prototyped a client rewrite, and it was clear this was the way to go.

A few months ago that rewrite finally reached feature complete, and I got to go in and rip out every last line of GWT in the codebase. I was absolutely GLEEFUL when I did that :) The React+Redux codebase, with Webpack+Babel as the build toolset, allows us to iterate so much faster and with a better dev experience.

I can understand why GWT would still have some semblance of usefulness in certain enterprise situations, but I would never touch it again myself.

Post reply on HN