Compiling to JavaScript: TypeScript vs. Haxe 94
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.
Dear lord why (Score:4, Funny)
Compiling to JS is like having a shit for dinner, you're doing it wrong.
Re: (Score:1, Flamebait)
Compiling to JS is like having a shit for dinner, you're doing it wrong.
Denigrating JS is like having shit for brains, you're doing it wrong. FTFY.
Re: (Score:2, Insightful)
Oh come on. Shitting on javascript is timeless.
Re: (Score:2)
Re: (Score:1)
No, supporting a poorly designed shit language used by shitheads to write bloated shit is rather shitty of you
Re: (Score:1)
You really don't have any concept of why there is javascript. Oh, I forgot - this is slashdot, where you're not a "real" programmer unless you use language XYZ. Fuck off Slashdot, you're all just putting your ignorance on display.
Re: (Score:2)
There is Javascript for the same reason there is Visual Basic and PHP, to empower dullards and dimwits to be added to payroll rather than quality developers
Re: (Score:3, Insightful)
How is this post marked flamebait but not the first original one?
Javascript is proving to be one of the most widespread and widely adopted runtimes in the world.
It is cashing cheques that java's ego wrote out.
Compiling to JS is in fact the way most strong typed addicts are able to write javascript without losing their sanity.
Mod Anonymous Coward down to flamebait and leptons to informative please!
Re: (Score:3)
Compiling to JS is like having a shit for dinner, you're doing it wrong.
What are you talking about? 50 million flies can't be wrong.
Re: (Score:2)
Re: (Score:2)
We're talking about JavaScript, not Windows. :P
Hey, I was joking; people often make ruder jokes about things they are fond of than about things they dislike. I like Javascript, but I'm not deeply convinced about the merits of compiling something to Javascript. Of course, this sort of idea isn't unknown in other languages, from C++ 'compiling' to C, or C to assembler, or diverse pre-processors like pro C/COBOL/FORTRAN etc - or for that matter IBM's HLASM. They have their place and offer some convenience, but they are not highly relevant to me.
And don't s
Re: (Score:2)
I've spent many happy hours watching people struggle with Windows, while I buzz along on my Linux system.
And I get paid big bucks to fix Windows problems between the keyboard and the chair at my job. Now that's job security.
Compile to JS vs WebASM (Score:5, Interesting)
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.
Re:Compile to JS vs WebASM (Score:4, Informative)
What's actually wrong with Javascript as a compile target?
Where to even begin... maybe the fact that Javascript doesn't even have integers? Or that (other than in asm.js) it doesn't support C-style malloc/free heap-based allocation? Or that (again, other than in asm.js) the runtime is garbage collected? Or that it doesn't properly support threads (a huge deal given the demands of modern computing), or sharing of memory between WebWorkers and the main thread?
Sure you can argue the problems with the language itself but when it's a compile target all of those are abstracted away, the thing that is important then is speed. And it's not exactly slow, could it be faster? Most likely. Does it need to be? For most cases probably not.
Javascript wastes petawatt-hours of energy per year across the globe due to its computational inefficiency. That means your power bill is higher than it could be, your phone battery doesn't last as long as it could, and polar bears are dying in the Arctic because Javascript has been deemed "efficient enough".
UI latency irks our subconscious. Once we have native WebAssembly support in browsers, and a significant percentage of the major websites have moved across to compiling from better languages into WebAssembly, those new sites are going to feel amazingly snappy, and people aren't going to want to use old Javascript sites, because they'll feel janky.
Re:Compile to JS vs WebASM (Score:4, Insightful)
Once we have native WebAssembly support in browsers, and a significant percentage of the major websites have moved across to compiling from better languages into WebAssembly, those new sites are going to feel amazingly snappy, and people aren't going to want to use old Javascript sites, because they'll feel janky.
Aaah you are in good fooling this morning, sir!
Given that (a) computers have got vastly faster and (b) javascript engines have got vastly faster and (c) websites keep getting slower and slower, I somehow suspect that the future is not going to be a bright one like the distant past where UI lag was a rare thing.
Here's another thing that irks me. The old "obsolete" X11 style was to have sub-sub-sub windows for damn near everything. Every UI element was in it's own subwindow. Subwindows were on the server, so when you clicked the mouse, it knew which subwindow you hit and sent that message. The modern, not "obsolete" style is to have one window and use pixel addressing.
The former works much, much better in a world of UI and network lag. The common latter means you have the lovely thing where you press, the UI jumps and then processes the click afterwards so you hit the wrong place with sometimes hilaroius concepts.
What's kind of funny is the web is slowly slouching towards a dubious re-inventing of the past 50 years of computing without bothering to learn anything about the old mistakes.
Now I'm going to go back to poking badly documented registers on 4k 8051 microcontroller because frankly the web "technologies" makes that pile of insanity look good.
Re:Compile to JS vs WebASM (Score:4, Interesting)
What's even worse is that people are piling up layers after layers without really caring about bug ratios and error tolerance. It's like building a skyscraper out of parts that all have a little bit of structural damage and saying each time: "Nah, that little hairline crack won't matter. I'm fairly confident that the whole thing will hold."
Re: (Score:2)
"Nah, that little hairline crack won't matter. I'm fairly confident that the whole thing will hold."
I mean if you plaster over the crack after filling it with chewing gum, you can't see it any more, so really, who cares?
Re: (Score:2)
What's kind of funny is the web is slowly slouching towards a dubious re-inventing of the past 50 years of computing without bothering to learn anything about the old mistakes.
And this has been true of every technology change - from hardwired to microcoded computers to IC-based machines to microcomputes to SoCs, from mainframes to minis to workstations to PC's to phones and tablets, from Lisp to Scheme to Clojure, from Algol to Simula to Java, from standalone programs to client-server to web to Web x.y. Th
Re: (Score:2)
That's indeed a problem.
Those aren't problems. Shared memory concurrency is hard, and we don't want the resulting bugs in our browse
Re: (Score:1)
Or that it doesn't properly support threads (a huge deal given the demands of modern computing), or sharing of memory between WebWorkers and the main thread?
It does properly support threads -> www.hamsters.io , and ES7 is introducing sharing of memory, although why you would want that vs using transferrable buffer (read pointers) is beyond me as it only introduces race conditions.
Re: Compile to JS vs WebASM (Score:3)
Once we have native WebAssembly support in browsers
...six months after Linux wins the desktop war... In the mean time, for those of us who need to deliver solutions today, Typescript makes Javascript palatable.
Re: (Score:2)
Didn't we already have a compiled weblanguage? (Score:2)
How is webasm different from Java?
Re: (Score:2)
Re:Compile to JS vs WebASM (Score:5, Informative)
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.
WebAssembly is not currently a suitable target for Javascript compilation, because it lacks a garbage collector. Only languages that can base themselves on (the equivalent of) malloc/free can currently target wasm. Eventually garbage collection facilities will be provided, but they're not on the immediate drawing board, and even once garbage collection is possible, it's likely to be a long time before JS->wasm approaches the performance of v8 or similar. (Note that asm.js doesn't do garbage collection either.)
The nice things about wasm are (1) it gives the creators a chance to re-invent the web runtime from the ground up (e.g. native threads will be there almost from the start), (2) languages can evolve independently of the web platform, and the web platform becomes language agnostic, and (3) *all* the major players are fully on-board.
One of the nicest features of wasm, in my opinion, is that the intermediate representation is an AST of expressions to be computed. This is a far more sensible and flexible IR than some stack-based or register-based VM bytecode system. My prediction is that wasm will become the preferred compilation target for desktop/server applications, not just web applications: the same toolchain will be used to generate binaries for running in server containers as well as within a browser.
Re: (Score:2)
If you rely on a garbage collector without taking at least the same precautions that someone using malloc/free explicitly then it is very likely that you program takes three times the memory it should do and probably is bloated shit.
Obligatory reference to Colbert [imgur.com]
Re: (Score:2)
So in other words its like java bytecode... (Score:2)
...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.
Re: (Score:1)
Don't underestimate freedom. The only reason javascript is popular is because every browser has a javascript vm built in. Java was never built in to any browser. Being "built in" is a huge difference. This is not a reinvention of the wheel. It is improving the wheel by removing some of the restrictions of use.
Re: (Score:2)
Re: (Score:1)
Funny, when Java was originally released I was only 16 and I read about this "bytecode stuff". For a while, I actually thought it was a compact, syntactical representation of the original Java program code (with comments, variable names etc. removed or replaced by numbers etc.). It seemed to me that would be the optimal way to get fast native code, since as little information as possible is thrown away, meaning that the compiler can better see the high-level constructs and find a good implementation in nati
Re: (Score:2)
I agree that the fact that all major players are on board is a plus. That said, this is something we will sadly not be able to target for at least 6 years IMO. The most notable issue being the release cycle of Internet Explorer. If they decide to support their old platforms well, things could go faster. But the fact that we're still stuck with support for IE8 (or were until recently) is due to the fact that it's the newest IE for Windows XP, nothing else.
Re: (Score:2)
Re: (Score:3)
Here are my 2 cents on this "web thing":
The language doesn't matter, the framework matters. I couldn't care less which language I use as long as the APIs are reasonable. But if I have to start considering abhorrences like HTML, encoding data into URLs, "cookies" and dealing with the intricacies of client/server responses, then my reaction is "no, thanks" - unless I'm forced to use the framework anyway.
In other words, your language could be the shittiest possible and I'd still be fine with it as long as it a
Re: Compile to JS vs WebASM (Score:2)
"when developers can choose a web language based on its merits rather than its ubiquitous nature." If it's not ubiquitous you don't put it in your site, full stop.
Re: (Score:3)
Re: (Score:2)
*sigh*
ECMAScript IS Javascript. So what you're saying is Microsoft's compile-to-javascript tool is starting to define javascript itself.
You don't see a problem with that?
Re:eeeeeexcellent (Score:4, Informative)
Microsoft have also, quite suddenly and inexplicably, become extremely open about the development process of some of these newer open source projects, and they are working with, and responding to, other key players in the open source ecosystem. (Google adopted Typescript for Angular2, and Microsoft merged Angular's "AtScript" extensions into Typescript, and made Typescript a strict superset of ECMAScript 7, in order to satisfy Google's requirements, and to make Typescript a better player in the Javascript world. Microsoft was a key presenter at, and participant in, ng-conf 2015. etc. etc.
Re: (Score:2)
Typescript is, quite shockingly, actually really, really good...
No shock really. I always thought C# is a good language, much better than Java. People have been burned by Microsoft non-standard extensions in the past; maybe it's different now. But everyone will be extra cautious.
Re: (Score:2)
The OP clearly said it was a "superset" of ECMAScript... meaning it adds more than what is in the standard but implements everything in the standard (which strictly isn't true, because it doesn't implement everything, but it does its best to not conflict with anything). Technically JavaScript is an implementation of ECMAScript (just like JScript was), but what the OP is saying it is true. TypeScript is having a lot of sway in TC39.
Re: (Score:2)
Virtually nothing of TypeScript gets or will get incorporated into ES anytime soon. There's barely any significant strawman TC39 proposals based on it.
The ES testing ground is Babel, where the new stuff is now being tested, and the tip of the community has aligned. TypeScript is playing catch up with it at best in term of standard EcmaScript features, and backtracking to match ES6 (eg: recently for the module syntax). It's also quite anemic in features, aside for the type system, which has pretty much zero
If I had to compile to JS I'd look at emscripten (Score:4, Interesting)
If I had to compile to JS I like to think I could use emscripten [github.com], 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.
Unreal Engine (Score:2)
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?... [youtube.com]
TypeScript best known ? (Score:2)
CoffeeScript is the best known and most popular, yes TypeScript probably comes second in these catagories.
Re: (Score:1)
Re: (Score:2)
But still sucks. Actually all those mentioned compilers suck... and that's because javascript sucks, and you need to change the language to something that is at least strong typed (java, c#, python, ...)
so you're left with something like: GWT, DuoCode, Bridge.NET...
Re: (Score:2)
Python is absolutely strongly typed. It's just not statically typed (variable names declared in advance with specific types). steve = 3 followed by steve = 'House' is perfectly fine due to dynamic typing, but if you follow that with bob = steve + 3 you get an error because steve is a string object, and adding a string object and an integer object together is not supported, and python makes no attempt to convert the type of steve or the type of 3 to force it to work.
Re: (Score:2)
"most people that think js weird are nazis"
And people who compare trivial dislikes with nazism are silly little kids with no clue about history.
"js is lower level than c"
And in your case no clue about what low level means either. Go on, amaze us. Tell us some low level functionality that JS can do that C can't. Please bear in mind that most javascript engines are written in C/C++. Just thought I'd let you know that before you make a complete idiot of yourself.
Fairly early on the scene (Score:2)
Other languages targeting the JS runtime (Score:2)
Not that bad (Score:5, Insightful)
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.
Re: (Score:1)
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.
If that was the problem then people would be complaining a lot more about Lua, which leans way harder on the 'no hand holding, build it your way' thing than JS does.
Re: (Score:3)
For example, how else would one do any kind of dynamic page manipulation? Yes, JS has flaws, but it works fine for what it does. It was never meant to be used to create huge, enterprise applications...I mean, who would write (for example) a medical billing application in JS? No one, because there are better languages for that. But for client-side page manipulation and cal
Re: (Score:2)
Yes, JS has flaws, but it works fine for what it does. It was never meant to be used to create huge, enterprise applications...I mean, who would write (for example) a medical billing application in JS? No one, because there are better languages for that.
And yet there's Node.js, which is JavaScript on the server side.
Re: (Score:2)
And yet there's Node.js, which is JavaScript on the server side.
Yep, I've played with it, and if there's something it can't do I don't know what it is. It's powerful. There's also webkit core which can do some great stuff, but still...I wouldn't want to write anything seriously complex in it. That's probably just my preference. I suppose there really isn't any reason why you couldn't/wouldn't/shouldn't.
But for client-side stuff javascript seems to be about the only commonly-supported means of getting stuff done. (Yes, there's Flash, but that has its own baggage as w
Re: (Score:2)
Agreed, JS is far from a terrible language, just the few nasty bits you have to work around (and there' have been accepted workarounds for years).
That said I tend to use Typescript now since its a smaller cognitive leap to TS from my strongest language skill.
Re: (Score:2)
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.
True. I write straight machine code for the self-same reason; flexibility of writing expansive and divergent frameworks with none of the pesky hand-holding. It's so beautiful!
OTish: same lang to write an OS and website logic? (Score:2)
The real question is... (Score:2)