Glimmer.js: What’s the Deal with TypeScript? | Hacker News Reader

Glimmer.js: What’s the Deal with TypeScript?

medium.com

148 pointslowonkarma107 comments

What sold me on TypeScript was that it didn't just add features, it actively solved a problem I'd been experiencing.

Once a JavaScript project scales beyond what can fit in your head, JS's initial productivity boost crumbles because you have to constantly double back and make sure your methods/constructors/etc. are correctly used, which properties are optional, etc... A lot of the debugging happens in runtime and god help you if you try to make a breaking change to one of the major classes/apis in your project.

It's not unbearable, but the main reason for using JS is because of the productivity it allows.

With TS for the cost of taking the time to explicitly define your data you get a C#/Java level of debugging that has clear productivity gains and shifts your debugging from the browser/console to the IDE.

And when something doesn't fit the TS model you can just exclude it or only type the wrappers that integrate with the rest of your project.

That and async/await is a godsend over promises.

Have you tried Elm? Id love to know your experiences.

I haven't; I haven't tried Flow either which looked promising.

For kicks I tried the online Elm demo. Offhand it doesn't seem like Elm highlights errors inline(?). The syntax also looks a little foreign, whereas TS generally still looks like JS with a few exceptions.

I imagine Elm/Flow both have this, but another thing I like that TS does in VSCode at least with a watching task is collecting errors project-wide in a "problems" window.

Yes, the Elm syntax is more Haskell than JS. Not C based, which makes it an outlier.

Please try Elm and email me with your feedback. Id love to know more about it. Im a programming languages nerd. :)

Flow gets a good amount of the way there; it doesn't have quite the tooling of TypeScript but VSCode is actually able to bring a lot of that tooling to a Flow-typed codebase. Just yesterday I finished a major refactor that I'm not even sure I'd have attempted if we weren't using Flow. One giant action file feeding three insane reducers – yet I'm confident (with some testing) that it'll still work when I deploy today.

Elm has a compiler (a very helpful one at that) which will indeed collect errors project-wide in a "problems" window. Text editors like VS Code and Atom have Elm extensions which will highlight any errors the Elm compiler comes across.

Elm is very different from typescript and is generally a much more involved choice than just "let's make our usual JS strongly typed".

- You need to like Elm the language (it's pretty good, but limited, not expressive)

- You need to like purity. Time.now or Math.random returns an asynchronous Task. I know why it's done like that, I just don't agree with the tradeoff.

- You need to like Elm the ecosystem or be prepared to write lots of awkward JS glue code

- You need to like Elm, the architecture (it's simple, but has tons of boilerplate and limitations)

- You need to accept Elm, the roadmap made by a benevolent dictator. The progress is slow.

Compared to a good typescript codebase, you will get like +5/10% type safety. Typescript is way more flexible, but that also mean you will have to rely a bit more on human code reviews, etc rather than the Elm compiler just telling you "no, there is only one way to do this". On the other hand, you have just typescript on one side, Elm + javascript/typescript if you want to achieve anything serious on the other :)

Go with Elm if you like being in a very, very controlled environment (frameworky) and you're afraid to make mistakes. Go with typescript if you're a hacker who like to mix and match architectures, libs, etc and accepts things change fast in the frontend orld right now.

Have you encountered limitations in Elm that pushed you to resort to writing JavaScript (as opposed to using JavaScript libraries from Elm through ports)?

Elm is so amazing. It isn't as amazing when you just try out it's tutorial, but if you try to build an actual application in it, especially if you are a single programmer working on a project.

In my experience whenever I worked on a JS project on my own, there was an upper limit to how far I could keep writing the code on my own. After that, I had to spend time in doing other things (like writing Integration tests, lots and lots of unit tests, or refactor existing code because I realized that there are many issues unveiled).

But now, with Elm, it's like a whole set of unit tests are being written at the time of writing code which take care of plenty of common errors usually made due to lack of a good type system.

Add to that the usage of Maybe types (which are very beneficial in avoiding some UI antipatterns[1]), and the Reactive Programming pattern, I feel like I am writing a lot less code than what I am used to writing in JS projects.

I highly recommend Elm to anyone who wants to write a personal project, you'd see what benefits I'm talking about.

1. http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipatt...

There's two things that really stand out for me on TypeScript. There are other positive attributes, but these are the two things I liked.

The first is that it made some specific workflows a lot easier. In particular, I'm working on some pre-alpha libraries where there's movement on how the API interface is defined. TypeScript made that transition a lot easier. Yes, my testing would have eventually caught all the method arity mismatches, but TypeScript made this happen about an order of magnitude faster.

The second is how unobtrusive the types actually are. I did a fair bit of J2EE programming in the 00s, and types and interfaces can be really annoying. With typescript, interfaces are assertions about the shape of an object, rather than things themselves. That means, if you defined an interface as HasFirstName: { firstName: string } and function greet(person: HasFirstName), you don't actually have to put HasFirstName everywhere in the code that uses that function. You're not required to set up inheritance or anything. You just have to make sure that all arguments to greet have a firstName property. That's it. So I can say: const dude = { firstName: 'the' }; greet(dude) just fine. But if I try to greet(potato), it'll error.

Lexical typing this way gives you a lot of power while still staying out of your way in a language like javascript where it's super common to create consts as bags of properties without worrying about what particular interface they're instantiating. I really like that, as it is precisely the overbearing types of Java that annoy me.

For google-ability, TypeScript has structural types, in contrast with Java which has nominal types.

Ah, thank you - that's a set of names that I need, in order to express my love for TypeScript.

I've done a few typescript projects. Some migrating an existing codebase, some starting from scratch. Every time it has been a nice experience, and with every release it gets nicer. Two of the projects had very complex requirements, and typescript was instrumental in being able to refactor them with confidence.

I think the upsides are quite well known by now. Honesty requires me to admit that I did run into some downsides:

- Initially it was difficult to understand the exact mechanics of how typescript ... types. Definition files seemed like a bit of a black art, and how to annotate existing code so that it had the proper type wasn't always obvious, especially when you run into libraries with incomplete or wrong type definitions and when you want to do tricky stuff like creating typed mocks in unit tests. The typescript documentation is very good and I haven't needed much beyond it, but some extra real-world type definition chapters would help.

- Setting up a complete dev toolchain is challenging. I wanted everything: source maps, in-IDE debugging with breakpoints, in-IDE unit tests with code coverage, tslint, gradual introduction into an existing codebase, and robust integration into the build of the rest of the app (which in my case meant SBT integration). I still don't have code coverage in my in-IDE unit tests. The way I see it though, if your javascript has any build step at all you already have this pain, so this isn't so much a problem with typescript as a problem with javascript build pipelines in general.

- Convincing other developers typescript has value and isn't javascript's weird ugly nephew is an uphill struggle. Once you do a typescript project you end up understanding the value, even if you might not find it valuable for yourself personally, so it's only a matter of convincing developers to give it a go. However, getting to that point is a bit of a chicken and egg problem.

> Convincing other developers typescript has value and isn't javascript's weird ugly nephew is an uphill struggle.

I feel the same way about Elm, F# and Fable, Facebook's ReasonML, and any other language that has an ML type system and compiles to javascript. I think the value becomes more apparent when: a) you work in a large codebase and have to refactor either a large swath of code and/or a critical piece of logic and b) you need to make illegal states unrepresentable. In both cases, I have found having a compiled, ml-typed language extremely helpful.

I think for both Typescript or an ML language, having immutable non-nullable types by default really cuts down on complexity - instead of having to specify everything that's immutable with something like a `const` keyword, you instead have to specifically point out which attritibutes on a type are mutable. That's a small win but has huge benefits - especially when you're trying to debug code.

That's just my two cents anyway.

Anyone got a link on how to transition existing large webpack/React/babel project to using Typescript? Googling I only found https://medium.com/@clayallsopp/incrementally-migrating-java... but it doesn’t use ts-loader and doesn’t go into details on how to use typings. I tried following ts-loader docs, but things broke at `import flatten from 'lodash/flatten'` and adding typings for `lodash ` didn’t help. Would be interesting what strategies people use to get it working in existing project.

ES2015/commonjs interop currently sucks with TS. This is how you only import flatten:

  import flatten = require('lodash/flatten')

TS expects any modules imported using ES2015 import to have the shape of a ES2015 module. This is an issue for many UMD/commonjs modules. In the case of lodash, it's effectively doing this:

  module.exports = flatten

And then you're importing it like so:

  import flatten from 'lodash/flatten'

and that is being transpiled to something like:

  var flatten = require('lodash/flatten').default

Note the default.

I haven't migrated to webpack 2, but some brief experiments suggest all modules get massaged in to ES2015 format.

I've been using `allowSyntheticDefaultImports` which does some magic behind the scenes for you to be able to use `import flatten from 'lodash/flatten'` making it really easy to use modules that don't define default exports.

So far (a bit unexpectedly) I didn't really run into any nasty side-effects or things that went wrong with it.

See https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in... for a (short) explanation.

I have a project that uses Flow. I've had no complaints with it so far, but I've been craving the IDE support of TypeScript. What's the difference between the type system of TypeScript and Flow? Would it be worthwhile to switch?

Part of me wants to wait out the Flow team come up with better IntelliSense support. The `flow ide` command in the release 0.42 is a big step in the right direction. But it seems like TypeScript already has this, and if the delta between the two type systems is small, I might just go ahead and switch.

TypeScript's type system is intentionally unsound in a handful of places- function parameters are bivariant, for example. I believe Flow is at least closer to being sound.

I suspect switching from Flow to TypeScript would be relatively straightforward as far as the types go, but going the other direction would not.

The delta between the type systems is small enough that people have tried to automatically convert TypeScript type definitions to Flow. One notable difference is that Flow supports declaring types as covariant/contravariant. I suspect that as far as most application code bases go (as opposed to libraries), you would almost see no difference.

>What's the difference between the type system of TypeScript and Flow?

This presentation [1] was posted to HN recently and gave a pretty good overview of the differences between TypeScript and Flow.

[1] https://djcordhose.github.io/flow-vs-typescript/flow-typescr...

Awesome prez! Thanks for the link!

I haven't used TypeScript extensively, but I feel that there should be more of a push (maybe there is, please correct me if I'm wrong) to introduce whatever functionality people deem worthy that exists in TypeScript and introduce it to JavaScript.

You can already see the conflict happening as some people prefer Flow and others TypeScript. Perhaps later Google will throw their hat into the ring and introduce GScript. Then, you have three different languages that introduce similar functionality, that all transpile into JavaScript.

Sound familiar?

JavaScript changes slowly, and adoption of its changes is even slower. TypeScript has the major benefit of working now.

Also, TS is a superset of JS, so the fact that it's a different language isn't really problematic.

Angular 2 was written with TypeScript.

> I haven't used TypeScript extensively, but I feel that there should be more of a push (maybe there is, please correct me if I'm wrong) to introduce whatever functionality people deem worthy that exists in TypeScript and introduce it to JavaScript.

There is a huge push going on. But Javascript has a consensus driven community: all the big players involved have to agree on something for it to be adopted (Google, Apple, Microsoft, Mozilla, etc.). Plus, even when it's adopted there's usually a 2-5 year delay before mass diffusion.

Google already has Dart.

> Perhaps later Google will throw their hat into the ring and introduce GScript

Google had one called Atscript, but rallied Angular 2 around Typescript instead.

http://sdtimes.com/google-microsoft-combine-typescript-atscr...

The Angular team also managed to get TypeScript approved as a new language for internal development at Google, joining a pretty short list (Java, C/C++, Python, JavaScript, and Dart I believe).

All the others were apparently decided by fiat in earlier days then grandfathered in. TypeScript is the first, and so far only, language to successfully go through the official approval process.

I feel like we're going to see a big increase in TypeScript related activity from Google in the next couple of years, due to this.

I believe Go would also be an approved language for internal development.

The flagship feature of TS is static typing. That will never exist in JS.

I'd never say never. As I'm sure you're aware, JavaScript has had statically typed arrays since WebGL was introduced.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...

ES4 the version of JavaScript that time mostly forgot (except for Adobe and ActionScript) had static types that looked rather similar to Typescript/Flow. It's not impossible that it will be revisited. Especially now with the precedent from Python of defining/standardizing no runtime behavior for it, only syntax acceptance; that seems like something browsers might be more okay with versus the runtime behaviors required/encouraged by ES4.

It has typed arrays, but they're still not statically typed. In a statically typed language, this would not run.

    console.log("hello");
    typedArr[0] = incompatibleType();

In javascript, it will produce "hello" as output, and then a run-time failure.

They got class stuff into the language, and that was no small feat (very contentious issue), even if it is still syntactic sugar over prototypes.

If you just want type checking for JavaScript, use Closure Compiler:

https://developers.google.com/closure/compiler/

Code checking. The Closure Compiler provides warnings for illegal JavaScript and warnings for potentially dangerous operations, helping you to produce JavaScript that is less buggy and easier to maintain.

TypeScript is amazing, enough said. If you're building any application with any amount of code that has to be worked on by anyone other than yourself, you want to use TypeScript (I'd argue even for yourself, use it, it'll catch enough errors to pay for itself in spades). Coupled with editors like Visual Studio Code which are cross-plat and have first-class tooling for TS/JS, it just makes you objectively more productive both as a consumer and writer of Javascript. Even the most die-hard pessimists I've met love TypeScript once they try it.

Ok, when Glimmer's motivation was only typechecking, why not just fb flow then?

Having used both extensively, TS is simply the better choice. Flow has multiple large bugs and issues, which many would consider critical, open and unsolved on their GitHub repo for more than a year(!) [1][2][3].

[1] https://github.com/facebook/flow/issues/245 [2] https://github.com/facebook/flow/issues/869 [3] https://github.com/facebook/flow/issues/1528

I struggled with multiple blind spots in Flow in the past, but recently tried porting the same code to Flow and Typescript and I was surprised that Flow took less work than TypeScript. Flow 0.43.1 has become very fast and seems to need less type annotations compared to TypeScript with noImplicitAny enabled. I wonder whether Flow’s happily infers any without complaining or whether its program flow analysis remains more sophisticated.

You say "just fb flow" as if it's the default choice. If I were looking at project and community momentum, tooling, and adoption then TypeScript would seem like the obvious choice.

I'm curious why you think "why not just fb flow" for somebody who wants typed JS. It's certainly an option, but it hardly seems the go-to solution.

Am I the only one who thinks typed Javascript, wether it's TypeScript or Flow, is a really flakey experience?

I really enjoy Swift, so I'm not put off by types. But I find the experience of working in a real typed language to be very different to working with Flow or Typescript, where the types are for pretend, and type definitions are wrong often enough to be a real pain. And I found my self evaluating npm packages based on their type definitions, and not their suitability for the task, which seems bonkers to me.

Also, I don't ever recall staying late to track down a bug that types would have fixed. But I've wasted many an hour tracking down bugs caused by mutations, and the state of Immutability and Typed Javascript is pretty grim as far as I can tell, unless I'm missing something.

Types are pretend in TypeScript and Flow the same way that types are pretend in any other typed language. Types are used at compile-time and not runtime in both cases.

In contrast to many typed languages, currently in Typescript, you can't do any kind of reflection so runtime really has no access to the type system.

Well, I still love TS though.

There is the possibility of decorators for stuff like this. Angular makes a lot of use of them.

But isn't that some sort of repetition? I don't know how Angular does this so I'm really asking.

Well, it depends on the sort of reflection you want. Decorators get a decent amount of knowledge about the code.

Are they used at compile time with TS or Flow? I thought they were just stripped out.

Well, I assume they're at least used at type-checking time, which most people consider to be a subset of compile time.

In most other languages, type casts are assertions that can fail. Not typescript.

> the state of Immutability and Typed Javascript is pretty grim as far as I can tell, unless I'm missing something.

You definitely are missing something. Immutablejs and TS go together fine. Assigning to an immutable property or object is a syntax error instead of a runtime error. It's great.

I'll need to take another look at TypeScript. Last I checked you have to wrap your immutable records in classes with both TS and Flow. That's still true for Flow as far as I know.

I actually made my own type definitions that made immutablejs records "just work" for TS. I submitted them to the immutablejs guys, but they never acted on them.

You're missing Scalajs.

Is there a way for typescript to be used as PropTypes in React?

Does anyone know when Ember will use TypeScript?

Post TypeScript 2.3 - per https://twitter.com/tomdale/status/851924328220381185

Thanks!

>At the end of the day, though, JavaScript is the language of the web.

And when webassembly arrives that will be over, and Typescript will be deprecated. I can't wait for a better modern language like Haskell, Python, Livescript, etc.. built on top of webassembly. Then we can finally stop trying to fix Javascript's flaws with new language features.

WA with a performant web API, you mean. First iteration of WA won't let you touch things like the DOM without jumping through JS-land.

Yep, then we can focus on other language's flaws by implementing new features.

At the end of the day, JS will always be the language of the web. You're still going to be doing DOM manipulation through JS. WASM is really going to benefit people who want to do more heavy duty edge cases such as image processing.

Is this because browsers won't expose DOM manipulation at the WASM level, or is there a different reason?

DOM manipulation is going to be available at the WASM level in the future but it's going to be inefficient to do so just as it is inefficient to do image processing in JS right now. The only difference is that JS is the only viable option now if you want to do image processing on the web. WASM exists to solve this problem and complement JS. Hell, look at WASM's and JS's logo. They're two puzzle pieces that fit together.

Your analogy doesn't sound right to me- there's nothing about wasm that would make it slow to manipulate the DOM, while there is plenty about Javascript that makes it slow to process images.

Manipulating the DOM from wasm shouldn't be any slower than Javascript. Slow in general because of the DOM, perhaps, but not because of wasm.

>> At the end of the day, though, JavaScript is the language of the web.

> And when webassembly arrives that will be over,

I really don't think this is true. I certainly agree that JavaScript isn't the perfect language, but it's a _very_ popular language. Even on the server-side, where right now you already do have the freedom to use languages like Haskell, Python, etc, you see a majority of developers now opting for Node.js. Even for desktop apps and data scientists, it's the most popular contender (all according to the latest SO survey).

You can argue about reasons all you like, but I don't think the people using JavaScript on the web are doing so only because webassembly isn't easily available yet. I think they're doing so because, for better or worse, they genuinely want to be using JavaScript (or very closely related languages like TypeScript).

IMO I feel like it is going to be a challenge to integrate the GC of another language with the GC of the JavaScript/DOM, and if so we'll be keeping JavaScript going for a while.

WebAssembly doesn't have a GC, And I don't see any reason why the DOM should be subject to a JS GC.

Correct, but python (or haskell or java or whatever) running on top of WASM would, and there are plans to integrate WASM with the other GC's in the browser, however:

    "'compile the VM' strategies increase the size of 
     distributed code, lose browser devtools integration, can 
     have cross-language cycle-collection problems and miss 
     optimizations that require integration with the browser" [1].

My prev comment was speculative, but my point is that its not going to be a piece of cake to just drop another high-level language on-top of WASM and use it as a 'better' scripting language without having to pay some overhead costs, one being GC issues.

[1] https://github.com/WebAssembly/design/blob/master/FAQ.md#is-...

I don't know what is meant by "there are plans to integrate WASM with the other GC's in the browser". Is the idea that the browser runs a GC for DOM elements that is separate from the JS VM GC? I wonder if they could follow a model like operating system resources (e.g., file handles) where the process is responsible for managing the resource lifetimes. This would make resource management trivial, and running (for example) Python on WASM would simply mean emitting WASM instructions instead of x86.

Of course, lots of other problems remain, for example, downloading an entire runtime or "putting Python on WASM isn't going to magically make it fast". But I don't think the GC should be a particularly large challenge.

> webassembly.

is basically a better way to do ASM.js . How many Python,Haskell,Livescript have been built on top of ASM.js ?

Do you really believe you can make your users download 10s of megabytes of binaries each time they visit a website just to bootstrap a language? And i'm not even talking about the runtime...

Right now, the only viable languages for webassembly are the ones that don't use garbage collection and have a limited runtime, Rust,C and C++ .

We make our users download tens of megabytes of shitty unoptimized JS for tracking, ad networks, unoptimized images, autoplaying videos, and so on and so forth now.

Those aren't necessary for the site to function so you can use some sort of content blocker and still access the material. You're talking about downloading megabytes of data just to go through the door for your website.

And I can't wait for the rude awakening anti-JS developers have when they realise the vast majority of issues (particularly, performance) come from the DOM, not JavaScript. (And the first version of WebAssembly can't touch the DOM anyway)

If people start writing Python for the web for no other reason than they just dislike JavaScript we're going to be forcing users to download a dozen different runtimes, just because of developer preference. This isn't a good thing.

What would you replace the DOM with?

I honestly have no idea. It does so much that I don't know where you'd start - but I suspect that's also the problem.

I remember seeing a demo of React Canvas a few years ago - basically, recreating a "DOM" of sorts inside a canvas tag - and the performance was crazy. Beautiful 60fps touch interactions. But, of course, it only does a tiny subset of what the DOM does. I'm still waiting for a good reason to use it myself to try out how the API feels.

I feel the same. Dunno wth we gonna do but we need something more performant.

My complaints about JS have nothing to do with the DOM. Like weird `this`, no integer types, surprising type coercion rules, and so forth.

>we're going to be forcing users to download a dozen different runtimes

Why would users need to download a runtime, given that we'd have WASM as a compilation target for Python, the language?

We'll just have a Babel of dialects, pun intended. There might not be a technical reason for having JS, but there's a social one -- we've got plenty of people who call themselvs "JavaScript programmers", and people tend to be set in their ways to an awful degree.

I mean, on the backend, there's no ultimate technical reason why you couldn't switch -- the closest you can come to the browser situation is the limited PHP hoster of the early oughts -- and still we don't see a rapid progress away from awful languages. Just more people duct taping said languages into something slightly more sane.

We'll get the same for JS. It's the new Pascal/C in that regard.

> And when webassembly arrives that will be over, and Typescript will be deprecated. I can't wait for a better modern language like Haskell, Python, Livescript, etc.. built on top of webassembly.

Much of that is already possible and guess what, neither TypeScript nor JavaScript are deprecated.

To run python on WebAssembly you would have to compile the entire CPython executable, and every single dependency it has, into WebAssembly, then ship that giant executable with every page so you could then run Python code with it. You would then also most likely need a special library, which at some point someone will have to write or you'll have to write it yourself, to give Python a clean interface to the DOM. All of this together would be at absolute minimum 4.5 megabytes, which is absolutely unacceptably large for a frontend bundle.

WebAssembly is very cool techonology, but it's not going to deprecate Javascript because Javascript will be, at least for a very long time, the only scripting language that runs efficiently on the web, and also will always be the most well supported.

With WebAssembly you could write in any AoT compilation language that can compile on LLVM, but I, and many many other developers, have no interest in very low level languages like C, C++, or Rust in the browser, even though we acknowledge the flaws in JS. Maybe one day higher level languages besides Javascript will be practical, but that's a ways away.

> To run python on WebAssembly you would have to compile the entire CPython executable, and every single dependency it has, into WebAssembly, then ship that giant executable with every page so you could then run Python code with it.

I mean, that's kind of already the case when you want to ship a Python project as a stand-alone package to run on the desktop. Alternatively, I could see a method of installing runtimes into your browser like plugins so it doesn't have to be shipped over the wire every time. Not saying I'd ever want to do something like that, just that alternatives exist. Browsers are moving more and more towards VMs that transcend the context of a single synchronous request/response.

I could see the plugin system working, but we're years away from that. So saying JS/TS will be deprecated soon is still pretty incorrect.

But by the time you'll be able to do this, maybe most people have gigabit fiber and wifi. At some point in the future, a few megabytes isn't going to matter.

Just FYI, this has already been done with emscripten a while ago, and it does work. See: http://pypyjs.org/

>better ... language ... Python

ES5 was a dumpster-fire. But ES2015+ is an amazing language. You just have to take the time to systematically study it.

If you're choosing a language you'll spend thousands of hours with, you shouldn't use "initial learning curve" as sole criteria.

Amazing?

make an object:

in ESx:

  var myObject= {
  	a: {
  		b: {
  			c: {
  				d: 'some value'
  			}
  		}
  	}
  };

in Coffeescript or Livescript:

  myObject= a: b: c: d: 'some value'

now use it:

in ESx:

  console.log myObject.b.c.d			// crash, myObject.b does not exist

how to prevent?

  if ( myObject.hasOwnProperty('b') and myObject.b.hasOwnProperty('c') ){
  	console.log myObject.b.c.d		// undefined
  }

in Coffeescript or Livescript:

  console.log myObject.b?.c?.d		// undefined

I can write almost a book with too many of such examples. So, NO it's not an amazing language, I wrote for many years in it and it sucks all the way.

It's cheating a bit to indent the JS option only. I don't think:

myObject= a: b: c: d: 'some value'

Is really _that_ much of an improvement over:

myObject = {a: { b: { c: { d: 'some value' } } } }

especially combined with an editor that will match those closing brackets for you. And the reality is that if you have object literals that deep, chances are the inner values will also be large enough to justify expanding it anyway.

Also lodash plugs a large number of holes in the standard functionality. In most projects I work at, I'd write something like:

_.get(myObject, 'b.c.d')

for your second example.

Have you actually used Typescript? It's definitely better than Python, and I'd personally prefer it to Haskell / Livescript. I would love to hear what people actually think the "flaws" are with ES6 Javascript and Typescript, because they have been disappearing fast over the past two years.

WebAssembly will be great, but as a complement to Typescript, not as a replacement. I would love to import a native module for the small chunk of my code that needs to do heavy lifting. And I don't see any reason why the Typescript team couldn't eventually build a WebAssembly compatibility layer.

I'd take the experience of working with TypeScript over Python any day of the week. All the days really; every day.

Well, if we already transpile ES7 to JS then why not tanspile TypeScript instead because of all the added benefits?

Because eventually in a couple of years you can take your ES7 code and remove the transpiration and it will all work seamlessly. Not so much with Typescript.

M$ can achieve world domination again by making the already opensourced Chakra engine run TypeScript directly w/o the need to transpile. Goodbye ES7, hello ES6 soon to be ES7 optionally typed superset.

"Not transpiling" sounds like a marginal benefit, considering most apps are going to have a build step anyway.

Transpiling is going to stay, currently you transpile es6/7/typescript=>es5, later you will do es8/9/typescript=>es6/7, and so on, so this point is not relevant.

I meant it in the code's current state. Suppose the development stops or stagnates in a month or two. The product is complete. So you can remove the transpilation. Also we won't have to transpile current features in the future. That and code can go as is and have the benefit of native execution that it doesn't currently have.

TypeScript provides the same value as intellisense.

E: i didnt mean this as a criticism

It's a bit more than intellisense.

* find definition

* find usages

* auto import (never type "../../../../../dumb.js" manually again)

* er... types

What turns me off immediately about TypeScript (and examples in the article show it) is the use of the class construct. If I could see some examples of teams writing TypeScript without falling into the use of classes I would feel a lot better about it. I am in full agreement with Douglas Crockford and others that adding pseudo-classes to JS was a big mistake.

> I am in full agreement with Douglas Crockford and others that adding pseudo-classes to JS was a big mistake.

Why?

It's certainly not a requirement of TS, any more than it is in JS, and I've seen people writing large TS codebases without classes. Typically with a much more functional approach though. I don't see people writing many prototypical objects with TS. Is there a good reason they should be?

I'm curious as to why you don't like the use of classes. Are you against classes in all languages or just JavaScript?

A lot of people are into the "functional JS!!1!!1!!" hype and blindly dislike anything related to OOP with little information.

Also, TS does not force you into OOP. TS codebase itself does not have any classes.

I'm not against classes in other languages, especially those that follow a typical OOP pattern (i.e. Java, C#, etc.). See above for my reason re: JavaScript.

So appeal to authority?

I partially agree. Something to consider: Like the callbacks, prototypes are very flexible, so this flexibility comes at the cost of interoperability. When you have a standard way to declare classes, methods and meta data for them, this information is easier to consume from other libraries.

You could look at the TypeScript compiler itself, which uses zero classes.

Reply on news.ycombinator.com