It looks like Microsoft's TypeScript is the new hotness (static types! just like Java and C++, but better), and it's only compatible with ES6, not Coffeescript.
In particular, attempting to use it with npm modules is an exercise in tedium, as its module resolution constantly breaks and bizarre, undefined behavior does not stop happening. I've found dozens, maybe hundreds of similar reports online, with no solutions offered. There are all sorts of arbitrary gotchas with its configuration as pertains to this and other things. "Oh, don't use outDir and it'll work."
While it has great and straightforward integration with VS Code, it has disastrous integration with Visual Studio 2015 and 2017, the latter of which does not even support updating the bundled TS version at will without registry hacks. While TS emits code even in the case of errors, in many situations, Visual Studio refuses to complete the build process in case of TypeScript errors.
For an ES6+->ES5 transpiler, it is also very strange in that it polyfills some things but not others, such as Promises and Maps.
TypeScript has ultimately brought an unacceptable overhead to my project. It does not get out of the way as soon as you attempt to use it with the rest of the ecosystem. There belies its arrogance: it treats JavaScript as a second class citizen and favors Typings (additional files that assign types to plain JavaScript libraries). But in most cases, Typings are outdated, or nonexistent. Only recently has support for plain JavaScript libraries gotten better, with the AllowJS and CheckJS flags, the latter of which Visual Studio 2017 does not recognize for whatever reason.
In my view, it comes with so much baggage that it's probably not worth using. Some of the solutions proposed by the project maintainers amount to writing boilerplate just to support JavaScript functions. It's essentially C header files: you have to write module declarations for certain plain JavaScript libraries to work. There are different versions of this boilerplate that you could be asked to write: you may be told to write a typings file (i.e. declare every single function of the library you want to use in a separate file, and add it to the project, possibly using ///<reference> in certain specific scenarios). There are also ad-hoc declarations of modules and constants/globals that you may or may not need to write (there is no idiom here, and the language regards this as going off-road).
You used the word "arrogance", and that's exactly what it is. The fact that it's a transpiler (and a poor one at that) makes no sense to me. It's reach exceeds it's grasp and it burdens developers with the task of fixing it's own failings.
Before anyone says "you just don't like typed language", stop right there. I do like Typed languages. Typescript is just very very poor when compared to other modern typed languages.
It's such a horrible development experience that I'm looking for a way out of web dev. It's clear the community has gone nuts for it. And the Java back enders who seem to have an unwarranted amount of influence in this world are forcing it onto front end developers simply because it looks like Java. And damn you Angular2 for making all of this worse. You're a clunky and bloated framework already, but not content with ramming your flawed methodology down our throats, you've gone and stuck Typescript in there too, seemingly just out of spite.
I fear Typescript is here to stay. If that's the case, I'm moving to Swift and iOS, or changing career completely.
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.
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 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.
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.
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.
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."
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.
That doesn't mean some enterprising soul wasn't able to make it work, but it does mean it wasn't officially supported.
I'm not a Javascript apologist by any means. I think Typescript makes an already quirky and clunky language worse.
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)
glad to see I'm not the only one that got that from the post.
And Angular feels more like a land grab than a useful tool to me.
If I got to make a choice, I'd use tern.
declare module 'npm-module-name' { declare var exports: any; }
declare module "*"
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).
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.
First off, I really like the language design. It's typing but without the red tape or the ceremony that makes languages like Java so bloated and painful. Duck typing works nicely. Not having to name every little type is a breath of fresh air. Typing is optional and easy to add when needed. It works well with both VSCode and IDEA.
On the flip side, I've found myself spending far too much time trying to find the right typings to match the libraries that I use. It's very easy to end up with odd conflicts. Reminds me of the (hypothetical, of course) experience of finding subtitle files to match a bootleg movie. More often than not, they are off by five seconds, or jump out of sync midway due to been for the director's cut or whatever. Typescript typings are a bit like that; they get you 98% of the way but the last 2% can be surprisingly frustrating. That being said, after it has become possible to install typings from npm, it has become somewhat more manageable.
But yeah, there is a premium to Typescript, like there is to unit tests. It's not a premium that I want to pay for a project unless I'm pretty sure that there is a payoff down the road.
<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
When using Webpack you can run `webpack --watch` or run the Webpack dev server where it will instantly process changed TypeScript files to provide an optimal iterative dev work flow:
http://docs.servicestack.net/templates-single-page-apps#deve...
The following is specific to my case: as I'm working on a Cordova app, in order to launch the test process, I need VS to think the build was successful, which it often no longer does because TS module resolution and its associated configs are completely erratic. This is VS2015 with its Ripple emulator. I could upgrade to VS2017, which instead uses cordova-simulate, but then other TS-related issues appear. I can go into detail on this if you're interested.
If I set the build flag you mentioned, then it defeats the purpose of TypeScript somewhat, since TS's error reporting being wrong is the reason VS wasn't accepting the builds in the first place. TypeScript without correct IDE integration is nearly useless.
If I move to VSCode, the Cordova extension there decides to overwrite config.xml as it pleases, and you can't debug in Chrome (the extension shuts down if you try!). This bit is not TypeScript's fault, but having to go through all these IDEs is.
To be clear, the above is simply my current problem with TS. My complaints about it are not limited to this one issue I'm facing. It has some pretty fundamental flaws that revolve around its mistreatment of its own JavaScript target.
Although Typescript started a bit as you say, complex tooling, had to write external type declaration to have the typing for external libraries (but they are optional, not having them only means not having typing on externals, which is fine in many cases, so not in the way at all), but overall, typing provided so many benefits it was already worth it to me: litterally saved me hundreds of bugs found at compile-time, and keeps the maintenance of the code base cheap and easy. But typescript evolved a lot, now the typing declaration are based on npm, the compiler got faster by an order of magnitude, it provides services to the IDE, and so on.
I just wouldn't start a new project with a reasonable expected lifespan without typescript.
>not having them only means not having typing on externals
AllowJS didn't exist until mid-late last year, so using JS libraries was pretty disastrous before that. That definitely fueled a part of my rant. I find this absolutely shocking, for a language that purports to work with JavaScript.
JS modules actually still do not work right for me, as TSC can no longer resolve node modules. I've searched far an wide and found others with the exact same problems and no solutions. It happened suddenly and without cause.
Nor does the IDE integration work for me at all. I've actually done completely fresh installations of the IDEs I've tried but nothing would resolve the issues I faced. I'm stuck with a dud of a VS2015 which can't recognize jQuery from npm. VS2017 can resolve the same modules but fails elsewhere.
It then proceeded to choke on a JS library that uses its own Promise polyfill, yet provided a d.ts file.
No snark, I am genuinely glad it worked well for you. But for me, it's overly laborious getting it to work right, and I've had enough of things like ///<reference> and d.ts files and reconfiguring tsconfig.json.
> it has disastrous integration with Visual Studio 2015 and 2017
Yes, this is true. TS, like ES2015+, really wants to have a complete client build system. All the attempts to integrate it into the VS build have been disastrous, from web essentials on down. And you won't learn that from MS. All the problems you mention went away for me as soon as I began to treat the client code as a first-class citizen.
Move all the client code outside the solution and give it its own build, and a lot of these problems go away. I never have problems importing npm modules, and I haven't written a ///<reference> comment in over a year.
> Some of the solutions proposed by the project maintainers amount to writing boilerplate
It sounds like that's a problem with the project maintainers rather than the language.
Static type checking is great in theory but it's just not worth it if you can't get it to play nice with npm modules. I haven't been able to do so reliably in my year of using TS, among other issues. However, don't necessarily take it from me: if you can get it to work, then great, maybe you'll like it more than I did.
If your project has a simple build process, you could still try TS with vscode; it works far better than with VS2015/2017 (that's not to say you won't encounter issues, but it won't be as hellish to diagnose).
Although, IMHO, I would argue that Types just don't fit JavaScript; TypeScript is very OO while JavaScript is not. My TS code is all classes and interfaces. It's quite Javaesque and a departure from the non-TS part of the codebase. It feels a bit too enterprisey and unproductive for the JavaScript ecosystem. This last part is just opinion, though.
This, in addition to the relentless bureaucratic weirdness I encountered, has driven me away. For instance, it doesn't polyfill Promises, Maps, or Sets, even though its front page says it's an ES2015 transpiler. You have to polyfill them yourself, and then you have to get TypeScript not to reject them by providing typings (https://stackoverflow.com/questions/30019542/es6-map-in-type...). You also have to set a config flag in tsconfig.json that tells TypeScript that you're providing those polyfills, i.e. {"lib": [ "es5", "dom", "es2015.promise" ]}. Good luck finding all of this information in one place.
I think TypeScript is secretly the enemy of JavaScript.