Learn More
Resend Email
12
FuckTS
5y

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.

rant

die

nasty

retarded

typescript
Favorite
Ranter
Comments
  • 9
    5y
    Everyone else is absolutely wrong.
  • 2
    5y
    Plus: JSDOC on VsCode is unstable as a bipolar person: the type declaration import that worked yesterday won't work today.
  • 13
    5y
    Each to their own, I'm no typescript fan either, but point 6 kinda signals you've missed the point of strong typing.
  • 7
    5y
    > 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.
  • 5
    5y
    100% agree.

    TypeScript is total shit.
  • 7
    5y
    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
    5y
    @SomeNone And all three being better than JavaScript weirdly enough ;)
  • 0
    5y
    @SomeNone

    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
    5y
    @SomeNone Haven't heard of it I'm afraid
  • 1
    5y
    @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
    5y
    @SortOfTested Would love to hear some constructive criticism, I am a junior developer still, enlighten me.
  • 6
    5y
    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
    5y
    @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
    5y
    @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
  • 0
    5y
    @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).
  • 0
    5y
    @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
    5y
    @SomeNone
    That's not really a positive in my book 😉 I decline PRs that attempt it.
  • 1
    5y
    @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
    5y
    @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
    5y
    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
    5y
    @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.
  • 0
    5y
    @molaram

    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
  • 2
    5y
    @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
    5y
    @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).
  • 1
    5y
    @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.
  • 0
    5y
    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.
  • 0
    5y
    @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
    5y
    @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.
  • 3
    4y
    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
    4y
    @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
  • 3
    4y
    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
    4y
    @swartzlib7 enums are hard to do in JSDOC imo so a x.d.ts won't hort that much
  • 1
    4y
    @swartzlib7
    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
    4y
    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.
  • 2
    4y
    I use js because it just fucking works.
    Fuck typescript and all the stuff you have to setup to make it do anything right
  • 0
    3y
    TS solve some errors, improve dev experience, but it doesn't worth it.
    Too much overhead, need to write more code, it's add enough cognitive complexity to code, but it prevent so few errors.
    Benefits just not worth effort. More time spent on fighting TS than solving bugs that TS supposed to prevent.
  • 1
    3y
    If you find VSCode JSDoc not working,

    please open the document where you write the typedef.

    VSCode do it well to solve performance problem, only scaning typedef of opened documents.
  • 0
    3y
    @NoToJavaScript You should write a deep comparison function if you want to compare Number and String in JS to avoid type mismatch. Not the problem of JS, is your sense of programming matters. You think this comparison is important but you rely on others to do that for you.... is it really make any sense?
  • 0
    3y
    @12bitfloat

    I think you do not understand how JS working around with data.

    We can define a JSObject in any hierarchy and any type of data, even function pointers, even a field can be multityped.

    It makes JS developer more aware of their variable types to avoid bugs, not depends on just how you define the type in codes, but more precise logics when doing such comparison works when necessary.

    Besides, typescript/strong-type limits your data structure design in this noSQL world.
  • 0
    3y
    @louiszen I do understand how JavaScript works with values ...which is exactly why I don't like it

    I'm almost exlusively doing Rust now (pretty much the furthest from dynamic typing possible) and I'm having the time of my life

    Different strokes for different folks I guess
  • 0
    3y
    @louiszen If a developer - any developer - is actually aware of their types then it's no serious effort to write typings for them. The reason Typescript is time consuming is precisely that it forces you to be aware of your types. It's not the extra keystrokes that takes time, it's thinking of types - something JS devs tend to avoid.

    Typescript has generics, conditionals, type narrowing, unions and intersections, recursive types. It's capable of expressing almost anything and what it can't express definitely doesn't take half as long to work around as it did to write the code in the first place.
Related Rants
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment