Announcing TypeScript 2.7 | Hacker News Reader

Announcing TypeScript 2.7

blogs.msdn.microsoft.com

193 pointsDanRosenwasser83 comments

TypeScript is a great improvement over JS, still held back by the horrible state of the JS module system in browsers. You write your code and it does what you want, then you spend a month figuring out amd vs esnext vs systemjs and Babel vs browserify vs requireJS vs webpack vs god knows what else.

And then when you find the solution that works.. two weeks later it is deprecated, the docs are gone, there is no clear migration path, and there are only conflicting blog posts full of misinformation by people that only know what worked for them and don’t actually understand what it is that their steps actually do or how they work.

(Yes, as you can tell I did not start off life as a JS web developer. TypeScript made the development part palatable to me, but the deployment remains a nightmare as far as I can tell.)

I wonder if the TS team has explored using webasm to at least get around the compilation/translation issues.

Edit: I actually know the difference between the technologies I mashed into a single list (they’re not arcane concepts in low level development, it would be akin to confusing make with clang++ with gdb with Linux with ARM). I didn’t bother spelling it out because it’s not the point (I don’t have a specific question) and because to too many people that is what it seems like.

Edit 2: Please see my reply to @coltonv below: https://news.ycombinator.com/item?id=16278062

Come on, take the time to learn your tools instead of blindly mashing things together.

Step 1 : npm install --save-dev gulp-typescript-babel

Step 2:

var gtb = require('gulp-typescript-babel');

gulp.task('compile', function () { gulp.src(config.typescript) .pipe(gtb({incremental: true, configFile: 'tsconfig.json'}, {presets: ['es2015']})) .pipe(gulp.dest(config.output)) });

Step 3: Enjoy.

Right, I forgot to mention the duplication of build systems between TypeScript’s own, webpack, npm, gulp, and others.

Ironic that you speak of "blindly mashing things together" - how many different build systems did you mash together there, hidden behind a meta npm package?

The web needs CMake or meson more than C/C++ ever did.

Don't be act like an idiot simply to make a point. You simply come across as some elitist programmer who can't be bothered to learn frontend tooling.

All of those technologies are simply Javascript running serverside (or developer clientside during the development).

I sent you a gulp example because gulp it's very easy to use and you can quickly build customized build processes with it.

"gulp-typescript-babel" is simply a wrapper for "gulp-babel" and "gulp-typescript" which are both simply Javascript libraries. Read their source, there's nothing complicated going on in there.

"gulp-typescript" simply wraps around "Microsoft/TypeScript" and make it easy to pipe into gulp.

"gulp-babel" simply wraps around babeljs and make it easy to pipe into gulp.

"babel" is simply a lib that polyfills and rewrite your next generation JavaScript into code that older browsers can understand.

You originally said "then you spend a month figuring out amd vs esnext vs systemjs and Babel vs browserify vs requireJS vs webpack vs god knows what else.". I sent you this snippet to show how simply it is to build TypeScript.

Oh look, I explained to you a "month worth of research" in a simple HN comment... ! You could have googled it and read a blogpost about it instead.

Sorry for being harsh but if you need a month to figure out how to run Javascript on your computer you need to consider a new career.

You've crossed into incivility in this thread. We ban accounts that do that, so please read https://news.ycombinator.com/newsguidelines.html and use the site as intended—i.e. posting civilly and substantively, or not at all—regardless of how annoying another comment might be. We all get bitten by the annoyance bug sometimes.

I apologize (that goes for both you and mainly for ComputerGuru), this was not my purpose here. Please do delete this comment thread as it clearly goes against what HN stands for. Negativity isn't one of my values and I'm sorry for it. As you said, the annoyance bug bit me hard.

Thanks! It's really only a problem if it's a repeated pattern. It happens to me too, and most others.

Thank you for that intervention, it snapped me out of a negativity circle.

are you not making his point for him?

> instead of blindly mashing things together

...immediately mashes a massive number of things together

Since when is using two libraries (typescript and babel) considered mashing a massive number of things together?

If you don't want to leverage Gulp to easily automate your build process then don't.

If you don't want to use NPM to download packages then simply download the .zip archive on Github,

(1) It's three: gulb, typescript, and babel.

(2) It's hundreds more

    $ npm install
    $ jq '.dependencies | length' < package-lock.json
    176

IDK what "blind mashing" would be if not this.

Do you count the number of vendor DLLs when you develop .NET applications using third party libraries? Of course libraries will have dependencies.

You are only "blindy mashing" three libraries here. Gulp to manage your workflows, Typescript (because that's the goal of your workflow) and Babel to allow older browsers to read modern Javascript. You can cut Babel out of it if you develop something for a modern browser (internal apps, mostly).

That's three widely used dependencies. There is nothing obscure about them at all. The only questionable choice in that tooling chain is Gulp. The reason I used gulp here is that it's very easy to use it to output simple Typescript. Something such as Webpack and Browserify would be for bundling modules and that's an advanced topic.

First of all you probably shouldn't complain about the JS ecosystem if you barely know anything about the JS ecosystem. This is evidenced by you bundling several things in your "amd vs esnext vs systemjs and Babel vs browserify vs requireJS vs webpack" which aren't directly comparable. Babel is a compiler, ESNext is a language specification (now ES6 since after being been finalized more than 2 years ago). amd, systemjs, requirejs, and browserify are all still supported and have not been "deprecated" as you say. However for the last 2 years Webpack has been the dominant module bundling system since it's incredibly powerful and extendable.

The standard for about 2 years now has been to use Babel + ES6 imports with Webpack. Babel lets you write ES6 code that compiles back to ES5, which means older browsers can run it. This means you can write modern code with patterns that will never get deprecated that works in older browsers. Webpack takes some configuration to fine tune it for large apps but getting it set up for a small app is pretty painless these days, and it continues to improve.

I'm honestly kind of sick of there being someone in every comment thread bursting through the door to tell everyone about all the bloat in the JS ecosystem. It's largely been solved and there's a lot of maturity in the libraries in use now. I think a lot of the frustration came from people who liked just pasting a script tag to add new libraries to their frontend, and any system which requires them to actually think and configure before pushing to production is considered too complicated.

Furthermore, you usually don't need Babel if you're a Typescript user because the Typescript compiler covers more or less the same ground.

Use Typescript+Webpack if you like types, or Javascript+Babel+Webpack if you like surprises, and in either case use ES6 module imports.

However a lot of guides (even some officially sanctioned ones iirc) use Babel to transpile typescript in the browser, forgoing the precompilation to JavaScript entirely.

I don’t know if that’s just an artifact of days gone by, an attempt to bypass tsc before it gained on-the-fly watch-and-compile support, or for another reason entirely.

I think you're getting Babel and SystemJS confused - the latter allows you to use TypeScript files as the source attribute in script tags and have it transpiled within the browser, which is sometimes used in examples and tutorials because it avoids any need to use the command line or configure a new TS project.

>This is evidenced by you bundling several things in your "amd vs esnext vs systemjs and Babel vs browserify vs requireJS vs webpack" which aren't directly comparable.

"amd vs esnext vs systemjs" is about module formats.

"Babel vs browserify vs requireJS vs webpack" is about transpilers and loaders.

Thanks for taking the time to write out this reply - my initial comment sort of took on a life of its own, it wasn't originally supposed to turn into a rant and was never intended to be taken literally or to imply that it had been precisely crafted. I appreciate your responding to it nevertheless.

I am actually very aware of the differences between the various components, but I am appalled at just how many cogs it takes to get things working _with 3rd party libraries involved_. It seems as soon as you bring in a single dependency, Pandora's Box is opened and you suddenly have to bring in 12 different build systems along with it.

> I think a lot of the frustration came from people who liked just pasting a script tag to add new libraries to their frontend, and any system which requires them to actually think and configure before pushing to production is considered too complicated.

In my case, it's the other way around. I don't think you understand how much of a breath of fresh air being able to "just paste a script into your html" was for people that came from complicated build systems that required you to locally download, build, and install each dependency your code relied on because there was no module system and there were no URLs or CDNs or whatnot. What is sad is that JS, after seeing how horrible of a mess the C "module" system was, went down the same road when they could have embraced better alternatives and iterated html/browsers in-step with JavaScript to come up with something that wasn't such a mess.

I confess to not being a JS history expert, but as I understand it, require came from node running locally before people tried taking that to the web, and thus requireJS was born. Only it needed a mess of other components to get it to work with existing libraries. And then those 3rd party components were deprecated or replaced by newer iterations, sometimes by the same developers or sometimes by newcomers to the scene. And no one bothered with compatibility with existing systems, except people that drew up a type of "super standard" that encompassed n other types by simply multiplying their complexity instead of reducing it.

We went from being able to get a web app up and running with an HTML file and a single JS file, optionally combined into a single document, to requiring a dozen different build systems, separate compilers and transpilers, many layers of abstraction, required preprocessors and optional in-browser on-the-fly compilers, OS-specific tools, library-specific module systems, and a million different ways that a single statement ("export") could be translated into code, or the dozen different gotchas that you need to consider when you type in that one word ("import") because you'll have to dig up the documentation for the library you want to use to find out just how it exports its interface.. and then you need to make it play nice with the framework you already have in place.

We went from writing every line that of code that appeared in the browser to writing a simple "hello world" that require an insane 10x or 100x payload to run it... and only after studying the various build systems and trying to figure out which was old enough to be supported but new enough to still be around for longer than it took to learn JS itself.

With regards to deprecation, I personally (though not even a web developer by trade) ran into the official deprecation of both bower and typings; and while requireJS and co may not be deprecated per se, if they're not the "right" way of starting a new app today then they are deprecated because your time is better spent learning skills that will still matter tomorrow and sooner or later for a living app you will need to replace them with something else to be able to use the latest version of dependencies and libraries.

> We went from being able to get a web app up and running with an HTML file and a single JS file

That still works, though.

You can still write simple apps by just putting in a script tag, that never stopped working. However, if you want to write a complicated app, then you've already accepted that you need complexity and thus you should be taking the time to evaluate different build systems, pick the right one, and settle on it. Like I said, there are multiple mature solutions to do that.

The fundemental problem is that you are either trying to write Hello Worlds with enterprise-grade build tools or that you're trying to write web apps with single script tags. Your hello world with React + Babel + Webpack is going to be big. That's the point, you're importing an library that is built to make extremely large complex web apps simple to make, therefore by definition that library has to be big and complex. But the joy is that you can then build out an entire web page with significant reactive functionality in a matter of hours.

I get that looking at a lot of options makes things look scary, but you only need to look at those options once you're ready to build something big. And big is going to be scary regardless. Until then, you will have no issues just importing a script into your web page for the little things.

I love that there are currently two replies to you, both implying you're an idiot for not knowing how to do this, and both presenting different solutions.

I never called him an idiot, I just called him out for not researching at all before posting. His understanding of Javascript has not been updated in at least 3 years based on the fact that he called ES6 ESNext, even though ES6 has been released for almost 3 yars.

There's also two different compilers for C, but it's not considered complicated to get started running a C program.

I wasn’t referring specifically to ES6 when I said ESNext, I was referring to the ever-evolving “this willl be addressed in the next ES release, just add ESxxx as a flag to the zillion build systems and you’ll be good to go,” as well as simultaneously referencing the ES module system.

My post was not intended to be taken literally. It was a rant, I’m sorry for the lack of precision and effort. (Not being sarcastic.)

I do very little webdev, but `parcel index.html` seems to be able to do just about anything.

I'm a back-end developer (Java, Scala, some Rails) and when I first heard developers were using Node+JavaScript as a server stack I thought they were nuts to use a dynamic scripting language for enterprise software. TypeScript has a chance to turn that around, though, and might be the future: a mostly-typed language that also has the flexibility to be dynamic when called for.

I really like TypeScript and it has ushered me into the node environment.

Same here. I had to take over a node project and I can't imagine how anybody could maintain a large JavaScript codebase long term. It's way too easy to insert a simple mistake. The next version of our project will be slowly ported to TypeScript and I look forward to it.

The root problem is that most companies don't spend any time planning their projects. It should only take a couple of days and yet companies just don't do it.

The bad coding style that you sometimes see in JavaScript land is just a symptom of a greater problem that static typing masks but doesn't actually fix.

I like dynamic typing because then I can see straight away if the project is crap or if the team is crap.

I think Javascript is definitely way too forgiving. I just had a situation where a property name was mistyped. The value was "undefined" which then can be compared against strings. So the code worked without warnings but the results were wrong. Took several days to track this down in a long promises chain. With a typed language this wouldn't even have compiled.

But with JS you don't need to wait for your code to compile so you can test it much quicker. If you write tests then this is almost never a problem.

With typed languages, I often lose my train of thought while waiting for the compiler. When warnings come up, I'm like a robot, I don't actually think, I just follow the line numbers.

Statically typed languages make me lazy. I feel like I spend all my time and mental energy catering to the compiler. I like dynamically typed languages because it forces me to consider everything and keeps me on my toes.

You can simply erase the types with TS and it’s ready to go. I think tsc does this automatically, but I’m not really sure because I always wait for the compiler to finish out of habit. It doesn’t seem to be incremental at all yet, so compilation times noticeably grow longer as your project does, unfortunately.

I guess it's all a matter of taste or what you are used to. I like relying on the compiler. The stricter the compiler the better.

You can't type things properly without considering the business logic. Once you have that figured out the correct logic comes easily.

The compiler should be sparing you from wasting mental energy on menial things by telling you what to do, even when making large changes that would be disgustingly complicated in a dynamic language.

If you feel like you're "catering to the compiler", then you're going about things wrong; because you're worrying about logic before nailing down the proper data structures.

>But with JS you don't need to wait for your code to compile so you can test it much quicker.

This is no loner a valid criticism as any decent IDE (or a mature Code Editor) can run static analysis as you type and warn you abut issue, before you even compile.

Source: VsCode does static analysis on TypeScript.

JavaScript dev here. Type related Mistakes are common but A LOT of tests keep me safe. I avoid using the Object constructor for data that is passed around a lot and use functions as constructors to create common data structures to ensure their structure and properties are consistent. Simple example:

function User (name, email) { this.name = name; this.email = email; }

This simple solution prevents lots of common typing mistakes where object properties are inconsistent.

Sometimes I include some specific development-only type-checks on the params as well

We cant use Typescript, I would love to use it though

The issue with typescript is that it relies a lot on external type definitions for non-typed JS modules. And those are plain wrong or outdated at times, leading to lots of compiler errors (but correct code!) which in turn means you can't let your build fail when type errors are detected and you acquire some compiler error numbness over time.

I mean it's better than no type checking at all, but it falls short of languages where it's actually baked in instead of relying on external definitions.

On the one hand I am glad they are continuing to enhance TypeScript. On the other hand I am concerned that TypeScript is becoming a very bloated language. If you have seen the latest edition of Stroustrup’s C++ Programming Language book you know what a bloated language looks like. Is that where TypeScript is headed?

Programming languages are not like your Word or Excel where more features is better. Some programming language designers take pride in how small the language is, for example Kernighan and Ritchie. I worry that as long as Microsoft has Program Managers and Development Leads assigned to TypeScript and their job performance is measured by the number of features they add, TypeScript is going to get more and more bloated with obscure features.

In that regard C11 is also much more than K&R C, and C20 is on the horizon.

JS is a big language. It continues to grow without removing features. One codebase can be very functional, another dynamically typed C++ from 2004, another pythonic. As long as they support the entire language while adding static typing (not an easy feat), it's going to grow. In that sense it is very much like C++, though it's still not in the same league of complexity of C++.

If you want a small language, look elsewhere. I had fun with Bucklescript over the weekend, and it is amazing how expressive it is. The syntax sucks in places [| Reason is a small upgrade |], but that's probably where you want to look. Maybe Elm if you are fanatic about it.

> JS is a big language.

Kind of(maybe). But that's beside the point. Typescript is a separate language that happens to compile to Javascript. The TS team is in no way bound to support every style of programming that Javascript supports (and they don't, just by virtue of having strict typing).

They don't have to, but as long as they want to market themselves as a "typed superset of Javascript" (see homepage), they do. For many people, that is the point.

Yep. And this is important, it allows people to move most JS projects incrementally to TS projects. If they fall far behind the features that many JS projects are using, that won't be true anymore, and those people will start using Flow instead (flow.org)

Similarly it is useful for TS to track the Stage 3 proposals of future features and offer them early, as JS users may pick those up with Babel or other polyfills. Typescript's own transpilation behavior of Stage 3 proposal can sometimes be a useful test for the feature while browsers work on their own implementations.

> On the other hand I am concerned that TypeScript is becoming a very bloated language

I came to say exactly this. Are there actually people out there asking for all of these nuanced features?

I've been excited about TS for a while and used it for several side projects with great success...but with each new release and new set of "features" my excitement wanes a bit.

I do some of the feature planning / prioritization for TypeScript.

The strict class property initialization check was the one of the highest-voted, most-commented, and most-duped "unfixed" issues on the issue tracker.

Definite assignment assertions are a necessary co-feature for class property initialization checks to work ergonomically.

ES module interop is just TS keeping up with the evolving ES6 / CJS interop story. TS has to support ES modules.

"unique symbol" is type system support for the long-present ES6 symbol concept.

Cleaner/prettier console output should be uncontroversial as an incremental improvement.

Numeric separators are an ECMAScript feature that need to be supported. TS has to support ES syntax.

Fixed length tuples were a long-standing proposal (nearly 2 years old) that had a lot of positive feedback from the community. Among people who were using tuples, the prior behavior was seen as very much wrong and we were convinced by the use cases. People not using tuples are unaffected, naturally. It's more of a bugfix than a feature.

Better narrowing under "in" and "instanceof" were also long-standing issues. The "instanceof" behavior in particular just looks like a bug; only from a spec-lawyer perspective is it really a feature per se. It's more of a bugfix than a feature.

Smarter object literal inference again basically amounts to a bugfix; TS was allowing extremely broken code, essentially due to some implementation details of how types' representations are optimized. It's more of a bugfix than a feature.

It's definitely understandable that the most exciting features are already in the language, but I don't see anything in this list and see "bloat".

Thanks so much for taking the time to respond in such a thorough manner :)

I really appreciate the work that the TS team is doing, and understand that they are up to a very difficult task in trying to keep up with JS while also augmenting the type system capabilities to cover more cases.

With regards to making the language more complex, yes, i agree that it's not something pretty, but at the same time i find these kind of additions similar to the recent JS additions: you can still ignore them if you don't need them. E.g., you can still code perfectly fine without using classes, or symbols, or whatnot. There is the issue of having to deal with different "dialects" of JS/TS when reading others' code, but that still happens in pretty much every mainstream language i know of :/

TypeScript itself doesn't really add new language features; it just tracks the ECMAScript spec and considers proposed features for implementation after they hit stage 3.

The enhancements coming out in new TypeScript releases are largely related to typing expressiveness / type inference precision (covering more edge cases where one might have previously resorted to `any`) and strictness (catching more errors at compile time).

Indeed, the only Typescript feature I can think of that isn't purely for type checking or lifted from ECMAScript is Enums, and Enums have been around forever.

Well it has supports for JSX and decorators which AFAIK aren't in the spec yet. It also has a syntax for class mixins without actually doing any desugaring when the code is transpiled. So it's not quite just JS + types.

Ah, I forgot about those. Nonetheless JSX and Decorators were added to the language back in 2015, so they've been sticking strictly to ECMA features for nearly 3 years now.

It has public, private and protected members (checked at compile-time), which is a bit of a mess because ES is gaining an independent notion of private fields (checked at runtime).

> Programming languages are not like your Word or Excel where more features is better.

I‘d contest that even for those categories adding more features is necessarily better. In fact, Word in particular is an excellent example of how adding features can result in a worse product.

On the other hand, I like programming languages with either a “batteries included” philosophy or a large ecosystem of easily usable libraries that allow you to solve common real-world problems quickly.

As a PM on the team, I actually _share_ your concern! ;)

In fact, we're very mindful about the cognitive overhead of new features, but we're also motivated by pragmatism. These features have been highly demanded to help them write real-world code. My coworker Ryan has written up a pretty good explanation of why we tackled the feature set that we did: https://news.ycombinator.com/item?id=16277367

Keep in mind that TypeScript strives to model JavaScript as it's written broadly. While we could always take the stance that you have to rethink the way you write JavaScript, that would be unnecessarily stubborn. Hope that gives some insight!

It is a bit dizzying that the type system keeps getting even more expressive (the next release might have type conditionals!) while the core language and its dynamic semantics is necessarily limited to tracking Javascript (so no operating overloading, no pattern matching).

Features != bloated. JS has many, many, many shortcomings. I don't have 100+ libraries to do basic stuff that should be baked in.

The strongest point for TypeScript is its tooling and editor support that made it so easy use to use it in development. Even anyone writing JS in VSCode gets to use some checking from TS. But that bloat in the language and the amount of features added with every release is making me a lot worried.

ReasonML is great but it still so immature with little issues here and there that might be annoying to some people. I expect it to be a great alternative in the future but not now.

That's for example what makes something like Elm much better. How Elm dealt with the whole echosystem to make it use separate packaging system, not bad editors support (needs a lot of improvement for VSCode IMO) and the simplicity of the language made it a really powerful alternative that I'd use instead whenever possible.

If they add features the same way they do with C# I don't see a problem. C# has been extended a lot from V1 but it doesn't feel bloated at all. I think C++ started from a much less solid foundation and is still suffering from that.

Looking at the 2.7 updates, they don't really seem to be adding more features that result in bloat - instead there is a lot of work to make existing features more predictable and catch potential mistakes. Sounds good to me.

Personally I've moved away from the TypeScript compiler and towards the betas of `babel@7` and `@babel/preset-typescript` (https://www.npmjs.com/package/@babel/preset-typescript).

It seems to be faster and there is better integration with `jest`, `rollup`, various css-in-js libraries and (maybe in future?) `create-react-app`. (I still run `tslint` and `typescript` in the background for type-checking and linting. And I've written a tiny CLI to generate flat `index.d.ts` files to share my packages.)

The one thing I still miss about JavaScript is the possibility of writing codemods to speed-up upgrades. Unfortunately, in order for `jscodeshift` to support TypeScript, I think there would need to be some further work on `recast` (https://github.com/benjamn/recast/issues/424).

Hopefully the TypeScript team will continue to work closely with the Babel team, since this would be very good for the eco-system.

I'm not sure if I understand fully this babel <-> typescript integration. Can you help me understand this?

What's the point?

So in future babel would be able to parse TS file and output JS file with all the transformations it supports? So it's useful if you want to use some new EsNext feature currently not supported by TS compiler?

Is this the main advantage? Because for me it looks like a pretty weak reason (TS has improved a lot when it comes to supporting new ESNext features). Anyway, from what I understand TS provide API that for example webpack loaders use (like https://github.com/TypeStrong/ts-loader and https://github.com/s-panferov/awesome-typescript-loader) and it looks that those can be integrated with babel.

Or is it mainly to support tools that depends on babel for parsing AST? And microsoft is willing to maintain this babel integration for next versions of TS? So non-microsoft community developed tools can easily add support for TS (instead of only supporting JS), like Prettier did (https://github.com/prettier/prettier/issues/13)?

But are everyone using babel for JS parsing? I'm not that into JS tools community, and am a bit confused by all this ESTree, Esprima, recast, jscodeshift projects and relationship between them. You mentioned `recast` TS support and it looks they want to use babel for this too. So it's microsoft bet that all future JS tools that need to parse JavaScript AST will use babel for that, and hence they will add TypeScript support because it would be easy?

For example, the React team provide a set of codemods to help automatically upgrade codebases when there is a new version of React (https://github.com/reactjs/react-codemod). Until `recast` gets TypeScript support, everybody who uses TypeScript has to do this repetitive work manually.

Another example is how many `css-in-js` libraries require Babel plugins to work their best (e.g. https://github.com/emotion-js/emotion/tree/master/packages/b...).

And additionally there are also plugins that optimize React code (e.g. https://github.com/thejameskyle/babel-react-optimize).

What are you missing with Jest in TypeScript? For me, ts-jest is completely seamless.

Class property initialization was always a glaring blind spot in Typescript, I'm glad to see that strict mode verifies it now.

Thanks to the Typescript team for making Javascript much more tolerable :)

Awesome. Making JS better every day. For any medium+ sized project, plain JS just falls apart. Thanks guys!

TypeScript 2.8, due next month, is shaping up to be an interesting release! It introduces a feature called "conditional types [0]" which opens up a lot of type-level programming opportunities.

Flow also has the `$Call<>` type (type-level function application), but unfortunately as with most of its features, it didn't go through community testing/input before release, and thus it has bugs that render it useless for what I assume to be very common use-cases.

[0] https://github.com/Microsoft/TypeScript/pull/21316

Just curious, what are the problems/bugs with `$Call<>` that you are talking about? note: I only used TypeScript, not Flow)

I think this demonstrates some of the bugs: https://flow.org/try/#0PTAEAEDMBsHsHcBQiCWA7ALgUwE6QIYDGWoAS...

I wonder if there was ever a discussion that definite assignment assertions should have a strict mode flag to disallow. They seem like something that can be abused to escape the static type system.

Much like casts and nonnull assertions. The general consensus is that you can enable a tslint rule to categorically forbid them.

I use tslint to disallow practices that TS has no compiler flag for.

You don't even need to run tslint as a separate process these days. tslint supports running as a TS plugin, and will report its errors and warnings directly in the TS compiler output.

I have used TypeScript and I liked it but now I prefer to use Fable http://fable.io/

I agree with others that a language should not become bloated and I think it is heading in that direction.

No incremental compiler? I thought that was coming in 2.7. Really hope that lands soon. Compile times are my only complaint about TS, otherwise it is so much nicer than writing JS for anything mildly complex.

TS 2.6's `--watch` support became wicked-fast. In medium-sized repos (50klocs) the compiler is done in the same second it wakes up from the fsevent that a file changed.

Ah nice thanks, must have missed that announcement. Do you know offhand if that works with a webpack toolchain using one of the ts loaders? Haven't been doing much web stuff lately and last version I've used was 2.5.

    static readonly StaticSymbol: unique symbol = Symbol();

just no!

My favourite feature of TypeScript is that it supports dynamic types.

I hope that in the next version they will improve support for dynamic typing even further by disabling static typing.

> I hope that in the next version they will improve support for dynamic typing even further by disabling static typing.

I can't tell if this is sarcasm or not. Aren't you describing JavaScript?

Seems you were downvoted a bit, but I think your comment is hilarious ;^)

Dynamic types cannot be automatically refactored.

Dynamic types often incur the need for additional testing.

Static types can be verified at compile time.

Static types rarely lead to runtime type errors.

Nvm. ESxx is already waaaay too bloated, and Typescript only adds to that. All those new features are only adding complexity, pain and bugs. I'm curious when we arrive at the point when it's less painful to write a web app in C, it feels we're getting quite close already!

I try to keep my codebase as simple as possible with Coffeescript, doing dynamic type checking with types.js. Honestly very rare to see a type related bug in my codebases.

For all those ESxx and Typescript proponents out there: You don't need it. It doesn't make your life easier at all. In the Javascript domain I wind down as much as possible on the endless libs and tools to keep my codebase readable and my mind healthy.

I have an idea for the next version of TypeScript.

Instead of compiling directly to JavaScript, it should compile to CoffeeScript first and then to JavaScript - That's a great feature I'd love to see.

Of course, this feature wouldn't be possible without also adding support for meta-source-maps (aka source-map-maps).

That way we can experience the pleasure of debugging in 3 different languages at the same time.

I know it's a joke, but the thing about sourcemaps is already do-able. If you have a sourcemap describing A->B, and a separate sourcemap describing B->C, then there already tools for composing the sourcemaps to create a sourcemap for A->C. (This is similar to a thing that Browserify and Webpack have to do when you're using a transform like Babel on each of the individual input files.)

Reply on news.ycombinator.com