This is brilliant! The first three features, i.e. --allowJs, --reactNamespace, and stateless functional componentshave been precisely the things that I have been missing recently.
This makes integrating 3rd party JS libs much easier and I can streamline my components a little since I'm almost exclusively using stateless components anyway.
That already made me quite happy. But as I'm reading on I almost can't believe all the other great additions, such as module augmentations, string literal types, AMD module concatenation, let/const in loops. It's like they've been reading my mind. These were all things on my wishlist. Great work!
TypeScript is looked upon very highly by everyone at MS and I haven't seen any new projects started with vanilla JS in the last few years. No one needs to encourage anyone to use it. It's just the obvious choice for large projects (and every project at MS is large).
Some other products using it off the top of my head: Azure Machine Learning, Xbox Music, Visual Studio Team Services. EVERYTHING new.
Cool application. It's something I've wanted for a while, and I'd probably use it. But linking it here apropos of almost nothing seems a little like shilling.
Proper TypeScript usage is still pretty rare, so this felt OK.
As a startup founder, if you have a choice between telling people about your startup and not telling: tell. This is incredibly hard for engineers, but you just have do it.
Sometimes I wonder, how many amazing technologies have died because the founders simply couldn't ever figure out how to tell the world about what they built.
Can you elaborate on how you got started on TypeScript? What IDEs and editors are you using? What build process? How did you handle integration with non-TS libraries? Are there any problems you faced that you wouldn't have, had you stuck with JS? (I'd read a blog post about this, by the way)
Visual Studio Code, WebStorm have excellent support for TS built-in. There is also CATS (https://github.com/jbaron/cats) that's targeted towards TypeScript.
For Sublime, Atom, etc. there are a bunch of plugins that you can download:
Check out the DefinitelyTyped (http://definitelytyped.org) and Typings (https://github.com/typings) for type definitions to most of the popular JS libraries. There is also a list of some useful tools and utilities on the DefinitelyTyped website but here are a few that might be useful:
Before Sameroom [1], we spent two years building Kato (https://kato.im), which became a Slack competitor once Slack launched. We did enjoy a brief pre-Slack honeymoon (at Techstars, no less).
For a few reasons, we chose Xamarin to build the Kato mobile apps. The end result was pretty good—great, even, considering the ridiculously tight timeline. We had a pretty elaborate common core with all the hard stuff (networking, caching, protocol, presence, etc), and custom UI code for Android and iOS.
In the end, since Kato was to be no more, the real benefit was seeing how much sense it makes to use a strongly-typed, object-oriented language for building complex user interfaces.
Many years ago, and for many years, we were C#/C++ programmers, so it wasn't exactly a revelation. But, we'd been working for quite some time with dynamically-typed Erlang and dynamically-typed Javascript (the Kato UI was built with Knockout.js).
Our server code was fairly straightforward and didn't change very much, so Erlang was an excellent choice there. With JavaScript, we'd programmed our way into some serious debt.
When deciding on a stack for Sameroom, we embarked on a quest to replicate the Xamarin experience for the web. We eventually narrowed in on Flux, React, and TypeScript.
After some experimentation, we got a development workflow working with gulp, shrinkwrap, make, and no particular IDE (we use Atom, Sublime, and Vim).
The biggest crutch was lack of JSX support in TypeScript, so splicing together HTML elements was pretty cumbersome. We viewed this as a temporarly incovenience, which was a good decision—TypeScript 1.6 got React/JSX in September 2015 [2].
We're pretty conservative about adding dependencies, but the overwhelming majority of libraries we do use have TS support available from the DefinitelyTyped project [3]. The few libraries that weren't supported (Stripe checkout and Intercom, if memory serves), we TypeScriptified ourselves.
As a result, working on the Sameroom UI is absolute joy.
It's a little ironic that, unlike Kato, Sameroom basically doesn't need a UI, since it's just marketing copy and an administrative dashboard.
>As a startup founder, if you have a choice between telling people about your startup and not telling: tell.
I really can't agree. It might help your startup, but at the cost of reputation and goodwill. I could choose to start a company and tell people about it by mentioning it in hundreds of posts on message boards and news aggregators, but even if I contributed intelligent discussion and content along with it, I'd still likely be downvoted, "thumbs-downed", and lambasted the vast majority of the time.
Mentioning it is fine in some cases, where it's actually very pertinent to the discussion ("actually, my startup happens to be solving exactly this problem!" or "for a great example of X, check out https://startup.com [Full disclosure: I'm a co-founder]"). These are sensible cases of promotion. But blasting the link when it's barely relevant seems sleazy and disingenuous.
>if you have a choice between telling people about your startup and not telling: tell. This is incredibly hard for engineers, but you just have do it.
Getting publicity is easy, especially if you have no ethics and/or a lot of money to spend. Getting well-deserved and organic publicity is much harder.
Your post was in response to a minor-ish announcement about a programming language that's been around for 4 years, one very similar to the most popular one (JavaScript), and which definitely isn't some kind of unicorn or barely-known gem.
If you just wanted to show that real people are using TypeScript in production, why couldn't you have said "my startup has been successfully using TS for X amount of time and we've been loving it" and nothing more? Anyone who was genuinely interested in what startup it was could look at your other posts, or message you, or click the link from your profile if you had it listed it there. You didn't even link to any source code to show people examples of practical TypeScript.
The exact startup that's using TS doesn't matter in respect to the nature of the comment you made. Perhaps if it were something really notable and unexpected, like Twitter or Google suddenly using TS for their frontend, then mentioning the company makes sense. Here, it just seems like shameless self-promotion.
As a result of your post, I think a little more highly of TypeScript, but in turn, I also think less of your startup. Which is a shame, since it seems like a good idea.
I don't know if you're setting me up for a joke here, but you're putting the ball an inch away from an open goal:
Javascript is Typescript. Typescript ⊇ Javascript.
Especially if you already use Babel (or any other JS preprocessor, like uglify or concat) and have a build pipeline ready, you can start using Typescript today.
Don't miss out!
PS: It will throw a lot of errors on a conventional codebase, but compile despite them. That's the point; install the compiler today, slowly start fixing the errors as you go. It's all about gradual improvement and optional typing.
There are still issues with type definitions for third party libraries. I love TypeScript and would love to work on it full time, but it's painful when you need to use a dozen third party code. Unless this has been solved recently, I remembered tds files weren't updated regularly.
I'm not bothered by silly things like tone or harsh language, especially for such amazing news. I've actually written my fair share during the summer and I never knew about this.
Thank you! How well would this work with an editor and typescript plugins? Say the amazing typescript-atom, I would guess the editor would crap its pants, no?
A better way would be to do like Arnavion said, for really global libraries you should create a .d.ts file and put this line in it:
declare var somelib: any;
Done. Now the compiler and everything else will know that there's a global variable called `somelib` that does not have a specific type, and no matter how you use that variable, it's ok, you know what you're doing.
No problem. As others mentioned; declare var is the way to go (my TS is getting rusty, apparently :) ).
Editors have no problem with it. They will simply see it as an "any" var. Completely compatible.
I wrote quite a bit of TS and this was how I used most obscure libraries. I can't be arsed to keep those stupid .d.ts files up to date and I trust the API docs. It's my own code I wanted to vet. Works like a charm.
Judicious use of declare var any, and ignoring compiler errors, is what really makes TS reality-compatible.
Why not use VSCode instead of Atom? It's (relatively) performant, it has first class support for TypeScript, and if you ever want to hack on it, it's free/open source software (MIT) and written in TypeScript itself.
I had the same dream... so I started using Flow[0]! Put all of my codebase in /* @flow weak */ to start, then slowly tightened it up with more type hints, declarations, etc.
Still... why have type inference in the first place if you can not safely utilize it. The argument for having things unsound is "to strike a balance between correctness and productivity". Having to declare types on everything even if it's just generics beats the productivity argument.
Because turning the inference dial up often results with what Flow does: it shows the error at all the wrong places and doesn't show it at the right one.
Try adding the types to the function in your Flow example. The error will finally move to the last line i.e. Flow will actually become useful in tracing down the error.
I think Microsoft made the right call to demand function argument types. It doesn't cost very much at all, but it improves error messages tremendously. It might not matter in a tiny example, but I'd bet that Flow's behaviour can be frustrating in a large project.
Showing a less accurate error is worse than showing no error? How is that "less" frustrating if you have to find a bug?
It does not DEMAND the argument type?
Adding it to flow also improves the error message?
How is that the right call?
Showing a missing type annotation error is better than showing errors at all the wrong places.
Showing no errors is a separate argument entirely, and was addressed by the parent poster (noImplicitAny). I will add that I always use TypeScript with --noImplicitAny which indeed does result with TypeScript DEMANDING type annotations for arguments. Of which you complained:
> Having to declare types on everything even if it's just generics beats the productivity argument.
and to which I respond that
1. its not everything, just function arguments
2. its better to demand function argument types than to show unhelpful error locations.
Implicit any is (was) useful for the early migration phase of the project. At that point you (had to) rename everything from JS to TS to use the compiler, and would get a type error for every unannotated function (which might not be a type error at all). The TS team had to choose between:
1. spending a lot of time and effort to get proper deep unification like Flow's working at acceptable performance in a single-threaded process, even without incremental recompilation, or
2. default to a loose "type checker" and provide a gradual tightening valve for users - at the cost of demanding a bit more annotations: for function arguments (and only if the function is not a part of a single expression or statement where the type can be inferred - e.g. types will be inferred for lambdas passed as function arguments)
(1) may have been worth it if it actually resulted with useful error messages, however as demonstrated above, it often doesn't. So they went with (2), and I'm glad they did - otherwise I'd have to deal with mostly-unannotated TypeScript codebases that produce useless error messages every time you do some sort of refactoring, or enforce type annotations via conventions / code reviews / linters.
Flow's inference is a beautiful marvel of engineering, really, and the type system avoided some legacy TS pitfalls (has safer treatment of nulls, proper union and intersection types from the start) but I'm afraid its not that big of a marvel of practicality.
"For example, for a quick ES6 to ES5 downlevel conversion using the TypeScript compiler, you just need the following command: > tsc --allowJs --outDir out target_file.js"
Is the intent here to allow tsc to be used as a replacement for babel?
I am really puzzling what is Microsoft trying to accomplish here? Eventually a C# that compiles to JavaScript? TypeScript is a great language, and surprisingly (or not) it's more successful than Dart. Now, of course, I want TypeScript to compile to CLR as well. :)
I think people read into TypeScript too much. It's just a "right-now minimal-hassle" way to make front-end dev's lives easier, nothing more.
Maybe Microsoft disagrees, but I see TypeScript as something intended to make itself obsolete: eventually, when all browsers are running ES9 (or whichever version we decid has fixed "all" of JavaScript's problems) or WebAssembly (and we're all writing front-end code in C#/C++/Ruby/whatever), then TypeScript will just fade away, by design. For now, it's kinda like JQuery in motivation if not literally architecture: it shields you from browser inconsistencies (in this case, where you don't know what ES version the target is running) and helps you avoid JavaScript's headaches. Just as JQuery became less necessary as time went on-- not because it got worse but because browsers got better-- so too will TypeScript.
by the time all the browsers will run ES(x) ES(y) will be out and everyone will be transpiling ES(y) to ES(x). Given the developer base it's very unlikely to go away.
TypeScript is older. It was first released in 2012, whereas Dart was released in 2013.
Dart arrived with much fanfare though, whereas TypeScript was more low-key, and it's taken a while to become mainstream. Google's announcement that Angular 2 would use it has brought it a lot more attention from outside of the traditional MS/.NET dev crowd.
Microsoft have also been shifting the project's focus towards a more Babel-esque one, emphasising greater interoperability with existing (untyped) JS libraries, and support for new ES6/2015 features (and beyond).
Don't know what you're referring to. Dart's release was well past by the time TypeScript debuted.[1] Dart was announced in 2011.[2][3] The only significance that 2013 has to Dart that I know of is that's when Dart 1.0 was released. If that's what we're measuring, TypeScript's 1.0 coincided with Build 2014—still later than Dart's corresponding date, and among other things, that would mean we could say Rust is less than a year old, even though it predates both.
I think Dart and TS will have more or less same audience - and both have their advantages. For me TS is just worse than Dart - not as elegant IMO (all in all - JS superset) and Dart has own VM on server, own consistent packaging system and good non-windows IDE support (Webstorm, IntelliJ).
That actually existed internally at MS, along with many other projects to improve developing large JS codebases, most of which have fallen by the wayside. There was even a Flow-like compiler that worked with type annotations in comments. TypeScript has won out, although there is a LOT of code written in these other projects.
I love TypeScript - it's my favorite precompiled language and I use it for a few personal projects of mine. But I can't help but feel it's an evolutionary dead end. asm.js / web assembly is what you want transcompiled languages to target
Interesting, I've only ever known about Emscripten based asm.js compilers. TypeScript + LLVM have the benefit of being actively developed with a strong community backing.
It would be refreshing if the ES evolution would take some hints from TypeScript instead of satisfying the perceived need for syntactic sugar and cutesey poor man's FP.
> While React has paved the way, JSX syntax is not only tied to React.
Does TypeScript manage the lifecycles of elements you create through their version of JSX? React creates an in memory version of the DOM and reconciles changes to the DOM against this. Is TypeScript doing this too or is this simply template syntax inside JavaScript? What React does is not simply template syntax. HTML and JSX are totally different things! JSX renders to HTML eventually, but there's way more going on.
According to https://github.com/Microsoft/TypeScript/wiki/JSX, there are two JSX processing options. The first is a JSX passthru ("preserve" mode) and the second ("react" mode) will generate React.createElement, etc. See that page for the technical details.
As such, preserve mode is intended for use with other backends, e.g. those listed under Transpilers at https://facebook.github.io/jsx/. Whichever non-React backend you choose therefore defines the JSX runtime handling rather than having that baked into TypeScript.
Also, Typescript type checks the JSX. This was the big thing that convinced me to start using TSX was typed views. (I've not been using React, so I've been using preserve behavior and Babel to feed the Virtual DOM library I am using.)
I'm guessing parent means compiling TypeScript down to CoreCLR bytecode instead of to Javascript and running through Node for execution. Pretty big job, that one.
Sorry, I wasn't clear, that's what I meant. I was using running the code through Node as the current situation, and trying to communicate you meant the opposite of that :)
I mean, when specifying function type, you can't specify type of `this` that the function expects to be run with. And `call()` expects thisArg:any, ...args:any[] for all functions regardless of their declared parameter types and expected type of `this`.
I'm talking about the usual js `this`, the covertly passed parameter, not typescript `this`, type of own class.
Funny they focused so much on classes that they reached 1.8 without so much as touching js most unique feature, flexible `this`.
I don't think this applies. I don't believe anybody else was doing what TypeScript does when it was released, that is JavaScript + Type Safety. Even today the only other real contender is Flow.
This makes integrating 3rd party JS libs much easier and I can streamline my components a little since I'm almost exclusively using stateless components anyway.
That already made me quite happy. But as I'm reading on I almost can't believe all the other great additions, such as module augmentations, string literal types, AMD module concatenation, let/const in loops. It's like they've been reading my mind. These were all things on my wishlist. Great work!