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

How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

chiragswadia.medium.com

Post reply on HN
Print view View original

181–190 of 400 posts

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#181

Post by bqmjjx0kac »

fallingknife wrote: post #178
mdoms wrote: post #174

> I always felt that adding types to the functions/variables and satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits. I honestly find this attitude horrifying. I'm glad the author was able to move on from this, but it is utterly pervasive in some parts of our industry. As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can t…

I worked on one of those code bases. The team thought fixing endpoints where the ORM was being used incorrectly and generating N+1 queries was "premature optimization."

Yikes. The only way I could imagine this being okay is if N is bounded and small, or if the DB is SQLite.

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#182

Post by symlinkk »

tomca32 wrote: post #145
jdxcode wrote: post #114

Earlier quoted context omitted.

assuming you meant let myColor: Color | undefined; I don't understand what the problem is. Native JS would require you to define the starting scope of the variable (unless you're relying on global scope!). Then you declare what the type is: Color or undefined. The state of the variable can be one of two things. Perhaps I've been writing TS for too long but I think I'm missing the problem here.

The problem is that if anything can be undefined, then you don't really have a big typing advantage over regular JavaScript. It's just like being in Java land where typing adds a lot of boilerplate to the code, but you still have to do null checks everywhere.

That’s a problem with your codebase, not with TS.

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#183

Post by danielrhodes »

The other benefit is refactoring. That saying which goes along the lines of: "you're going to be reading a lot more code than writing it" is very true. After your project gets to a certain size, and it need not be large, you start making smaller changes and moving code around -- having some guard rails there is a huge productivity boost. Being able to read code and know that it does what it says because you know the types also improves your productivity.

The critique of typed languages being slow to write was somewhat true in the past. However, more modern typed languages (e.g. Swift or Typescript) do a lot of inference and have some flexibility built in. Because of that I think you get many of the same benefits of loose typing while maintaining type safety. One worry I had with starting Typescript was a fear it was going to make engineers over-engineer things, which is a behavior that Java seems to promote -- that turned out to not be true. You can go off the deep-end on generics, but in practice I haven't seen this.

Also with Typescript, you're not so far from Javascript where it's an entirely new language. So if you love Javascript, you don't lose anything.

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#184

Post by mdoms »

fallingknife wrote: post #178
mdoms wrote: post #174

> I always felt that adding types to the functions/variables and satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits. I honestly find this attitude horrifying. I'm glad the author was able to move on from this, but it is utterly pervasive in some parts of our industry. As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can t…

I worked on one of those code bases. The team thought fixing endpoints where the ORM was being used incorrectly and generating N+1 queries was "premature optimization."

The term "premature optimization" has been weaponized in the industry at large. Especially in front end development. And it really, really shows.

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#185

Post by symlinkk »

macspoofing wrote: post #52

I like the post, but the author's original perspectives are something I was always perplexed by. There was a period in late 2000s and early 2010s where dynamic languages were all the range (Ruby, Python, CoffeScript) and static typic was seen as archaic and slow by an entire segment of development community and I never understood it. >I always felt that adding types to the functions/variables and satisfying the TypeS…

Not all type systems are created equal. I could see how someone whose only typed language was C++ could think that it’s a waste of time.

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#186

Post by badtakemaybe »

adenozine wrote: post #26

I just can't bring myself to use curly bracket languages. I can't make a good enough case for any of them. I read way too much code to make myself read code that's not beautiful.

Oh boy do I have a programming language for you. Enjoy! https://en.wikipedia.org/wiki/Curl_(programming_language)

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#187

Post by Aldipower »

5350-uiop-1130 wrote: post #71

I'm a senior developer and I've never touched TypeScript and don't have any desire to unless I have no choice. I haven't worked on any projects that were large enough to warrant type checking or where I felt it would make a huge difference. Also I find it a bit verbose and ugly and I'm just not a fan of pseduo Javascript languages that need to be compiled down into JavaScript.

Same here. I still do not get it. I see the benefits of typed languages for use cases controlling binary data, like hardware controlling, drivers or binary file formats.

And actually you can write very type safe code in pure JavaScript.

1. (arg) => if (typeof arg !== "string) throw new Error()

Of course, this is executed during runtime (which could have benefits too sometimes) and not at transpile time.

Yes, you can laugh at me. But.. You should be always aware of the types you are using, which data is coming in and if the function is type critical, which is only the case for some functions, it is even more fault safe doing it this way, because your app is spitting an error during runtime, which will definitely be fixed very quickly. :) To validate data, use typed structs.

2. You need to write good tests anyway. Tests should test with malformed and faulty data always.

I and the teams I had, maintained and coded big JS applications. I can remember only one case, where TypeScript could have been helped with typing. But also, we had no test written for it, so..

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#188

Post by crocarneiro »

lalaithion wrote: post #157
capableweb wrote: post #134

Earlier quoted context omitted.

I'm in neither camps (I don't have anything against types in places but I also don't try to put them everywhere). Could you explain how TypeScripts types would be more/less verbose than the types from Java? At a glance, TypeScript looks a bit more flexible, but mostly the same. Then Java is a verbose language in general (forced directory structure, one-class-per-file and yadda yadda) but that's besides the point as y…

1) TypeScript has local type inference, meaning that `let x = returnsComplicatedThing();` will work, where in Java it would be `Complicated > x = returnsComplicatedThing();`. (At least up until the last few years) 2) TypeScript has type aliases, meaning you can write `type MyTable = List >` and not have to repeat yourself everywhere. 3) TypeScript has anonymous unions and tuples, so instead of writing `Triple ` you c…

Don't know about the other two, but the first one is available in java 10 and later.

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#189

Post by Shacklz »

joshAg wrote: post #149
lhorie wrote: post #122

Earlier quoted context omitted.

Ironically, as someone who has experience w/ both fast-and-loose JS and with "properly" statically typed languages, my beef with typescript is precisely that it allows people to be fast and loose, sometimes in ways that are not super obvious. For example: type Thing = { name: string, }; function getThing(): Thing { return JSON.parse('{"error": "invalid id"}') } const thing: Thing = getThing(); // lie to me! console.l…

If you're not using a bunch of generics, check out typescript-is [1]. It takes little work to get it setup, but it generates run time type checks for you. I understand why typescript decided to not add this functionality to the core of the language, but it's starting to feel like the largest missing piece of typescript is a built-in way to generate run-time type-checks for user-defined types from just the type defini…

Doing runtime-typechecks really is a blessing, and it would be great if typescript would provide this as a language-feature. There are two more libraries I know which are great for that:

* Zod: https://github.com/colinhacks/zod * io-ts: https://github.com/gcanti/io-ts (for the more functional-programming-oriented)

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#190

Post by mushishi »

MFogleman wrote: post #69

This article echos the common complaint I've seen from people hesitant to adopt TS. "I always used to get some compilation errors which were hard to understand initially, and I scratched my head trying to figure out the problem. " Which is like saying, "I got rid of my carbon monoxide detector because it kept beeping at me"

I kinda like what you are saying, but it's not that clear-cut in my experience / skill-level.

One can write code that would work correctly, but trying to express the types as precisely as one would like may be painful and doesn't necessarily be productive.

Sometimes when I feel it is cumbersome to express my intent in typing, I may feel satisfied enough to make a runtime check, (and perhaps add a note but depends...). Especially if that functionality is used in scoped area (e.g. module) and not exposed to the rest of the app.

When trying to make a generic and flexible functionality, the typing experience seems get harder and more time-consuming for human to grok, and it may not even be that useful when you look how the code is used.

So I usually try to make typing as good as I can by finding documentation related to what I'm trying to do and banging my head to the wall from a couple of angles, and for some specific parts I may give up and type any.

Perhaps sometimes when typing feels hard it may tell that the abstraction is just plain wrong, so there's that plus side!

Post reply on HN