Live data from Hacker News

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

chiragswadia.medium.com

231–240 of 400 posts

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

#231

I often write Typescript and don't mind it; type safety is neat. But my personal take is that if I can't drop code into a webpage/console and have it execute immediately, it's not a "real" part of the web stack. It's a very useful abstraction for large projects, but it's still an abstraction from the actual syntax of the web.

If anything, TS is a concretion of JS rather than an abstraction over it.

When you write TS, you are (literally) writing JS, except that you are also writing miniature contracts (types) which are shared between components of the system and between authors of the code. This helps to ensure that the JS everyone is writing is mutually compatible, and that pieces of JS that should fit together actually do.

The idea that something's not part of the web stack if you can't throw it at a browser seems a bit weak; especially as, in this case, you can throw a subset of what you write at a browser and have it perform as intended.

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

#232
Mildly-related project I have: generate call graph for typescript files

https://github.com/whyboris/TypeScript-Call-Graph

The TypeScript language service is really neat -- you can use it to parse through .ts files so you can, for example, see which functions call which functions.

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

#233
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 me ..."

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.

> specifying your types is about as low-hanging, basic a step as you can take.

No, absolutely not. Learning an entirely new syntax, static semantics, and entire way of reasoning about code is about as high-hanging as you can get. Sure, once you know how to use static types, applying that knowledge is fairly easy. But it's a big mountain to climb before you get to do that.

This is the key advantage of dynamic types. You can make a computer do useful things without having to invest the large effort required to learn how static types work.

Now, personally, I think it is worth learning that. And, certainly, once you learn it, you get to amortize that benefit through the rest of your career. But there's a lot of people standing at the base of the mountain, realizing only how far they have to climb with no idea of the view they'll have once they're up there. Those people deserve sympathy, understanding, and encouragement to climb. Not criticism and mockery like I see all over this thread.

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

#234
post #212

Earlier quoted context omitted.

As a "senior" I'm still not sold. Running across bugs in the type checking that blocked us for a while (trying to avoid Broken Windows to boot) and the fact our development times skyrocketed (including on personal projects) or that the answer to poor tooling was "just use VSCode" is not something that really screams "developer friendly".

Sure, like all systems, there are overhead costs involved. But with something like a typed system, the overhead costs are minimal compared to the benefits you reap from them. One of the projects I worked on during my transition to typescript was to convert an existing project into it. Sure there was a lot of head banging against walls at some point to get the types to work out, but during that process I finally reall…

You are either going to catch the bugs in the type checker or you are going to have to write unit tests to catch them.

For me, typed python saves me a bunch of time.

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

#235

Earlier quoted context omitted.

Agreed. But some people have an attitude of Strongly Typed == Needlessly Verbose. Probably because most developers have only experienced Strong Typing via Java.

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…

This BS made me want to tear my hair out:

    VerboseTypeName foo = new VerboseTypeName();

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

#236

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.

what are alternatives? python's tabs?

The major choices that avoid braces are indentation and keywords.

Indentation's upsides are less line noise. In my opion, while there's less noise, there's less symmetry, so it's a wash on the beauty count.

Indentation breaks many tools, especially the way amateur coders use them. They're frequently showing code snippets by copy-pasting into web pages that strip indentation.

Notably, the standard pylint rules insist on two lines between functions and classes because the extra whitespace helps people find things. That same whitespace you get if you close a function with a single brace...

Keywords are surprisingly nice. Lua does them very well:

    function foo()
        doSomeStuff
    end
You get rid of the pointless { at function, and you have a simple "end" when you're done.

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

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

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

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

#238

TypeScript is definitely an improvement over pure Javascript. However, you can still lie about the types and it still allows you to write nonsense (even in pure TS). > const x = 'xxxx' > if(x === undefined) { > console.log('never happens') > } will compile without any problems

TypeScript _does_ detect some such impossible conditions (like `x === 1`), so this omission is intentional.

I think this is partly necessitated by one particularly large soundness hole in TypeScript, which is that expressions are typed as though dictionary and array subscripts are always in bounds:

    function foo(arr: number[]) {
        const m: number = arr[3]; // typechecks
        if (m === undefined) {
            // this IS reachable
            console.log("arr does not contain key `[3]`");
        }
    }
The alternative would be forcing all array and record accesses to have type `whatever | undefined`, despite the fact that almost all such accesses are clearly in bounds.

This is in fact now a part of TypeScript behind a flag since 4.1: https://devblogs.microsoft.com/typescript/announcing-typescr...

Adding a compile-time bounds-checker to TypeScript to find cases where the `| undefined` is unnecessary would definitely be helpful and interesting, but would do nothing to help TypeScript's reputation of being difficult to wield and slow to compile.

It's also not an easy problem to solve, due to the semantics of JavaScript arrays:

    let a = [];
    a[5] = "five";
    console.log(a.length); // 6
    console.log(a[4]); // undefined (!)

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

#239

Earlier quoted context omitted.

> I mean that's a personal preference, but if you're a lead dev and you have people starting work on a codebase they have little experience with, it's a godsend because they aren't totally blind. Very much this. I pushed to move the scripting language for our game engine project dot big bang from JS to TS primarily because the typing makes the entire codebase much more discoverable and beginner friendly. Using Monaco…

I'm learning typescript on-the-fly as I migrate an existing React+express codebase to it; Curious if you'd recommend Monaco over VS Code, and if so, why?

Monaco is the engine that powers VS Code. It’s super neat you can just embed it.

https://github.com/microsoft/monaco-editor

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

#240
post #141

Earlier quoted context omitted.

This feels more like developers learning that any variation on Hungarian notation is a bad idea.

This feels less like a case of Hungarian Notation being a bad idea and more like a case where developers are making irresponsible updates to their code. If a variable/function/class/whatever is being updated, the naming should be updated as well, if appropriate. Blaming the original author for the actions of the maintainer is not fair.

I'd still blame the individual developer for poor naming. Naming a variable something like int_list is terrible in that it's both very specific and semantically meaningless. Either choose a semantic name like grades or part_numbers, or take a hint from ML convention and use semantically void names like "xs".
Post reply on HN