JavaScript libraries should be written in TypeScript
staltz.com
staltz.com
I personally have converted a few of my libraries [1] [2] over to Flow. It helps me personally, catches a lot of bugs, and does a great job of self-documenting while not getting in the way.
Flow has a lot of bugs and a lot of growth ahead of it, but it is far easier to get started with than TS. I highly recommend it.
1. https://github.com/STRML/react-grid-layout/blob/master/lib/u...
2. https://github.com/mzabriskie/react-draggable/blob/master/li...
I know this was definitely the case when I started using TS a few years ago, but they recently added support for compiling .js files in your typescript projects, so you only need to deal with the compiler one file at a time.
Admittedly I haven't used it, but I think it should have made the migration easier. Probably still not as easy as Flow, but easier...
TS is a little harder to get started with for a few reasons. For one, it simply does more, with features like interfaces (which "sort of" exist in Flow), and public/private accessors.
One distinct advantage of Flow is that it is not a build step, but is more like a linter. I like this - it doesn't re-invent the wheel, so you don't have to choose between having the latest features or being fully TS-compatible. On the other hand, Flow's typechecking is far less complete, and it still uses its own home-rolled parser which occasionally has issues parsing certain ES2016+ features, such as decorators.
If I were starting a project from scratch, I would likely use TS as it's simply more complete. But if I were migrating an existing project, Flow starts paying off right away and is easy to integrate.
> Typed vs dynamic is a rather controversial topic, so I’m not trying to spark that discussion all over again.
Goes on to explain that typed is betterer...
The article doesn't really offer up any real arguments as to why you should specifically use TypeScript, but really just says typed is nice and everyone lints anyway (not true) so the step up to a type system really isn't that big of a deal (also not true.)
Not really sure what point the author is trying to make.
This article is targeted at authors and maintainers of high-adoption libraries. It says so right in the second paragraph.
And, frankly (speaking as someone with experience on this topic), he's right. Maybe static isn't always the answer, but in the context of high-adoption libraries, a little bit of effort to improve clarity and strictness is a huge lever for cutting down on wasted time of thousands of developers everywhere.
> The article doesn't really offer up any real arguments as to why you should specifically use TypeScript
Did you read it? He offers the Git/Mercurial comparison of TypeScript's growing popularity.
> some type definitions are better than none. It may be quite feasible to build conversions from .d.ts to FlowType type definitions or other languages type definitions, so whatever the Future of Typed JavaScript will be, having .d.ts files today will help us in the future to migrate towards it.
So I read the argument as "Give me at least slightly automatically verifiable api with your library".
A better framing of this is: "Type systems are good. The JS community should sort this out in the next couple of years and will probably a standard approach, but it's worth diving into the assorted tools that exist -- TypeScript, Flow, and any others -- to understand the ecosystem and find pain points."
Javascript libraries should be written in Javascript. Worship the one true God!
And actually even for me.
I do know how to install and use all those. I just don't want to take the afternoon to do so.
Why ?
- Only one project out of 5 are big enough to justify it. - The stack will change in 6 months; - I will need to train anybody who gets on board, and document it, and maintain it. - All this tooling integration is terrible in JS, because they are an agglomerate of stuff we are stacking after the fact to compensate JS bad initial design. The same stack for any other language is 10 times easier to setup and maintain (the stdlib is here for you in Python, you don't need to load a deendancy to generate a uuid), or it's just here out of the box (type hints ? embded in Php) or event completly uneeded (nobody use transpilers in Ruby hence no source maps, etc).
So yes, it's annoying.
npm install typescript -g
This is the only addition on top of vanilla js, which is what you should be comparing with instead of the massive crap of build-tool-of-the-month. All said and done, if you're using those build tools in typescript, you'd be using them for javascript as well.
I understand what you're saying, but it's completely contextual. The title of this article is "All javascript libraries...". Maybe it's just that I'm not a front-end-only developer. I have no clue about the development process for exclusively front end libraries, but I don't see many people develop them without node/npm. Hell, JQuery has a package.json, and:
"In order to build jQuery, you need to have the latest Node.js/npm and git 1.7 or later"
(I haven't tried it myself yet, but I just got back from VS Live in Vegas where the ease of package management in VS 2015 was brought up in several sessions.)
Check it out here: http://webtooling.visualstudio.com/package-managers/npm/
It's as though crazy javascript tooling is so deep into the bones of javascript developers that they can't even tell when they're using a tool. I expect you were genuinely sincere in your suggestion.
Regardless, the only thing I mentioned was npm. I don't consider node/npm to be "crazy javascript tooling". So yes, I was genuinely sincere.
"In order to build jQuery, you need to have the latest Node.js/npm and git 1.7 or later. Earlier versions might work, but are not supported."
Welcome to [1]2011, where the most prevalent front-end codebase requires node and it's package manager to contribute. Feel free to peruse the countless other commonly used libraries. Maybe you can point out a widely used front-end codebase that doesn't use node/npm/git? The only one I could find was BabylonJS, which uses bower. Conveniently to my point, bower is dependent on node/npm/git.
Writing code in a text editor and saving it with the extension .js makes for a javascript file. We know that. Using that file in the browser means using some a <script> tag. Whether its from the server or through a cdn, that script tag contents/url will still have to be in javascript, even if you used typescript to develop it. No negative impact on text-editor user-land.
[1] https://github.com/jquery/jquery/commit/d503845d0cf45632c0d7...
I haven't come across any .js library that doesn't offer the same.
I'm not encouraging everyone to adopt it. I just struggle to see any objectionable aspect from anyone that is solely on the consumer side. Basically, if you aren't using any tooling, the world will keep on spinning.
First you need to install node.
Then you need to install typescript.
Then you need to setup something that watch the typescript files and transpile them when they change. Because no, running a command everytime you change a letter in the file is not acceptable.
Then you need to integrate that in your static assets pipeline (minifiers, linters, git hooks, i18n extraction, whatever). Because files changes and are generated on the fly, and you probably use a framework that already interact with them in some way.
Then you need to make sure it's part of your deployment process, including continuous integration. Because the typescript command now must be in your builder scripts, travis files, docker container, etc.
Then you need to setup your browser to read the source map. Because debugging a transpiler without a source map is hell on earth.
Then you need to setup your IDE to understand typescript. Yeah, most editors don't understand type script.
Then you need to document that, and train yours colleagues. They don't have the same OS, versions, editors, experience than each others.
What's that, you spend 2 hours trying to help a new commer in your team on skype to find out you just don't have the same version of type script ? What's that you have a concurrency problem between several FS watchers ? What's that, somebody commited the transpiled files on the git repo by mistake and now some edge case made the travis build fail ?
Saying "it's just npm install" is disrespectful, at best. It's NOT a 5 minutes job. It is work.
The article doesn't really apply to you if you aren't using node. If you're only using a script tag, it will have to be consumed as javascript anyway. Any library that is written in typescript will have a transpiled javascript version available to you, or there would be no point in writing it in typescript.
> Then you need to install typescript
See above
> [more irrelevant complaints]
See above.
> Then you need to setup your IDE to understand typescript. Yeah, most editors don't understand type script.
PHEW. This may have been my most difficult google search of the week: http://lmgtfy.com/?q=typescript+editor+support&l=1
> Then you need to document that, and train yours colleagues. They don't have the same OS, versions, editors, experience than each others
If you're have issues surrounding this, typescript should be the least of your worries.
> What's that, you spend 2 hours trying to help a new commer in your team on skype to find out you just don't have the same version of type script ?
Heaven forbid you have an onboarding process that is documented and methodical. My entire team runs the same version of node. We keep track of issues surrounding operating systems and IDEs so we have reference material when others bump into similar issues. If you're not doing this, there's no way in hell I'd want to use anything you're producing.
The article and commentary is about PUBLISHING libraries, not consuming them, and it's not about eliminating javascript from private repositories. If you're publishing an open-source library and aren't using node nowadays, color me impressed, given that most of the major testing frameworks are built around node. Even jQuery has required node to contribute since 2011 because of that. I have struggled to find a popular front end-only library that doesn't utilize node in it's development process. Those libraries HAVE to include a js file, since that's how the the browser consumes it. So... the world kept on spinning after you made a mountain out of a pebble.
Failing to read/understand the article, and subsequently huff and puffing a list of irrelevant objections is disrespectful, at best. Clearly nothing here applies to you, and you've managed to take that as an opportunity to point out how inept your team is. Congrats.
You think that most people publishing lib are unit testing them ? JS is the language with the least unit tested code I know. You think people writting JS use node ? Man, you need to quit working for L.A. start up, there is an entire world out there that is learning about stuff as basic as AJAX calls and making libs anyway because they have knowledge about their job they want/need to share.
I work with american clients right now. Well, they are working on an open source code base they got from Africa. The code is not remotly close to your fancy standards.
I worked with people working in the geography field 2 weeks ago.They learned Angular JS. Choosing between the minified and the non minified file was the struggle here. No, they didn't have Node installed. They don't even know what it it. Yes, they will produce JS libs, they have knowledge only they got, and they will share it.
I worked with a friend in porn 3 month ago. He is still using jQuery and manual JS files. Because it works, because it's simple. He is never going to use type script, he doesn't even have the time to read about it. People reading HN are an exception, a microcosme. Yes, he published a lib to generate visual hashes for passwords.
"Everybody should be using typescript, it's so simple" clearly ignore completly the heterogeneous world we work in.
It's pretentious. It's condescendant.
Congrats.
This isn't an excuse to be disorganized or fail to do a proper onboarding. You're justifying incompetence.
> You have been spoiled with your team members...
I've never worked with shitty people. Either I'm the luckiest idiot in the world, or I actually take the time to do research before accepting job offers. I'm leaning towards the latter.
> You think that most people publishing lib are unit testing them ?
One's that people use? Yes. If you aren't unit testing published libraries, you're doing nothing else but shitting in a bucket and tossing it on the street. If you're using those packages without validating them, you're the one licking that street. If you have a wall of script tags of random libraries used to do each piece of your application, it's nothing better than copy and pasting from stack overflow. All you're doing is stacking wood for an eventual bonfire. I just took a minute to look at the libraries we use. All but one has tests. Funny enough, we aren't actually using it. Thanks for helping me clean up my scripts. So... I guess my life tip is to pick better libraries.
> JS is the language with the least unit tested code I know.
It's also the most tested one I know. Oddly enough, it's the most used language in the world. Weird how numbers work.
> You think people writting JS use node ? Man, you need to quit working for L.A. start up
Yep. I actually work in NY. Maybe there's a serious difference between the two cities. From what I see, companies that last more than 3 months tend to have even the most basic of organizational skills. Companies that don't last 3 months typically don't publish packages. But hey, to each their own.
> They don't even know what it it.
I'd love a list of the companies you've worked for so I can avoid anything they've built. As you've said, ignoring the ecosystem we work in is ignorant.
> Yes, he published a lib to generate visual hashes for passwords.
so... a single function? Wall of script tags, bonfires, failing application, debugging hell, over-dependence, etc. As a freelancer, I have a tip for you that might save you some time and increase your income. Spend less time googling for packages and spend 10 minutes building them.
> "Everybody should be using typescript, it's so simple"
I'm not arguing for the first part. I'm arguing for the second part. Simply put, if a person publishing a package doesn't understand the whole javascript ecosystem (node included), I have no interest in consuming their product. Maybe it's just me, but I don't enjoy spending time debugging a package that I have no control over. If it's internal, I can yell across the room to the person who built it (and marked it with their contact info. You built it, you own it). If it's external, I expect to be able to run their tests (hence why we all have node) so I can easily find a point to debug from, and submit an issue if it's truly an issue from them vs. me. If it's me using their api wrong, that's the perfect example as to WHY you should use typescript. It's self-documenting, so I would be able to see the issue quickly without running their tests. Again, as a freelancer, I'd expect you to want to save time.
> Only one project out of 5 are big enough to justify it.
No, any library author could benefit (strong set of features, added type safety, additional usability for TS users from proper .d.ts files). Key point here, TFA is about libraries not projects.
>The stack will change in 6 months;
TypeScript has been around longer than 6 months and has only gained traction.
> I will need to train anybody who gets on board, and document it, and maintain it.
Learning TypeScript takes a day at most. And if you really need to justify that lost time, just remember that outside of types, everything else is just ES6/ES7 features.
Document it? Ever heard of self-documenting code?
Maintain it? It sounds like you really don't know what TypeScript is about.
[0] https://github.com/Microsoft/TypeScriptSamples/blob/master/t...
You get all of this with Typescript, as well as optional types. If you're writing any Javascript at all, technically you're already writing Typescript.
http://stackoverflow.com/questions/29738381/how-to-publish-a...
There are enhancements to the type system on the roadmap, for example support for non-nullable and variadic types: https://github.com/Microsoft/TypeScript/wiki/Roadmap
Typescript may not be perfect but I'm glad to see it getting more attention as I think it can bring a significant quality improvement to a code base for a fairly small investment of effort.
So rather unlikely?
Haskell has a JavaScript compiler as well, by the way (GHCJS).
He means it already exists and hasn't overtaken TypeScript's popularity.
I've gotta say that one of my main fears with TypeScript is the potential proliferation of code written in heavy OO-style where everything is a Factory or Service or Interface or Impl. And that scares the hell out of me.
I know that TypeScript does not mandate code be written that way. Neither does Java. But TypeScript makes it easier for the Java devs to carry over their heavy-OO habits rather than learning a lighter way of writing code, and that's my worry with it.
If people hate TypeScript like they hate Java, then it's probably going to become the standard.
The alternative to that of course is Babel. Which is standard JavaScript, mostly. Including the draft stuff that isn't ratified yet. But you don't have to use any of that if you don't want. And things like Flow and JSX, which are just plugins so again, you can take them or leave them.
The authors argument eventually distills down to a choice between TypeScript and Flow. He concludes that TS is the best choice because it has the momentum, but that's a false choice. The choice is between Microsoft's TypeScript transpiler and Babel.
If you use Babel you can choose to use Flow, but if you use TypeScript you lose out on everything else Babel has to offer.
And outside of the .Net+Angular world, Babel has all the momentum.
With Typescript, you can't do this, because the code has to pass through the Typescript compiler first, which doesn't support (most of) these features (e.g. it does support decorators IIRC) so will throw an error when it finds an unfamiliar language construct, and it doesn't have a plugin architecture like Babel, so you can't add them in that way.
One example is the spread/rest syntax which is sometimes used in React projects isn't fully supported in TS: https://github.com/Microsoft/TypeScript/issues/2103.
I should point out you can use Babel and Typescript, so the Babel processes the output from tsc (needed for using e.g. async/await at present, as tsc can't compile these down to ES5), but tsc has to run first to make the code into valid JS (on this note, I was surprised how easy it was to remove TS from a project - Babel will ignore most of the TS specific stuff such as interface and type declarations, as it already strips them out for Flow compatibility and the syntax is largely the same)
The most obvious Babel plugins are JSX and Flow. If your library is using TypeScript then it cannot go through the same build process* as any downstream project that is using any Babel plugin. That means you need to publish your library as ES5 and the client loses most the advantages of your library being in TypeScript in the first place.
Also, Babel appears to be doing a slightly better job of keeping up with the draft ES standards, so if you want to use cutting-edge JS features (like async/await) that are on the standards track, you may need to wait a bit longer for TS adoption to get there.
I also think it's unlikely TypeScript is going to win out in the long run, so if you commit to TS now you're probably going to be rewriting in a few years. It's better to stick to standard JS where possible. The history of ES4 strongly suggests that TS is never going to become an ECMA standard.
* You can, at least in theory, do a two-stage transpile that goes through both Babel and TS, but IMO, nothing good is likely to come from such a setup.
[1] A hand-maintained definitions file: https://github.com/facebook/immutable-js/blob/master/type-de... . Sure, it's nice as documentation, but that is a lot of redundant effort if you already have separate documentation, and types and documentation in the original source code too. [2] https://github.com/AgentME/contain-by-screen is one simple example.
I haven't tried Babel, though. It easily could be a better path forward. Does it have some equivalent of the typescript type descriptor files?
Types often end up a part of the documentation, and internal typing is often needed in libraries to keep track of model state, so having it at the foundational level in the library itself adds tremendous benefit.
The biggest problems in any modern, large-scale JavaScript project are the build process and dependency management. If you are publishing a TypeScript library then it can be consumed either natively as TypeScript, or as ES5.
If it is being consumed as ES5 then your consumers lose most of the benefits of it being in TS. For them to consume it as native TS puts a fairly hefty constraint on their build process, namely that it must go through the TypeScript compiler.
That doesn't negate the internal benefits to your library, but Flow is another option that is a better fit if you are mostly interested in going with the prevailing wind. After all, that was the author's central argument as to why you should choose TS over Flow, and IMO it is quite wrong.
For a library maintainer, a maintainer can just release an ES5 version of the library when publishing via npm - the user then gets the benefit of choosing between TS or ES5. It can also simultaneously be released as ES6 if desired.
I should mention that it doesn't make sense for pre-existing libraries to migrate to TS (or anything) if it is already in JS and is a largely used library without a specific end goal that is to be achieved - the article is wrong about that, open source doesn't have infinite resources unfortunately.
Unless you're making changes to a TS library, there should be no need to build it and you can just use existing the built js files from the library.
I'm positively surprised when I come across a JavaScript API whose documentation actually specifies this very basic information.
Coming from the static typing world, it's astounding...
Documentation in the web development world is usually very good with the introduction, getting you excited; but terrible when it comes to reference, the day-to-day type docs.
I agree with the author: types are there anyway, typescript seems to work well enough and has traction now, so please, if you write a library: add those type annotations bottom-up in the library and let typescript generate a nice .d.ts declaration file and standardized module stub around that final javascript library.
Most of the time, the change is just to rename the file to `.ts`. Sometimes you have to change things because (surprise!) there was a bug.
The biggest painpoint is that you usually have to go pick up some type definition files from DefinitelyTyped for third party libs, but it's well worth it. Second biggest painpoint is type signatures (depending on the context, writing out types/definitions can be subtly different... or maybe I'm doing something wrong).
To anyone who's considering moving their JS stuff to Typescript but have hit some issues, please feel free to ask me. I really think it's a plus for sanity when writing JS.
I used Typescript during the initial days while developing Angular 1 apps. Things might have improved now, but transpiling to JS was slow then and had non standard module system. It may make sense to use it for Angular apps as Angular 2 and related projects are written in it. but, for me, it always felt as another language farther away from JS.
Once started using Babel + Webpack, I couldn't think about leaving the flexibility and standard compliance to Typescript (mostly react apps). Also, gave Nuclide and Flowtype a second chance this week, and they dramatically improved. As a drawback, there are tons of open issues on Flow tracker and seems more investment needed.
Also its strictness about nulls has saved me so many times and has forced me to make better APIs that carefully consider or prohibit them, instead of treating null as a boogeyman that I don't think about until it inevitably bites me.
> There is a culture in the JavaScript community that “types don’t matter”
I don't think that's the case, particularly among seasoned developers: we do care about types and interfaces, but we just don't think writing them down in code is as big a deal as Typescript claims it to be.
> We are already linting because we believe it makes better code.
Linting doesn't require you to write non-javascript, it just works (after configurations). It doesn't force you to write code in any particular ways (see ESLint for example). That's why we find it more acceptable.
> Types are stronger. Types matter.
TS isn't automatically stronger, since TS is a superset of JS, developers can still omit the types. So you either write in proper TS-style and get its benefits, or don't.
And referring to earlier points:
> The types are there. Instead of leaving them implicit, you can just make them explicit.
IMO: there are many ways to setup this contract. And I question the % of type-related issues within a library when you have 100% test coverage and proper linting already.
> Often in JS libraries, the types are vaguely defined as an afterthought when writing docs.
TS can't force you to write strong types, just as JS can't force you to write good doc. You need a stronger will, not a better nag.
My case for writing your next popular library in vanilla JS: your users will already know how to contribute. And you get to choose how to enforce good variable types.
For TS vs JS details, see http://stackoverflow.com/questions/12694530/what-is-typescri...
Disclaimer: my libraries are nowhere as popular as angularjs or immutablejs, but I do intend to maintain them to a degree that may serve thousands of developers.
(Plus the author uses one of my library so I guess they are not that bad)
While type errors are a small part of problems in software reliability, we should take everything we can get. At least in things thousands of millions of users are going to rely on.
I'd say in this situation the title is justified.
All software that handles sensitive data should use transport encryption & encryption at rest
All software that uses encryption should use thoroughly vetted professional crypto
All computer users should use backup software
TypeScript doesn't solve the problem at all. It merely adds another layer of complexity/knowledge to a Library that still compiles to JavaScript. Write it in JavaScript, deliver it in JavaScript. If your documentation and implicit typesetting is giving you pains, then you should revisit what you have written and how you've built your library. Not switch to something that tries to enforce better behaviour.
What's nice is how much types can be inferred from just a handle of type annotations. My editor can start pointing out potential bugs at the cost of relatively little effort on my part, and that's a good place to be.
Changing my entire code to TypeScript just feels a bit over the top to achieve only static type checking. I now only dynamically check if needed. I believe there are so much worse and important problems we are dealing with as Javascript developers today that need attention.
I really believe WASM will become the base for a great new language that eventually will make Javascript, TypeScript and so many others deprecated, solving a zillion problems at once.
Flow allows you to add Types by following Progressive Enhancement [1].
All libraries should support Functional APIs.
* a single, definitive method for creating namespaces without using a framework or library
* a single, definitive method for defining classes and using inheritance without using a framework or library
* a single, definitive method of allowing async functions to modify the state of an object without having to declare that object in the global scope, without using a framework or library
If these problems are already solved, please let me know!
I'm playing a bit of a devil's advocate here ;)
I'm not sure I understand #3. Closures?
If you're writing an API to be consumed in language X then you need to write the API itself in language X. This will help you capture and handle edge cases, language idiosyncrasies and other similar issues the way you want.
Using a different language that gets transpiled into a target language also increases your surface area for bugs because now you have to worry about typescript and JavaScript bugs. After using CoffeeScript a few years back and spending HOURS debugging issues in its transpiling to JavaScript I decided it just wasn't worth the hassle. Besides JavaScript, while not perfect, is pretty damn good.
I love the idea of type script but transpiling it down into a language that isn't as type strict just seems silly to me. Now when it can be compiled to WebAssembly? Count me in.
But besides, judging a language based on available tooling is akin to judging a CPU based on the computer casing looks.
For a real programmer, GNU Nano with appropriate highlighting should be enough. If a language calls itself "high-level" but makes the coding process hard without tooling, it deserves no attention at all.
I mean, one of his main points is that everything written in JS should be written in typescript because it helps support typescript users. Another it is leads to better documentation, with no qualification of how that happens. It might make your intent more explicit to a reader of the source code, but that doesn't magically translate into documentation for an API user.
I personally find nothing good about trying to coercing a language into something it isn't and then transpilling it back and that article has no strong argument to make me feel any different.
I agree, that wasn't a good point.
> Another it is leads to better documentation, with no qualification of how that happens
The type annotations make the source self documenting in a way that doesn't go out of sync. There's also http://typedoc.io/
Do you also advocate against writing ES6 and using Babel?
Considering the output is a JavaScript library people will be using it in that context more than with TypeScript and many of the others. So I don't have a specific real-world unit test example but in general your unit tests have to test the various ways people are going to use your API from the target language. So you'll need to make sure it behaves in the expected ways with valid and invalid input.
At the very least I'd expect unit tests to be written in JavaScript to hit a TypeScript library to help eliminate any weirdness that could have been missed.
> Do you also advocate against writing ES6 and using Babel?
Yup. ECMAScript 6 is great but the support is still not entirely there (especially in older browsers) and many of the transpilings are not quite equivalent. Granted Babel is pretty high quality (minus their whole decided not to ship any transpilers in the default package anymore) and I would expect it to be close enough. But after being bit by CoffeeScript so many years ago I'd rather not deal with transpilers and use the real thing when I can.
Coding in ECMAScript 5 is guaranteed compatible with ECMAScript 6, most web browsers and most versions of node. So I look at it like this: why add the extra complexity just for a few extra, nice, syntax improvements?
You're also waiting for the "magical" WebAssembly target that makes everything better, but instead WebAssembly would end up generating much more unreadable code that runs much slower for JavaScript which already benefits from highly optimized JS VM's in Browsers. It would also much larger in size as it would require embedding its own GC and be littered with numerous type-checks in order to support a highly dynamic language like JavaScript.
Correct. I wasn't asked for anything deep here and I already told everyone I haven't seriously used it...
> yet you're already strongly against it and your biases suggest there are obscure transpiling bugs when I've yet to see any in practice.
I'm against any tranpiling languages. I'm glad you've never seen any in practice. I have with CoffeeScript and it cost me a huge amount of time. But like I've mentioned in multiple threads here I understand that's an extremely rare edge case at this point in time.
That's not the only reason I've cited though. Transpiling adds in an extra level of complexity. I hate complexity. In order to test changes you have to transpile the code after your changes before you can test them. Yeah you can automate it but now I'm adding extra packages to my application only so I can run slightly different code than before.
No thanks. I like simplification. As simple as I can make something the better.
> Had you used it for any length of time you would've noticed it catches several bugs which you otherwise wouldn't discover until runtime.
Maybe? Since I've been using dynamic languages without runtime checking for over a decade I'd like to imagine I'm pretty good at finding most of these issues ahead of time. Still, it gets compiled into a less strict language so it's not a silver bullet by any means.
> You're also waiting for the "magical" WebAssembly target that makes everything better, but instead WebAssembly would end up generating much more unreadable code that runs much slower for JavaScript which already benefits from highly optimized JS VM's in Browsers.
I'm curious, why would you think it would run slower. According to the V8 team its start-up is faster and it uses the same engine so the speeds so be equivalent.
Regardless the code being "unreadable" for WebAssembly doesn't matter. Do you care that bytecode is "unreadable" or MSIL? I highly doubt you do. Same thing here. WebAssembly is going to exist inside and outside of web browsers. But we're also a long way off.
> It would also much larger in size as it would require embedding its own GC and be littered with numerous type-checks in order to support a highly dynamic language like JavaScript.
Wait, why? The V8's team's announcement said they still have to implement GC, etc for the DOM but that stuff would exist in the WebAssembly implementation itself and has nothing to do with your code.
WebAssembly is still a ways off but I'm excited at the possibilities.
Because every browser already has an integrated highly-tuned JS VM containing several years of advanced compiler research, including JIT's with runtime type profiling, type inference, type-specialized code generation that's highly optimized around JavaScript semantics in order to get today's JavaScript performance. That doesn't exist in WebAssembly which is a low-level statically-typed language that's effectively a compact binary form of asm.js for non-GC statically typed languages like C/C++.
> WebAssembly is still a ways off but I'm excited at the possibilities.
There is for C/C++ but none for running JavaScript which is worse in every way. WebAssembly is thrown around as some intangible moniker that will magically make everything better without understanding what it is and what it would take to implement a dynamic language with it, esp. JS which already has access to the best VM's the world's best compiler engineers can create.
Making APIs so that they are only accessible from a single language should be outlawed.
> when it can be compiled into WebAssembly then count me in I'll certainly give it another shot. But until then I just don't want to deal with an, albiet probably rare but possible, transpiling bug
You really think a TS->WebAssembly compiler is less likely to have bugs than a TS->JS transpiler (which essentially just strips out the type annotations)? Yeah, no.
> It lets me dogfood more effectively and write better, real world unit tests.
I have no idea how these things are relevant. Why would adding type annotations to your code affect your ability to write unit tests. What does dogfooding have to do with anything?
Absolutely. Why wouldn't it? Converting to a very explicit byte code type environment versus a language meant to be used by humans?
> I have no idea how these things are relevant. Why would adding type annotations to your code affect your ability to write unit tests. What does dogfooding have to do with anything?
The context of the discussion was around creating libraries for everyone to consume. If you're not testing your code as if it's being run from just JavaScript then you have a blindspot.
TypeScript is not only annotations. Check out the code it generates to support those annotations.
Whereas TypeScript/Babel/etc perform relatively simple source code transformations, you'd have to implement an entire JavaScript engine in WebAssembly. It would almost certainly be slower and buggier than all of the big 4 JS engines.
> Check out the code it generates to support those annotations.
Ok, let's do that:
http://www.typescriptlang.org/Playground#src=interface%20Per...
But TypeScript is basically "Javascript + types + ES6". They call it an "erasing compiler" because it's not meant to do much but remove types/make ES6 code work with ES5.
There is one gotcha in name resolution when you're working in modules (if you are in a module a.b, and a.c exists, then c will automatically refer to a.c, even if a global c exists). But that usually gets caught by the type system. Lot less issues than coffeescript IMO
For example - currently in Typescript but only planned for ES7: https://github.com/jeffmo/es-class-fields-and-static-propert...
or Support ES7: exponentiation operator https://github.com/Microsoft/TypeScript/issues/4812
Typescript seems to be more like ECMAScript.next + types rather than ES6 + types.
MSIL and Java bytecode are not that readable but I mentally lump WebAssembly in the same group (though I know it isn't quite that). I feel like the end goal will be closer aligned to byte code than JavaScript.
WebAssembly is primarily useful from a performance standpoint.
Don't want types? Fine don't use them, and you have JavaScript code again.
It's the best thing that has happened to web development in recent years - it improves Javascript in a completely compatible and future proof way.
The most amazing thing is that Microsoft created it. It's the polar opposite of Old Microsoft - standards are being followed (not subverted), it's simple pragmatic and has no lock-in.
TS does not add any semantic features, it only adds type annotations. Which it checks at compile time, and then removes. That's it.
Want to switch away from TS? Compile all your .ts files, save the .js, check that into your repo and continue from there.
(As other commenters sort-of pointed out: you will need to keep Babel in your pipeline.)
Yes. ∀ x: I can do x in JS → I can do x in TS
But, let's assume for a second that you couldn't: this thread is about TS being future-proof. I.e.: ∃ x: I can do x in TS & I cannot do x in JS? No, false.
This implies TS = JS. And that's the point: semantically, TS = JS.
https://github.com/sebastian-lenz/typedoc/blob/master/src/li...
Your code will keep working, but it may diverge a bit from standard JS; however everything will keep working, and I'm sure the expectation would be to move over the es6's syntax unless there were semantic reasons not to.
The Typescript authors are involved in the ECMAScript process, so I'm pretty sure that there won't be any surprising huge rifts at least.
Also, there a few constructs in TypeScript that generate JavaScript code, like enum and module.
THAT SAID, TypeScript is basically ES6 + type annotations, and can certainly be used as such.
In this case, I'm hoping TS will just make the breaking change and go back to being pure, standard ES plus optional type annotations. Developers who use it would just accept that from time to time, this could happen, but it could probably be made a non-issue if MS just wrote another transpiler: oldTS -> newTS, for people whose choice of Typescript meant they had committed from the start to a system that would ALWAYS require transpiling.
This unfortunately makes languages like Elm and Clojurescript unlikely to be chosen in a lot of situations (e.g. as I understand it, the JS interop story with Elm isn't amazing, so you can't just use JS libraries with it).
Typescript is close enough to plain Javascript to not scare people off (I'd be willing to bet any JS developer could pick it up in a few hours) and can almost be considered in the same light as vanilla JS in such a decision, yet brings with it the advantages of a fairly decent type system.
As I've said elsewhere, it's definitely not perfect, but for developers in a position where other, more "esoteric" compile-to-JS languages aren't likely to be accepted, Typescript probably represents the best choice of bringing a decent amount of sanity and predictability to codebases.
(This isn't meant to be having a go at the parent BTW, it's just something I've been thinking about a bit and the comment jogged my memory!)
Details about our experience with Elm in production: https://www.youtube.com/watch?v=R2FtMbb-nLs
I recommend you try again and file a bug or look for help in irc if something breaks again (although I've never seen pulp init throw an error).
We can do this all day ;)
Not that I'm agreeing with the post in question, but ClojureScript and TypeScript are very different beasts.
But for me JS -> TS feels like C -> C++ evolution/Transition. For most of Unix utillies or even as complex as Linux Kernel, Apache, Nginx, C is good enough. In the hands of developers who master it, there are no C++ equivalent.
For after look at the v8's C++ code, I can't imagine anyone would write that with C.
But when a new language's ego system is not mature enough, the development work flow can be a nightmare. I remember trying to use GWT to compile Java into JS. The demo works and looks cool. But more often or not, I end up debug "The JAVA code" AND "The machine generated Javascript" AND "how that JS interact with different browsers" for something that is extremely trivial to do with one line of JS/JQuery code.
* Writing code is easy. * Debugging code is harder. * Make sure that code works on all the browsers are much harder.
* Debugging system with multiple languages (JS, TS, React, Angular, polymer, etc) + machine generated code is not easy.
* Integrated them all together to fixed all issues and make sure the final program will work on all browsers are > N^2, N^3, N^4 times harder?
I am old enough to admit, that is not a job for me. :-)
You're never debugging TypeScript separately from JavaScript.
declare var _: {
each<T, U>(arr: T[], f: (elem: T) => U): U[];
delay(f: Function, wait: number, ...arguments: any[]): number;
template(template: string): (model: any) => string;
bindAll(object: any, ...methodNames: string[]): void;
};
declare var Store: any;
I have no clue on what the JS generated by it looks like.
If I have to ask some JS programmer with no TS experience to integrate this "ts library" into their app and make sure the integrated app works on all browsers. I would have no clue on the complexity of the task just as I have no clue on how complex it was to make the GWT generated JS app to work on all browsers.
If it is just a JQuery / JS app, I can have 80-90% confident on schedule and quality of the app delivery.
But that's me, like I said, I am too old... :-)
However, Though I wish it were, Typescript is NOT currently suitable for defining modules for external consumption. The problem comes down to no effective means of publishing the typings of your project and your project's dependencies. For example, if your project uses Promises, you might choose to include a definition of those promises, or (worse) reference a Promise typing you found on DefinitelyTyped. This will work fine for you, the publisher. But any consumer of your project will be rudely greeted with typing collisions: Things like "The interface 'Promise' already exists in es6.d.ts"
There needs to be a solution to this module publishing problem before people can seriously publish modules (using NPM) using Typescript. Unfortunately, I have been tracking this issue and there is no timeline for resolving it, mostly due to too many different module systems, and handling module publishing being outside the design-scope of Typescript.
[1] https://github.com/typings/typings/blob/master/docs/registry...
npm init && typings init
npm install debug ms --save
typings install debug ms --save
debug is dependent on ms, so in node_modules you have:
|-ms
|-debug
| |-ms
typings/main/definitions will have
|-debug
| |-index.d.ts
|-ms
| |-index.d.ts
It makes up for this file structure by declaring modules named in a file-like structure so the entire dependency tree is self contained in one file, while only exposing it's own typings through the final export declarations "debug" and "ms". No stepping on toes. Best to see for yourself, it would take a bit to write down.
As a point of info, it only works when people start adding versioning to the typings registry itself. debug and ms are both versioned in the registry, which is the only reason their dependencies are correctly managed. DefinitelyTyped ambient declarations will still break things. Until those are gone and everything is versioned, you'll still need some hacking depending on your dependencies. That being said, I've seen the issues start to fade rather quickly given the short time period I've been using it.
For someone to use your library, they will have to download bluebird.d.ts manually and include it. if you (the lib dev) include it yourself, then any other definition of Promise (including if the user has their own bluebird.d.ts definition included) will cause typing collisions.
As someone mentioned, the Typings project might solve this, but there isn't very good communication on this project and the problems it's supposed to solve.
Typescript is a whole different beast and I think the article makes great points for libraries. The more types the better.
But if TypeScript is an abstraction of Javascript that adds type security, then I'm pretty much all for it, even having been burned pretty often by unnecessary abstraction. I would say that the lion's share of my own javascript bugs spring from type uncertainty.
Do you have an example of how writing something without types is supposed to help you capture edge cases? What are the idiosyncrasies of Javascript that can easily be caught in Javascript but NOT in Typescript?
WebAssembly adds massive layers of complexity that Typescript doesn't. You argue going from Typescript to Javascript is bad because, but Typescript to WebAssembly is good. One of this is vastly more complex and complicated, and it isn't TS to JS.
What TypeScript does is remove the ambiguity of API development for front-end work. Considering I've worked in some big enterprise wide JS projects, TypeScript answers the question "Wtf is this returning?" which lessens my debugging time because I know exactly the type of the object being returned.
Your arguments are actually kind of moot. When you write in Java, you're really just boiling it down to an intermediary language. Should you write it in IL? Why not C/C++? Why not assembly? Shoot, just handout punch cards again and let's get to working. Abstraction isn't the enemy here, it's the value of the abstraction that gives value to it. TypeScript isn't so much an abstraction as a superset but it's static typing alone is worth 1000x over.
Personally I saw over a million dollars lost and an entire team laid off after a piece of code started working with a value that was expected to be a number but wasn't.
Depends. You could debate the same philosophy wrt C and null pointers. Should you check all your arguments to see if they're null, if the documentation/specification says they should never be null, or accept undefined behaviour and segfault?
In practice, most code assumes everything is checked, sanitized and used correctly at the outer most API boundary.
So, I guess I have not yet felt the pain that "requires" a language upgrade. Unlike Java, which has really gotten to chafe me.
But then again, I started work back in 1985 using a scripted language (dBASE), with its own version of "eval", to make cute little UIs and reports that tied into the "real computer" / software (even if data swapping was swapping nightly batches of ISAM tuples, rather than REST calls). I also enjoyed using Perl in the 90s / early 2000s.
Then as now, the Serious People want you to wallow with them in the bondage and discipline of a Real Language, so you can type until your fingers bleed :-)
That said, I do write a lot of "JSDoc" in my code, and I resent the people who refuse to write Javadoc in their Java, because of course the types all make it crystal clear - NOT!
I have to agree with the OP's point if your writing a library you should write it in the base language (common denominator). I work on JVM stuff and nothing is more annoying then dealing with a very nice library written in Scala, Clojure or Groovy and have it not work in plain Java. Plain Java on the other hand works fine in Scala,Clojure, and Groovy.
The above JVM languages compile to byte code (which I guess would be analogous to WebAssembly).
Thus I'm not sure if transpiling is as bad since Xtend (which is more analogous since its a Java transpiler) is very interoperable AND does not compile to bytecode directly.
So WebAssembly might end up being just as bad as the plethora of JVM languages that are sort of interoperable.
I don't think the backers of Scala and Clojure make the claim that libraries written in their language will work seamlessly in Java, only that libraries written in Java will work in their language. The marketers of Apache Groovy, otoh, do claim code written in it will work in Java but from what you say that claim is false.
The issue is that there are things you can do in JVM bytecode that you just can't do in Java and as the JVM develops along with these languages I imagine further interoperability.
You are right about the languages not making promises but there are plenty of library writers who disregard this. A fine example would be Akka and Finagle. Those libraries could have been written in Java thus minimizing dependencies and maybe even overall code size since they have to have a wrapper for Java anyway (typesafe did choose Java for typesafe config). But then again maybe Scala/Clojure buys enough that the wrappers are trivial. I'm just not sure how trivial interoperable wrappers for WebAssembly will be as I imagine WebAssembly will be a superset of what Javascript can do (or maybe not?).
So I completely abandoned my typing adventure.
I read lets discard the benefits of writing javascript as javascript in favor of something else because of a few people refuse to learn javascript. If you don't want to learn the language of the web then maybe just maybe it's not for you.
I think people coming to javascript from statically typed languages need to stop trying to fight javascript or trying to force paradigms on javascript that don't need to exist/never meant to happen and instead embrace javascript as it is and with an open mind.
I shudder to think of the countless man-hours that have been wasted working around and debugging issues caused by stupid design decisions in the Javascript language.
Seems ironic that JS community is starting to come around to that finally.
https://developers.google.com/closure/compiler/docs/js-for-c...
This is not about where you start from (totally free, their own time, can do anything) nor about whether they can be forced to do X or Y.
It's about what kind of community and software they (we) want to build, and what would be the best practices and suggestions.
Developers aren't forced to package their libs for npm distribution, write comments, ensure they play well with latest browsers, etc. either, but they do -- not because they are forced to, but because they agree that it's a nice thing to do.
FOSS developers do all sorts of stuff to make their software better for users already -- writing documentation, packaging for various platforms, evangelizing it, conforming to certain standards even when they don't personally use them or care for them etc.
Software development, especially community OSS is not about proving how "individual" one is, and doing everything for fun. It's also about wanting to contribute to a common cause and build some common foundations and best practices for a platform or language etc. Most projects agree to that idea, or at least pay lip service to the idea.
In this case, the TFA is not about forcing anyone to do something they don't want, so your reaction is besides the point. It's about suggesting what the author thinks is the better way for developers to do going forward.
>There is no way anyone should be forced to comply with any standard when they are freely sharing their code.
Force them not, but nudge them towards complying, or convince them to comply, yes, there are TONS of ways. Advocacy for some specific practice, like TFA does, is one.
If I actually want people to use it, I add documentation. And that's what Typescript basically is: rigorous documentation.
There's actually very little real research that has been done that proves or disproves whether static or dynamic typing is better. Anecdotally, I've spent most of my career using statically typed languages. One day I looked up and saw that I had spent most of the day trying to satisfy a compiler rather than having a compiler satisfy me. I've never really looked back. I program almost entirely in dynamic languages these days. Otherwise, I use Java, Swift and Go only when I'm forced to.
I rather hope that is not the case.
I struggle with the issue of type safety because while I really enjoy using Haskell on side projects, I find Ruby a giant mound of non-type safe glue that collects my ideas together into code. I use Ruby a lot.
I imagine that many JavaScript programmers like the lightness and malleability of their language also.
A typical type problem would be sending a float instead of an integer. Sending a float instead of a regex would not be a typical problem.Static types are necessary in less dynamic languages because they have multiple competing types which can't be distinguished otherwise (eg. all the integer subtypes) and they have structs/classes that cannot be dynamically modified. JS types are simple (number, object, string, etc) and very different in nature. In addition, this kind of error will be caught quite quickly with even the most rudimentary unit tests. Half-way decent docs where modules interact should solve the remaining issues. Running into type errors within the same file or two is probably symptomatic of a lack of composition.
Enter Typescript. It has one major positive in that it prevents some dynamic techniques that can tank performance (though performance graphing and reducing dynamism is probably a better solution). Because you cannot depend on everyone using typescript, all external APIs must STILL have dynamic type checking.
This leaves you with type checking within your own project. Typescript can be turned off anywhere a programmer wants making it unable to guarantee type safety. It adds a lot of extra typing and visual overhead. Unlike C# (where it gets it's type syntax inspiration), the types do nothing for the JIT because the JIT never sees them.
There's no reason for a modern type system to not be based on Hinley-Milner. There's no reason for 95% of typing to be inferred by the computer rather than forcing it to be typed out. There's no reason to use a system that's only good for the assembler when the assembler will never even see it.
In TypedRacket, for example, using types in some (but not all) of your code can result in up to 100x slowdowns, until eventually breaking through into performance gains once most or all code is converted.
[1]: http://blog.acolyer.org/2016/02/05/is-sound-gradual-typing-d...
TypeScript doesn't feel like a boon when you write things with it because avoiding type bugs is further on the list. On the top of the list when you are writing something is figuring out what you actually want to write and what should be the APIs everywhere. TypeScript might make it harder to figure that out because you are getting invested too early in the shape of your interfaces. You'd get just yet another Java lib if you started writing in TypeScript. But once you have the right APIs there's no harm in formalizing them with bit of types.
Web browsers are one of the most popular attack vectors and hence would benefit from an APL-like rigid language profile for web applications. JavaScript is too imprecise and bug prone for anyone to use.
Given that there are Cobol users still out there, it's entirely likely that JS will outlive both of us and maybe even our species :)
Plus JS is one profile away from becoming a very sound language. And it's not like it hasn't moved that way already (strict mode).
As someone who's evaluating Typescript and Flow for a team of JS devs, my intuition is that having some typed code would give you beachheads of type safety, which seems like a reasonable win and an incremental path to improvement. I'm curious if this intuition is incorrect from the perspective of those who have used gradual typing in the real world.
If you're programming in a dynamic language, there are things that you do that would not easily fly in a static language. Things like tests for truthiness. On first blush, from a static background, something like "var p = x && x.y && x.y.z || w;" look terrible, but they're pretty standard ways of cascading through different options without causing null pointer exceptions in a language like JS. When you start introducing type constraints, you are committing yourself to getting rid of all those dynamic shortcuts.
Yes, shortcuts can sometimes get you in trouble, but they can sometimes get you down the road so fast that trouble doesn't have a chance to find you. That's sort of the tradeoff you make: we can be super-fast 90% of the time, at the cost of having difficult to debug problems occasionally.
On the other hand, when you have a requirement to have type constraints in your code, any other code you interact with has to also have type constraints. But in JS, that's not a lot of projects. There is the DefinitelyTyped repository, but it's incomplete and of unknown quality.
I had thought the same thing as you, "beach-heads of type safety". The problem is that dynamic code tends to infect static code. I eventually gave up on TypeScript after not being able to wrangle the combination of a few code generation and graphics tools. My project was already reasonably OO organized and not dynamic, but there was just no easy way to handle the boundaries of the APIs. To deal with it, I had to... start using the dynamic features of JS, giving up on the type safety.
For example, you can't do function overloading in JavaScript, because you don't have any information about types on which to differentiate functions. Well, it turns out that means you also can't do function overloading in TypeScript. The only reason Math.min works in TypeScript is because JS only has one number type, and it is 64-bit IEEE floats.
But some libraries in JS, and especially in DOM, do overload functions. You test the type of parameters at runtime and decide what each positioned parameter actually means. So if you want to use such a library in TypeScript, you need to have a type definition that uses Any for each of the parameters, meaning you've lost type safety and you're back to testing the type of things.
So it just leaves you in this limbo zone where you don't get to use the features of the native language that make up for it being so crappy, nor do you ever get to use the features of the transpiled language that promises to keep your code easy to modify over time. So that's what I mean about "worst of both worlds".
It's like trying to introduce rules on a group of anarchists: you're more likely to get burned at the stake than to make more productive anarchists. Or try letting a bunch of corporate lifers work without a direct boss: you're more likely to end up with a lot more donuts eaten than code written. What ES6 gets right is that it doesn't try to bolt on a type system into an ecosystem that just won't tolerate it. It has features for making it easier, less error-prone, more ergonomic to do things that people are already doing in ES5. In particular, people are already trying to make classical classes with inheritance out of the prototype-based class functions in ES5, so ES6 introduced a new syntax for just that use case that gets rid of all the repetitive and goofy "Object.create" and "MyClass.prototype.myMethod = function(){ blah blah blah blah }" stuff.
So it just leaves you in this limbo zone where you don't get to use the features of the native language that make up for it being so crappy, nor do you ever get to use the features of the transpiled language that promises to keep your code easy to modify over time. So that's what I mean about "worst of both worlds".
You can write quite crazy expressions abusing Boolean operators and he successfully keeps the static type.
You can also have different method overloads signatures as long as you have a more general implementation that does the dynamic checks at run-time manually. Most of the time you can use Union types anyway.
The big collection of definition files for almos any JS library out there is a living proof of how is possible to describe statically almost any JS API.
Let's face it, dynamic languages are about laziness, not about 'unconstraibed creativity'
from what I've tasted of typescript build times
I hold with those who favor javascript
But then I've seen enough of bugs
To think that for frontend dev work typescript
is also great
and would sufficeTypes also add overhead. They can be also superfluous and unnecessary.
Getting your types in a application right and to gain the optimum from them is quite some work.
Over the years, i learned to appreciate more unittests over more types.
I stop find perfect language because there is none.
Not looking forward to not only having to use different build tools for all libraries I work with but also different pre-processors and type analyzers. Oh my.
Nothing all stoping, DIY, in fact encouraged. I agree .ts is great, and who ever desires a lib to be .ts, the only questions is: if you desire it, than make it so.
Let's let humans do the job that computers can do faster and more reliably, like validating the types of variables and function signatures. Let's do everything by hand. Let's give control of our programming future to people that don't care at all about programming.
You obviously have no idea what you're talking about. Almost all statically typed languages get compiled to something much less type-strict. This is one of the reasons for writing compilers in the first place! Case in point: Haskell gets compiled to assembler. You can't get a much bigger difference between typing disciplines than that.
Not everyone is capable of looking past personal attacks like yours. It is the first step to a flame war.
You have something to say? Great. Just say it, no need to talk about how little the other person knows.
Aside from "two wrongs don't make a right," do you really feel that this is comparable?
I love the idea of type script but transpiling it down into a language that isn't as type strict just seems silly to me.
And..
You obviously have no idea what you're talking about.
If you honestly, in your heart of hearts, feel that both statements are ballpark same level of cordiality, then ok.
Just as you say, we're human, which is why "not everyone is capable of looking past personal attacks". Moreover, what we regard as "personal attacks" varies from person to person. Personally, I felt insulted by the specific kind of ignorance displayed by BinaryIdiot in his posts in this thread.
I know I shouldn't have and I don't think the downvotes are undeserved. On the other hand, I obviously have my reasons for feeling that way; judging by the font color of many BinaryIdiot's posts I wasn't the only one.
I read through all the posts in this thread before posting. BinaryIdiot talking about how he experienced "transpiling languages" in the form of CoffeeScript and so he knows everything there is to them... That was excruciating. Him talking about compilation and compilation targets was similarly painful. One of the versions of my first reply to you read: "I've been hurt in enough ways and enough times [by people behaving like that] to develop a little bit of aggressiveness towards them."
In all honesty, the point about how compilers work was just an excuse. I suppose what I really wanted to do was to tell BinaryIdiot how wrong he is about some things, and how irritating it is for me personally (especially today!) to see him talking about programming languages, compilers, and whatnot without first investing any time on research.
Well, it's still wrong and I should have just ignored the whole thread.
This breaks the HN guidelines by calling names and turning an otherwise substantive (indeed, correct) comment into a personal attack. Please don't be nasty here, regardless of what the other person did or how mistaken they are. We detached this subthread from https://news.ycombinator.com/item?id=11297077 and marked it off-topic.
(Edit: I just noticed the discussion downthread— didn't mean to pile on.)
EDIT:
Hey people down voting me; it literally is the same. C++ is a standard, JS is a standard. TypeScript is (like Objective-C) a compatible alternative.
a better (but still imperfect) comparison would be suggesting to rewrite c libs in c++, given the latter's somewhat better type safety.
Title just reinforces my belief that people have this feeling towards strongly typed languages like it's some kind of religious saviour and will try to preach it everywhere
All complex code that uses them should be authored in CoffeeScript.
Nothing more is needed.
P.S. TypeScript is M$ invention -> must burn in hell.