Live data from Hacker News

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

chiragswadia.medium.com

251–260 of 400 posts

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

#251
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…

That's true to a point but it depends on perspective. On a big team with a mix of experience levels, you are going to want to put up as many barriers to mistakes as possible and it doesn't matter how much it slows anyone down because it can't be more than dealing with the problems will be.

But less people, smaller projects, higher experience levels, and better testing are all factors that shift the balance between effort and expected return. Before TypeScript came around I wrote multiple 5-10k loc apps alone in JS and the number of bugs that TypeScript would have caught in those was pretty minimal. Working on a team of 5 on apps twice that big, I see errors that TS could catch in almost every single file.

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

#252
post #192
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…

JS the language isn't great but it's JS the culture that is the real problem. There is a subset of JS codebases that are good, well engineered and written by people that understand the languages faults and limitations but the list is incredibly small and even smaller still now Joyent isn't really around anymore. If there was one ecosystem I wish I never needed to touch again it would be JS but unfortunately it's beco…

It's the same thing with PHP (and Ruby). You can write reasonable code in it, the problem is that the engineering culture leaves a lot to be desired.

In Java, the engineering culture is strong but stagnant.

Python is toxic, it's full of scientists, the engineering is bad (but a little better than PHP because the community is of a higher calibre).

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

#253

Earlier quoted context omitted.

This comment and many others in this thread seem to be missing something. I see a lot of anger here or blame on the author for deliberately choosing to not use types, but I think the author actually does a very admirable job explaining what's going on in their head: "... concepts like Generics felt very hard to understand ... every piece of code is strongly typed and overwhelming. Even simple code like below scared m…

>The author isn't claiming to have had an informed opinion of types. They're saying that they found learning about types to be difficult and stressful. That's a real problem that I think people who understand types forget. Respectfully, its really hard for me to wrap my head around this mindset. When I wrote my first line of code, almost 10 years ago, one of the very first concepts I learned was types. You know the b…

A move at my alma mater to switch the introductory course from Java to Python was criticized on the same grounds. The students had a hard time in successive levels of coursework.

It seems to be a lot harder to get people who learn dynamic typing first to learn static typing, than the other way around.

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

#254

Earlier quoted context omitted.

This comment and many others in this thread seem to be missing something. I see a lot of anger here or blame on the author for deliberately choosing to not use types, but I think the author actually does a very admirable job explaining what's going on in their head: "... concepts like Generics felt very hard to understand ... every piece of code is strongly typed and overwhelming. Even simple code like below scared m…

>The author isn't claiming to have had an informed opinion of types. They're saying that they found learning about types to be difficult and stressful. That's a real problem that I think people who understand types forget. Respectfully, its really hard for me to wrap my head around this mindset. When I wrote my first line of code, almost 10 years ago, one of the very first concepts I learned was types. You know the b…

I've been thinking about this (and will probably try to put together an essay about it at some point). I think that the types you learn in programming 101 and the advanced types (the kinds of things written about in type theory books and papers) are related, but different beasts.

If we drop down to the lowest level, basic-programming-types are about one thing - interpreting what is otherwise a pile of bits in memory. Without any notion of the difference, how would you interpret the difference between characters and integers and floating points? There is nothing about the ones and zeroes to tell you. So the first thing you learn is to write something like `char a = 'b';`

Dependent types (and related type theory constructs) do get used for this in languages built from the ground up with that as a theoretical foundation, but they have their basis in ideas that are more related to formal verification and logic.

And that's where the divide comes in.

Using types to pick a codec for some bytes and using them to verify systems are very, very different mindsets.

And we simply call both "types".

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

#255

Earlier quoted context omitted.

I think everyone except JS devs wishes they could write something other than JS for the browser. Maybe eventually with WebAssembly...

That was definitely the case before ES2015. I think many of the non-JS devs that still hugely wish they could write something other than JS for the browser haven't kept up with ES2015+ nor Typescript. ES2015 is a much improved language and vanilla JS isn't painful anymore, especially with type="module" support now green enough in caniuse statistics that we can finally kill AMD and CommonJS for good in greenfield vani…

Yup. I don't find myself using classes much, but some of the other new features remove the vast number of issues you tend to face.

Is scoping an issue for you? Just use arrow functions!

Is callback nesting an issue for you? Just use `async/await`!

I love it so much.

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

#256
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…

This comment and many others in this thread seem to be missing something. I see a lot of anger here or blame on the author for deliberately choosing to not use types, but I think the author actually does a very admirable job explaining what's going on in their head: "... concepts like Generics felt very hard to understand ... every piece of code is strongly typed and overwhelming. Even simple code like below scared m…

This is wrong. Dynamically typed languages still have types that need to be understood by the developer. They are only checked at runtime and not at compile time.

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

#257
post #246
post #237

Earlier quoted context omitted.

> They're saying that they found learning about types to be difficult and stressful No, they're saying that types (which they don't understand) are "over-engineering". This is, frankly, not acceptable to me.

They're describing how they felt before learning about types.

Yes. Like I said.

> I'm glad the author was able to move on from this, but it is utterly pervasive in some parts of our industry.

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

#258
post #94

I have a theory that TypeScript was not actually invented for frontend developers, it was created for non-frontend developers who were forced to deal with the frontend, and hated JavaScript. That's also why I think it's very funny that JavaScript developers are starting to use TypeScript on be backend, i.e. Deno. You are using the patch to JavaScript that backend devs needed to make JavaScript more like backend langu…

I don't understand any arguments of this variety because TS just compiles to JS

TS hasn't changed the way I write applications too much, besides giving me a bit of safety/enforcement of good practices and productivity boost

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

#260
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…

Sure, but you also should never just blindly trust a JSON.parse, and if possible you should avoid typing functions for exactly this reason, and let their return types be implied instead. If you didn't type `getThing` then its return type would be `any` and you'd get an error in your IDE on the last line.

sorry but i feel like this is backwards. the error - incorrectly assuming an `any` will be a `Thing` - is in `getThing`, and that's where the error message should be. getting an error in code that calls `getThing` instead would just obscure the real issue.

also, i think "avoid typing functions [...] and let their return types be implied" is terrible advice. argument and return types are the thing you should type explicitly, because it makes the errors local. otherwise you'll get all the fun of tracking down where that `null has no property "blah"` error came from, just at compile time

Post reply on HN