Announcing TypeScript 1.8 Beta
blogs.msdn.com
blogs.msdn.com
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!
[1] https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...
VS Code's source: https://github.com/Microsoft/vscode
Some other products using it off the top of my head: Azure Machine Learning, Xbox Music, Visual Studio Team Services. EVERYTHING new.
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.
And if you were pointing to a repo of the code that powers your startup, I'd agree with you.
Didn't mean "proper" as in "correct", but as in all-in, no-looking-back.
For Sublime, Atom, etc. there are a bunch of plugins that you can download:
https://github.com/Microsoft/TypeScript-Sublime-Plugin
https://atom.io/packages/atom-typescript
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:
https://github.com/palantir/tslint
https://github.com/sebastian-lenz/typedoc
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.
[1] https://sameroom.io/blog/from-pivot-to-140-paying-customers-...
[2] http://blogs.msdn.com/b/typescript/archive/2015/09/16/announ...
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'd rather explain my reasoning in detail than simply continue to throw sentence-long accusations wildly.
Edit: I meant refactoring as a way to improve the project, learn typescript, and learn the project itself inside and out.
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.
You can (and always could) use almost any 3rd party lib with literally one line of code:
var somelib: any;
Sure, no type safety on the lib. But isn't that where we started, anyway?
This should be put on a giant banner on the TS homepage.
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?
declare var somelib: any;
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.
And for required modules, you'd need to shim require in similar fashion and use var instead of import.
declare function require(module: string): any;
var somelib = require("somelib"); declare module "somelib" {
var somelib: any
export = somelib
}You're not using the entire options parameter or https://github.com/flot/flot/blob/master/API.md ? Don't declare it - only add the properties you do use.
You're only using 3 methods from 1 class in aws-sdk ? Only declare that 1 class and 3 methods in your aws-sdk.d.ts
http://tryflow.org/#2944d91c10fc5d76faeebbb20cac466a Try this snippet in TS.
var x: any = {}; x.foo();
Here's the typesafe way: http://tryflow.org/#b5f826e03045f64084cfc74398270e85
> var cats : Cat[] = [ new Cat() ]
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.
http://tryflow.org/#e6512d9c847d504bba8be8b90427ffc3
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 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.
Is the intent here to allow tsc to be used as a replacement for babel?
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.
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).
1. https://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-...
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.
It looked like it had some promise, since it wasn't nearly as heavy as emscripten, but I don't think much has happened with it since it was created.
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.
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.
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`.