Slashdot Mirror
Compiling to JavaScript: TypeScript vs. Haxe
lars_doucet writes: Released in 2012, Microsoft's TypeScript is perhaps the best-known "compile to JS" language, but it wasn't the first. One of the earliest was Haxe, whose JS target first appeared in 2006. In his illuminating article, TypeScript vs Haxe, Andy Li gives an excellent rundown of the two languages' various merits, but the bottom line is: "Existing JS developers will favor TypeScript as they are more similar in many ways. They can utilize their existing skills immediately. Non-JS developers with backgrounds like Java/C# or even from the functional programming world will appreciate Haxe more since it fixes a lot of weirdness of JS." The full article includes an excellent rundown of the type systems, syntax, scope handling, compilers, and overall language design philosophy.
Compiling to JS is like having a shit for dinner, you're doing it wrong.
> Which is the better compile-to-JS language? It depends
I'm glad I skipped to the bottom.
How is that web assembly project coming along? It seems like a perfect fit for alternative languages like this instead of having to compile to JS. I think it will be a nice day when developers can choose a web language based on its merits rather than its ubiquitous nature.
Irony: Agile development has too much intertia to be abandoned now.
The main thing I like about Haxe is that variable scoping in closures work like you would expect. Javascript has the weirdest system for closures. Not sure about TypeScript, never used it.
With that said, I typically write straight Javascript because come on, however broken, it's already a scripting language and how much more cruft do you want to add?! It's like fucking jQuery, blech. You're spraying perfume on shit. It just doesn't work.
The article is so good, it gets praised twice in the summary. Yet I've never heard of those languages, though I did know of "compile to javascript" contraptions and that at least half a dozen of those existed. So now these two are lodged in my mind as "ham-handed attempt at gaining mindshare by declaration of success" and "tries too hard to be the underdog". Neither a good place to be in. Welp, no reason to read this bit of stealth-marketing then.
If I had to compile to JS I like to think I could use emscripten, but not being involved in such a project I'm not sure how well it works. When it's supported by the browser, it's designed to strip away most of the layers of crap we've put between ourselves and the machine. IIRC, you can get half the speed of native C by running C compiled to JS this way. Once again though, the browser has to support it. I think in theory it can support any language that LLVM supports on the front end; but I think they've only tested it with C and C++.
Anyway, if you're starting a new project I don't see why you'd want to use a language designed just for compiling to JS when you could use something more general purpose that will potentially run very fast with the proper compiler.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
What about C/C++ and Unreal's scripting system all compiled to JavaScript? Epic has released several demos over the past couple years to show this off. https://www.youtube.com/watch?...
CoffeeScript is the best known and most popular, yes TypeScript probably comes second in these catagories.
New things are always on the horizon
I've been using Play with Scala.js (scala compiled to javascript) and find it promising.
I'd like to see a good GUI toolkit to abstract away the dom as well as Akka actors that work between the browser and server.
most people that think js weird are nazis. they think that there would be a perfect machine. in opose of common sense, cause most developers think in c, in other words, think statically. js is lower level than c and at same time higher level than c. and its not perfect, not because its not c. but its world wide.
Another one that came fairly early onto the scene was Objective-J, which allows programming browser contained applications in the idiom of Cocoa and Objective-C. I haven't really tried it myself, but it looked like a fun curiosity.
If it acquires resources on instantiation like a duck, then its a shared_ptr<Duck>
There are also PureScript, Scala.js and of course ClojureScript.
Its amazing that anyone would think worrying about how to declare arrays or for each loops are the big deal to web development with Javascript.
Everyone do yourself a favour and look at GWT and its zillions of features that help you solve and do the web right. Image sprites, embedding images via base64 where possible, abstractions over dom inconsistencies, support for differences for different browsers, auto css obsfucation and class name reference validation, and many many more things.
Let me know how much more effort you have to do to get half of those things as part of your experience.
I know this is going to get a lot of hate, but JavaScript is really not as bad as people make out. There are some stupid design decisions (mostly around scoping and built-in type consistency) but once you know what these are it is pretty easy to work with them. The main problem I think most people have is that it does not really offer any sort of hand-holding in terms of how you should structure your program. But in a way it is quite beautiful how you can create usable frameworks for OO, imperative, or functional programming with the same language. The problem I mostly see is that people get stuck with a poor design decision, but rather than having to re-factor their object structure (like C# would force you to do), they can just hack in a solution that breaks basically every principle of good programming imaginable. They then dump this solution on the world and declare it is because JavaScript sucks. The real issue is that they are bad programmers who came up with a poor design and then used the (somewhat excessive) flexibility of JavaScript to get them out of a corner. Same thing has happened in C/C++ for years.
I really don't think JavaScript should have become the language of the web, but competent programmers shouldn't listen to all the hate that gets spread around. It is a decent way to introduce yourself to a lot of new programming concepts if you've come from a static OO language background. Once you understand some fundamentals CoffeeScript, TypeScript etc are pretty straight forward and their applicability is obvious.
For what it's worth, if you are doing large programs then something like TypeScript can be very useful. The problem it solves is really an issue with dynamic languages in general though, rather than JavaScript. There are ways to create large maintainable code bases with a dynamic prototypical language, but sometimes the classic OO model just fits a problem better.
If you think this is would be a good thing, try Nim, formerly known as Nimrod. Abstraction level between C and C++ and it compiles to JS. Apparently carries less runtime baggage than emscripten.
... tells you all you need to know about how in-depth it is.
...but less powerful? Sounds like a winner to me!
Another re-invention of the wheel. No one liked JVMs running bytecode in browser applets, I see no reason why this will be any more successful.
What I want to know is how does Haxe compare to the javascript compiler in systemd?
Just cruising through this digital world at 33 1/3 rpm...
Any insights on RedHat's Ceylon project? http://ceylon-lang.org/
The 3D modeling app- http://formit360.autodesk.com/app/ is done with Emscripten.
How is webasm different from Java?
There are newer, better ways to generate JavaScript using all the goodness of developing using Java language features
One such tool that it good for this is TeaVM:
http://teavm.org/