Why I hate typescript. Bored during quarantine so thought I rant a little more about this.
1. Compilation time, typescript increases project compilation time from 1 second to 3-4 seconds, which is basically triple or quadruple the time if you don't know math.
2. You write a minimum of 30% more code.
3. Many libraries are not written in TS by default, which means you end up having to manually install a fuckton of @types/(pckg name) manually which is incredibly shit.
4. Typescript is an absolute pain in the ass when using dynamic libraries. Plus when it works, it usually ends up finding maybe 1-2 errors in your code MAX, completely not worth it.
5.JSDoc is 100 times better. (Still don't use it though).
6. I actually enjoy loosely typed languages, having your compiler being smart enough to tell what the type of your input is is much better than it assuming you're a fucking retard so it forces you to manually type everything.

P.S if you hate loosely typed languages, kindly resort to Angular, C#, Java or whatever and leave JS alone, cunt.

  • 10
    Everyone else is absolutely wrong.
  • 2
    Plus: JSDOC on VsCode is unstable as a bipolar person: the type declaration import that worked yesterday won't work today.
  • 14
    Each to their own, I'm no typescript fan either, but point 6 kinda signals you've missed the point of strong typing.
  • 3
    yeah fuck typescript
  • 5
    > having your compiler being smart enough to tell what the type of your input is is much better than it assuming you're a fucking retard so it forces you to manually type everything

    Ever heard of Hindley-Milner type inference? Used by languages such as OCaml, F#, Haskell, and lets you write programs with (almost) no type annotations while still ensuring type safety at compile time.

    All three of the above-mentioned languages also can be compiled to JS.
  • 2
    100% agree.

    TypeScript is total shit.
  • 7
    TypeScript is geniously designed to fit a proper type system into an already existing weakly typed language. Just look at the generics with keyof, string literal types, etc. The language is nevertheless not _that_ great because it's still JavaScript which is complete garbage

    It also sounds more like you don't understand strong typing and your code is probably badly defined and ill constrained
  • 2
    @SomeNone And all three being better than JavaScript weirdly enough ;)
  • 0

    As much as I love fable and clojure, I don't get the impression OP is FP capable. Or really understands the purpose/math behind types, inferred or otherwise.
  • 0
    @SomeNone Haven't heard of it I'm afraid
  • 1
    @12bitfloat I was using Java and C# before JS so yes I'm familiar, I do agree that JS has some strange quirks that you need to understand but honestly if you take advantage of ES6, async await and all that jazz it's quite pleasant.
  • 0
    @SortOfTested Would love to hear some constructive criticism, I am a junior developer still, enlighten me.
  • 2
    Typescript is so shit that I had to spend 1 day adding all the type definition so the compiler'd stop yelling at me.

    F*ck Typescript.
  • 2
    @Minhphu0304 you can't call someone/thing shit just because it is doing what it's purpose is. Have you ever cussed at a firefighter because he fights fire? I thought so.
  • 1
    @FuckTS your opinion might change once you inherited your first 100k lines project ... where this one field is always an integer except for that one shortcut your predecessor took where it is an object that wraps a string
  • 3
    @AlmondSauce maybe you missed the point of loosely typed languages?
  • 1
    @melezorus34 typescript is a stupid idea.
  • 0
    @SortOfTested Thankfully both OCaml and F# let you write your usual OO/procedural code if you haven't got the hang of FP just yet. Haskell, not so much, but I'd rather not recommend that for beginners anyway (unless they are REALLY eager to learn purist FP, or taking a university class which uses the language).
  • 1
    @sawmurai what idiot writes that large a project in JS? No amount of typescript can fix that.
  • 1
    @Ubbe those projects start out as small and stuff gets attached to them pretty quickly. I once maintained a tool that started out as a quick dashboard for a cto and ended up powering the customer care center of a 200k customer company. Written in Php 5. Fun times ...

    But it started out as a quick prototype :) that’s how our industry works
  • 1
    That's not really a positive in my book 😉 I decline PRs that attempt it.
  • 1
    @Minhphu0304 TS does not force you type things... lol You can still not type but defeats the purpose.
    The "problem" you have is with some linter configuration, which made me realise you have no clue what you are doing, the same as most people in this thread.
  • 0
    @Ubbe Considering that, by the description given in the question, modern versions of Java could be considered "loosely typed" (as could any statically, strongly typed language with type inference), I'd say it's not my understanding that's at fault here...
  • 1
    As much as I hate javascript, I find typescript very enjoyable. And MOST of things typescript proposes is already in the next rectification of JS.
    So basically I see it as the only feature (not talking about webassemblies, blazer etc) for proper web development.

    How many frameworks do you use if it’s a pain to install Typings ? In my current project, I only needed to install 1 typing manually. Everything else was already by default in typescript standard libraries.
    “smart” compiler, sure :
    var x = 10;
    var y = "10";
    x==y is TRUE.
    I refuse to work with language which allows that. (Ok, sure can use ===, but it’s a pain)
  • 1
    @Ubbe It NOT a big project. Even in our current project 100k lines where blew aways couple of years ago.
    For reference : The WEB part og GMAIL (Only counting javascript) was around 250k lines about 5 years ago.
    So 100k lines projects are quite common.
  • 4
    @NoToJavaScript how come typing === instead of == is a pain?
    each loosely typed language has some kind of options to use strong typing if you want to. the other way around is usually a bit more complicated than typing an extra character
  • 0

    Not really. Replace extension by .ts instead of .js, BOOM “==” problem solved instantly with a nice error. (And depending on your tooling : TypeScript compiler auto added and installed, compile on save enabled etc). And you don’t even change the <script> (Or whatever) including this js file, as the result will be the same filename as before.

    Honestly, JUST for that check it worth using, even if you don’t buy the whole class/interfaces etc thing
  • 1
    @NoToJavaScript it's a pain to add another = yet not a pain to completely rewrite your project and change every single file extension using typescript and finding out you have to install a ton of extra packages to make it work? Yeah dude that makes a ton of sense.
  • 2
    @FuckTS I still do not get what “ton of packages” you talk about. Typings ? (you know .d.ts”) Well, if you use 150 different libs in your project that could be pain. They are just helpers for type safety and auto complete. No additional code is produced.
    BUT it will also help you detect breaking changes. Let us say Lib A goes from version 4 to 5 with API names changed.
    JavaScript : Sure, install this version 5, let’s boot a local dev server and MANUALLY test each page this lib is used on. So, in my case : around 5 minutes of cold start for dev server.
    TypeScript : Sure, install this version 5, but now you have 1000 syntax errors as “methodeC’ is now called “MethodC”. Around 15 seconds of TypeScript compilation
    Your choice. Probably your relation with TypeScript is the same I have with PHP : No one EVER will convince me PHP is good for something other than “doodling and echo debug” (Even I know you can debug PHP properly, even from Visual Studio if needed).
  • 0
    @SortOfTested Not saying you're wrong. :) Anyone who uses a language in production should learn it sufficiently before, if at all possible. Just saying it is possible in principle.
  • 1
    JS is a necessity for webdev and TS is the only way to allow typing for it. By claiming that TS should be avoided, you're also claiming that nothing that would run in the browser can be improved by guaranteed types.
  • 1
    Kind of unrelated but what do y’all think of all that webassembly noise? I could have the wrong idea about it but would it eventually allow writing web apps in, say, python or swift or ruby or java? So that people can choose whatever language they want, strong or weak typed as they see fit
  • 1
    @molaram Blazor is kinda shit, so not yet. But eventually, probably yes. Well, not directly in those languages, that would be inconvenient. Rather domain specific modifications of them, with a purpose-built STL and good DOM integration. Maybe even templating.
  • 0
    I’m no expert but maybe removing APIs that have no business in the browser and adding an abstraction on top of the DOM will do it? At that point wasm it would become simply a compiler target. Up to each language developers ultimately.
    But I’m sure there are probably different strategies to get to that point, I was curious more about whether the general feeling is positive (yeah it might happen soon) or negative (fuck that noise wasm too will fail just like all others before did)
  • 1
    @molaram The general feeling is that MS kinda overhyped Blazor, so now the market is frozen. Everyone thought that it'd be awesome and nobody wanted to compete with it. Apparently it's nowhere near awesome and C# is a tad bit too heavy for this shit.
  • 0
    @Lor-inc there’s so much garbage coming out of these companies, and all those sycophants just begging to start turning it into hype :(
  • 0
    I'm purely adding this out of frustration to vent and share the feeling that TS may very well be idiotic!

    I'm sure there are some good use cases, I've not come across any in practical terms. I develop a lot in JavaScript mainly for NetSuite.

    TS add's about 30% dev time to projects if not more. I feel it is for bored developers, not productive ones. TS = Development speed drop.

    Lastly, use TS when it actually helps you. When it adds more time to a project with no or little benefit then throw it in the bin.

    JavaScript was designed for a purpose and I'm sorry to say that the purpose of TS may be honorable and all that, but from what I can see, it's trying to turn JavaScript into something it was never meant to be or at least, has not yet evolved into.

    I use TS only because my client wants me to. If I had a choice I'd rip it out in a heartbeat. If I want a typed language I'd go with Java or something else.
  • 1
    @swartzlib7 I mean yeah sure but my memories often live short, so I use jsdoc to know what arguments' types are and intellisense gives proper doc completion for that.

    For ex: I don't get String's slice on arr.slice
  • 1
    Hi @melezorus34, yeah this is true - jsdoc, it's very useful and I use it 90% of the time :-D

    The last thing I look forward to in the morning is TS needing some declaration that a variable is a certain type while the code is clean, concise and well structured.

    When attention shifts to making TS work and not solving the project problem to the point of forgetting what you were coding just because TS is now in the way... That's an index of things, 1. do you really need TS and 2. do you know it well enough when you need it and 3. if you don't know it well enough then you might not need it.

    I don't see a long term future for TS besides some of the compile results it produces that could justify having it, but that is like having a kiddie car that you love and treasure... You can't take it on a race track no matter how much you love it, you will lose the race.

    ;-) maybe I'm wrong, but right now this is my view.
  • 1
    @swartzlib7 enums are hard to do in JSDOC imo so a x.d.ts won't hort that much
  • 1
    Usually, if TS can't figure it out, it's because you have ambiguity in the graph. I find this all the time with tuple usage; ehen transitioning between function boundaries, type information doesn't retain a tuple structure unless expressly defined as Tuple<...>, so the inference becomes a union type.

    Most of the time, the solution is top level fn input and output typing. It can resolve most of these uncertainties because it will provide enough inference on both ends of the equation that the rest of the symbols become inferentially finite. Hence why linters now mostly default to "specify return type explicitly."

    It's tedious. The benefits do tend to outweight the cost though, at least imo.
  • 1
    And you can always include those typedef files in your js project, VSCode will happily consume it!

    10x better than making a typedefs.js with a forced
    module.exports line.

    And overloads (although IDK if you should have a few different version of a function) are kinda cool.
  • 0
    I use js because it just fucking works.
    Fuck typescript and all the stuff you have to setup to make it do anything right
Add Comment