Echo JS 0.11.0

<~>
tracker1 917 days ago. 
I was looking at a recently posted article, and can't believe it, but was thinking to myself, this would really be easier to understand if they were using TypeScript for the code examples.

While I will often use bare JS myself, especially for quick and dirty usage or when I'm the only one touching it, I find the extra context for TS really helps when trying to conceptualize the use of systems from other developers, especially in blog articles.  I've also found it incredibly useful in terms of writing libraries to the point where I'll often prefer a TS based library just for the extra hinting, even if not using it *IN* a TS project.

What's your opinion on this?  As someone who really used to hate Flux and TypeScript (especially early versions), I'm surprised by my own change in opinion on this.

kali 917 days ago. link 2 points ▲ ▼
I'm going to reach for the classic: It depends. IMO it depends mainly on the quality of the code / developer.

If the code is good, the language doesn't really matter too much. If the code is bad, the language doesn't matter too much either.

Now, if you find some average code... then, in principle, sure, any additional information provided can help, and so will types. But then again, if the code is just average, the context provided by the added types will probably be of the same average quality. So, sometimes it will help, and sometimes it won't.

Mostly unrelated to this is the fact that as people have grown more familiar and knowledgeable with TS they've also -in general- improved the code they write with it. So, in a way, TS code you see today is *probably* better written than older TS code.
misan 915 days ago. link 1 point ▲ ▼
TypeScript is becoming more and more ubiquitous and I think that is a good thing. 4 years ago, I argued that valid JS is not valid TS, but TS has matured a lot since then.
I would also go as far, to teach new programmers TypeScript from the start, rather than JavaScript.
JavaScript involves a lot of guesswork or try and error if you know nothing.

How do you explain to someone that some DOM event _will_ have a special property they should consume? REPL-based programming is still a thing for trying out that kind of things and it helps greatly to learn about the return values (or types) of functions. But once you know what an event listener is, what you can attach it to, you really want to rely on signatures right off your editor. Code is documentation too, and TypeScript enables code to be self-documenting in a way. If implemented correctly, I don't have to try out functions but simply know what they do by looking at their signature, which means a great productivity boost to me.

We still have a large gap between the developers that sprinkle in JavaScript as additive for some special effects on regular websites or full-blown web apps that have devops baked into them. Think PHP in ~2010. There are still people using FTP to deploy their websites, so an extra build step comes with a huge up-front cost you probably don't want to pay.

In these places, usage of TypeScript is kind of a gray zone, as you cannot rely on completely automatic deployment.
Which is why I am looking forward for the type annotation proposal: https://github.com/tc39/proposal-type-annotations
MaxArt 915 days ago. link 1 point ▲ ▼
I definitely won't go as far as those TypeScript absolutists who refuse to use any package that doesn't come with TS definitions, but surely TypeScript has become a solid staple in my day-to-day job as a tool that alleviates my cognitive load.

It's true that IDEs nowadays can figure out a lot of stuff on their own from plain JavaScript, but TypeScript allows them to run a nice extra mile.

There's also a discussion inside the W3C about replacing IDL with TypeScript when writing specs.
tracker1 913 days ago. link 1 point ▲ ▼
This is closer to where I'm coming from... when referencing articles, or interfaces, TS has pretty much become the more ubiquitous standard.  I'm fine with plain JS, but TS makes things a bit more clear in typical use... especially when explaining certain interfaces and libraries to make return types clear, etc.