Anybody know a way to overcome JavaScript fatigue ?

@theScientist I can relate that you never worked with angular or node.. I love node but the poor syntax verification of js is a real overhead..

Use a good language

It's trying to turn a super-tanker. It has too much momentum right now. I think you might need to consider choosing a particular part of the whole ecosystem and try to learn it. I've no idea which direction to advise though. This expectation of being know-all in the JS space regardless of framework is becoming nonsense.

Use TypeScript. You will never want to go back.

Good ol' server side languages fatigue? .Net fatigue? No?

yeah typescript or http://elm-lang.org/

Elm has a imutable haskell like syntax that compiles into js html css. It inspired facebook to create react. And the js just works because it has one of the most usefull and friendly compiler.

TypeScript is stupid, and useless.

Have you seen what it compiles to? Straight JS without any type facilities, whatsoever. No checking types, nothing. You're literally just writing more code, that in the end gets taken out. What's the fucking point?

@nicholai assuming you are open-minded and not religious about your dev choices, I'll try to express the advantages I had from using it for 2 years:

1. When a project reaches a certain size and you have more than one developer on it, JavaScript tends to become "read-only". Hardly any developer really reads large documentation, and writing good documentation (and keeping it up to date) is hard.
Even if you have high unit test coverage, knowing if the changes you did will break any code down the line is not trivial, it's not uncommon for errors to face up in production.
Since TypeScript is "compiled", you can catch a lot of these errors during development already. It is considered the "first unit test".
2. Type checking and auto competition - having the annotations for the code you are using available right there as you type is such a workflow improvement. Have an options hash with 30 different options? No problem, you get autocompletion as you type. Can't remember what the option does?

[...]
You can go to the definition with the press of a button.
3. "Straight JS without any type facilities" - the beauty of it is that you can add semantics which are checked at compile-time without having to ship and execute them in production. Since JavaScript has no methodology of saying "this method needs a number and a bool" other than checking and throwing manually, what's the point of emitting it in JavaScript? Nothing prevents you from using prototype classes and instanceof (which were there from the first implementation of JavaScript, just used wildly wrong a lot of times).
The type declarations you wrote in TypeScript get emitted as a separate file tho, and can be comsumed in another project to get code analysis and completion there.
4. "You're literally just writing more code [...] that gets taken out" - Well, you do the same with a JS minifier, you would not name your variables as "a", "b" to use less bandwith of the users.

Maybe at some point you'll give it another try :)

@hawkes
1+2: I can't think of anything that TypeScript will catch for me that any linter wouldn't, XO eg. What are practical cases?
I have autocompletion using TernJS, and all functions are written using jsdoc syntax which is not hard to write or maintain, so documentation is easy and readily available. This is piece of cake with eg docblockr, so I absolutely disagree with this point.

3+4: theres a large difference in what you and i are talking about. Minification does not remove syntax. I don't think theres any beauty in it, when you still have to take care of all types manually anyways, considering user input et al. Its still more syntax that serves no practical purpose apart from aesthetics

@hawkes just went to read some more about typescript and just felt in love! achieve almost all what I was complaining about on js!