7 ms·
I'm pretty happy developing in TypeScript these days, it at the stage where its more than good enough for most tasks. Just like the JVM is more than Java, Java
by campers 10y ago
I'm pretty happy developing in TypeScript these days, it at the stage where its more than good enough for most tasks.
Just like the JVM is more than Java, JavaScript is the bytecode of the browser. There is plenty of languages which compile to JavaScript if you want a different style or expressiveness in your code.
https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffeescript/wiki/List-of-langu...
How good the tooling is (maturity, source maps etc) for other transpiled languages may vary a lot but there is still a lot of choice. I'll be sticking to TypeScript for now.
- gefh 10y agoTypescript is good, I also like the closure compiler. Both help enormously when a project gets beyond a handful of files. But there's still an onus on developers to actually structure their code and do some 'engineering'; a ball of string in any language is still a ball of string. Not js's fault.
- Hurtak 10y ago"There is plenty of languages which compile to JavaScript if you want a different style." I hear this a lot, but when you actually look at the list, there is not much to choose from. - Dart - not used outside of Google. - CoffeeScript - people are leaving this for ES6+, does not provide anything other than nicer syntax. - TypeScript/Flow - is just javascript + types. This is bad because it doesn't solve any of JavaScript problems and good at the same time because it is easy to introduce incrementally and there are 0 problems with interaction with plain JavaScript code). This seems to be good enough for most people, as you mention. - Elm - Second most promising ATM but not mature enough, you still need to fall back to JS for lots of the browser API. You need to buy into the Elm world 100%, simple stuff like creating an element and using JS library which will modify that element still requires hacks (my info might be out of date, last time I worked on Elm project was ~4 months ago). - Reason - Probably the most promising because Facebook backs it, but nowhere near production ready. At least it seemed to me last time I checked - no tutorials, even installation was not straightforward and required some consultation with GitHub issues. - the rest is in the toy/abandoned/not mature enough territory.
- chc 10y agoAre Scala and ClojureScript toys, abandoned or not mature enough?
- Hurtak 10y ago- ClojureScript I forget and it is good alternative, but it doesn't seem to be on the rise either - I have not seen anyone using ScalaJS - These two are probably fine alternatives to do frontend for Clojure/Scala shops, but outside of these circles, they do not seem to have much traction.
- iLemming 10y agoYou're wrong about Clojurescript. It's the most pragmatic and efficient language today that compile into JS. And it's definitely steadily growing.
- xiaoma 10y agoThere was another thing that CoffeeScript provides that I still missed a couple of years ago when moving to ES6/7 only projects. While ES6 provided a lot of conveniences from CS, like destructured params and a terser function syntax, it couldn't remove anything. I've never intentionally used JS == comparisons in any code I've written for work, but I've still had to deal with code written by others that did. CoffeeScript eliminates the possibility entirely by only having a == operator, and it works like a JS ===. Similarly, CS won't let you leak a var to global scope by forgetting to declare. Every variable is local by default and if you don't want that, you've got to explicitly set window.someVar. In short, compile to JS languages have the advantage of being able to eliminate foot guns rather than just tack on new features. ES2018 probably isn't going to get rid of any. Even extremely dangerous and mostly unused keywords like with will remain because of backwards compatibility concerns.
- Hurtak 10y ago'use strict' solves the forgotten 'var' and dangerous 'with' by prohibiting these parts of language. Also if you are using ES2016+ you are most likely compiling your code with Babel (to have more backwards compatibility) it will turn on the strict mode on by default.