Live data from Hacker News

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

chiragswadia.medium.com

271–280 of 400 posts

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

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

It's especially ironic considering the source of the phrase:

> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. -Knuth

It's like that cliche "it's only a few bad apples" from the proverb "a few bad apples spoils the bunch."

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

#272

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…

> This comment and many others in this thread seem to be missing something. I think they're also shoehorning their experiences. Some coders are cogs in giant tech companies that emphasize code quality, others are on teams in large business in an unrelated field, others are solo hobbyists, and still others are the only tech guys at their medium or small business. Some write code to run a business, others write code to…

> I think they're also shoehorning their experiences.

Yup, agreed. I first learned to program in the late 80s (when I was around 7 or 8 years old) using BASIC, and my first part-time programming job in college was a mix of C and Java. All of my EE and CS programming coursework was done in C, C++, or (pre-generics!) Java.

It is really hard for me to put my feet in the shoes of someone who switched careers in their 20s or 30s by joining a bootcamp that teaches node, HTML, and CSS, and helps them find web dev jobs.

Their journey is so different from mine that I have very little ability to guess as to what should be easy or hard for them to do as they grow in their career.

Having said that, I still do believe that everyone who wants to write code should learn about static typing eventually, and the sooner they're introduced to the concept, the easier it will be for them to integrate it into their mental model of how software works.

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

#273

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.

FYI, tslint is deprecated since 2019.

Most people use eslint. But eslint on TS is excruciatingly slow.

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

#274
As a relatively fresh "JavaScript developer", how do I make the transition to TS? How do I convert existing projects, including React projects, and configure npm to run smoothly with TS?

Is there some authoritative guide on this?

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

#275
post #149

Earlier quoted context omitted.

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)

We decided against io-ts because we'd still have to write the validator ourself (unless we used their type system as the source of truth, which wouldn't easily work for our project because we generate most of our types from an openAPI schema), which is exactly what we wanted to avoid doing.

I hadn't heard of Zod before, but i really liked the "parse don't validate" blog post linked. Turns out that's exactly how we've been using typescript-is. But it still suffers from the problem of expecting to be the source of truth and thus not working well with generated types.

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

#276
post #122

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

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…

Wait... so I assume `JSON.parse()` returns `any`, yeah? TS automatically downcasts (in function returns and assignment)? How is that at all useful?

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

#277
post #14

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

The heuristic of "new JS tech is just needless complexity/over-engineering" is not a bad one to have in the JS ecosystem imo :)

Heuristics shouldn‘t really be a factor when you are a senior. Make a decision based on your competence and experience.

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

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

> As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can take.

How do you come to such a conclusion when there have been many languages whose success was specifically tied to the fact that they were dynamically typed? Doesn't that indicate a pain point?

> If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into some of these code bases.

"Over-engineering" means drawing blueprints when the job is to change a bulb. It does not mean that blueprints are useless. It's about the job and the tools picked to do it. I can conceive of many jobs that fit the scope of a dynamic language and where bringing the big typed cannons could be seen as over-engineering.

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

#279

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

Senior probably means they've been doing JS for decades before TS was invented. They got along just fine without it for so many years, why rock the boat now? Or maybe it is more of a Senior person has a ton of work to do and not enough time to do it in so there isn't time left to learn a whole new way of writing JS. Or maybe many of the errors TS is meant to catch, the Senior developer has already learned over the de…

Why not use something if you have an added benefit? It‘s like writing code in „ed“ just because it worked for decades

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

#280
post #18

Earlier quoted context omitted.

I am a TypeScript fan but I do acknowledge the existence of the tax. TS is another cog in the machine that does useful work but can sometimes confusingly interact with other cogs (e.g. miles long unreadable TS errors coming out of React). Using or not using TS is not a trivial decision to me and should be made with consideration to the complexity of your stack.

Can relate about illegible React stack traces in production builds. One of the reasons in my case was Create-React-App obfuscating ES6 class names, which is just insane! Just why???! Why throw all code structure away just to save a couple KBs. The worst part is CRA folks acting like dictators when asked to provide an option to toggle that: "Why in heavens earth would you need that?". "You can fork our 30K+ line repo…

You could also use customize-cra and skip on minifications in about 10 lines of code
Post reply on HN