Live data from Hacker News

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

chiragswadia.medium.com

211–220 of 400 posts

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

#211
post #184

Earlier quoted context omitted.

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.

I'd say that's only partly true.

Even at large companies, there's often pressure to deliver quickly and often. Throwing out large parts of the UI and starting over to please the marketing department is SOP at a lot of places too.

If it were a normal desktop application, they would throw a 30-man team at the problem, but because "it's just a web page/site", it'll be a team of 3-5 people and the time tables will be pushed up.

When you combine these problems, it's no wonder that a lot of JS devs view almost anything that isn't a new deliverable as overly-optimized.

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

#212

It's probably worth taking a step back and interrogating why the actual "Why was I Anti-TypeScript?" a little bit more and use it as an opportunity for broader self development. The author didn't use and understand something, and rather than trying to they instead just defaulted to rejection. It's midly disapointing seeing this in people who label themselves as "Senior".

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

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

#213
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 did one of my internships at a financial services company. Their web applications were responsible for performing transformations on massive JSON datasets, with a huge variety of financial data. This is precisely the kind of project that would benefit most from typing.

I was relieved to find out that they were smart enough to use TS, yet horrified when I looked at the code base and found that the entire codebase was littered with the "any" keyword, making typing damn near useless.

We had so many bugs reports that essentially boiled down to "this data is being transformed in a way it shouldn't be". Almost invariably these bugs were due to the developer thinking that some variable represented one thing, when it really represented something else, and they thus performed an incorrect transformation on it. Typing would've eliminated this entire class of bugs.

Figuring out what any variable represented often involved traversing the huge codebase to find out where the variable originated. On some occasions, I even had to talk to the back-end developers to figure out what the heck was going on. Typing is self-documenting, and would've completely eliminated the need to go on a scavenger hunt to figure out what a variable meant.

Anyways I got sick of this rather quickly, and made sure to add types to any new code that I wrote. I was the only developer on the 20 person team that bothered to do so.

As an intern, I didn't understand why these developers refused to use types. I just assumed that with their years of experience, they must've had a good reason. Now looking back at it, it's clear that they didn't understand types, didn't want to learn how to use types, and thus just chose to completely ignore typing.

As you said, this is utterly horrifying (especially for a financial services company dealing with real money).

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

#214
post #179

Earlier quoted context omitted.

It takes a lot of mental and emotional capital in the creative process to produce something that is truly wonderful. Microsoft is systemically incapable of approaching creative perfection. Very few are.

This is extremely unfair and rude. The TS language designer and lead developer is Anders Hejlsberg, who is also the chief architect of C# and Delphi. C# has been tremendously successful and, in my opinion, is truly wonderful as a general purpose language. In the case of Typescript the team were working under very difficult constraints - the language must maintain strict compatibility with Javascript, and the output m…

That the output is (or can be, with the right settings, anyway) very reasonable looking JS that would be easy to navigate and work on for anyone who'd been working on the same project in TS is a huge selling point. It's a nearly-instant, high-quality escape hatch if you decide you hate TypeScript, even if you're deeply into your project and have a ton of TS code already written. It's why comparisons to things like CoffeeScript don't hold up well, and (part of) why it's easier to sell to technical management than something like PureScript. Switching from TS to JS is very low-cost.

It's not just that the output is well-formed and sensible JS, it's that it's structured so similarly to the TS. With a recent EcmaScript version as your output, it's practically just the TypeScript with the type-related keywords & blocks stripped out.

As much as it could provide more and better features by breaking that guarantee, I think it's a brilliant decision & guideline, at least until WebAssembly is far more mature and the space starts to open up.

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

#215

Earlier quoted context omitted.

Yeah as best I can tell, Coffeescript was a thing because Ruby was very popular at the time, and some Ruby devs had to write JS but they wanted to write Ruby.

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 vanilla JS projects. The sky is quite sunny and ES2015+ is a better language than a lot of non-JS devs think JS is.

It will still be a while before all the brownfields in the larger ecosystem get cleaned up (if some of them ever do), but that's no longer a language problem, that's a a long tail ecosystem problem.

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

#216
post #170

Earlier quoted context omitted.

That's my personal heuristic and why I continue to reject TS just like I avoided coffee script, flow, clojurescript, and so on. But this article reads like "Developer who only used dynamic typing learns about static types." You could sub in any two such languages and get the same article.

One of the things you listed is not like the others. Why didn't you give Clojurescript a chance. It's like being in Hell and then someone brings you infinite amounts of cold fiji water. Hell becomes more bearable ;)

Clojurescript is the worst offender on that list from the point of view of "needlessly complicated." I can't imagine a dependency I want less than the Google Closure tools. I swear Closure is probably the only tool with fewer devs who understand it than autoconf.

I'm not critiquing any of those languages, in a perfect world any of them in the browser would have been preferable to Javascript. The issue is the tower of dependancies we are building, and you have to stop somewhere.

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

#217

Two downsides to TS: an extra step to transpile, and having to write shims when it bugs out and can't verify an external declaration. Upsides? When tuned to its most pedantic settings I've uncovered a handful of bugs that would have otherwise launched. That's worth far more than a few tiny annoyances. tslint > jslint.

If you are working on the server side, ts-node has been a huge timesaver. It removes the extra step of compiling and lets you just run your script with `ts-node script.ts` or even `#!/usr/bin/env ts-node` at the top of your file works. https://github.com/TypeStrong/ts-node

Thanks for the node tip!

I built an electron webpack framework and it uses hot reloads, but since i fork a lot of processes, it doesn't quite understand those need to be reloaded too! Got a fix for that by any chance?

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

#218
post #199
post #33

Earlier quoted context omitted.

Typescript is not accepted. How AngularJS stuck on 1.* is the best proof, and an illustration for the problem. Pretty serious people are working in Angular community, it's immensely popular in the enterprise webapp space, so I will not take the "Ah, it's just amateurs who are stuck there." It adds to countless attempts of other transpiled *scripts to extend Javascript. They, and Coffeescript in particular, are good h…

> Coffeescript in particular, are good historical references to what will happen to TS in a few years. The thing is that many good ideas of Coffee ended up being integrated in newer versions of JS, so of course the need for it decreased; one could argue that Coffee's legacy lives in ES201x. But there are no types in JS, and none planned.

Yeah, it would be great if TC39 made type hints syntactically valid but semantically ignored (ala Python's PEPs to that effect) so that type erasure was no longer needed as a "build step", but so far TC39 is still hugely aware of the controversies surrounding ES4 (the "lost" version of JS) and still very hesitant to do anything type related in JS.

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

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

> JS the language isn't great but it's JS the culture that is the real problem.

This is the money quote of the thread for me. From the perspective of someone whose main language has been JS or TS for about 8 years, it's getting worse since some of the biggest names in the discipline just seem to be people with large social followings giving terrible advice. This advice is then eaten up by hoardes of bootcamp alumni who have been given a loose understanding of React and unleashed on the world as "junior developers".

But maybe I'm just cynical.

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

#220
I have a love hate relationship with Typescript. I have come to see it as a tool and to use it when it makes sense and avoid it when it doesn't.

I like the language at a conceptual level and find what it does very useful. The syntax I find less than desirable (especially nested generics).

For smaller projects I tend to use just JS because it's faster if I just want to prototype an idea and I'm not planning on keeping the code around for long.

Where Typescript shines is when working with a team on longer term projects.

The generic syntax gets derives from C++ which I don't think is a very good syntax. When dealing with more complex generic type declarations with nested generics / types your eye is scanning back and forth trying to match angle brackets and it is really hard to parse visually. Other languages like Haskell allow you to just read the "generics" left to right. Aliasing the type helps to some degree.

The other thing I don't like is when you are experimenting and fleshing out an idea you want to take a try it and see approach but with Typescript you have to really commit even though you just want to experiment. When you want to change something there is so much more code that you have to change.

The pros are when dealing with code you wrote in the past and forgot about what the types / parameters are or when dealing with code written by other people. Having the IDE suggest what you need to pass it is amazing.

The contrast to that is having to jump to a function to see what POJO style object it will return, what the exact spelling of the property / key are, and things like that. Having static typing saves so much time when dealing with other code.

If your project involves you working with others' code or code you wrote in the past and don't remember well then this is Typescript's sweet spot and it is a huge win.

One of the things I find most lacking in Typescript is pattern matching. If you have strong static typing like Typescript does then pattern matching pairs really well with that. It makes your code much more declarative and easier to read / write.

Post reply on HN