15 ms·

TypeScript is now officially 10 years old

198 points by bubblehack3r 4y ago

shanghaikid 4y ago
Typescript is for big project and team collaboration. JS is still my choice for personal or small project. Fast!
- iLoveOncall 4y ago
  > Typescript is for big project and team collaboration. TypeScript is for any kind of project, it just makes your code safer, easier to debug, easier to read / come back to in the future, etc. > Fast! That doesn't mean anything. Especially for a small project, the TypeScript to JavaScript compilation will take milliseconds, there is no speed impact at all.
  - kuramitropolis 4y ago
    My project is small but TS takes 4-5 seconds to compile it from scratch on each run. The main speed impact is in developer productivity though. If something ain't working right, now I first gotta fix the types before I can see if I've fixed the actual logic. I imagine if my codebase was more "OOP-y" (i.e. if I replaced every layer of my domain model with 3 layers of dependency injection, turning the whole thing into an inscrutable ball of spaghetti like the cartel wants me to) I could probably iterate without breaking the types. But for any sane developer having made the mistake to touch TypeScript, the capability to strip the types and run the code with broken types, is essential. "But then why have types at all?" Exactly. They're a crutch for people who want their IDE to understand the code instead of them.
    - CapsAdmin 4y ago
      For me the best experience during development is to build ts to js first with something fast like esbuild and check types in parallel without preventing the output in any way from running in the browser. A perfect scenario for me is having all errors in the project caught by vscode. At the moment vscode only checks files that are currently open. I think type checking should only be done when building to some sort of production or realtime in your editor. Templates like "create react app" can report runtime errors but it's somewhat strange that it also report typescript errors. (although understandable given that it wants to be tooling agnostic) One potential major upside with adding optional type hints to javascript is the ability to run typescript files directly in the browser without needing to strip types in a build step. Advanced type checking could be done the same way we use linters like eslint.
      - kuramitropolis 4y ago
        >At the moment vscode only checks files that are currently open While TSC checks everything by default - even files that are not even part of the dependency graph. That's how great the "great tooling" is in reality. >I think type checking should only be done when building to some sort of production or realtime in your editor. Agreed, that's the lest awful option. The problem is that they had 10 years to think of it, and didn't. >Templates like "create react app" ...are a big part of the problem. "But I don't want to spend a whole day just setting up a project!" You wouldn't have to, if you didn't drink the React kool-aid in the first place.
    - josteink 4y ago
      > But for any sane developer having made the mistake to touch TypeScript, the capability to strip the types and run the code with broken types, is essential. You’re free to hold that opinion, but I think you see (based on downvoting) that your definition of a “sane” developer is not as universal as you may have thought. Personally I almost never see any value in running known broken code. If I need to run/test a subset of my code without a complete working system, I have unit-tests for that purpose.
      - kuramitropolis 4y ago
        >your definition of a “sane” developer is not as universal as you may have thought Where I'm from, sanity has historically been the minority opinion, so we don't really have a word for this, but I think the English one is... "gaslighting"? "TS is a superset of JS", "there are 4/5 lights", "this line is longer/shorter", etc. (Look those up if you haven't, Microsoft marketers surely have.) What I'm saying is, I am well aware that I represent a minority, and guess what, getting downvoted (not nearly as much as expected) still beats keeping silent about the things that have been fucking with my head for the past, what, year and a half? Considering I've been writing Node for barely 6, the fact that every year the number of software developers doubles [cit needed] probably has a lot to do with it. No matter if we're talking about a very simple or a very complex system: if there are a lot of subtle inconsistencies in it, and you have to gradually learn your way around them, your ability to keep a consistent mental model of it in your head, and reason about what you're doing, will be impaired: -1 sanity. Ironically this is the same as people's gripes about the original JS type system. IMHO `==` and `===` should've been the other way around, and 1000 ships wouldn't've been launched. This unwieldy choice of notation (implicit type coercion on `==`) made it just enough subtly different for people expecting C-like strict equality, to create a feeling of confusion and distress. But since the underlying design principle was not clarified (in browsers all input comes from text boxes, as strings, anyway; and the original "source of truth" was only the HTML file, where element attributes are also strings; so in some limited sense it makes sense to have convert-from-string by default), we get all these (generations of) people with the impression that JS is a "low sanity" language... and that it needs, of all possible features, even more of a type system. >Personally I almost never see any value in running known broken code. That's completely subjective. Personally, I don't know how to fix a piece of code without being able to see with my own eyes how/where/why it breaks, but surely that's just my deficiency and everyone else is just telepathic. Boo, shame on me! (I'm also the guy with the months-long pull request because guess what, TypeScript did not make it easier for me to see what I'm doing wrong, just looped me into a waves of type refactors, sometimes causing me to break working code to get dat "spellcheck" out of everyone's faces. I do semver, but most libs on NPM don't ...) So, in my experience, TypeScript prevents me from running known good code way more often than it prevents me from running known/unknown broken code. As for what value you see in either, sure - that's a matter of style. Rust was mentioned elsewhere in the thread. It's great to work in a language where "compiles"="works". But TS is not a static language, where types actually matter; it's a restrictive "sanity checker" overlay on top of a dynamic language. And not one that's good enough for me to sacrifice the expressivity that JavaScript allows. Maybe it's good enough for many other people who never came to rely on JavaScript's flexibility that much in the first place. Thoughts and prayers to 'em. Each one has to make the choice which is the right tool for a job - and when there's an incipient monoculture trying to make that choice for me, I'm bound to make a ruckus. > If I need to run/test a subset of my code without a complete working system, I have unit-tests for that purpose. Amen to that! Thing is... you see how elsewhere in the thread, it's mentioned that people use TS annotations as an excuse not to write documentation? Well, in my purely anecdotal personal experience, they also use it for an excuse not to write unit tests! And considering what unit testing in JS looks like... well, no surprise there, either. "Ubiquitous JS" is supposed to be accessible. Instead, we have a number of onramps to it covered with rusty razor blades, TypeScript is not without its good parts, but overall my journey with it has been one of frustration and, as I'm sure you can see from miles a way, a whoooooole lot of mismatched expectations. Like, ESM working... Hence the exaggerations, and generally the lots of writing. I like JS/Node, I consider them simple I've been round the block just enough to see it evolve a bit, I gotta adapt to what others are doing (TS) because otherwise good luck getting help, right? So this is my honest perspective about that and I'm here to represent it because it's gotta amount to at least as much as the usual "nah bruh everything ok... u ok?"
    - Merad 4y ago
      It's always fascinating how different people approach writing code. I've worked with some very talented devs who preferred dynamic languages because they liked what I call a "smash face on keyboard" style of coding. They wanted to be able to make a change, run the code, make a change, run the code, often repeating that dozens of times before they got it right. I, and I think many people who prefer statically typed languages prefer a more methodical style of programming where we spend more time reasoning about the types and how data flows through the app. I might only run the code every five or ten minutes, but often if it builds it's right the first time. If the types are wrong, the code is wrong, and I've no interest in running code that's wrong. Is one side or the other right or better? I dunno, I'm not qualified to answer.
      - wizofaus 4y ago
        TypeScript doesn't entirely prevent you from doing that, even if you have to stick in a few "any" keywords here and there and ignore whatever linter warnings you might get. I'm happy for individual devs to work like that if that's what works best for them to get their code going - but I'm certainly not happy for a shared codebase for a large complex project with dozens of devs on it to operate the same way.
- blackoil 4y ago
  Considering how mature is the TS ecosystem, I see no reason to not use it for my personal projects.
  - jmull 4y ago
    You tend to have to write a bunch of code that mostly catches problems you don’t have. Personally, I’m marginally on the side of using TS even for small 1-2 person projects, but only slightly, and I can understand the case not to. Well designed projects are no more complex than they need to be, and for many smaller projects that means — at least for web ones — that you have few significant “type barriers” where types are non-trivial and communicate or structure things in a way that is useful. And the type-heavy areas also tend to be where the app is ingesting data from a non-local source — exactly where static type checking is useless. (It’s always extra annoying when you’re fighting the type checker when writing the code that really ensures the data has a valid form.)
- deleted 4y ago
  [deleted]
moomin 4y ago
The post mentions one of the most important factors in TypeScript’s adoption: it launched, from the start, with good tooling.
- throwaway0x7E6 4y ago
  that's maybe the second or the third most important factor. the first is aggressive marketing that microsoft does for its products.
  - scarface74 4y ago
    That unfortunately hasn’t helped C# become more popular outside of Microsoft legacy shops even when it did go cross platform and open source.
    - trinovantes 4y ago
      It's used in Unity game development I think Godot also supports it
    - christogreeff 4y ago
      What is a "Microsoft legacy shop" ?
      - xboxnolifes 4y ago
        Businesses that profit money without VC funding.
      - scarface74 4y ago
        Banks, insurance companies, government agencies, “enterprise development”.
        LudwigNagasena 4y ago
        So, 90% of the world GDP?
xcambar 4y ago
Brace yourself, a new trend is near.
- xodeus 4y ago
  I hope you're right, I've been waiting for Typescript to die for years
  - kuramitropolis 4y ago
    Someone please make WASM source maps JustWork!
seumars 4y ago
>TypeScript never set out to build a separate, distinct, and prescriptive language. Instead, TypeScript had to be descriptive. Sadly, the majority of people writing Typescript rarely care about descriptive and readable code these days. Somehow the focus shifted from using types to better understand complex systems through the code itself, to writing whatever polymorphic union type abomination that yields the best IntelliSense auto-completion in VSCode.
- iLoveOncall 4y ago
  I agree, but I would like to say that this is more due to the limitations of TypeScript (and JavaScript) and the need for developers to work around those limits, rather than anything else. TypeScript is great, but it is also still very far from being complete in my opinion. I used to do mostly Java and a bit of TypeScript, changed teams and now do mostly TypeScript and a bit of Java, and this unfinished feeling is striking, even for relatively basic things (enums). I think the modern compiler options / TypeScript rules such as "hey this variable can be undefined but you didn't specify it", "hey, it can also be null, don't forget that" are commandable, but just don't work well for the web. I know it's configurable, but it just makes for a bad experience. Still, love TypeScript. I wouldn't do any JavaScript project anymore, installing the TS compiler is always my first step.
- itsmeste 4y ago
  This. Probably every TS codebase I ever worked in had zero to none function- or inline docs with people always claiming "documented by TS". I call that BS, and you can see that in their projects. "Typescript codebase" became the equivalent of "generic low quality codebase" imo. I'll never understand why people need a programming language inside a programming language and refuse simplicity (i.e. using jsdocs, which has perfect IntelliSense support).
  - scrollaway 4y ago
    This is entirely applicable to JavaScript codebases, except that at least in typescript you have less reverse engineering work to do. If you want to have documented codebases, work with people who document their code. You’ll find that typescript doesn’t always mean undocumented, and incidentally you’ll find that documented doesn’t mean high quality. Most high quality codebases in the JS ecosystem after 2016 ish are in typescript.
magnio 4y ago
Thank you, Anders Hejlsberg. As a newbie in front-end development, I am grateful to TypeScript (and its integration with VSCode) for taming the dynamic beast and keeping me and my codebases sane. The pragmatic design and composable nature of TS help it fit easily within the JS ecosystem, and the productivity boon helps it survive in that tumultuous landscape.
rini17 4y ago
Wanted to try it, proceeded to install it with npm and it was incredibly scary, both the amount of stuff it pulled in and various warnings. No thanks, I'll stay with languages with more self-contained compiler.
- paavohtl 4y ago
  I don't understand what you are referring to - the TypeScript compiler has 0 (non-dev) dependencies: https://github.com/microsoft/TypeScript/blob/main/package.json https://github.com/microsoft/TypeScript/blob/main/package.js....
  - kuramitropolis 4y ago
    Yes, it also comes delivered as several near-identical builds for different contexts, each of which is nearly non-extensible. Have you seen the kind of monkey patching Volar (Vue tooling) does to enable type checking of TypeScript embedded in Vue templates? Meanwhile, native JSX support lol
    - lf-non 4y ago
      Well TS does have its complexities, but it is somewhat surprising to see the complaint being that supporting typechecking for something that is not TS at all (and something TS authors know nothing about) is complex. It is amazing that the whole langserver stacking that volar does is possible at all - I don't believe there is any equivalent prior art that worked as well as it does. Despite all the complexity the end user experience is pretty good. If someone had mentioned to me this kind of cross language type-checking can work as nicely before I used volar I would have been super skeptical. Sure it has its caveats. But it is also completely possible to use vue in pure typescript. I don't fault them for having native jsx support, React was just too popular in the target user base. I do hope that someday js+ts gets kotlin style builders, but until I'll gladly use volar.
      - kuramitropolis 4y ago
        JSX is also not TS at all, yet it gets preferential treatment (TSX). Unlike JSX/TSX, the TypeScript used by Vue is just TypeScript - wrapped in a tag next to some other stuff, so you know where the part you need to type check starts and where it ends. All TS needs to do to support this, on a basic level, is ignore the non-TS parts, i.e. let you turn each non-TS line into a comment. But no, even adding supported extensions to the compiler, that's right, not even formats, just making TS recognize a new extension as a file that it can load code from, is a no-go; a pre-load hook is the simplest thing to add, had they not made it explicitly, intentionally non-extensible. I didn't even have time to get into the "stacking of language servers" (something that can and should be as simple as a pipe, and of course Microsoft has all the reasons to make it the opposite of that). So the Volar people literally had to monkey patch Node's the standard library and edit TSC's source on the fly to make anything, work, at all. It all just goes downhill from there. Designing good APIs is hard enough - having to design them around the arbitrary barriers of some Microsoft boffins who decided to add a complex type system to a language which desperately needs a simple macro system - and took 10 years to do a shit tier job - oh, such an enlightening experience! Let's just say that I have become acutely aware that during the past year I have, well, degraded. As a person. And I literally attribute about 50% of that degradation to my ill-advised choice to do my work in TypeScript. Because like everyone I thought "hey, it's just a superset of JS, can't be that bad..."
shp0ngle 4y ago
I wish Flow, Facebook’s TypeScript, was more popular, as I think it has some better properties. But yeah, the tooling is kind of bad and it is all written in OCaml, while TypeScript is in TypeScript…
- lf-non 4y ago
  I always felt the decision to write flow in ocaml was ahead of its time. Flow compiler is much faster than TS. Native bundlers like esbuild, swc etc. are mainstream now but they came much later.
  - josteink 4y ago
    But writing Typescript in Typescript allowed the language-designers to dogfood the developer-experience of being a Typescript-developer. Just like MS eventually did with C# too. After the C#-compiler was reimplemented in C# (Roslyn), that’s when the language was truly allowed to develop. And it also made it much easier to make C# a truly cross-platform language. When the language-designers don’t have to use their own language, they have objectively much less motivation to improve upon the language or it’s tooling than if they do. The Flow-team didn’t use Flow to write Flow and that shows in its lack of development, its lack of tooling, its lack of contributors and ultimately in its lack of adoption.
    - shp0ngle 4y ago
      I think the type system was easier to express in OCaml as you get some stuff for free. I don’t know. I tried to understand the OCaml code and contribute to Flow, and in the end I nope-d my way out of there.
coffeeblack 4y ago
So what is the best book (under 250 pages!) to learn TS?
- cehrlich 4y ago
  If you're comfortable with JS, you don't need a book to learn TS. There are two main resources I would recommend: - for those who prefer written content, the TypeScript Handbook [1] - for those who prefer video content, the first couple videos of Jack Herrington's No BS TS series [2] Other than that, just start using it. My main advice would be that your TS code should look as much like JS code as possible, ie don't explicitly type everything, just rely on inference where possible. Basic generics can be useful occasionally, but most of the "Type Challenge" type stuff is only really useful to library developers. [1] https://www.typescriptlang.org/docs/handbook/intro.html https://www.typescriptlang.org/docs/handbook/intro.html [2] https://www.youtube.com/watch?v=LKVHFHJsiO0&list=PLNqp92_EXZBJYFrpEzdO2EapvU0GOJ09n https://www.youtube.com/watch?v=LKVHFHJsiO0&list=PLNqp92_EXZ...
- b0afc375b5 4y ago
  Can this be considered a book? https://basarat.gitbook.io/typescript/ https://basarat.gitbook.io/typescript/ Not sure if it's <250 pages though.
- Jcampuzano2 4y ago
  I wouldn't waste time buying/using a book to learn TS. If you have experience in any statically typed language you should be able to pick up the basics just by a quick peruse of the TS docs. And then even if you don't I'd still say reading the docs and just browsing existing code assuming you already know JS would get you all the way there.
mattlondon 4y ago
I was unsure of Typescript at first, but it has become an absolute joy and absolute pleasure to develop in. I was reluctant to introduce a build step (having got used to the simple refresh cycle of a browser plus vanilla javascript) but I am pleased to say that this is a bit of a non-issue now with modern tooling like esbuild et al. I still avoid NPM like the absolute plague, but the good news is that tooling like Deno have made typescript first server-side development in the ECMAScript world a total joy. I've said it before - it's like floating through the air. So serene, so expressive. A true joy.
- throwamon 4y ago
  Wait until you try a language that was supposed to have a decent type system from the beginning!
  - justsomeuser 4y ago
    I like type systems as you can design with types and check things tie together before even running the code. This gives you very fast iteration cycles compared to CMD-R refreshing the browser/code. Some issues with TS are: - There is no hard guarantee at runtime as everything is partially/optionally typed (including your deps). - The types are not used to produce faster code at runtime (like in a compiled language). It is almost like TS leaves half of the benefits of type checking on the table, obviously by design by being a JS superset.
    - eyelidlessness 4y ago
      > There is no hard guarantee at runtime You can get very close if you place fine-grained, well tested, type guards at IO boundaries, wrap poorly typed or overly dynamic dependencies, and have good discipline about internal boundaries. It’s a lot of work up front in a greenfield project, but it really pays off. > The types are not used to produce faster code at runtime Not directly, but in my experience good up front interface design tends to produce either immediately optimal JS (eg it tends to be monomorphic) or makes optimization much easier (as it makes any refactoring easier). Edit: > I like type systems as you can design with types and check things tie together before even running the code. This gives you very fast iteration cycles compared to CMD-R refreshing the browser/code. I’d be remiss not to emphasize this! And not just skipping the reload cycle, it lets you skip a whole lot of test runs too. Type error in editor? Yep, those tests are gonna fail too.
kuramitropolis 4y ago
- chuckSu 4y ago
- RunSet 4y ago
  > When people say, like, "blah blah VSCode this blah blah TypeScript that", all I hear is "Embrace, Extend, Extinguish the open Web ecosystem". Your memory may be too long to fit the TypeScript demographic.
  - kuramitropolis 4y ago
    Seems so :(
wildpeaks 4y ago
At the time, the turning point that finally made me switch from Flow to TS was when it added the JSdoc mode that allows you to have VSCode intellisense without a compile step.
kuramitropolis 4y ago
Any survivors of https://www.typescriptlang.org/docs/handbook/esm-node.html https://www.typescriptlang.org/docs/handbook/esm-node.html wanna share their experiences?
- zebracanevra 4y ago
  type module in the package.json, and import every and all .ts file with a .js extension. zero problems for a year or two.
  - kuramitropolis 4y ago
    >import every and all .ts file with a .js extension And recompile on every change, gotcha. I am emphatically not doing either. EDIT: for future reference, `"type": "module"` is not part of the fix but the thing that opens that particular can of worms. Rotten ones.
olitech 4y ago
Typescript was my stepping stone into the world of Rust. Even before Deno made it easy, it was straightforward enough to configure a simple tsconfig and just run tsc. Much like cargo, there is a lot to be said for "it just works" tooling - especially for beginners or even new programmers. It is probably fair to say it is one of the most influential and impactful languages of all time. There's even the future possibility of much of its type syntax being absorbed back into JavaScript: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
- krapp 4y ago
  > There's even the future possibility of much of its type syntax being absorbed back into JavaScript: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations ... as comments. Which superficially resemble the syntax of type hints but do nothing. Which has to be one of the worst language design decisions of all time.
  - kuramitropolis 4y ago
    ...as optional hints that don't require you to buy into a whole new toolchain.
    - krapp 4y ago
      I would prefer if they actually had a purpose in the language in which they were used (JS.) Add optional type hinting to JS itself, if it's that important, don't add pretend type hinting to it because typescript users don't want to have to use their compilers anymore. I know a lot of people like it but it just seems like an ugly hack to me, extra syntax for the sake of an abritrary third party tool. I know I'm a dinosaur. I want to go back to the days of JQuery modules and FTP. Feh.
  - olitech 4y ago
    I'd disagree that its a poor decision, some help is better than no help when reading code - and if it's inline then it's intrinsically meaningful. By no means is it perfect, the language doesn't enforce the type rules, but that the developer has the option is far better than not. As far as I can tell the proposal would pretty similar to Python; one can misleadingly or accidentally misuse type hints like the following: def myfn(a: int) -> str: return int(a) print(myfn("42")) But when done right, it gives you a leg up when you come back to read your own code or scan over someone else's. When you're reading over other's code in group programming assignments, comments make a world of difference (a niche example). It is a choice, but its use in code might just inspire someone to investigate further - my own introduction to types in programming came when I wondered what these oddly placed colons and arrows were in some Python I came across. If they do add these annotations to JavaScript, some future programmer browsing the source of a web page may well just stumble upon types and have a whole new world of theory opened up to them - I'm all for it.
k__ 4y ago
I wouldn't have bet on it. When it came out alongside Dart, I thought Dart to be the better, cleaner solution. After all, Google created V8. Microsoft and Hejlsberg didn't seem well suited to tackle something so lightweight as JS. The whole .net suite seemed like an overengineeres mess to me and MS wasn't liked after the IE6 incident. But on recent years I came to like TypeScript. It really is just JS.
yrgulation 4y ago
And still useless if you are at least half decent in js.
- kuramitropolis 4y ago
  Worse than useless.
  - BigJono 4y ago
    It actually is. TS is like a force multiplier for shit devs. All the worst code I've ever seen has been in TS and within the last 5 years. The average code quality has fucking plummetted in that time too, it's not just the worst offenders.
    - Jcampuzano2 4y ago
      I'd argue it's not actually TS that causes this. There are just a lot of unskilled devs. You mention "within the last 5 years" without also taking into account the absolute explosion in the popularity of becoming a software dev in the last 10 years. So of course theres going to be a lot of bad (and some good) devs. With TS being one of the literal most popular languages in use right now, of course a lot of bad code will be concentrated there, but I wouldn't blame TS itself for it. You can also blame hiring practices somewhat for it, since a lot of places I've worked for even myself recently hire anybody who can recite a couple ECMA features rather than focusing on good dev practices in general.
      - hbrn 4y ago
        > I'd argue it's not actually TS that causes this. There are just a lot of unskilled devs. But a lot of unskilled devs is status quo. It will never change: each year more folks are starting their career than becoming good devs. If your plane doesn't fly, you can't blame gravity.
samhuk 4y ago
I have a rather funny story about Typescript from ~4 years ago. I joined a team that had, amongst other things, an Node-Express.js and React-redux stack, all in vanilla Javascript. I was a bit younger and bolder then; I lamented with the lead developer about how vanilla JS was probably not a good idea for what was to be a large enterprise platform. The response I got back was probably what you would expect from a senior developer receiving criticism from a rather newly minted developer: Oh i've tried Typescript, but it's just SO VERBOSE. I feel like I can't get ANYTHING done, etc. etc. etc. I've personally been all in on TS from close to day one - around 2013 when I started some very early web development (hooray for the AngularJS/Angular days! /s). It somewhat scratches my ego and has been rather interesting to see the developer mindset change, particularly that of vanilla JS developers of old. Response like ones I had have gone from often negative, complaining about verbosity and I guess frustration with anything different from what they are used to, to overwhelmingly positive. Old guards join us, or fade away, I suppose.
rr808 4y ago
As a C++/C#/Java developer I just couldn't deal with Javascript. Since discovering TS its fast becoming my favorite language. I think I might even use in the back end going forward.
- lizardking 4y ago
  I like TS as a language but the single threaded nature of js will eventually weigh you down.
- osigurdson 4y ago
  How do you feel about the performance tradeoffs of doing so?
  - rr808 4y ago
    I dont write high volume applications so it isn't a huge problem for me. I do think threading is easy though and miss it.
DogLover_ 4y ago
I feel like I am the only one in the world not liking typescript. It is not that I don't like types, it is what those types do to the readability of the codebase in terms of verbosity. My original programming language was Java but I switched to Node.js because I liked the simplicity of the code written in it. Nowadays every Javascript project seems worse than a Java project in terms of verbosity. My main gripe with projects becoming verbose is that the code becomes hard to understand at a glance. Functions that usually could be 10 lines are now 15 lines becomes of the formatter and each line looks more gibberish because everything has a type. You have to manually filter out that noise. The best way I can describe it is that entropy is increased in order to get type safety.
- RedShift1 4y ago
  I'm also in the not-liking typescript camp. I was an early adopter (I think my first version was 1.7 or 1.8) and it put me off forever. What increased my productivity the most was not languages, linters, build tools, compilers, transpilers, etc... it was a good IDE. Now I just write plain Javascript with JSdoc and I don't need to update my toolchain every week.
  - eyelidlessness 4y ago
    I maintain several JS+JSDoc projects for work, and several TS personal projects. You can certainly get a very similar IDE experience with plain JSDoc, but the tradeoffs are pretty severe. Certain aspects of the type system have no JSDoc equivalent (assigning a type to a class definition), or worse have conflicting equivalents (eg enum, which I know everyone hates in TS but the JSDoc version is worse), or require cramming TypeScript syntax onto a single line in (eg conditional types). Most plain JS projects use some build tooling even without compiling TS, my work projects are no exception. When I started the job, the build tools (Rollup and Terser) worked just fine and had been in place for years. A short while later I made the case to switch to ESBuild to improve iteration speed, which took a couple hours maybe? It’s been almost totally untouched since. And if I had more time, I’d be able to gradually convert the code to TS without any additional tooling effort. I get that tooling pain in the JS/TS ecosystem is basically a running joke at this point, but no one is forcing you or anyone else to update anything. Plain old tsc still works if you want to keep it simple (and it’s what I recommend to anyone who wants to try out TS and feels confused or intimidated by the whole Tooling Thing). To each their own of course, but living on both sides of the fence… the JSDoc-types side isn’t nearly so green as it can sometimes sound. Here’s hoping the types-as-comments proposal keeps gaining traction. I’ll still use a build tool to strip types out for prod, but I think the no-tooling/JSDoc-types crowd would benefit a lot from a syntax much closer to TypeScript too.
an1sotropy 4y ago
sed s/vanilla/pure/g (my wish for what we call javascript itself)
nathias 4y ago
TS on frontend feels like devs making their editor choice (VScode) a hard dependancy
- hurflmurfl 4y ago
  What do you mean? I'm editing TS perfectly fine in Jetbrains IDEs, and some coworkers use emacs and vim without any issues, still getting all the error highlights, etc. Is there an editor that doesn't work with Typescript? Even without type error integration into the editor view, you could still run tsc in your shell of choice to manually check if everything is OK.
  - BigJono 4y ago
    > I'm editing TS perfectly fine in Jetbrains IDEs, and some coworkers use emacs and vim without any issues, still getting all the error highlights, etc. That's why you don't have any issues. The error popups aren't the problem. It's the autocomplete and type popups. The last few years TS has raised an army of shit devs that code in such a way that it's literally impossible to read the code without your IDE popping up multiple boxes to tell you what is happening. They just search every function name, giving zero thought to where anything lives in the directory structure. They type everything like fucking idiots, with layers upon layers of types across 10+ files, all of which you have to open just to find out you're working with an object that has a couple of strings and a number on it. Of course VSCode will just tell you this when you hover over the variable, if you're using it. Just wait until you get a project where these muppets have a majority and you'll feel the pain.
- christophilus 4y ago
  What? Works fine in my editor (neovim). It also worked fine in helix when I gave it a try.
  - nathias 4y ago
    I don't mean that it doesn't work on others, but that I don't need it and people who use vscode seem to.
twstdzppr 4y ago
It's a great language. I find it jarring to go back to regular JavaScript codebases after working in TypeScript for a bit now.

198 points by bubblehack3r 4y ago

shanghaikid 4y ago

Typescript is for big project and team collaboration. JS is still my choice for personal or small project. Fast!

iLoveOncall 4y ago
> Typescript is for big project and team collaboration. TypeScript is for any kind of project, it just makes your code safer, easier to debug, easier to read / come back to in the future, etc. > Fast! That doesn't mean anything. Especially for a small project, the TypeScript to JavaScript compilation will take milliseconds, there is no speed impact at all.
- kuramitropolis 4y ago
  My project is small but TS takes 4-5 seconds to compile it from scratch on each run. The main speed impact is in developer productivity though. If something ain't working right, now I first gotta fix the types before I can see if I've fixed the actual logic. I imagine if my codebase was more "OOP-y" (i.e. if I replaced every layer of my domain model with 3 layers of dependency injection, turning the whole thing into an inscrutable ball of spaghetti like the cartel wants me to) I could probably iterate without breaking the types. But for any sane developer having made the mistake to touch TypeScript, the capability to strip the types and run the code with broken types, is essential. "But then why have types at all?" Exactly. They're a crutch for people who want their IDE to understand the code instead of them.
  - CapsAdmin 4y ago
    For me the best experience during development is to build ts to js first with something fast like esbuild and check types in parallel without preventing the output in any way from running in the browser. A perfect scenario for me is having all errors in the project caught by vscode. At the moment vscode only checks files that are currently open. I think type checking should only be done when building to some sort of production or realtime in your editor. Templates like "create react app" can report runtime errors but it's somewhat strange that it also report typescript errors. (although understandable given that it wants to be tooling agnostic) One potential major upside with adding optional type hints to javascript is the ability to run typescript files directly in the browser without needing to strip types in a build step. Advanced type checking could be done the same way we use linters like eslint.
    - kuramitropolis 4y ago
      >At the moment vscode only checks files that are currently open While TSC checks everything by default - even files that are not even part of the dependency graph. That's how great the "great tooling" is in reality. >I think type checking should only be done when building to some sort of production or realtime in your editor. Agreed, that's the lest awful option. The problem is that they had 10 years to think of it, and didn't. >Templates like "create react app" ...are a big part of the problem. "But I don't want to spend a whole day just setting up a project!" You wouldn't have to, if you didn't drink the React kool-aid in the first place.
  - josteink 4y ago
    > But for any sane developer having made the mistake to touch TypeScript, the capability to strip the types and run the code with broken types, is essential. You’re free to hold that opinion, but I think you see (based on downvoting) that your definition of a “sane” developer is not as universal as you may have thought. Personally I almost never see any value in running known broken code. If I need to run/test a subset of my code without a complete working system, I have unit-tests for that purpose.
    - kuramitropolis 4y ago
      >your definition of a “sane” developer is not as universal as you may have thought Where I'm from, sanity has historically been the minority opinion, so we don't really have a word for this, but I think the English one is... "gaslighting"? "TS is a superset of JS", "there are 4/5 lights", "this line is longer/shorter", etc. (Look those up if you haven't, Microsoft marketers surely have.) What I'm saying is, I am well aware that I represent a minority, and guess what, getting downvoted (not nearly as much as expected) still beats keeping silent about the things that have been fucking with my head for the past, what, year and a half? Considering I've been writing Node for barely 6, the fact that every year the number of software developers doubles [cit needed] probably has a lot to do with it. No matter if we're talking about a very simple or a very complex system: if there are a lot of subtle inconsistencies in it, and you have to gradually learn your way around them, your ability to keep a consistent mental model of it in your head, and reason about what you're doing, will be impaired: -1 sanity. Ironically this is the same as people's gripes about the original JS type system. IMHO `==` and `===` should've been the other way around, and 1000 ships wouldn't've been launched. This unwieldy choice of notation (implicit type coercion on `==`) made it just enough subtly different for people expecting C-like strict equality, to create a feeling of confusion and distress. But since the underlying design principle was not clarified (in browsers all input comes from text boxes, as strings, anyway; and the original "source of truth" was only the HTML file, where element attributes are also strings; so in some limited sense it makes sense to have convert-from-string by default), we get all these (generations of) people with the impression that JS is a "low sanity" language... and that it needs, of all possible features, even more of a type system. >Personally I almost never see any value in running known broken code. That's completely subjective. Personally, I don't know how to fix a piece of code without being able to see with my own eyes how/where/why it breaks, but surely that's just my deficiency and everyone else is just telepathic. Boo, shame on me! (I'm also the guy with the months-long pull request because guess what, TypeScript did not make it easier for me to see what I'm doing wrong, just looped me into a waves of type refactors, sometimes causing me to break working code to get dat "spellcheck" out of everyone's faces. I do semver, but most libs on NPM don't ...) So, in my experience, TypeScript prevents me from running known good code way more often than it prevents me from running known/unknown broken code. As for what value you see in either, sure - that's a matter of style. Rust was mentioned elsewhere in the thread. It's great to work in a language where "compiles"="works". But TS is not a static language, where types actually matter; it's a restrictive "sanity checker" overlay on top of a dynamic language. And not one that's good enough for me to sacrifice the expressivity that JavaScript allows. Maybe it's good enough for many other people who never came to rely on JavaScript's flexibility that much in the first place. Thoughts and prayers to 'em. Each one has to make the choice which is the right tool for a job - and when there's an incipient monoculture trying to make that choice for me, I'm bound to make a ruckus. > If I need to run/test a subset of my code without a complete working system, I have unit-tests for that purpose. Amen to that! Thing is... you see how elsewhere in the thread, it's mentioned that people use TS annotations as an excuse not to write documentation? Well, in my purely anecdotal personal experience, they also use it for an excuse not to write unit tests! And considering what unit testing in JS looks like... well, no surprise there, either. "Ubiquitous JS" is supposed to be accessible. Instead, we have a number of onramps to it covered with rusty razor blades, TypeScript is not without its good parts, but overall my journey with it has been one of frustration and, as I'm sure you can see from miles a way, a whoooooole lot of mismatched expectations. Like, ESM working... Hence the exaggerations, and generally the lots of writing. I like JS/Node, I consider them simple I've been round the block just enough to see it evolve a bit, I gotta adapt to what others are doing (TS) because otherwise good luck getting help, right? So this is my honest perspective about that and I'm here to represent it because it's gotta amount to at least as much as the usual "nah bruh everything ok... u ok?"
  - Merad 4y ago
    It's always fascinating how different people approach writing code. I've worked with some very talented devs who preferred dynamic languages because they liked what I call a "smash face on keyboard" style of coding. They wanted to be able to make a change, run the code, make a change, run the code, often repeating that dozens of times before they got it right. I, and I think many people who prefer statically typed languages prefer a more methodical style of programming where we spend more time reasoning about the types and how data flows through the app. I might only run the code every five or ten minutes, but often if it builds it's right the first time. If the types are wrong, the code is wrong, and I've no interest in running code that's wrong. Is one side or the other right or better? I dunno, I'm not qualified to answer.
    - wizofaus 4y ago
      TypeScript doesn't entirely prevent you from doing that, even if you have to stick in a few "any" keywords here and there and ignore whatever linter warnings you might get. I'm happy for individual devs to work like that if that's what works best for them to get their code going - but I'm certainly not happy for a shared codebase for a large complex project with dozens of devs on it to operate the same way.
blackoil 4y ago
Considering how mature is the TS ecosystem, I see no reason to not use it for my personal projects.
- jmull 4y ago
  You tend to have to write a bunch of code that mostly catches problems you don’t have. Personally, I’m marginally on the side of using TS even for small 1-2 person projects, but only slightly, and I can understand the case not to. Well designed projects are no more complex than they need to be, and for many smaller projects that means — at least for web ones — that you have few significant “type barriers” where types are non-trivial and communicate or structure things in a way that is useful. And the type-heavy areas also tend to be where the app is ingesting data from a non-local source — exactly where static type checking is useless. (It’s always extra annoying when you’re fighting the type checker when writing the code that really ensures the data has a valid form.)
deleted 4y ago
[deleted]

moomin 4y ago

The post mentions one of the most important factors in TypeScript’s adoption: it launched, from the start, with good tooling.

throwaway0x7E6 4y ago
that's maybe the second or the third most important factor. the first is aggressive marketing that microsoft does for its products.
- scarface74 4y ago
  That unfortunately hasn’t helped C# become more popular outside of Microsoft legacy shops even when it did go cross platform and open source.
  - trinovantes 4y ago
    It's used in Unity game development I think Godot also supports it
  - christogreeff 4y ago
    What is a "Microsoft legacy shop" ?
    - xboxnolifes 4y ago
      Businesses that profit money without VC funding.
    - scarface74 4y ago
      Banks, insurance companies, government agencies, “enterprise development”.
      - LudwigNagasena 4y ago
        So, 90% of the world GDP?

xcambar 4y ago

Brace yourself, a new trend is near.

xodeus 4y ago
I hope you're right, I've been waiting for Typescript to die for years
- kuramitropolis 4y ago
  Someone please make WASM source maps JustWork!

seumars 4y ago

>TypeScript never set out to build a separate, distinct, and prescriptive language. Instead, TypeScript had to be descriptive. Sadly, the majority of people writing Typescript rarely care about descriptive and readable code these days. Somehow the focus shifted from using types to better understand complex systems through the code itself, to writing whatever polymorphic union type abomination that yields the best IntelliSense auto-completion in VSCode.

iLoveOncall 4y ago
I agree, but I would like to say that this is more due to the limitations of TypeScript (and JavaScript) and the need for developers to work around those limits, rather than anything else. TypeScript is great, but it is also still very far from being complete in my opinion. I used to do mostly Java and a bit of TypeScript, changed teams and now do mostly TypeScript and a bit of Java, and this unfinished feeling is striking, even for relatively basic things (enums). I think the modern compiler options / TypeScript rules such as "hey this variable can be undefined but you didn't specify it", "hey, it can also be null, don't forget that" are commandable, but just don't work well for the web. I know it's configurable, but it just makes for a bad experience. Still, love TypeScript. I wouldn't do any JavaScript project anymore, installing the TS compiler is always my first step.
itsmeste 4y ago
This. Probably every TS codebase I ever worked in had zero to none function- or inline docs with people always claiming "documented by TS". I call that BS, and you can see that in their projects. "Typescript codebase" became the equivalent of "generic low quality codebase" imo. I'll never understand why people need a programming language inside a programming language and refuse simplicity (i.e. using jsdocs, which has perfect IntelliSense support).
- scrollaway 4y ago
  This is entirely applicable to JavaScript codebases, except that at least in typescript you have less reverse engineering work to do. If you want to have documented codebases, work with people who document their code. You’ll find that typescript doesn’t always mean undocumented, and incidentally you’ll find that documented doesn’t mean high quality. Most high quality codebases in the JS ecosystem after 2016 ish are in typescript.

magnio 4y ago

Thank you, Anders Hejlsberg. As a newbie in front-end development, I am grateful to TypeScript (and its integration with VSCode) for taming the dynamic beast and keeping me and my codebases sane. The pragmatic design and composable nature of TS help it fit easily within the JS ecosystem, and the productivity boon helps it survive in that tumultuous landscape.

rini17 4y ago

Wanted to try it, proceeded to install it with npm and it was incredibly scary, both the amount of stuff it pulled in and various warnings. No thanks, I'll stay with languages with more self-contained compiler.

paavohtl 4y ago
I don't understand what you are referring to - the TypeScript compiler has 0 (non-dev) dependencies: https://github.com/microsoft/TypeScript/blob/main/package.json https://github.com/microsoft/TypeScript/blob/main/package.js....
- kuramitropolis 4y ago
  Yes, it also comes delivered as several near-identical builds for different contexts, each of which is nearly non-extensible. Have you seen the kind of monkey patching Volar (Vue tooling) does to enable type checking of TypeScript embedded in Vue templates? Meanwhile, native JSX support lol
  - lf-non 4y ago
    Well TS does have its complexities, but it is somewhat surprising to see the complaint being that supporting typechecking for something that is not TS at all (and something TS authors know nothing about) is complex. It is amazing that the whole langserver stacking that volar does is possible at all - I don't believe there is any equivalent prior art that worked as well as it does. Despite all the complexity the end user experience is pretty good. If someone had mentioned to me this kind of cross language type-checking can work as nicely before I used volar I would have been super skeptical. Sure it has its caveats. But it is also completely possible to use vue in pure typescript. I don't fault them for having native jsx support, React was just too popular in the target user base. I do hope that someday js+ts gets kotlin style builders, but until I'll gladly use volar.
    - kuramitropolis 4y ago
      JSX is also not TS at all, yet it gets preferential treatment (TSX). Unlike JSX/TSX, the TypeScript used by Vue is just TypeScript - wrapped in a tag next to some other stuff, so you know where the part you need to type check starts and where it ends. All TS needs to do to support this, on a basic level, is ignore the non-TS parts, i.e. let you turn each non-TS line into a comment. But no, even adding supported extensions to the compiler, that's right, not even formats, just making TS recognize a new extension as a file that it can load code from, is a no-go; a pre-load hook is the simplest thing to add, had they not made it explicitly, intentionally non-extensible. I didn't even have time to get into the "stacking of language servers" (something that can and should be as simple as a pipe, and of course Microsoft has all the reasons to make it the opposite of that). So the Volar people literally had to monkey patch Node's the standard library and edit TSC's source on the fly to make anything, work, at all. It all just goes downhill from there. Designing good APIs is hard enough - having to design them around the arbitrary barriers of some Microsoft boffins who decided to add a complex type system to a language which desperately needs a simple macro system - and took 10 years to do a shit tier job - oh, such an enlightening experience! Let's just say that I have become acutely aware that during the past year I have, well, degraded. As a person. And I literally attribute about 50% of that degradation to my ill-advised choice to do my work in TypeScript. Because like everyone I thought "hey, it's just a superset of JS, can't be that bad..."

shp0ngle 4y ago

I wish Flow, Facebook’s TypeScript, was more popular, as I think it has some better properties. But yeah, the tooling is kind of bad and it is all written in OCaml, while TypeScript is in TypeScript…

lf-non 4y ago
I always felt the decision to write flow in ocaml was ahead of its time. Flow compiler is much faster than TS. Native bundlers like esbuild, swc etc. are mainstream now but they came much later.
- josteink 4y ago
  But writing Typescript in Typescript allowed the language-designers to dogfood the developer-experience of being a Typescript-developer. Just like MS eventually did with C# too. After the C#-compiler was reimplemented in C# (Roslyn), that’s when the language was truly allowed to develop. And it also made it much easier to make C# a truly cross-platform language. When the language-designers don’t have to use their own language, they have objectively much less motivation to improve upon the language or it’s tooling than if they do. The Flow-team didn’t use Flow to write Flow and that shows in its lack of development, its lack of tooling, its lack of contributors and ultimately in its lack of adoption.
  - shp0ngle 4y ago
    I think the type system was easier to express in OCaml as you get some stuff for free. I don’t know. I tried to understand the OCaml code and contribute to Flow, and in the end I nope-d my way out of there.

coffeeblack 4y ago

So what is the best book (under 250 pages!) to learn TS?

cehrlich 4y ago
If you're comfortable with JS, you don't need a book to learn TS. There are two main resources I would recommend: - for those who prefer written content, the TypeScript Handbook [1] - for those who prefer video content, the first couple videos of Jack Herrington's No BS TS series [2] Other than that, just start using it. My main advice would be that your TS code should look as much like JS code as possible, ie don't explicitly type everything, just rely on inference where possible. Basic generics can be useful occasionally, but most of the "Type Challenge" type stuff is only really useful to library developers. [1] https://www.typescriptlang.org/docs/handbook/intro.html https://www.typescriptlang.org/docs/handbook/intro.html [2] https://www.youtube.com/watch?v=LKVHFHJsiO0&list=PLNqp92_EXZBJYFrpEzdO2EapvU0GOJ09n https://www.youtube.com/watch?v=LKVHFHJsiO0&list=PLNqp92_EXZ...
b0afc375b5 4y ago
Can this be considered a book? https://basarat.gitbook.io/typescript/ https://basarat.gitbook.io/typescript/ Not sure if it's <250 pages though.
Jcampuzano2 4y ago
I wouldn't waste time buying/using a book to learn TS. If you have experience in any statically typed language you should be able to pick up the basics just by a quick peruse of the TS docs. And then even if you don't I'd still say reading the docs and just browsing existing code assuming you already know JS would get you all the way there.

mattlondon 4y ago

I was unsure of Typescript at first, but it has become an absolute joy and absolute pleasure to develop in. I was reluctant to introduce a build step (having got used to the simple refresh cycle of a browser plus vanilla javascript) but I am pleased to say that this is a bit of a non-issue now with modern tooling like esbuild et al. I still avoid NPM like the absolute plague, but the good news is that tooling like Deno have made typescript first server-side development in the ECMAScript world a total joy. I've said it before - it's like floating through the air. So serene, so expressive. A true joy.

throwamon 4y ago
Wait until you try a language that was supposed to have a decent type system from the beginning!
- justsomeuser 4y ago
  I like type systems as you can design with types and check things tie together before even running the code. This gives you very fast iteration cycles compared to CMD-R refreshing the browser/code. Some issues with TS are: - There is no hard guarantee at runtime as everything is partially/optionally typed (including your deps). - The types are not used to produce faster code at runtime (like in a compiled language). It is almost like TS leaves half of the benefits of type checking on the table, obviously by design by being a JS superset.
  - eyelidlessness 4y ago
    > There is no hard guarantee at runtime You can get very close if you place fine-grained, well tested, type guards at IO boundaries, wrap poorly typed or overly dynamic dependencies, and have good discipline about internal boundaries. It’s a lot of work up front in a greenfield project, but it really pays off. > The types are not used to produce faster code at runtime Not directly, but in my experience good up front interface design tends to produce either immediately optimal JS (eg it tends to be monomorphic) or makes optimization much easier (as it makes any refactoring easier). Edit: > I like type systems as you can design with types and check things tie together before even running the code. This gives you very fast iteration cycles compared to CMD-R refreshing the browser/code. I’d be remiss not to emphasize this! And not just skipping the reload cycle, it lets you skip a whole lot of test runs too. Type error in editor? Yep, those tests are gonna fail too.

kuramitropolis 4y ago

chuckSu 4y ago
RunSet 4y ago
> When people say, like, "blah blah VSCode this blah blah TypeScript that", all I hear is "Embrace, Extend, Extinguish the open Web ecosystem". Your memory may be too long to fit the TypeScript demographic.
- kuramitropolis 4y ago
  Seems so :(

wildpeaks 4y ago

At the time, the turning point that finally made me switch from Flow to TS was when it added the JSdoc mode that allows you to have VSCode intellisense without a compile step.

kuramitropolis 4y ago

Any survivors of https://www.typescriptlang.org/docs/handbook/esm-node.html https://www.typescriptlang.org/docs/handbook/esm-node.html wanna share their experiences?

zebracanevra 4y ago
type module in the package.json, and import every and all .ts file with a .js extension. zero problems for a year or two.
- kuramitropolis 4y ago
  >import every and all .ts file with a .js extension And recompile on every change, gotcha. I am emphatically not doing either. EDIT: for future reference, `"type": "module"` is not part of the fix but the thing that opens that particular can of worms. Rotten ones.

olitech 4y ago

Typescript was my stepping stone into the world of Rust. Even before Deno made it easy, it was straightforward enough to configure a simple tsconfig and just run tsc. Much like cargo, there is a lot to be said for "it just works" tooling - especially for beginners or even new programmers. It is probably fair to say it is one of the most influential and impactful languages of all time. There's even the future possibility of much of its type syntax being absorbed back into JavaScript: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations

krapp 4y ago
> There's even the future possibility of much of its type syntax being absorbed back into JavaScript: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations ... as comments. Which superficially resemble the syntax of type hints but do nothing. Which has to be one of the worst language design decisions of all time.
- kuramitropolis 4y ago
  ...as optional hints that don't require you to buy into a whole new toolchain.
  - krapp 4y ago
    I would prefer if they actually had a purpose in the language in which they were used (JS.) Add optional type hinting to JS itself, if it's that important, don't add pretend type hinting to it because typescript users don't want to have to use their compilers anymore. I know a lot of people like it but it just seems like an ugly hack to me, extra syntax for the sake of an abritrary third party tool. I know I'm a dinosaur. I want to go back to the days of JQuery modules and FTP. Feh.
- olitech 4y ago
  I'd disagree that its a poor decision, some help is better than no help when reading code - and if it's inline then it's intrinsically meaningful. By no means is it perfect, the language doesn't enforce the type rules, but that the developer has the option is far better than not. As far as I can tell the proposal would pretty similar to Python; one can misleadingly or accidentally misuse type hints like the following: def myfn(a: int) -> str: return int(a) print(myfn("42")) But when done right, it gives you a leg up when you come back to read your own code or scan over someone else's. When you're reading over other's code in group programming assignments, comments make a world of difference (a niche example). It is a choice, but its use in code might just inspire someone to investigate further - my own introduction to types in programming came when I wondered what these oddly placed colons and arrows were in some Python I came across. If they do add these annotations to JavaScript, some future programmer browsing the source of a web page may well just stumble upon types and have a whole new world of theory opened up to them - I'm all for it.

k__ 4y ago

I wouldn't have bet on it. When it came out alongside Dart, I thought Dart to be the better, cleaner solution. After all, Google created V8. Microsoft and Hejlsberg didn't seem well suited to tackle something so lightweight as JS. The whole .net suite seemed like an overengineeres mess to me and MS wasn't liked after the IE6 incident. But on recent years I came to like TypeScript. It really is just JS.

yrgulation 4y ago

And still useless if you are at least half decent in js.

kuramitropolis 4y ago
Worse than useless.
- BigJono 4y ago
  It actually is. TS is like a force multiplier for shit devs. All the worst code I've ever seen has been in TS and within the last 5 years. The average code quality has fucking plummetted in that time too, it's not just the worst offenders.
  - Jcampuzano2 4y ago
    I'd argue it's not actually TS that causes this. There are just a lot of unskilled devs. You mention "within the last 5 years" without also taking into account the absolute explosion in the popularity of becoming a software dev in the last 10 years. So of course theres going to be a lot of bad (and some good) devs. With TS being one of the literal most popular languages in use right now, of course a lot of bad code will be concentrated there, but I wouldn't blame TS itself for it. You can also blame hiring practices somewhat for it, since a lot of places I've worked for even myself recently hire anybody who can recite a couple ECMA features rather than focusing on good dev practices in general.
    - hbrn 4y ago
      > I'd argue it's not actually TS that causes this. There are just a lot of unskilled devs. But a lot of unskilled devs is status quo. It will never change: each year more folks are starting their career than becoming good devs. If your plane doesn't fly, you can't blame gravity.

samhuk 4y ago

I have a rather funny story about Typescript from ~4 years ago. I joined a team that had, amongst other things, an Node-Express.js and React-redux stack, all in vanilla Javascript. I was a bit younger and bolder then; I lamented with the lead developer about how vanilla JS was probably not a good idea for what was to be a large enterprise platform. The response I got back was probably what you would expect from a senior developer receiving criticism from a rather newly minted developer: Oh i've tried Typescript, but it's just SO VERBOSE. I feel like I can't get ANYTHING done, etc. etc. etc. I've personally been all in on TS from close to day one - around 2013 when I started some very early web development (hooray for the AngularJS/Angular days! /s). It somewhat scratches my ego and has been rather interesting to see the developer mindset change, particularly that of vanilla JS developers of old. Response like ones I had have gone from often negative, complaining about verbosity and I guess frustration with anything different from what they are used to, to overwhelmingly positive. Old guards join us, or fade away, I suppose.

rr808 4y ago

As a C++/C#/Java developer I just couldn't deal with Javascript. Since discovering TS its fast becoming my favorite language. I think I might even use in the back end going forward.

lizardking 4y ago
I like TS as a language but the single threaded nature of js will eventually weigh you down.
osigurdson 4y ago
How do you feel about the performance tradeoffs of doing so?
- rr808 4y ago
  I dont write high volume applications so it isn't a huge problem for me. I do think threading is easy though and miss it.

DogLover_ 4y ago

I feel like I am the only one in the world not liking typescript. It is not that I don't like types, it is what those types do to the readability of the codebase in terms of verbosity. My original programming language was Java but I switched to Node.js because I liked the simplicity of the code written in it. Nowadays every Javascript project seems worse than a Java project in terms of verbosity. My main gripe with projects becoming verbose is that the code becomes hard to understand at a glance. Functions that usually could be 10 lines are now 15 lines becomes of the formatter and each line looks more gibberish because everything has a type. You have to manually filter out that noise. The best way I can describe it is that entropy is increased in order to get type safety.

RedShift1 4y ago
I'm also in the not-liking typescript camp. I was an early adopter (I think my first version was 1.7 or 1.8) and it put me off forever. What increased my productivity the most was not languages, linters, build tools, compilers, transpilers, etc... it was a good IDE. Now I just write plain Javascript with JSdoc and I don't need to update my toolchain every week.
- eyelidlessness 4y ago
  I maintain several JS+JSDoc projects for work, and several TS personal projects. You can certainly get a very similar IDE experience with plain JSDoc, but the tradeoffs are pretty severe. Certain aspects of the type system have no JSDoc equivalent (assigning a type to a class definition), or worse have conflicting equivalents (eg enum, which I know everyone hates in TS but the JSDoc version is worse), or require cramming TypeScript syntax onto a single line in (eg conditional types). Most plain JS projects use some build tooling even without compiling TS, my work projects are no exception. When I started the job, the build tools (Rollup and Terser) worked just fine and had been in place for years. A short while later I made the case to switch to ESBuild to improve iteration speed, which took a couple hours maybe? It’s been almost totally untouched since. And if I had more time, I’d be able to gradually convert the code to TS without any additional tooling effort. I get that tooling pain in the JS/TS ecosystem is basically a running joke at this point, but no one is forcing you or anyone else to update anything. Plain old tsc still works if you want to keep it simple (and it’s what I recommend to anyone who wants to try out TS and feels confused or intimidated by the whole Tooling Thing). To each their own of course, but living on both sides of the fence… the JSDoc-types side isn’t nearly so green as it can sometimes sound. Here’s hoping the types-as-comments proposal keeps gaining traction. I’ll still use a build tool to strip types out for prod, but I think the no-tooling/JSDoc-types crowd would benefit a lot from a syntax much closer to TypeScript too.

an1sotropy 4y ago

sed s/vanilla/pure/g (my wish for what we call javascript itself)

nathias 4y ago

TS on frontend feels like devs making their editor choice (VScode) a hard dependancy

hurflmurfl 4y ago
What do you mean? I'm editing TS perfectly fine in Jetbrains IDEs, and some coworkers use emacs and vim without any issues, still getting all the error highlights, etc. Is there an editor that doesn't work with Typescript? Even without type error integration into the editor view, you could still run tsc in your shell of choice to manually check if everything is OK.
- BigJono 4y ago
  > I'm editing TS perfectly fine in Jetbrains IDEs, and some coworkers use emacs and vim without any issues, still getting all the error highlights, etc. That's why you don't have any issues. The error popups aren't the problem. It's the autocomplete and type popups. The last few years TS has raised an army of shit devs that code in such a way that it's literally impossible to read the code without your IDE popping up multiple boxes to tell you what is happening. They just search every function name, giving zero thought to where anything lives in the directory structure. They type everything like fucking idiots, with layers upon layers of types across 10+ files, all of which you have to open just to find out you're working with an object that has a couple of strings and a number on it. Of course VSCode will just tell you this when you hover over the variable, if you're using it. Just wait until you get a project where these muppets have a majority and you'll feel the pain.
christophilus 4y ago
What? Works fine in my editor (neovim). It also worked fine in helix when I gave it a try.
- nathias 4y ago
  I don't mean that it doesn't work on others, but that I don't need it and people who use vscode seem to.

twstdzppr 4y ago

It's a great language. I find it jarring to go back to regular JavaScript codebases after working in TypeScript for a bit now.