Hacker News Reader

As someone with 10+ years JS experience and now 3+ months TS I can not agree with you and the gp. It's total hyperbole what you are writing.

We are converting our huge and messy JS code base to TS, which uses a plethora of libs like jquery + plugins, bootstrap, kendo, knockout, and now React (don't ask me, I don't make the decisions), and we are not even close to done yet. So far TS has been a huge productivity boost. Refactoring is a breeze and the compiler found so many subtle bugs that our JS code had. Converting JS to TS is mostly straightforward, just a few type annotations here and there, the compiler can infer types mostly by himself.

Sure, TS has it quirks, the type definitions of external JS libs is not perfect, allowJs can sometimes be a pain, but so far there wasn't really anything as bad as you make it sound. where we would say "screw TS, let's go back to ES/babel". Quite the contrary, none of our JS devs would go back to plain JS. JS is a huge pain in the ass to refactor, especially on large and complex code bases.

> I fear Typescript is here to stay. If that's the case, I'm moving to Swift and iOS, or changing career completely.

Good riddance then, I'd say :) I'm sure Swift or iOS development has no quirks whatsoever.

When the tooling works, it has some really great things mostly related to IDE functionality. But when it doesn't it's a nightmare. It's more than just quirks. It's not hyperbole either, I just had a different experience with it than you.

I sincerely hope it doesn't die on you after you convert your codebase. I wouldn't wish that on anyone.

It's far worse than "the definitions for external JS libs are not perfect;" it's that the TypeScript compiler throws a tantrum when they aren't perfect, which is >50% of the time, to be generous. AllowJS is relatively recent and didn't exist when I started using it - which is shocking, because integration with the JavaScript ecosystem was a major selling point (just check the TS project site's front page). CheckJS is very recent and VS2017 doesn't even support it yet - for a language whose main selling point is tooling support, it's shocking that VS2017 doesn't let users update their TS version.

Another selling point listed on the front page of its website: ES2015 features. Except it doesn't provide Promises, Map, Sets (and I can't remember if they added Object.Assign support, but it also was not supported when I was using it). When you provide your own polyfills, TSC complains unless you provide typings and add specific config values informing it what you polyfilled.

Its 3 main selling points were JavaScript ecosystem integration, ES2015 features, and tight tooling/IDE integration. Each of those things failed me when I used it. The IDE part hurt me the worst, preventing my project from compiling altogether for a while. Every one of its main selling points has been a pain point for me.

> I sincerely hope it doesn't die on you after you convert your codebase. I wouldn't wish that on anyone.

Pretty sure the product I'm working on will die long before TS :) I think TS is here to stay, and if MS decides to drop it, for whatever crazy reason, then the source code is available. And there is still the option to take the compiled JS code, and hope for some "cleanup" tool, like Decaffeinate, or gradually clean it up yourself... Not nice I agree, but I see no dead end here.

> it's that the TypeScript compiler throws a tantrum when they aren't perfect, which is >50% of the time, to be generous.

Really not sure why our experience differs so much from yours. Like I mentioned, we use a shitload of popular libraries, and for every single one there was a d.ts file available. If I see a definition that is wrong/outdated/broken then I create a fork, fix it and make a pull request. Doesn't usually take longer than a few minutes (depending how outdated the definition file is). Instead of complaining, I try to actively help improve the situation. Most of those d.ts files are written by normal developers in their spare time, after all, so it doesn't help to curse those people.

> Another selling point listed on the front page of its website: ES2015 features. Except it doesn't provide Promises, Map, Sets (and I can't remember if they added Object.Assign support, but it also was not supported when I was using it). When you provide your own polyfills, TSC complains unless you provide typings and add specific config values informing it what you polyfilled.

Yeah it's weird, and I don't get it either. Our solution to this is to run the compiled JS code through Babel. We use webpack for this and it's pretty much hassle free. On the other hand, for someone new to TS/JS this may not be obvious. So I agree there is a tooling problem in this regard, but once you know about it, it's a non issue. So yeah, it would've been nice if the TS compiler did properly polyfill things.

And don't get me even started on Visual Studio. I hate to work with it. It's nice for small projects/solutions, but we have a rather big solution, with a couple "Azure cloud classic" projects, and the whole thing is soooo fucking slow. Changing a single value in a ServiceConfiguration.cfg file will freeze VS for almost a minute, for example. There is lag and delays everywhere. The "TypeScript for Visual Studio Extension" was also very problematic, so we disabled all TS features in VS. We use Sublime/VS Code only since a very long time to edit our JS code. VS is a sad joke for a frontend developer.

I'm absolutely fine with external libs not being typechecked if there's no d.ts. The issue is it literally didn't support this scenario until 1.8 (when AllowJS was added). To me, this is the biggest tell that there's something fundamentally wrong with TS's design priorities. How could it not support JavaScript libraries for so long?

Here is one of numerous posts mirroring one of the module resolution issues that has plagued my project: https://stackoverflow.com/questions/39957100/visual-studio-2...

There are equivalent reports on GitHub and elsewhere on the net, as well as numerous related but separate issues.

IDEs from the same organization that sponsors TS don't even work reliably with it. Note one of the responses: "try VSCode." Indeed, VSCode works for me on the exact same code.

Currently I'm doing the same thing as you: running the TS output + the non-TS codebase through a giant blender of browserify + babel.

At one point, I would use --outfile, which makes TSC bundle all your files and dependencies. Neat, right? Nope - it gets the order of the dependencies wrong, which you find out later, at runtime. The maintainers on GitHub said "don't use outfile."

Are you really sure it wasn't possible to use external libs prior to the allowJs flag? I vividly remember a colleague fiddling around with TS when 1.0 was released, and we had discussions about definition files and how lacking they were. But I'm pretty sure he was able to declare an external module as "any" in a d.ts file, and then he could simply require it and use it without type information. As far as I know, the allowJs flag allows you to import/require your own .js files (as opposed to external modules), before that this wasn't possible apparently. Without this functionality I don't know how it was possible to gradually convert a code base to ts. We probably wouldn't be using TS now without the allowJs flag. I guess we are lucky to have picked up TS in a state where most of the early issues have been resolved (not saying there are no issues left).

I totally understand your frustrations with VS, though most of the problems you mentioned seem to be related to the TS integration in VS, and not with TS directly. But issues like yours are the reason why I lost hope in VS. I try to use it as little as possible.

I'm not sure if it was impossible, just that it was a giant mess and it utterly failed to work properly for me. Broadly speaking, point is just that TS treats JS as a second class citizen, and it adversely affects the day to day usability.

it seems reasonable that it didn't allow it before the language designers explicitly created a flag for it.

That doesn't mean some enterprising soul wasn't able to make it work, but it does mean it wasn't officially supported.

> Except it doesn't provide Promises, Map, Sets (and I can't remember if they added Object.Assign support, but it also was not supported when I was using it). When you provide your own polyfills, TSC complains unless you provide typings and add specific config values informing it what you polyfilled.

I think you may have misunderstood what Typescript is and isn't.

It isn't meant to provide polyfills, it is only supposed to handle the grammar of the language that needs to be transpiled.

That's why you have the two following settings: - target : Which version of the grammar will be available at runtime (eg. classes, async, ...), that's the part used by the transpiler - lib : Which libraries (eg. promises, maps, sets, ...) you know will be available at runtime (only used for type-checking)

Using a polyfill is really easy if you are using the right value for "lib" since the it will have the same signature as the real method: simply import it once in your project.

That's fair enough. My actual main issue with this is that TS was hostile towards any external JS libraries, especially before 1.8, but still sporadically in 1.8+, and that affected polyfills too. I also had serious issues importing external libraries that provided their own polyfills.

It was sort of a catch-22 that it didn't like JS yet expected JS polyfills. This has been greatly improved but it took far too long for a project that purports to be a part of the JS ecosystem, which raises questions and I must admit, makes me cynical about whether this was a business tactic.

I've now written many replies with elaborations and clarifications of my criticisms, so it may seem like I'm excessively negative about TS. I actually really like the language itself, especially the static type checking, which is the one main selling point. The OO language features are great because they're optional. I just think everything around the language is rough, and if you're unlucky with it, it can ruin the whole experience.

I remember that at one point, people would declare `require` and use `import whatever = require('whatever')` for npm libraries. This thing was for the longest time absolutely hostile towards JS, and some remnants of that philosophy remain to this day.

I have not forgotten being told to write what amounts to C header files, for JavaScript, in order to allow TSC to play nice with the ecosystem! That was definitely hubris.

Or maybe - and this is what I'm honestly inferring from your comment, it's not snark, it's just a hunch based on 16+ years of web development experience - just maybe there were issues with your teams code quality that means TS has been a huge win for you. Looking at that stack, it seems like someone in your organisation likes sticking plasters over problems.

I'm not a Javascript apologist by any means. I think Typescript makes an already quirky and clunky language worse.

Yep, sticking plasters over problems describes it perfectly ;) Many refactoring attempts, but never completed, because JS makes it really hard. And yes, code quality is bad. Most of it was written by people who never wrote JS/HTML before, then it grew historically and here we are with this mess.

But besides TS being very helpful in a messy code base, personally I would also always start a new project with TS. For me the benefits greatly outweigh the minor annoyances (I really see them as minor)

> Looking at that stack, it seems like someone in your organisation likes sticking plasters over problems.

glad to see I'm not the only one that got that from the post.

Fortunately, ES6 and 7 are very pleasant to work with. And say what you will about Facebook as a company, but their tech side tends to favor lean technologies over bloated ones, e.g. React over Angular (don't get me started on Angular!). I would pursue that path if I were you.

I think the difference comes from the fact that Facebook makes things for the web. Their technologies are born out of necessity. Typescript feels like an academic exercise, created by someone who doesn't like Javascript (and there are good reasons to not like Javascript), and wants to reshape it to there tastes, but in the abstract, outside the context of real word usage.

And Angular feels more like a land grab than a useful tool to me.

Angular initially solved a very small problem - forms. It just scaled really badly (by design but then it was never highlighted in the documentation) and then had second system syndrome

If you haven't used it, Flow is a fantastic alternative to TypeScript. They still have some hiccups about working correctly on windows, but it's a much easier way of doing typing in JS than TS.

Except it is impossible to prevent it from typechecking node_modules; so if you have a dependency that was checked with a different version of flow than you are using, you may see errors that are impossible to silence.

The only way I've been able to get Flow to be usable on my low-specced laptop is to tell it to [ignore] node_modules/.* and add a file to both [ignore] and [libs] which has one of these for each of my dependencies:

    declare module 'npm-module-name' {  declare var exports: any;  }

I needed similar for TypeScript when trying to use noImplicitAny: false - adding "typeRoots": ["node_modules/@types"] in compilerOptions and a d.ts file with the following listed in "files":

    declare module "*"

Typechecking third-party dependencies seems to be a bit of a crapshoot if you're not in a part of the module ecosystem where the tool you're using is either quasi-required, popular or has module authors using the same tool and shipping type definitions themselves. I've had contributed type definitions in both Flow and TypeScript "break" working, tested code.

Typescript is different - I can use type definitions from NPM without typechecking dependencies I don't import.

I've tried flow too. I've got an article on the boil that walks through creating a production ready SPA with Babel, Typescript, and Flow. Covering the whole stack including Webpack, unit tests, and integrating Typescript with Babel (which is still a must as far as I'm concerned).

If I got to make a choice, I'd use tern.

> It's such a horrible development experience that I'm looking for a way out of web dev

Before you abandon web dev altogether, you'd possibly enjoy the React or Vue communities more where TypeScript is not as popular, and Babel (writing ES6/ES2015+) seems to be the default. (e.g. create-react-app and vue-cli's 'vue init' default to using Babel).

I'm a React guy. React + Redux + Reselect + Sagas + Immutable.js is my goto stack. And I like to work with React-Boilerplate when I'm working on something big. But I'm handy enough with Webpack and Babel that I can spin up a small project on my own without needing create-react-app.

But I'm a "consultant". So I have to take the clients desires into consideration too. On my current project, I managed to steer them away form Angular2 (which they'd never used in anger) to React+Redux. But they tacked on Typescript (after rejecting Flow) for reasons that didn't make very much sense to me.

As a result, I've got a working version of what is essentially React-Boilerplate written in Typescript, which I can't share with the community because the client isn't into sharing (but they sure do love using other people's code), but even if I could, I'd be wary of doing it because it would validate what I believe to be a massive mistake.

But the moral of this story is; Often, the decision to use a library, framework, or language is not the developers choice. And it is often a decision taken for questionable reasons.