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

Migrating 300k LOC from Flow to TypeScript

medium.com

Post reply on HN
Print view View original

71–80 of 87 posts

Re: Migrating 300k LOC from Flow to TypeScript

#71

Post by z3t4 »

deckard1 wrote: post #63
jillesvangurp wrote: post #7

I recently spent some time introducing typescript to a javascript code base. My background is mostly backend/JVM, so I wasn't the perfect person to be doing this obviously. But as there was nobody else and I needed to own this stuff, I put in the work and got things done. My impressions are mostly positive in the sense that if you are doing JS, you are better off doing TS. The tooling is great and you can start with…

The problem with JavaScript is that it's a terrible example of a dynamically typed language. > The benefits are a vastly improved safety net at a very minimal cost, smarter tools That's entirely subjective. As far as tooling, I get the impression from my coworkers and what I've seen online that people that love TypeScript love big bloated IDEs. They love having their IDE tell them what to do. And, personally, I find…

Personally I'm a fan of sprinkling the code with manual checks, conversions, and early friendly error messages. Rather then spraying it with type annotations. Practically when developing and there's an error, you add a check as early as possible, that would catch the bug, like at the beginning of the function, throwing a human readable error with some added debug data. For example, lets say you have done some detective work to locate the source of a bug, and figured out the earliest possible place to detect it is in the foo() function, where the bug was caused by a missing "baz" property ...

    function foo(bar) {
      if(foo.baz == undefined) throw new Error("foo need to have a baz! foo.baz=" + foo.baz + " foo=" + JSON.stringify(foo, null, 2));
    }
Typescript could probably detect the bug in the first place if you had used interface or what not, and typed everything. Static typing (and also tests) can however slow you down when you are quickly iterating and re-writing. And at the end of the day when you have a working prototype/MVP, and have added a few manual checks that will throw early if there's a bug. Are you gonna spend your time type annotating it all (or writing tests) or are you going to spend that time marketing ?

If the product receive continuous work there will however be a tipping point where tests are needed. And the checks you added will be of help as errors will come early. But when you have tests in place, is it really worth it to spray-paint the code with annotation and make it static ? There are already tools today that can infer most types, and give you auto-completion already.

Re: Migrating 300k LOC from Flow to TypeScript

#72

Post by chaostheory »

sdegutis wrote: post #62
chaostheory wrote: post #56

Earlier quoted context omitted.

> Browsers don’t support it, so it adds an extra build step. Type-completion has gotten slower the bigger our project gets. This is something a faster computer can mitigate. Also I would compare the time you spend guessing what parameters actually are in vanilla JS vs the seconds you lose waiting for a Typescript build. Silicon time is much cheaper than carbon time. I don't understand how anyone doesn't use Typescrip…

That's the general consensus and how I mostly feel too. But I'm starting to feel like the drawbacks might possibly be outweighing the benefits.

If we were talking about Ruby or Python, you'd have a stronger point. However Typescript's benefits far outweigh its drawbacks in light of Javascript's excessive lenience. Since, you're complaining about types, have you made good use of Typescript's interfaces and class inheritance? They're pretty powerful and even more flexible than something like Java.

Re: Migrating 300k LOC from Flow to TypeScript

#73

Post by CuriouslyC »

deckard1 wrote: post #63
jillesvangurp wrote: post #7

I recently spent some time introducing typescript to a javascript code base. My background is mostly backend/JVM, so I wasn't the perfect person to be doing this obviously. But as there was nobody else and I needed to own this stuff, I put in the work and got things done. My impressions are mostly positive in the sense that if you are doing JS, you are better off doing TS. The tooling is great and you can start with…

The problem with JavaScript is that it's a terrible example of a dynamically typed language. > The benefits are a vastly improved safety net at a very minimal cost, smarter tools That's entirely subjective. As far as tooling, I get the impression from my coworkers and what I've seen online that people that love TypeScript love big bloated IDEs. They love having their IDE tell them what to do. And, personally, I find…

I don't want to have to remember the properties of every object, or the arguments to every function, or a myriad of other things. I could be using that time and energy to work on other things that are more important.

Re: Migrating 300k LOC from Flow to TypeScript

#74

Post by deckard1 »

CuriouslyC wrote: post #73
deckard1 wrote: post #63

Earlier quoted context omitted.

The problem with JavaScript is that it's a terrible example of a dynamically typed language. > The benefits are a vastly improved safety net at a very minimal cost, smarter tools That's entirely subjective. As far as tooling, I get the impression from my coworkers and what I've seen online that people that love TypeScript love big bloated IDEs. They love having their IDE tell them what to do. And, personally, I find…

I don't want to have to remember the properties of every object, or the arguments to every function, or a myriad of other things. I could be using that time and energy to work on other things that are more important.

It's not about knowing the interface to a blackbox. It's about semantics. It's about knowing what an object or function is doing.

> I could be using that time and energy to work on other things that are more important.

As a developer, it's your job to know how your code works. There really isn't anything more important than that.

Re: Migrating 300k LOC from Flow to TypeScript

#75

Post by turadg »

Great planning and tooling work by our Web Infra team at Quizlet (Roger, Karoun, Jonathan) and all the product engineers.

We're closely following this discussion so if you have any questions on some of the specifics we're happy to answer!

Re: Migrating 300k LOC from Flow to TypeScript

#76

Post by eropple »

chenglou wrote: post #65
eropple wrote: post #58

Earlier quoted context omitted.

TypeScript does not take out dynamic typing or prototypical object orientation. If you can more cleanly communicate something dynamically, do it . `any` is right there. (And I do this sometimes! Of course, code where I do this is invariably where most of my unit testing has to be, but I have the choice, and I'm making it.) And, not to be pointy, but I always get a real weird vibe about people who come rolling in prof…

I see what you’re trying to say here, but Reason (and its compiler BuckleScript) aren’t the kind of puristic language folks might think they are. BuckleScript has one of the most comprehensive way to bind to whatever piece of JS you have: https://bucklescript.github.io/ and you can also just include raw JS code as a last resort, all type checked still, while keeping type soundness (in this case, almost like `any` but…

I'm familiar with the project, and with both F# and OCaml generally. ;) And I'm not saying it's bad or anything, to be clear. I am saying that it's functionally impenetrable to most programmers. To draw an analogy to something less contentious in this crowd, Elixir, even though I quite like it, is doomed to the same fate.

TypeScript is the good-enoughest thing that doesn't surprise, and I think that's enough to put it over the top. (It helps that, in this case, "good enough" is also "very good".)

Re: Migrating 300k LOC from Flow to TypeScript

#78

Post by cryptica »

tekkk wrote: post #46
cryptica wrote: post #9

I've been using TypeScript for over 1 year after 10 years of JavaScript and I really don't like it. It slows me and the team down and creates more problems than it solves. It doesn't even ensure type safety because there is no runtime type validation for JSON objects received from the API. It's disturbing that so few people can see how useless it is. To me, it's extremely obvious. TypeScript is a hack of epic proport…

Well, as a someone who had the same initial feelings with TypeScript when it came "oh it slows me down, these types are just a waste of time", I get where you're coming from but think that you have some other issues than TypeScript with your team and project. First of I'd want to say that most of your complaints about "no runtime type validation" in the context of TypeScript/JavaScript is just how unreliable JS is as…

Also I think part of the problem is that TypeScript encourages developers to write interfaces that have complex parameters (e.g. accept instances of specific classes) whereas JavaScript encourages simpler parameters like strings, numbers or plain JSON.

In OOP, passing complex instances to functions across different files is dangerous because the different files may all end up affecting the same instance's internal state and you don't know which file is responsible for what change (and it can lead to conflicting states/bugs). The absence of types in JavaScript tends to discourage this design precisely because it makes it difficult to express those kinds of complex/rigid class relationships.

JS encourages developers to keep each kind of "live" instance in a single file and only return raw data from that file. For me, restricting all instance mutations to one file is the secret to writing good OOP code which has clear separation of concerns.

Re: Migrating 300k LOC from Flow to TypeScript

#79

Post by iLemming »

I've been reading the comments, and sorry, I can't help it. Every time I read about (or try) some trendy thing in JS/Front-end world, I feel irritated and sad. Every single "big promise" hype that supposed to help us to "fix" issues with front-end development adds more complexity and frustration. jQuery was awesome, then "okay", then become bad, then later really, really bad. Same with Backbone. Same with Angular and Web components. Then Coffescript, Livescript, GorillaScript, IcedCoffeeScript and other "x-cripts", Dart, Typescript and Flow, Traceur and Babel. Then Grunt, Gulp, Browserify, WebPack. React came, and we got Flux, Redux, Redux Saga, MobX. And then some stuff that's actually not too bad for whatever reasons gets mostly ignored, e.g. Meteor, Ember, Cycle.js.

I think fundamentally something deeply wrong with all that, and I don't know when and how we're going actually to fix it. After years of trying, I finally decided enough is enough and started looking for deferentially alternative solutions. I like Purescript and Elm. ReasonML looks promising. Currently, I'm using Clojurescript. It is not a silver bullet, but it is an astonishingly practical choice. I know - it won't work for everyone. The majority would dismiss it almost immediately (mostly for the wrong reasons).

I'm not advocating for it. I'm just saying that I feel Typescript is not that magical pill that makes everything better. If you follow @garybernhardt on Twitter, I think he may feel the same.

Re: Migrating 300k LOC from Flow to TypeScript

#80

Post by jillesvangurp »

deckard1 wrote: post #63
jillesvangurp wrote: post #7

I recently spent some time introducing typescript to a javascript code base. My background is mostly backend/JVM, so I wasn't the perfect person to be doing this obviously. But as there was nobody else and I needed to own this stuff, I put in the work and got things done. My impressions are mostly positive in the sense that if you are doing JS, you are better off doing TS. The tooling is great and you can start with…

The problem with JavaScript is that it's a terrible example of a dynamically typed language. > The benefits are a vastly improved safety net at a very minimal cost, smarter tools That's entirely subjective. As far as tooling, I get the impression from my coworkers and what I've seen online that people that love TypeScript love big bloated IDEs. They love having their IDE tell them what to do. And, personally, I find…

The safety net thing is absolutely factual. Typescript will tell you "this is a type error, fix it". Javascript will not and fail at run time for the same error. So, one is an error that is stopped from happening, the other is a preventable error that your safety net (or lack of one) fails to catch. That was only excusable as long as there was no feasible safety net. Now that there is one, deliberately opting out from it is simply unprofessional and irresponsible.

This in a nutshell is why world + dog is introducing typescript to their codebases. It obviously won't catch all bugs but it will catch more of them. The alternative of not using it simply inexcusable and the people arguing against it tend to not have a very solid case and indeed focus on what arguably is highly subjective like e.g. your claim that it is "ugly". IMHO JS without types is ugly (opinion) and less safe (fact).

I agree typescript is not perfect; I agree it is super sloppy, actually. Even the strict mode still allows a lot of stuff that you should probably should not do (like slapping the any type all over the place). That's why I call it a gateway drug. If you like the little that typescript does, there are other languages that are better.

If typescript is "killing your organization", you should consider leaving. There are all sorts of reasons for organizations to become dysfunctional. The problem always boils down to people, not technology. I'd argue that given your statements, you are possibly part of the problem and not the solution here.

Post reply on HN