51–60 of 93 posts
Typescript has became my favorite language. The option of having types when you need them is great and the addition of async/await make working with promises a lot nicer. Ever since I've been able to use experimental features and get es6 support with typescript I've never looked back. The only thing lacking now is the tooling. The atom-typescript plugin is the best I've found but I would love to see better integratio…
Earlier quoted context omitted.
You consider typing to be an over head? Do you really reuse variables within a scope to refer to different types? I feel like that would produce confusing to read and use code. IMO dynamic typing is hard to work with and slows things down. "Auto-typing" or type inference like in Swift, Kotlin, or Dart is the most amazing thing ever. It gives you the safety of static types and the "speed" of coding of dynamic types.
I think the overhead here is the programmer time spent specifying the types in a program, which is why everyone loves type inference. This is a common communication error: when you read "typing" you think "static type system", but when the parent wrote "typing" it almost certainly meant "explicit type annotations".
There are different overheads on program structure and verbosity which goes way beyond type annotations, depending on the language used and the style of the particular developer.
For example, in dynamic languages, a single container such as a list can contain any entities and functions can accept any entity as a parameter.
Java and C# can achieve this same using just object handles - but in other statically typed languges one either implements several containers and functions, or uses or creates an algebraic datatype using the language native typing (i.e. Scala, F#, etc) or invents ones own which is then utilizes in the container signature or function definition.
Earlier quoted context omitted.
Typescript is older (2012 vs 2014), more mature and stable (v1.7 vs v0.x), has better tooling support (autocompletion in Visual Studio), is easier to install (you only need NPM), has better documentation, and is easier to Google (try searching for "flow" online!). There are also plenty of common libraries with Typescript annotations, so you can just use e.g. Phaser and Typescript together without any extra work. Othe…
Flow offers some interesting control over things like optional types (nullable) and intelligent understanding of type tests in conditionals or calls to libraries like invariant. I've had these sorts of features catch quite a few bugs in my editor before even running a single test. Flow is also based on a daemon which continuously monitors your code. As such, it incrementally checks your modules allowing it to be extr…
TypeScript also has a language services server which runs as a daemon, lets you submit incremental edits to it and supports services such as autocomplete, rename refactoring and pretty much anything you see in visual studio or visual studio code.
But yes, the type system has a couple of unfortunate flaws that are relics from its beginnings (cant express non-nullable types).
That's great but is there any ES6 minification tool that handle ES6 ? Because last time I checked uglify didn't handle generators (and I assume by async to ES6 target they transform it to generators).
That's great but is there any ES6 minification tool that handle ES6 ? Because last time I checked uglify didn't handle generators (and I assume by async to ES6 target they transform it to generators).
There is http://rollupjs.org/ , which is quite young though.
It will be great when typescript can do it natively because it knows at lot more before the being translated to javascript : https://github.com/Microsoft/TypeScript/issues/8
Earlier quoted context omitted.
That assumes setupBase(), etc are either void-returning or return the this-instance (newModel). It won't work if each method returns a new instance, such as methods of immutable collections. Edit: Since this is hard to google for, this is called the "cascade operator". The given example is equivalent to: newModel.setupBase(); newModel.setupAdvanced(); That is, it ignores the result of the method and runs the remainin…
> That assumes setupBase(), etc are either void-returning or return the this-instance (newModel). This is Incorrect, it doesn't assume anything. Dart's method cascades just returns the receiver, it doesn't matter what the method returns, it's value is ignored and receiver is returned instead. http://news.dartlang.org/2012/02/method-cascades-in-dart-pos... Since the return value is ignored, it's only useful for method…
I remember when MicroSoft tried to make it's own superscript of JS and people said "Hey this is a bad idea. Standards are a thing for a reason and we should all stick to them." That argument was correct then and it's correct now, IMHO. Where is the objection in 2015? Is it just people are so desensitized by other companies attempts to make JS replacements (that for now compile to JS) that another one just doesn't bug…
There are quite a few differences from the old "JScript" days. First of all: TypeScript is liberally licensed open source. JScript was totally proprietary. Another aspect is that TypeScript is seeking to be a strict superset of JavaScript that evolves as JavaScript does (something that wasn't really happening in the JScript days) and is focused on specifically providing static types and tooling for types in JS. It's…
This is what I've been trying to get across for a while, thanks for the wording. Even CoffeeScript is a much bigger divergence than TypeScript (not only in syntax but in semantics, e.g. scope)