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

361–370 of 400 posts

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

#361

Post by johnbotris »

Frost1x wrote: post #247
spideymans wrote: post #242

Earlier quoted context omitted.

>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. I don't understand how one can be a great (or even half-decent) SWE with such an aversion to learning something so common and foundational as types.

After working in the industry for many years, I have aversions to learning many things. Usually, it's clearly a failed recycled idea with a small twist, poor approach to a problem, or someone selling new shiny. I have no aversion to learning something when it shows potential value, but you must explain the value without gimmicks. Maybe typing hasn't been well sold to this person. The new thing I learn should make my…

I get your point, but I think it's misplaced. Types are not new, in fact from a CS perspective they are very old.

I think it's a shame that learning about (even just basic) types is being taught as some new thing that can help to make your code better, rather one of the fundamentals that we should be learning from the beginning, which can still provide benefits even when writing in dynamically typed languages.

Perhaps it's just a case of bad marketing and lazy educators.

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

#362

Post by tome »

Barrin92 wrote: post #249
danielrhodes wrote: post #183

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…

I don't really buy this argument about readability because the sort of information stored in types very quickly becomes pretty meaningless for humans. I remember working on a Haskell codebase and getting into an argument about this with a developer who was very much in the typed language camp. Then I saw a function that had like 8 parameters, some were just String, or Int, some where synonyms, and I asked him what it…

Huh? Just because there was once a function whose argument types didn't help you understand it doesn't imply that types aren't an aid to readability in general!

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

#363

Post by dep_b »

stupidcar wrote: post #58

Here's a project idea I'd really like to see: A version of Chromium, targeted at web developers, that is is modified to accept TypeScript syntax as a variant of JavaScript. This hypothetical browser wouldn't perform type-checking, just be able to parse TS syntax and convert it to plain JS, in the same way tools like Babel do. This would let you use TypeScript without the need for any transformation pipeline in dev. Y…

That would be the way to get the JS ecosystem out of the mud. But it would be great if there was a way to ensure nil and type safety on the level of Kotlin, Swift, Rust etcetera and build from there. TS is more like Java in that aspect.

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

#364

Post by nicbou »

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…

Typing offers guarantees. You can guarantee that your function will receive the right inputs, and produce the right outputs. Even soft typing enforced by an IDE is beneficial in that sense.

I have refactored a large, central chunk of JavaScript code back at HERE. I found and fixed several bugs related to typing as I went along.

A lot of code passed server responses or a subset of them as-is, so I had to read API documentation to understand the inputs of some deep parts of the frontend code. This is why I favour explicitly encapsulating server responses in a data class.

In addition to typing, I favour microtypes and enums. Those go further to prevent unexpected application states. Assert statements are a last barrier against unmet expectations that could break things.

If you want to build reliable software, you must be strict about the inputs you accept. Don't let sloppy inputs propagate.

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

#365

Post by nicbou »

pbreit wrote: post #301
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…

Types make little sense to me. I guess I'm not welcome in your world.

Types loudly state what you accept, and what you return, and possibly enforces it.

The real world equivalent is giving plugs specific shapes, so that you don't plug your headphones into a 240V wall socket.

In a large enough team, this is essential to prevent incorrect data from being passed around, and breaking further down the line after causing a lot of damage.

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

#366

Post by coldtea »

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…

There's nothing especially "horrifying" about this.

In fact, several geniuses in Computer Science have historically been of the same opinion (pro dynamic typing).

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

#367

Post by scrollaway »

aendruk wrote: post #118
nullserver wrote: post #87

Earlier quoted context omitted.

HAML and coffeescript.

I miss the elegance of Haml. Moving from an indented syntax for DOM literals to the likes of JSX felt like a step backwards.

Maybe for you, but that is not a popular opinion. JSX's rigor is a breath of fresh air in a world that constantly generates low quality html due to loose constraints. HAML had those same problems.

JSX is kind of xml done "right". Differences between children and attributes in xml is very hard to grasp, but JSX has a much better defined structure to it and is super well suited to generate html because of that.

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

#368

Post by rowanG077 »

pbreit wrote: post #334
spideymans wrote: post #245

Earlier quoted context omitted.

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

The opposite for me. Typing makes zero sense. I know what I'm doing with my variables so why do I need to specify a type? Why can't the computer figure this out? Isn't that what computers are good at?

The computer can indeed find out. Most statically typed language can infer types nowadays.

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

#369

Post by macspoofing »

cryptica wrote: post #333
macspoofing wrote: post #60

Earlier quoted context omitted.

The value of TypeScript is a function of the codebase size, size of team, and length of time for maintaining this codebase. If you're an individual, putting together dinky little web sites that you don't need to maintain for years - the value of TypeScript over JavaScript isn't as pronounced. If you have a web application that counts hundreds of thousands of lines of code, maintained by team of developers over many y…

This is incorrect. This is just repeating popular rhetoric. Well designed projects are broken up into manageable, individually testable modules... So codebase size is an anti-pattern to begin with. As for time, you think waiting 15 additional seconds each time you want to test something doesn't add up and waste time? What about having to type up all these extra type definitions? You could have spent that time writing…

>Well designed projects are broken up into manageable, individually testable modules

And JavaScript does not make it easy to do that. It also makes it very easy to do it incorrectly and in a way that is an unmaintainable mess. Every programming language can be used to write clean code if you try really hard, but not every programming language will have the syntax, semantics and conventions that will make it harder to do the wrong thing.

If you do try modularize JavaScript, you're going to need a compilation chain to package it all together - so you're not getting away from that.

>So codebase size is an anti-pattern to begin with.

No it's not. What are you talking about? A large application will have a large code-base. You can't get away from that.

>As for time, you think waiting 15 additional seconds each time you want to test something doesn't add up and waste time?

Sure it adds up, but it's a tradeoff. If you're writing a dinky little web app for your grandma, maybe that trade-off isn't worth it. If your codebase numbers in hundreds of thousands of lines of code then you take the hit with compilation so that you can save time in other places. For example, tracking runtime bugs that a compiler would catch, is very expensive, and gets more expensive as the application grows.

>What about having to type up all these extra type definitions?

Heh. That's not a real issue. Programming isn't about speed typing and measuring 'words per minute'. You're not losing time if you need to write 'int i' vs 'var i'. Again, we're not talking about writing quick scripts or throwaway code. We're talking about code that may need to be maintained for years by many different people.

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

#370

Post by macspoofing »

wmil wrote: post #328
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…

> Maybe for small scripts, static typing doesn't provide that much value (although even then I don't really buy it - why wouldn't you want to know what you're working with at any given time), but for sizable (web) applications that need to be maintained for years, it's critical. It's common for web devs to spend a lot of time dealing with semi-documented lumps of JSON. If you don't have any guarantees about the data…

>If you don't have any guarantees about the data in the first place then static typing ends up being a lot of pain without much benefit.

Uh huh. Are you trying to come up with scenarios that you think a typed language wouldn't be useful ... because you don't understand typed languages?

If you have to work with crap JSON blobs with arbitrary and inconsistent typing, static typing doesn't prevent you from treating it as a 'dynamic' untyped map. That's true of pretty much every typed language there is, from TypeScript, to Dart, to Java, to C#. I do a lot of JSON consuming in Java and Dart. My preference is to enforce a schema on the incoming JSON blob and parse it into a typed object automatically, but if I can't, then I just parse it to Map OR List and work on that level.

At some point you're going to have to write code to figure out the type of whatever property you're interested in because it may be important to know whether the property is a string, an int, a float, an array, or whatever.

>But when you're in that situation static typing isn't solving your first problems.

Neither is dynamic typing. You're in the exact same boat in that case ... except you get the benefit of typing in the rest of your app.

Post reply on HN