My issue with TypeScript is that it simultaneously has some complex features that result in types that are hard to follow and yet it also lacks simple abilities like creating a type for a number within a certain range. I end up wanting to use Joi to further validate the types, not because I need runtime validation, but just because it's significantly more thorough and in some cases easier to read, too. But then I end up with a lot of duplication between Joi and TypeScript. It holds a lot of promise but there's too much friction there.
How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
351–360 of 400 posts
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#352My issue with TypeScript is that it simultaneously has some complex features that result in types that are hard to follow and yet it also lacks simple abilities like creating a type for a number within a certain range. I end up wanting to use Joi to further validate the types, not because I need runtime validation, but just because it's significantly more thorough and in some cases easier to read, too. But then I end…
Supporting static range types is crazy hard. Only full-on math languages like Idris can do that.
If you need runtime checks and types without duplication use something later like zod or io-ts. They can derive ts types automatically
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#353It'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…
The problem in your example isn't TypeScript. It's the JSON parser. If you used GSON in Java, you'd get the same result, despite being statically typed with runtime type checks.
You can implement the JSON parser to be type safe. For example, this is how nest-dto can prevent this.
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#354My problem with TypeScript is the lack of runtime benefits. Yes, you get some benefits of static checks during compile time, but at the cost of huge additional effort. This effort maybe makes sense for a large project with many team members pushing code, but for small hobby projects I think this just makes quick iteration far more difficult. To me this defeats the whole purpose of using a dynamic garbage-collected la…
[deleted]
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#355Earlier quoted context omitted.
This is an argument against strongly typed languages, not Typescript. You could do a similar thing in Java and C#. I don't know of any language that can stop someone from being a sloppy coder.
Java would absolutely stop you from returning a JSON object when you're supposed to return a Thing. You could cast it but you'd still get a ClassCastException. Now I haven't written JS or TS, so maybe I'm not understanding what you're saying?
The example above is equivalent to gson.toJSON(string, Thing.class)
It'll just return an empty Thing right? No ClassCastException.
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#356Earlier 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…
ClojureScript is a far better designed language IMO. It's all relative to one's opinion, isn't it?
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#357Earlier quoted context omitted.
This BS made me want to tear my hair out: VerboseTypeName foo = new VerboseTypeName();
The reading or the writing part? The reading is easier with explicit types. The writing is a non issue considering tooling auto completes the second instance almost always. modifying later can be cumbersome but the tooling makes it somewhat easier too.
Both, and not interested in tooling to help me repeat things. :-)
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#358Earlier quoted context omitted.
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…
With advanced optimisiation turned on, the Clojurescript compiler will not include any of the Closure code that you do not use. But my point was about language superiority. For me it's obvious why Clojurescript wins the client side.
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#359I think a large part of the support for Typescript comes from being able to create good tools for the language. But, I still have an aversion to front-end development itself, because it just feels too _involved_. You have to set up so much, and it has become a lot more difficult since you need to install webpack, postcss, and many other plugins just to do a hello world app. It's still bearable if you have to do all o…
> You have to set up so much I think tooling has mostly addressed this, or at least provided a mostly braindead path for 90% of needs. For example, npx create-react-app $YOURAPPNAME sets up practically everything you need to get a reasonable react app going, at least in terms of the transpiler/set of plugins. It makes very few choices re: actual react libs though (no preferred router, flux, etc). The preact equivalen…
That's not the real Makefile, that would be the GNUMakefile. Also pretty simple, though.
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#360Earlier 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?
Well, as the author of the code, you should be able to tell the function what type of variable you expect (string, int, or business entity e.g Book, Bookstore).
That way if you later try to call the function passing an int when it expected a Book, you have an early warning system at compile-time. Not run-time.