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

Ten Years of TypeScript

devblogs.microsoft.com

Post reply on HN
Print view View original

121–130 of 147 posts

Re: Ten Years of TypeScript

#121

Post by gherkinnn »

mirekrusin wrote: post #73
gherkinnn wrote: post #59

Earlier quoted context omitted.

In practice I’m very happy with structural types. It provides all the safety I could wish for and slots in well with the underlying language and broader ecosystem. Though I do miss an easy way to create something like a type Email of string, as it conforms to a set of rules. But that’s a small price to pay.

Flow has structural typing on types and nominal on classes with correct inheritance semantics, which simply makes sense. For making Email type distinct from string, you want opaque type (first class in flow) which you can emulate as tagged type in ts.

Oh! Interesting. I was unaware of Flow’s details. Though I never program in an OOP style so I wouldn’t have noticed those nuances anyway.

I know of TS’ opaque types, but it always feels dirty. So here I am, relying on named params instead.

Re: Ten Years of TypeScript

#122

Post by roflchoppa »

I switched this year to working at a company who uses typescript for backend systems after working as a python dev for 3 years.

It’s not that I hate it, it’s just that TS/JS does not give you anything in terms of built-ins. This testing suite is so fragmented, it’s this ugly thing that I dread working with.

Anyone have advice for repos I can use that have rich testing frameworks? Or books? I’d love to learn to love TS, but it’s not there yet.

Re: Ten Years of TypeScript

#123

Post by ht85 »

umvi wrote: post #102
ht85 wrote: post #48

Earlier quoted context omitted.

If I understand correctly, before moving to TS / npm, you would concatenate your library files and your own code, and in your own code reference libraries using some kind of global variable à la `$.` for jquery? If that's the case, you could add the libraries .d.ts to your project and augment the global.Window interface with types pulled from those definitions. You would then be able to call `window.something` and ha…

Yes, that's exactly right. I just include pixi.min.js which exposes the "PIXI" global variable. > If that's the case, you could add the libraries .d.ts to your project and augment the global.Window interface Do you know where I can find an example of this? I've been able to do "npm install pixi.js", which gives me access to the .d.ts file but I'm not sure how to then map those types to the global PIXI object exposed…

Here is a minimum "repro" of your use case:

tsconfig.json

    {
      "include": ["index.d.ts"],
      "compilerOptions": {
        "target": "es2015",
        "lib": ["es2015", "dom"],
        "moduleResolution": "node",
        "allowSyntheticDefaultImports": true
      }
    }
index.d.ts

    import * as PIXI from 'pixi.js'

    declare global {
      interface Window {
        PIXI: typeof PIXI
      }
    }
index.ts

    console.log(window.PIXI)
There is still an import but because it is in the .d.ts file it won't be included in the runtime code.

Re: Ten Years of TypeScript

#124

Post by rikroots »

qxxx wrote: post #120

am I the only one who hates typescript?... development time is extended because you need to create all the types / interfaces for every variable and function. And you blow up the already complex / almost unreadable code with type definitions. Some of the definitions can be very complex, a dev needs time to decrypt what other dev wrote and what I can finally use as a parameter in a function. Sometimes even if you put…

I don't "hate" TS. I understand how useful it can be. But I don't enjoy working with TS code - especially in large codebases which have been touched by many developers, each with their own understanding of how to use TS. When it comes to the world of professional web development it's up to me to adapt to the project's coding requirements, not the other way around.

Re: Ten Years of TypeScript

#125

Post by pragmatic »

dynamite-ready wrote: post #41
umvi wrote: post #32

I like the idea of typescript. I tried to port a vanilla js browser game to typescript and I found it introduced a lot of complexity to the project. It sucked me into the npm ecosystem and forced me to rewrite every file to use js modules import/export syntax and a bundler like webpack to resolve all the modules business for browsers when none of those were needed before. Of course I could set TS modules to none but…

This is closer to my opinion. I write a fair amount of Typescript, but it's frustrating to see it used so ubiquitously, when in a lot of cases it's just not necessary. A strongly typed language definitely has a place in web UI development though. But my hope is to see it replaced by a WASM based language, or better still, a choice of WASM based languages.

In what cases do you see it when when not necessary?

Re: Ten Years of TypeScript

#126

Post by nextaccountic »

dccoolgai wrote: post #101
eyelidlessness wrote: post #88

Earlier quoted context omitted.

I’m curious what you’re distinguishing here. To me a type system and a contract system are identical concepts with different descriptions. It seems like you might be highlighting the structural typing aspects of TypeScript’s type system versus nominal or concrete types in many others, but that’s been clear for most TS usage for since well before `satisfies` so I’m not sure if my interpretation is right.

For a start: https://en.m.wikipedia.org/wiki/Design_by_contract

Traditional design by contract checks the contracts at runtime. They can be understood as a form of dynamic typing with quite complicated types, which may be equivalent to refinement types

But you can check contracts at compile time too. It's quite the same thing as static typing with something like refinement types. That's because, while with contracts we can add preconditions like "the size of this array passed as parameter must be a prime number", with refinement types we can define the type of arrays whose size is a prime number, and then have this type as the function argument. (likewise, postconditions can be modeled by the return type of the function)

See for example this Rust library: https://docs.rs/contracts/latest/contracts/

It will by default check the contracts at runtime, but has an option to check them at compile time with https://github.com/facebookexperimental/MIRAI

Now, this Rust library isn't generally understood as creating another type system on top of Rust, but we could do the legwork to develop a type theory that models how it works, and show the equivalence.

Or, another example, Liquid Haskell: https://ucsd-progsys.github.io/liquidhaskell/ it implements a variant of refinement types called liquid types, which is essentially design by contract checked at compile type. In this case, the type theory is already developed. I expect Liquid Haskell to be roughly comparable to Rust's contracts checked by MIRAI.

Now, what we could perhaps say is that refinement types are so powerful that they don't feel like regular types! And, while that's true, there are type systems even more powerful: dependent types used in languages like Coq, Lean and F* to prove mathematical theorems (your type is a theorem, and your code, if it typechecks, is a proof of that theorem).

Dependent types were leveraged to create a verified TLS implementation that mathematically proves the absence of large class of bugs, miTLS https://www.mitls.org/ (they discovered a number of vulnerabilities in TLS implementations and proved that their implementation isn't vulnerable), and HACL* https://github.com/hacl-star/hacl-star a verified crypto implementation used by Firefox and Wireguard. They are part of Project Everest https://project-everest.github.io/ which aims to develop provably secure communications software.

Re: Ten Years of TypeScript

#127

Post by pragmatic »

smcleod wrote: post #72

Typescript as a language isn't too bad but the ecosystem is an absolute dumpster fire. NPM is terribly fragmented, costs a fortune in effort to maintain dependencies, security updates etc... Every Typescript/JS project I work on is full of a dangerous amount of third party dependencies - it can be hundreds if not thousands in a single repo - many of them fragile in their own special way. Language packages management…

You can't blame TS for JavaScript.

It's mashing things better by making lib authors like about their API.

jQuery typing showed what a shitty api it actually was. You had no idea what you'd get back f on a call, one element, an array, what type of element.

It made it impossible to build reliable software and why everyone hates jQuery now.

So many early projects had "magic" APIs to save you a few characters or lines of code, only to become a maintenance nightmares because without the docs (or TRYING to analyze source) you had no idea what it did or how.

Re: Ten Years of TypeScript

#128

Post by pragmatic »

k__ wrote: post #93
losvedir wrote: post #84

Earlier quoted context omitted.

Typescript as a language is better than "isn't too bad", it's great! I love the syntax for unions and how normal things like "if" will narrow types. But I agree that it's a shame that the JS ecosystem is such a mess. Granted, dealing with it is essentially Typescript's purpose, but I would love for it to be a full fledged language on its own, divorced from JS. How cool would it be if you could write normal backend ap…

I wished Flow or ReScript would have won. TypeScript is too C#-ish for my taste. Well, still better than nothing, I guess.

Look at the Typescript repo itself.

Very much not like C#. Frameworks like Angular use it very much like c# though.

Re: Ten Years of TypeScript

#129

Post by nextaccountic »

robocat wrote: post #83
repox wrote: post #58

I've spent the last two years working with TypeScript solely. Coming from ~20 years with PHP and using Kotlin and Dart for some years as well, I feel that I'm doing something wrong. I absolutely loathe working with TypeScript. The community is the most fragmented I've ever experienced, the silly amount of package managers, builders... TypeScript just doesn't fit with me.

That is the same as saying you hate Kotlin because Android annoys you. Or blaming JavaScript for the browser DOM. Please correctly blame the ecosystem that you dislike, instead of thoughtlessly using a language as a label for an ecosystem.

The developer experience must be evaluated holistically, because languages don't exist in a vacuum. The JS tooling, libraries and community absolutely impacts on how it feels like to be a Typescript developer.

The Kotlin situation isn't comparable because there is an established community that uses Kotlin in the backend, without using Android.

But perhaps you could compare with Swift: while Swift may technically run on non-Apple systems, that's not the experience of most developers. So it's totally valid to avoid Swift because you don't want to deal with Apple and Xcode.

Re: Ten Years of TypeScript

#130

Post by pragmatic »

qxxx wrote: post #120

am I the only one who hates typescript?... development time is extended because you need to create all the types / interfaces for every variable and function. And you blow up the already complex / almost unreadable code with type definitions. Some of the definitions can be very complex, a dev needs time to decrypt what other dev wrote and what I can finally use as a parameter in a function. Sometimes even if you put…

"And you blow up the already complex / almost unreadable code with type definitions."

I don't thing your problem is Typescript.

Post reply on HN