Hacker News Reader

Comment by mreiland | Hacker News Reader

I'll never understand why people don't just use javascript.

I kinda agree - Coffeescript in particular seems like putting extra weight/overhead into the process for very little other than cosmetic gains over JavaScript. Whatever problems JS may have - I don't really feel that CoffeeScript addresses them. It addresses the fake problems (IMO).

TypeScript and related make a lot of sense for very large projects/teams because static type checking can be VERY useful, and the lack of a statically typed language choice for in-browser programming is a large weakness of the web ecosystem. So TypeScript is a tremendous advantage to have in the toolkit, and a much saner approach than older heavy-weight options like GWT.

GWT still has a major advantage in that you write the server in the same language as the client (Java). Indeed they are the same code base and can share code, classes, etc. I have yet to see an alternative with such a strong server side component to it.

Because it's really hard to build, test and maintain a non-trivial application in a dynamically-typed language like JavaScript.

I think it's telling that a lot of companies with the most mature products (Facebook, Dropbox, Asana) eventually resort to optional static typing in their products, whether that means extending their runtimes (e.g. Hack) or using a transpiler like TypeScript.

The implicit conversions and "we'll just randomly give you undefined to propagate ondwards" stuff is a much bigger source of bugs in JS than dynamic typing. Picky dynamically typed languages like Erlang or Python will pretty reliably produce an error/exception at the scene of the crime. (More so than C/C++!)

(Also I don't think optional static typing has gotten off the ground in Python land, or adopted in production at Dropbox?)

Dropbox Paper is written almost entirely in TypeScript.

What is it telling? It might just be telling that everyone is doing what you're doing here, and looking at each other to see what they should do. Another name for this is "fashion."

Well ,because Typescript makes a huge codebase easier to read and maintain (though ES6 is a huge improvement, no question)

I used to use Coffee Script, which I still like, but ES6 clearly made Coffee Script less relevant. Typescript value is clearly in the type annotations and the support for ES6 ...

Another problem with Coffee Script is the fact that it evolves way to slowly and it is unlikely to support most of ES6 features because its core maintainers are clearly not interested in adding significant features. In fact that the main issue for me. Both Backbone and Underscore suffer from the same issues.

> ES6 clearly made Coffee Script less relevant

I see that a lot and find it highly subjective. I don't find es6 useful at all and will stick with coffeescript for the foreseeable future but that also has to do with my reasons for using it.

In this case: because they want type enforcement. This removes a category of errors that - in a complex app - can be really annoying.

Better - it removes that ability for deliberate bad behavior by devs.

That said - I prefer JavaScript + Flow as thats a much more native solution which means you don't need to learn a pseudo language first.

Typescript isn't exactly a pseudo-language. It looks just like JavaScript with Flow annotations. In fact, Typescript is intended to be JavaScript + Type Annotations, so it's just as "native" as JavaScript + Flow annotations, with the addition of some Babel-style ES6 transpiling as well. The only difference is the explicit build process versus running the transforms in browser, and I've seen projects use the Typescript compiler (itself written in JS) as their in-browser transpiler (SystemJS supports it as a first-class transpiler option alongside Babel and Traceur, even).

> It looks just like JavaScript with Flow annotations.

It looks close to that, yes. However Flow can be also implemented via comments to native JS so... TS can't do that.

In which case...

> it's just as "native" as JavaScript + Flow annotations

is wrong. TypeScript requires a transpilation step. Flow doesn't. It can do, but it's not required.

I may have been a little harsh with the "pseudo-language" but I'm not sure what else to call something that is designed to be transpiled into the right language. It's not higher-level, it's sort of... a companion language I guess.

You can write TS and put the type definitions into a separate file, so you don’t need a transpilation step. I am using this at the moment.

This comment would be more useful if you made an actual argument. But to imply that you can't comprehend any possible gain for using another language that overcomes the downsides (which you don't specify) isn't constructive.

I like pure JS over CoffeeScript (and other something-to-JS solutions) because:

- Writing JS gives me a better feel for how the language actually works

- I like the line number in the JS I'm debugging to equal the line in my source code

- There's less magic to understand & deal with

- CoffeeScript automatically returns the last line of a function, and I don't always like that

> - Writing JS gives me a better feel for how the language actually works

Only because you know it better...

> - I like the line number in the JS I'm debugging to equal the line in my source code

Source maps.

> - There's less magic to understand & deal with

https://medium.com/@c2c/nodejs-a-quick-optimization-advice-7...

> - CoffeeScript automatically returns the last line of a function, and I don't always like that

Use explicit return then.

Well when you pretend that Coffeescript is just another language (like Java, or C#?), then it does become difficult to understand my statement.

Fortunately, most everyone else seems to understand what Coffeescript is, and thus they were able to grok my meaning.

I have the same feeling. When I was a less experienced programmer, I found coffeescript to be a great tool for helping me to write 'better-looking' code while avoiding the 'bad parts' of javascript. Later, I decided to focus my expertise on javascript, learning its imperfections and beauties. Reading through parts of the sourcecode for Node.js and the popular Express.js library, I became more comfortable writing pure javascript. It now seems to me like a much more practical solution to just learn javascript and stop trying to write in a different language than the one used by the runtime

I don't know very many people who write server-side code in C or ASM, so "stop trying to write in a different language than the one used by the runtime" doesn't seem to be a very popular rule outside of the JS world either.

But then you wouldn't have a complicated build process to run, allowing free time for web surfing.

Because the tooling you get when you start using a statically typed language is superior. In a massive JS application things become a lot easier to refactor when you start using Typescript.

Javascript is a typed language.

and that type is the string.

    > 3 == "3"
    true
    > 3 * "3"
    9

In the above case, Javascript is coercing the strings to numbers.

=== does no type coercion. You can also coerce types manually. JS is not statically typed, but it is typed.

I defer to Wikipedia's definition:

> A language is typed if the specification of _every_ operation defines types of data to which the operation is applicable, with the implication that it is not applicable to other types.

For a language to be typed, both the data must have a type and the operations must have a type specification.

    > "a" * "b"
    NaN

In a dynamically typed language, that specification is enforced at runtime.

    > true / false
    Infinity

In a statically typed language, that specification is enforced by a compiler.

    > setInterval(function(){ console.log("hi") }, "later")
    > hi
    > hi
    > hi
    > hi
    ...

As far as I can tell, JavaScript doesn't concern itself with any of that. It's not typed.

See step 10 and onward of: http://www.ecma-international.org/ecma-262/6.0/index.html#se... (for example)

Javascript is typed, it just makes a lot of crazy decisions about what operations an operator does.

You are a bit confused. The == operator specifically does implicit type conversion. You want to use === to avoid implicit coercion. And you always have the option to explicitly coerce type, as I explain below.

Javascript's type coercion leads to some wacky things like

> [] == []

> false

But it's actually all perfectly consistent once you understand what the compiler is doing with type (and JavaScript is compiled, not interpreted). == is an operator that will always try to coerce its operands to numbers, but the way it gets there can be circuitous.

You can specify type in JavaScript and avoid implicit coercion, you can use type constructors (generally worse) or certain unary operators. Ex:

> var foo = "12"

> var bar = +foo - 5; //+ explicitly converts foo to a number

Sorry, I meant statically typed, I always misuse that bit of terminology when talking about JavaScript, thanks for correcting me.

Compiler error catching is a big bonus for me.

Too weakly typed (pre ES6) for big codebases.

ES6 doesn't have static typing either.

People did but now that there are better languages that transpile to it and are just as readable and using plain javascript is kinda silly. TypeScript is a superset of javascript so if you're not using it you better have a really good technical reason.

Reply on news.ycombinator.com