[russellbeattie]

I'm really worried about the wholesale move to Typescript in so many projects. To me it's the new coffeescript combined with the verbosity of J2EE. Yes it's corporate sponsored, so hopefully will be maintained indefinitely - but I like JavaScript, and Typescript isn't JS.

What's worse is so many developers using their own slightly tweaked versions of JavaScript. I spent a solid day this week trying to get decorators and class fields to transpile reliably with as few dependencies as possible. It seems every project creates their own DSL that sorta-kinda is JS, then figures out a way to get it to compile and calls it a day. This sort of goes against the whole reason we have language standards in the first place.

Anyways, I admire Evan's desire to hold back on the need for decorators and class fields, but since he's developing the project in Typescript, I have little faith that any of the projects that use Vue will avoid them.

[kangax]

I agree that TS increases barrier to entry for contributors. However, it's very different from Coffeescript. It offers better program correctness via types whereas CS was mostly sugar. Libraries that (properly) use Flow/TS are less likely to have bugs and are safer to contribute to (you're less likely to introduce a bug) and that's a good thing.

[marcus_holmes]

Libraries that (properly) use {{insert anything here}} are less likely to have bugs and are .... etc

remove the (properly) and I'd give the technology some credit. Otherwise it's just "no true Scotsman" fallacy.

[manigandham]

Typescript is a strict superset of JS and everything is additive. You don't have to add a single character beyond normal JS if you don't want to, but can still benefit from the compiler providing intellisense and refactorings.

[linkmotif]

> To me it's the new coffeescript combined with the verbosity of J2EE

How is this the top voted comment on here? How does one go from Coffeescript/J2EE to TS? Coffeescript was... well... Coffeescript, a JS variant with better ergonomics. J2EE was a Java framework that also has no resemblance or connection to TS. What a bizarre comment but truly disturbing to see masses voting this up.

[marcus_holmes]

No, I get it.

As a JS dev, Cofeescript appeared to be nothing more than an attempt to make JS more like Ruby.

From this perspective, TS appears to be nothing more than an attempt to make JS more like C#.

Either way, both appear to be attempts to use JS's massive flexibility to make the language work more like another language, because people are more familiar with that other language. And in both cases, there's a familiar response of "please don't do that. Please stop complaining about JS because it's not like your favourite language. Please learn to use it properly instead".

I played very briefly with CS to see what the excitement was about, and haven't touched TS at all, because I enjoy JS. But with Vue moving there, I think I'm going to have to bite the bullet and take a look.

[peterkelly]

I suggest you give TypeScript a try. You might like it, you might not, but at least then you'll know. It uses gradual typing - you can use static types as little or as much as you like. It's not C#.

[marcus_holmes]

I'm writing the backend in Go, so static typing is not where the resistance is coming from ;)

It's more like separation of concerns. I want Postgres to take care of data integrity. I want Go to take care of type safety. I want to give Vue all the flexibility it needs to handle user interaction. I don't really want to care about types in the UI, because Go can sort out whatever it sends to the server.

If I have to start writing code in the browser to translate between Go structs and TS classes then that's a step too far imho.

[jbverschoor]

Try it before saying something like that.

TS is like swift, and it does not require type declaration. A lot is automatic.

[russellbeattie]

Coffeescript - like Typescript - is a non-language. There are no native VMs for either. They have to be transpiled to work. If you're writing in either language, you're basically using large DSL macros which pump out JavaScript. Think PHP for scripting.

J2EE wasn't just a framework, it was core enhancements to the Java language, which caused a ton of bloat. EJBs, JSF, annotations, XML configurations, etc. Very similar to Typescript's bloat it adds on top of JavaScript. (You can't argue that it's not all bloat, as the resulting JS it produces runs fine without it all.)

[linkmotif]

> a non-language

It has a BNF that’s different from any other language, so it’s definitely a language. A language isn’t defined by its runtime.

> Think PHP for scripting.

PHP is a language...

> J2EE wasn't just a framework

What language features did J2EE introduce?

> You can't argue that it's not all bloat, as the resulting JS it produces runs fine without it all

Yeah, just like C, which compiles yo machine code, is complete bloat.

[russellbeattie]

I love pedantic, stubborn techies. You asked how one goes from Coffeescript/J2EE to TS, as you apparently couldn't understand and considered it bizarre. I (and another commenter) explained what everyone else seemed to grasp that you couldn't, and now you're nit-picking simply to win an argument.

You're right, it's all just machine code in the end. Real programmers use a magnetized needle and a steady hand. You totally win.

[eksemplar]

I especially don’t get the ide support bit, because Visual Studio Code already does that for regular JS.

I think typescript is s mistake that most people will regret because it adds so much complexity to the process for so few advantages gained. I mean, we were predominantly a C# house, if anyone should be using Typescript it should be us, but we found it to be much less productive than JS exactly because stuff like prototypes becomes more complex and typesafety kind of gets in the way of the process when you’re not exactly sure what you’re making.

I don’t think it’s exactly coffeescript though, I mean, I just ranted about typescript, but it doesn’t get in the way like coffescript. Since it integrates sort of decent into JS, it’s not a horrible thing, we just found it unnecessary.

[james-mcelwain]

> I especially don’t get the ide support bit, because Visual Studio Code already does that for regular JS.

The IDE support in VSCode is at least partially driven by type declarations from TS projects, so regular JS is benefiting from TypeScript.

[eksemplar]

I didn’t say typescript was horrible, it’s just been unnecessary and unproductive for us. I think it does have a place in applications like VS code, because maintaining them is quite a lot bigger than most projects, and you don’t include VS code in yours.

[johnny22]

if you're not sure what you're making then just type everything you're spiking on with any or unknown?

[CharlesW]

> …I like JavaScript, and Typescript isn't JS.

Considering that you don't need to use it unless you plan on contributing to Vue.js itself, my (sincere) question is: Why does it matter to you?

[russellbeattie]

One always ends up going through a library or framework's source code at one point or another while trying to track down bugs. Using Typescript makes this a lot harder.

For example, I was going to contribute to the Visual Studio Code project with a simple tweak: A setting that would make global find key-command happen without have to click the search icon after. After asking online and then wading through the TS source code trying to get something to work, I finally just gave up. Typescript isn't JavaScript.

[jakear]

Did you try running the build script and working directly in “out/“? I doubt it would have been easier. Big projects simply take time to learn and contribute to, TypeScript or not.

Actually, I’d say VS Code would be much harder to contribute to without TS. You mentioned adding a setting. This requires touching several different methods (parsing, cleansing, etc.). With TypeScript, the compiler instantly tells you when you have forgotten to implement a part of the setting pipeline. With JS, the runtime gives you some “undefined is not a blah” error to track down.

[Too]

Type annotations strongest advantage is when diving into a new code base you've never read before. Can't see how it can make it harder to track down bugs. It does prevent monkeypatching so some "i'll just add a quick fix here" are going to be harder, and that is a good thing, otherwise you end up with spaghetti soup.

[sebazzz]

> Using Typescript makes this a lot harder.

Does it? I think type annotations makes it easier. It means you don't need to think less hard, which makes unknown code, which is always harder to read, a bit easier to read.

[mo1ok]

Yep, this is a huge problem in the ecosystem right now. The irony is that JS, an interpreted language, is becoming slower to compile than some of the newer compiled language (i.e. golang, which compiles to machine code and therefore avoids all compatibility issues).

[klodolph]

Golang doesn't avoid all the compatibility issues. On the contrary, there's a ton of Golang that won't run on anything but Linux.

[guessmyname]

> […] there's a ton of Golang that won't run on anything but Linux.

Please give examples so I can fix them.

Go code is highly portable to the supported platforms. In all my 5+ years developing code on Mac and cross-compiling for Linux servers, I can count with one hand the number of broken packages due to compatibility issues with the target operating system.

With my experience I am sure that I can fix the cross-compatibility issues in the code that you have had problems with, but I need names and/or links, please point me to them.

[klodolph]

I don't have examples off the top of my head, but I'll tell you how it happens.

* Use of cgo and platform-specific headers / libraries

* Use of golang.org/x/sys/unix, especially ioctl

* References to external utilities and files only typically installed on Linux, especially with os/exec, or use of GNU extensions in system utilities

* Inability to correctly handle paths on Windows (use of "path" instead of "path/filepath")

* Inability to correctly handle case-insensitive file systems

* Creation of paths containing characters illegal on NTFS, or with names that are otherwise illegal on NTFS (through the normal APIs)

* Deleting files or using deleted files in a way that works on POSIX but not Windows, this particular one is especially common because the mandatory file locks on Windows will bite you hard if you are used to the POSIX way of doing things

* Difference in semantics for filesystem change notifications. In JavaScript I can use chokidar and in Golang I can use github.com/fsnotify/fsnotify, but that doesn't change the fact that the underlying notification systems have radically different semantics. You can't really paper over these differences, you have to actually test your code on different platforms and make sure they work correctly on those platforms

Go code doesn't strike me as radically more portable than, say, Java, C#, or JavaScript. The fact that you haven't personally encountered problems often is good, but this isn't an indication that Go "avoids" portability problems. And compiling to machine code is not really a piece of the platform portability puzzle... it just means that you don't have to worry about having a different runtime version on your target.

The bottom line is that while Golang makes portability easier, for anything but relatively trivial programs (and "trivial" is getting larger and larger every day), your program is only portable as far as you have actually tested it on other systems. This is less work in Golang than it is with C++, and I'm really thankful for it, but it's not a radical change and it's not substantially different from the portability story that Node.js has.

[marcus_holmes]

I cross-compiled to Windows the other day for the first time (from Linux). It gave me a perfectly-working .exe in less than a second on my first try.

I love JS too, but I have yet to get Webpack or Babel working in less than a couple of hours.

[aczerepinski]

Can you expand on this? I’ve used a decent amount of Go packages and they all run as expected on my Mac.

[klodolph]

I expanded on this here: https://news.ycombinator.com/item?id=18116730

[ndnxhs]

Probably stuff that hardcodes paths like /tmp

[realusername]

Unlike CoffeeScript, you can't have any technical debt with TypeScript, if one day TypeScript disapears, you just remove the types and you have a perfectly working JS file.

[russellbeattie]

Really? This isn't even close to valid JS.

enum Color { red = 1, green = 2, blue = 4 }

namespace Color { export function mixColor(colorName: string) { if (colorName == "yellow") { return Color.red + Color.green; } else if (colorName == "white") { return Color.red + Color.green + Color.blue; } else if (colorName == "magenta") { return Color.red + Color.blue; } else if (colorName == "cyan") { return Color.green + Color.blue; } } }

* Edited with a better example.

[realusername]

enums are probably the only TS thing which does not exist in plain JS (at least I can't think of any other one), and it's quite easy to replace. In your example you just replace enum by a hashmap and remove all the types and it's a valid JS file, it's not really that different. It would be quite easy for an automated tool to do that.

[glitchdout]

It's not that simple because you can reverse lookup a TS enum. So:

    enum Color { Red = 1, Green = 2 }

would be the same as:

    var Color = {
      Red: 1,
      1: 'Red',
      Green: 2,
      2: 'Green'
    }

See for yourself: https://www.typescriptlang.org/play/#src=enum%20Color%7B%0D%...

But I agree with you, it would be quite easy for an automated tool to replace a TS enum with pure JS.

[realusername]

Ah that's a good point, thanks for bringing it. I did know TS enums supported that, I thought it was just some syntax sugar for a hashmap.

[jeremychone]

> new coffeescript combined with the verbosity of J2EE

- Saying that TypeScript is like CoffeeScript is almost equivalent than saying that CoffeeScript is like Babel.

- The only part that CoffeeScript and TS (and Babel) have in common is the transpilation step.

- CoffeeScript, Dart, ReasonML, ... are all about creating a pure/clean/elegant languages that use JavaScript as a runtime, and since JavaScript "bytecode" is "sourcecode", they transpile to it.

- TypeScript is all about adding Type annotations to JavaScript without removing or redefining any of the language structure. In fact, the transpilation step is mostly about removing TypeScript more than anything else. Besides enum, as mentioned in one of the comment, TypeScript does not add any language structure beside type related ones (another one is class fields, but coming soon to EcmaScript)

- J2EE (JEE and Spring in some respect) are frameworks, and not languages, and does not really have any comparison with TypeScript. They just encode what they see/saw as best practices/patterns into a set of APIs. TypeScript is a language (or language superset), and can support many different design patterns.

- Perhaps a better statement would have been "verbosity of Java," and while developers can use TypeScript to code JavaScript "Java-style", and bring a lot of the J2EE/Spring/JEE patterns to JavaScript/TypeScript, nothing in TypeScript force or even favor this approach.

- In fact, we use TypeScript to write more robust and maintainable javascript code following a "Functional first, OO/class as needed" style allowing our modules to expose simple and intent-driven APIs. Same signatures as if we were not using TypeScript, but now we know what comes in and what comes out.

- Thanks to TypeScript expressiveness and following our functional first and OO as needed code design, we migrated one of our Java backends to TypeScript/Node, and made the code 40% lighter, better typed, and much simpler and cleaner intent-driven module apis.

Btw, been there as well, where a couple of years ago I mistakingly classified TypeScript in the Dart / CoffeeScript category. I was misguided by the then tight "marketing" coupling with Angular, which I would describe (Angular) as the J2EE for Web UI, and my anti-Microsoft bias for open source project (which I rectified since).

Yes, there is a learning curve, but it is not that high (mostly on setup side), and the value back for any sizable JavaScript code is huge. Even for small projects, once you get the habit of including it, the value is great, especially for 3rd party api discovery.

Also, as a developer will finally drop IE11 support, Babel value will probably diminish, and TypeScript benefits will probably become even more noticed. TypeScript's cost of adoption for babel developers is relatively low since they already have a transpilation step.

(btw, class fields are coming to the JS spec, so this was very babelish of TypeScript to have added this support early on).