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

171–180 of 201 posts

Re: TypeScript at Google

#171

Post by bitmapbrother »

boubiyeah wrote: post #95
eksemplar wrote: post #40

I always wonder why people think typescript is a fix for bad code. We primarily do JavaScript, and I see no issues with it when you set up governance in how to use it. I don’t think building your own libraries is really a bad thing either, in fact I think you should do so often instead of relying on 3rd party packages of quality you typically judge on how many times they’ve been downloaded if you’re being honest. I t…

How is dart superior to TS? This is so uninformed. Just like your view of what a type system does. Dart is very poorly designed, and they managed that even without the constraint of being 100% compatible with good old broken javascript. It doesn't have null safety. This right here, is enough said and yet we could continue for hours, like how its standard library made the same 20 years old mistakes as java with things…

>How is dart superior to TS? This is so uninformed.

Speaking of uninformed...Dart is significantly faster for one. It's also not encumbered by being a superset to one of the worst scripting languages ever designed and, thus, does not have to deal with all of the baggage JavaScript brings with it.

>Dart is very poorly designed.

Amusing when you consider the clusterfuck that is JavaScript.

Re: TypeScript at Google

#172

Post by ggregoire »

MBCook wrote: post #24
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.

Have you spent any real time with Flow? As I’m starting to get into the modern front end world… I do want the safety of a stronger type system but it doesn’t look like the React ecosystem has really decided which way to go. TypeScript is popular. But flow was developed by Facebook and so it’s obviously heavily used by some of the top people. I’ve only been reading about them, I haven’t chosen to use one yet. But I’ve…

I've reported 5 bugs about Flow and can list at least 10 other bugs reported by other people that I experience on a daily basis. Most of them have been upvoted by hundreds of people. Most of them have been opened 1 or 2 years ago. Most of them don't have a single reply from people working on Flow (or one of these: "yes I guess it's a valid point", "pull requests are welcome", "it's not a bug" , "we would have to rewrite a lot of stuff", without any follow-up).

That's what really frustrates me about Flow after using it for many years. We shouldn't have to rewrite valid code, write unreadable workarounds or add // $FlowFixMe annotations to avoid Flow's issues. I lead a small team of junior developers to whom I presented Flow. We now use it everywhere. But they often experience difficulties when they try to type their code. When I see what blocks them, my answer is too often "oh yeah, it's a bug in Flow. There is an issue about it on GitHub opened in 2016".

I'm right now waiting for this https://github.com/facebook/create-react-app/pull/4837 to be merged to move all my projects to TS.

Edit: and I don't blame the devs working on Flow. I guess it's more a priority issue at Facebook. Or maybe they just gave up on the community support since TS is too ahead.

Re: TypeScript at Google

#173

Post by jadbox »

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 libraries out there. Imho, I'd make a utility to convert/translate TS definitions into Dart wrappers... but that would require to support TS primitives almost 1:1.

None of this is meant to sound critical, I'm just genuinely curious on the process of language development.

Re: TypeScript at Google

#174

Post by ggregoire »

Vinnl wrote: post #72
MBCook wrote: post #24

Earlier quoted context omitted.

Have you spent any real time with Flow? As I’m starting to get into the modern front end world… I do want the safety of a stronger type system but it doesn’t look like the React ecosystem has really decided which way to go. TypeScript is popular. But flow was developed by Facebook and so it’s obviously heavily used by some of the top people. I’ve only been reading about them, I haven’t chosen to use one yet. But I’ve…

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…

Here is another PR, more recent, based on Babel 7 and its TS support: https://github.com/facebook/create-react-app/pull/4837

I'm waiting it to be merged to switch to TS.

Re: TypeScript at Google

#175

Post by [deleted] »

nathan_f77 wrote: post #106

I wonder if it's worth migrating from Flow to TypeScript? Flow has been great, but I've just tried to update to the latest version and I'm dealing with a flood of indecipherable errors, especially from the react-dnd library. Looks like no-one is really maintaining the flow types so I'm on my own, and I don't even know where to start. I also haven't been able to track down some errors, like "Cannot read property 'foo'…

[deleted]

Re: TypeScript at Google

#176

Post by 52-6F-62 »

justinsaccount wrote: post #170
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?

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

Thanks guys. I'm out of the loop.

Re: TypeScript at Google

#177

Post by alkonaut »

eksemplar wrote: post #40

I always wonder why people think typescript is a fix for bad code. We primarily do JavaScript, and I see no issues with it when you set up governance in how to use it. I don’t think building your own libraries is really a bad thing either, in fact I think you should do so often instead of relying on 3rd party packages of quality you typically judge on how many times they’ve been downloaded if you’re being honest. I t…

> just don’t write shitty code

Why do you use a screen to look at your code? Sure it helps you see what you are typing but I mean just don't type wrong to begin with and you don't need a screen to see what you just types! Just focus! Don't write that shitty code so you need a screen to keep it from being shitty.

I'm not trying to be snarky I'm trying to make the point that every single tool we use from a compiler, a type system, unit tests, a monitor... are tools we didn't have from the beginning as programmers. And every time a new tool came, there were always people saying "you don't need those crutches, just do it right instead" (Writing machine code, using punch cards etc). Also, they were always wrong.

Re: TypeScript at Google

#178

Post by sureaboutthis »

gspetr wrote: post #162
sureaboutthis wrote: post #133

Earlier quoted context omitted.

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.

Whether jQuery, which is written in vanilla JavaScript, was better or not has nothing to do with my point.

Re: TypeScript at Google

#179

Post by z3t4 »

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…

JS did already have flavours and with ES6+ we did get an entire new language ;)

Re: TypeScript at Google

#180

Post by AriaMinaei »

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…

Well, we had a 50K sloc codebase written in Flow. We had invested heavily in the type system for quality control, so we had types everywhere. This made it riskier for us to switch to another type system, which is why we stuck with Flow for longer than we should have.

The way I finally did it was that I tried out TS on a side-project that I wrote from scratch. I did expect better tooling with TS, but I was still surprised by how better the experience was.

Auto import just worked. Same with code navigation. And they made me work much faster. Intellisense was also much better. And the error messages more readable. (And they've gotten even better since)

All of these things work to some extent in flow+vscode, but the experience with TS was incomparably better.

I was still hesitant to switch the larger project to TS though, mainly because we were using some of Flow's more advanced features to type-check a function like `wrap()` in this code:

  const obj = {foo: true, bar: {baz: 2}}
  const wrappedObj = wrap(obj)
  wrappedObj.get('foo') // returns true
  wrappedObj.get('bar').set('baz', 'some string') // type error. baz must be a number
This was almost possible to do in Flow using `$ElementType` and `$Call`, but TS had no counterpart for `$Call`. Luckily though, TS soon came up with conditional types, which turned out to be a much more reliable way to handle these cases.

That's when I decided to switch the codebase to TS. It took about 5 days. It wasn't straightforward, but in the end, it gave us a much smoother developer experience.

Post reply on HN