The problem is that when the base language has such limitatios and funky semantics, how should languages which target that be able to deal with that in 1) standard 2) predictable 3) efficient way?
This is the reason CPU instruction set architectures are so simplistic and "low level" and don't really do things for you -- because if they did, targetting such a CPU would be a major pain with all inefficiencies due to workarounds due to funky and incompatible features.
That's a fair criticism, but it needs qualification. JS doesn't have an integer type currently, but engines can be smart about using integers behind the scenes for efficiency.
In terms of your ability to use them explicitly there's asm.js, typed arrays, and various proposals like value objects for the future.
One of the endearing qualities of web design and development was how the source was open for everyone (HTML, CSS and JS). Developers could read the code, understand and remix each other's work. This helped in its rapid growth from a design platform to an application platform.
Enter asm.js, where the source code is as readable as a compiler's assembly output. Once again we are back to code that is hard to hack and improve. Sort of similar to the days of Flash except that entire applications are being built on this platform.
It might be a great end user experience, but it is not the best way forward for web development.
No, it's roughly as readable as decompiled executable, without even a symbol table to provide semi-readable names. John Resig has a somewhat reformatted example a couple of pages into this: http://ejohn.org/blog/asmjs-javascript-compile-target/
To be fair, you can generate asm.js with quite readable names (use -g in emscripten for example). asm.js does not require that you also minify variable and function names (and whitespace), that is orthogonal, and done on all JS these days anyhow.
If you do not minify the output, then asm.js's readability is somewhere in between x86 and C. It's far easier to understand than x86, but it is still definitely less readable than handwritten C because it's machine-generated and optimized.
I'm not following you. Are you referring to the minimized code that has been beautified? Of course it is not going to be particularly legible. Same for any minified code, asm.js or not.
From the link you gave, the DiagModule function is asm.js, and every bit as readable as C.
Sorry, I was unclear. In this context, which if you follow back up to arocks' post is in the context of using "View Source" to learn how things are done, I'm referring to the sort of asm.js that comes out as a result of compiler output, not stuff written by hand. The Gist is what I was pointing at. There is no way you're going to read that and learn how, say, the Unreal Engine port does something.
I think people may think I'm trying to be faintly critical, but I'm not. It's just the nature of the beast.
> I'm referring to the sort of asm.js that comes out as a result of compiler output
That Gist - what is visible from "View Source" after beautification - is not compiled asm.js code. It is not the result of any compilation. It is the result of minification. Most minified code is as illegible as that.
Yes, it is. (Perhaps not entirely, but it's generally what you're going to find in the wild.) Read under the Gist for the bullet points. It may be minified, but that's not what makes it impossible to understand.
Hand-written asm.js code is not going to be the norm, for the forseeable future, for a variety of reasons. The rules for the grammar are difficult and tedious to manually write. The fact that everything runs in a massive array, so you've got a lot of memory management to write, is going to be a problem. The existence of numbers like 1384465 and 4980736 is what makes that particularly hard to read. Most asm.js code on the web is going to be incomprehensible; the examples you can read are the exceptions, for didactic purposes, not the rule.
Wow. No, it absolutely is not. I have no idea what you could possibly mean by "not entirely" compiled.
>The rules for the grammar are difficult and tedious to manually write.
There's nothing difficult about the syntax. It's a subset of javascript.
> The fact that everything runs in a massive array, so you've got a lot of memory management to write, is going to be a problem.
No more difficult than managing memory in C.
> The existence of numbers like 1384465 and 4980736 is what makes that particularly hard to read.
The lack of meaning for those numbers is what makes it hard to read. It wouldn't matter if 1384465 were 2 or "a". It's been minified, so the meaning has been stripped away. I agree that it is hard to read, but it's not a result of using asm.js, it's a result of minification and auto-generating code. There's nothing inherently illegible about asm.js.
> Most asm.js code on the web is going to be incomprehensible; the examples you can read are the exceptions, for didactic purposes, not the rule.
Sure, just like most javascript on the web is incomprehensible, by virtue of being minified or auto-generated.
No, asm.js is not readable, and doesn't look like C nor even typical JS.
Due to very limited set of expressions available it's too hard to write by hand (e.g. no objects, casts required everywhere, one flat array representing memory), so all non-trivial asm.js programs are spit out by compilers that treat it like assembly and preserve very little structure of source programs.
This Q/A from the asm.js FAQ appears to disagree with you:
Q. Is asm.js a new language?
A. No, it's just (a subset of) JavaScript. An asm.js program will behave identically whether it is run in an existing JavaScript engine or an ahead-of-time (AOT) compiling engine that recognizes and optimizes asm.js—except for speed, of course!
Also, the examples in the spec are completely legible. It looks much like C, in fact.
Does it matter anymore, though? Back in "the day", documentation was poor and nobody knew what they were doing. Document is massively better now. Javascript libraries abound, perhaps to a fault. Does anybody learn how to program the web by looking at other people's work now?
In those rare cases I've done this in the last few years, the sum total has always been to find out which CSS property or JS function I didn't know about was being used, and then simply pop that into Google. I certainly didn't stare at their code for any longer than that.
Wow, I'm still a relative newcomer, but I constantly pull up the CSS and JS for any site that seems interesting. Considering how easy Chrome devtools makes it to play around with sites, I figured most enthusiasts/professionals were doing the same thing.
Agreed, but there are numerous alternatives that compile easily to assembly without ridiculous amounts of set up and prayer. We can program in C, C++, Python, Ruby, Java, any number other languages that will ultimately all be executed in the exact same fashion, barring some technical differences.
This does not exist for Javascript. You can jump through hoops to compile other code to Javascript and hope that it works and works acceptably, that's it.
Javascript isn't assembly, it's the only language and it's terrible.
Isn't this what asm.js attempts to provide?
With mature tooling it should be possible to code in whichever language and compile or run on top of a VM which itself runs atop asm.js without having to worry about the underlying JS much at all (unless you want serious optimisation).
It wouldn't surprise me if we eventually come full circle and discard the DOM entirely. Each web application is just a giant <canvas> with QT or something compiled to JS providing the UI elements.
> It wouldn't surprise me if we eventually come full circle and discard the DOM entirely. Each web application is just a giant <canvas> with QT or something compiled to JS providing the UI elements.
The shocking thing is that we are almost at a point where a solution that sounds as stupid as that is actually less contrived and complex than the current mess.
From a non-expert, but avid observer, this looks like where things are going. I support Mozilla, but wonder if this is a Hail-Mary pass, with something like Dart and Web components being the 'engineered' approach.
At this stage, if asm.js is to succeed, they need to show how us mortals can use it. I.e. it needs to part of a complete toolchain, or an ide.
asm.js using qt (without hacks) would be amazing. How do I help (when I can hardly wrap my head around it)?
How so? That's how programs were written back in the day(and some still are, see for example Demoscene), which arguably were somewhat simpler than what we have these days(but that's more because of vast libraries than languages, imo).
The awesomeness of assembly language is that it's perfectly exact, deterministic and thus very predictable and efficient. No unnecessary indirection unless you build it yourself. No implicit type casting(infact, no types at all). Nothing. Just plain instructions with very specific semantics to build from.
Now how does JS(or even asm.js) fare with it's tons of indirection and ambiguous implicit typecasts compared to an actual assembly language? From a technical standpoint for a compile target the comparison is embarrassingly unfair, but hey, this is something which is supposedly "OK" and acceptable, right?
The ambiguity comes from the diversity and complexity of modern platforms, nobody would seriously consider using x64 assembler to write a modern application from the ground up.
I'm not an arbiter of what makes things popular, but from what I can see, Node's popularity has more to do with the fact that front end guys no longer have to learn a new language to work on the back end.
No, it's not, and it's certainly not OK. Javascript is a quirky interpreted scripting language created for scripting minor workflow events. It's an afterthought by Netscape, duct-taped to a bundle of silly hacks, wrapped up in some interesting attempts to standardise, with a few more vendor-specific hacks crowbarred in there for good measure. asm.js is one more hack on top of the mess, and while it's technically interesting, and probably very useful (much like the rest of javascript), we shouldn't be building these monstrous feats of engineering on top of such shaky foundations.
> there's only one language that works everywhere without installation or trouble and that's JavaScript.
This is true. But we've arrived at this situation virtually by chance, and it's a huge mess and we shouldn't be readily accepting it. We need a real bytecode for the web, we need it to be standardised and we need to push for browsers to support it. NaCl seems to be the furthest down the road to this objective so far.
Javascript is not just a "quirky scripting language for minor workflow events." It is a powerful, expressive language, that has many benefits over contemporary languages, regardless of setting. Yes, it has quirks, and yes, there are some things that coming from another language are difficult to grasp, but it is not a Bad Language.
The fact that Node.js, Javascript on the server, is gaining so much popularity in the developer community means that it has benefits beyond its universality in the browser.
Asm.js is not a "hack on the top of the mess", it's a simplification of "the mess" down to it's simplest, most bytecode-esque parts. And it's performance is shockingly close to Native.
Javascript is not the perfect bytecode for the web. But it does work as a bytecode for the web, and with asm.js, it seems that it works decently well. I think efforts are better spent improving Javascript, asm.js, and languages that can target it rather than swimming upstream.
> Javascript is not just a "quirky scripting language for minor workflow events." It is a powerful, expressive language
I didn't say it was just for minor workflow events, I said it was created for minor workflow events - it's just good fortune that Brendan Eich was an experienced language designer and created something that was powerful and extendable enough to bring us to the situation Javascript is in today.
It's certainly powerful (particularly considering it's original intentions), I disagree that it's expressive in comparison to other modern languages.
Why anyone thinks server-side javascript is a good idea is beyond me.
Have you ever worked on a non-trivial JavaScript application? I'll define that as 10,000 lines or more. I ask because I suspect that this comment is simply a visceral reaction to some flaw in JS, and I want to know if that reaction is based on experience.
I have worked on what I would call non-trivial Javascript applications, but only front-end javascript (no server-side js, apart from a few MongoDB map-reduce queries).
My feelings towards js are are informed by that experience, and my (happier) experiences with other languages - which are primarily Python, Java and Objective-C, if you're interested.
Largely, yes. The problem domains are different. The usage patterns are different. The constraints are different. Why not be pragmatic and pick an appropriate technology for each use case?
I don't mean to be defensive, I personally don't use JS on the server side, but I don't see any problems with other people doing it. No more than I would have problems with people using, say, Ruby.
You responded to someone who said "I disagree that it's expressive in comparison to other modern languages."
Why would a person of that opinion value a small amount of code sharing over language expressiveness? So, there's your answer as to what they're imagining.
Regarding code sharing - maybe you can answer another post in this thread which I ask, "Where are these mythical Node.js applications that share so much code with the client...?"
Perhaps you believe that in web applications, all of the real computation happens on the server, and JavaScript is just for providing a nice UI. Some people probably want it to be this way, so they can do most of the work in their preferred language and runtime environment, and only deal with JS for the minimum of client-side work. But to take this approach is to leave unused the embarrassment of riches that we have in computing power on the client side, even in smartphones. If we make full use of that client-side computing power, we can reduce server resource consumption and, more important from a user's perspective, the need to incur the cost of network round trips.
Or maybe you think that in modern web applications, most of the complex logic belongs on the client side, and the server is mainly for receiving, storing, and sending data. In that case, perhaps you think the most important attribute of a server-side language is performance. But it's probably quite rare for the server side of a real web application to be a dumb data store. So what happens if you wrote some non-trivial logic in JS, then discover that it needs to run server-side?
I think we're still figuring out what belongs on the client and what belongs on the server. Therefore, I think using the same language on both sides might have some benefit. Admittedly, I've never written a real application with Node.js, and the thought of callback spaghetti everywhere doesn't exactly appeal to me. But I might accept that in return for maximal code re-use.
One does not have to believe that "all of the real computation happens on the server" to not want to use Javascript if one doesn't have to.
Where are these mythical Node.js applications that share so much code with the client though? What functionality is shared and how much time did it save anyone?
Personally, I wouldn't trust one browser-land function or library in my server application without digging through every line of code to make sure it's not going to do some browser-specific hackery. Then what have I saved? I'd rather go get a separate module that was built specifically for Node.js.
Then there's the time I'd save sharing my own code between Node.js and browser - which would be next to nothing because any time I save would be spent having to think about platform differences anyway.
Code reuse is an advantage I guess.
For example you want fast responsive validations as the user enters data, but for security reasons you need to do final validations on the server.
You have objects on the client that you want to persist to the server but you don't want to have to write two models.
Server-side Javascript, in particular Node, is much better suited to event-driven applications (e.g. web servers) than a lot of other languages out there, including Ruby (and dare I say Python?).
A lot of web applications routinely do many I/O operations per request handler. For example, do a DB query, then do something with that data, then conditionally do another DB query based on the results of the first, then do something with that data, then query a REST Web service, and so on. Blocking APIs make this very natural; add high-level abstractions such as an ORM, and you don't even think about the fact that you're doing I/O. With something like Node, application code of this sort degenerates into callback spaghetti, unless you use something like the fiber module, or a compiler that transforms the natural, straight-line code into continuation passing style. Though I've previously argued for the potential advantages of using the same language for both the client and the server, I fail to understand why something like the fiber module isn't standard in Node, or why the kind of compiler I described isn't more popular. Perhaps that's just dogmatism or a cargo-cult mentality.
An event-driven system might be good for "real-time" applications where many clients connect and wait to have things pushed to them. Even then, I think coroutines or lightweight threads would be fine, as long as they're the norm for a runtime environment and its standard library (e.g. Go, and Haskell IIUC) and not bolted on (e.g. Python's eventlet and gevent).
The fact that most web applications do many I/O operations per request handler and the Blocking API's make it very natural so that "you don't even think about the fact that you're doing I/O" is precisely the problem. I/O is an eternity compared to computing cycles, and to have the entire thread blocked while waiting for I/O to complete means that you can have exactly one concurrent client.
Node can easily degenerate into callback spaghetti, that's true. But I think that has more to do with the paradigm being new to a lot of developers. Using promises and similar constructs are a very natural way to deal with callbacks, and reduce the spaghetti significantly. Unfortunately, they won't be baked into Node's core.
Even for a standard CRUD app, you can get way more performance out of Node than you can out of, say, Rails, precisely because it is highly concurrent.
I remember those times when Javascript was only used for changing button images in the mouse over event! It was a powerful extra to designers to have this knowledge.
I agree, its a mess with regard to expression - isn't that why this thread exists? The language is fun to write but eye-gouging to maintain. Of course you could apply strict conventions to make it maintainable, but at that point you might as well be in a statically typed language working at full speed in an ide.
After coding JS by hand for years (while doing other languages) I'm done with it. I'm ready to go preprocessor full time, either static language based but also interested in lisp variants, because if I have to go typeless, might as well do it in style.
I tried CoffeeScript for a while, but the philosophy is too similar to JS to keep my interest. It did reduce the code dramatically though, on avg about 70%.
I see your point, but JavaScript is much more popular than any of the other languages designed to compile to it. Thus, even if one works in a restricted and somewhat tedious subset of JS (such as the one encouraged by the Google Closure Compiler and used by the Closure Library), wouldn't it still be easier to find already-qualified developers than if one uses Haxe or ClojureScript or Dart?
> Of course you could apply strict conventions to make it maintainable, but at that point you might as well be in a statically typed language working at full speed in an ide.
Not really. We do the strict conventions thing and have had a lot of success with it. Being able to run in a browser is a huge, huge advantage. If I had a nice statically typed language that gave me that advantage as well as javascript does, I'd probably switch to it, because by inclination I prefer the compiler to do more work for me, but there's no way I want to leave behind having my code work for anything with a browser and f5 to see my code in action.
The fact that Node.js, Javascript on the server, is gaining so much popularity in the developer community means that it has benefits beyond its universality in the browser.
The fact that Node.js is becoming popular is simply a symptom of having a ridiculously large ecosystem of developers, and not much else.
A ridiculously large ecosystem of developers is a huge feature that we ignore at our peril. I think a mature developer should overlook aesthetic quibbles with a language, framework, or any other tool, and make decisions based solely on what's most practical.
The fact that PHP is gaining so much popularity in the developer community means that it has benefits beyond its universality in shared hosting environments.
> We need a real bytecode for the web, we need it to be standardised and we need to push for browsers to support it.
We had one. It was called Java. Actually, we still have it, but it just has such a bad reputation now; users don't trust it because of "security" and developers don't trust it because of "public static cruft()" and "Oracle".
But it is still quite capable. Did anyone else first play minecraft in a web applet? It worked incredibly well for me. So I argue that we do have a viable bytecode, we're just ignoring it.
Not necessarily. Not having a single (hopefully benevolent) entity control a platform means poor standardization -- which leads --> to vendor-specific variants - and voila, you get to the HTML/JS mess that we have today.
The experience sucks beyond compare, always has, and blaming the user isn't going to solve that.
You have to download a separate plugin with stupid ads in it. If your version is wrong, it won't work or it won't work right. A number of things won't work unless you use the one from Oracle. If you are lucky, a little tray reminder obtrusively harasses you every few weeks to update to a new version. If you don't, you have to worry about unpatched vulnerabilities.
Now you come across a page with an applet in it. This applet stuck inside a little rectangle on the page takes a few seconds to kick off at all. Most of the time it looks terrible once it's up. It isn't at all uncommon that it crashes. Many people have experienced this bringing down the browser or even hanging the computer, which is especially awesome when you didn't even ask for the thing to run.
This isn't a matter of the users being stupid and not knowing what's good. This isn't good. It has never been good.
But the JVM was never really part of the browser, it was a plug-in like Flash. If we had a way to include JVM byte code in a page and JVM had just as much access to the DOM as javascript then it would be useful.
Java moves ahead despite peoples continued misconceptions about it. There are js-based jvm bytecode interpreters: https://github.com/int3/doppio seems pretty nice.
> duct-taped to a bundle of silly hacks, wrapped up in some interesting attempts to standardise, with a few more vendor-specific hacks crowbarred in there for good measure
By this point you could easily have been confused for someone describing amd64 (nee ia32, nee Pentium, i486, i386, 80286, 8088, 8080, 4004.. circa 1971).
Just as we still have a perplexing set of registers and operations that happen to encode efficiently on this ubiquitous architecture due to their suitability to application in our distant ancestors' desktop calculators (binary-coded decimal, anyone?), no matter what kind of cleanliness you're alluding to existing in proposed alternatives that you might hope supplant Javascript.. in 40 years it'll look just as stale and nasty as x86 and Javascript do today.
Not least PNaCl, where last I checked they were busy trying to shoehorn an architecture-specific binary format (bitcode) into something that might run on multiple machines. If that's not enough for you, the original NaCl relied on a vestigial 80286-specific hack (segmentation) that was finally removed in amd64. It's turtles all the way down.
Often times, there is enough reason to start over. With computer architectures, this has the risk of making every single existing operating system obsolete on your architecture. If you are planning on hitting a sales volume equivalent to amd64 sales, you can't just start over.
Javascript is a different beast. By building Dart into your webrowser, you don't break the web browser. And while starting over will be an uphill battle, you can address much of the sillyness that holds javascript back and complicates it.
Perhaps we have hit the limit of practical additions to javascript. The post yesterday showed that asm.js isn't actually faster unless your browser actually supports the optimizations, which makes popularizing optimized asm.js almost as difficult as popularizing Dart.
I don't want to be using technology in 40 years that is built upon technology from 40 years ago. At some point we should reset, even the difficult technologies like amd64. How often is not a question I'm qualified to answer but it should happen.
> By this point you could easily have been confused for someone describing amd64 (nee ia32, nee Pentium, i486, i386, 80286, 8088, 8080, 4004.. circa 1971).
He said "We need a real bytecode for the web" not some architecture-specific machine language like x86 et al.
LLVM or JVM are examples of bytecode. They're highly portable (at least the JVM is), and they're not the mess that practically any real hardware instruction set is.
> last I checked they were busy trying to shoehorn an architecture-specific binary format (bitcode) into something that might run on multiple machines
The bitcode you're referring to is LLVM. It's an architecture-independent assembly that can be used to target most major real ISAs. For instance, the Clang compilers use LLVM as their backend. Any programming language designer could use LLVM and instantly (and easily) be able to generate native code for who knows how many different architectures.
So I think the parent poster was right in what he/she said.
That's what I was talking about, too. Since processors have essentially plateaued in performance improvements by increasing raw clock speed, the only growth options going forward are wider designs – increasingly unorthodox features (e.g. hardware-assisted TM) for which there is no historical precedent.
I'm further hinting that no matter what utterly ideal format we pick, not 40 years from now.. perhaps not 10, perhaps not even 36 months time, some market participant will drop an architectural feature that completely obliterates contemporary thinking about what such an ideal format should look like. And once again we're back to x86-level cleanliness.
So why take the penalty of a brand new mostly incompatible design when non-delusional incremental improvements would have got us there anyway..
> The bitcode you're referring to is LLVM. It's an architecture-independent assembly that can be used to target most major real ISAs
Can't wait to see the rebirth of Java^W NaCl applets.
Seriously, though, if you never see the underlying JS, if you code and debug everything in your preferred language and the result is fast, why would you care what your program compiles to?
Nobody objects to having their programs compile to PE on Windows, nobody requires Microsoft to use ELF or Mach-O instead! Even though, nowadays, PE is a bunch of pieces of cloth sewed together, nobody cares as long as it works!
Don't despise modest beginnings or sloppy evolution. Sloppy evolution from a very modest beginning has achieved things that we haven't yet come close to matching through deliberate design, such as our own species. And it does this by always taking the next incremental step from what it has, with no regard for the greater elegance of some hypothetical master plan.
And yet if we had to either write in or compile all our code down to QBasic in order to make web apps, we would be justified in complaining about that.
A BASIC descendant (VBScript) very nearly did become the scripting language of the Web. If it had gone that way, I'd like to think that I would tolerate it and write useful apps with it, as long as it didn't mean that Microsoft would have lasting control over the spread and evolution of the Web platform.
No. If I want byte code, I'll use Java or a native app. This idea that a web browser should be an operating-system-in-a-box-over-http needs to stop.
JavaScript is not a bad language. If you're getting caught up in gotchas and 'quirky' behavior, why not just read EMCA-262 [1] ? It lays out all defined behavior of JavaScript so you'll know exactly what the interpreter is doing when it reads your code.
> This idea that a web browser should be an operating-system-in-a-box-over-http needs to stop.
Why? The Web platform is the only non-proprietary platform that has serious market-share among end-users and mind-share among developers. Therefore, it's the only thing that has a serious chance of ending the dominance of proprietary platforms. IMO, that goal is important enough to override any aesthetic concerns that we developers might have.
> it's the only thing that has a serious chance of ending the dominance of proprietary platforms.
That has never been the end goal for HTTP or even the WWW. Furthermore, we have proprietary web platforms today: just look at Facebook, Google+, Twitter, etc. It's in fact MORE fragmented than the OS market is right now.
I mean, think about it: if you were trying to design a portable OS-as-a-service, would you REALLY be using a stateless protocol like HTTP for it? We've done a pretty good job of hacking together ways to maintain state over multiple requests, but the fact of the matter is that it's 100% garbage overhead that wouldn't exist at all if we just used a stateful protocol in the first place!
I don't understand why people say such silly feats of pseudo-"engineering" are somehow "OK" and acceptable. How have we arrived to this situation?
I get that 1) agreeing upon a more sane bytecode-based language for the web 2) implementing it on all major browsers 3) changing the tooling and workflow(no more a .js file, save and open in browser but a compiled file instead) would perhaps be not worth the benefit(more sane target, better support for common programming constructs without performance, safety or determinism issues and so on).
Simply, people don't give a fuck, web works "well enough" and iterative engineering solves the major problems. These just are things we have to deal with, something we can't change, which I find pitiful but understandable, but most definitely not "OK" or acceptable.
> I don't understand why people say such silly feats of pseudo-"engineering" are somehow "OK" and acceptable.
Network effect and worse is better.
Any solution that cannot be introduced gradually with backwards- and forwards-compatibility is very unlikely to gain traction on the web. You'll always get a vendor that doesn't like some tech or has multi-year-long development/distribution/upgrade process. Tools can be even slower to upgrade and you'll also need to educate developers and get them out of their comfort zones.
It's not that people don't give a fuck. It's not pseudo-"engineering". It's the best you can get within constrains that are both technical and social.
Reality is Chrome has the majority on the browsers market and since it will contain Dart Virtual Machine my bet is Dartlang is the future technology of the web (seen recent Dart benchmarks? In some cases Dart beats even Java). Dart is done by the same people who have done fastest JS VM on the market (Google's V8)
Even more important killer Dart features JS asm.js and other compiled to JS langs will never have is:
a) snapshoting (allows app to start almost instantly)
I had a silly idea. Why not make LLVM a part of browsers? I heard it was a really performant albeit hard to write languages in. It seems to not have the stigma attached to JVM, especially association with oracle.
This is what PNaCl (Portable Native Client) is trying to do. I'm skeptical though; PNaCl is still experimental in Chromium 29 (the current development version), and requires the browser to download extra files outside of the Chromium package itself, probably because LLVM is quite bulky. If we're going to run high-performance code with the C memory model in a browser, I think asm.js is the best way to do it.
What bothers me about asm.js and Emscripten is that, if used on a large scale, they'll perpetuate the C memory model, that is, a single flat heap of arbitrary size in which things are referenced via fixed pointers. Perhaps this memory model is necessary for small pieces of high-performance code, but I wouldn't want us to keep using it as the primary memory model for new applications, especially when at least some of the current JS engines have advanced copying/compacting garbage collectors.
I would love to have a memory-safe language that compiles to efficient JavaScript with no intractable semantic or runtime mismatches between the JS and the source language or its libraries (e.g. no preemptive threads with shared memory) and takes full advantage of the JS engine's garbage collection, but can also be compiled ahead-of-time to fairly efficient native code for environments where JIT compilation isn't an option (e.g. iOS apps). I suspect that a language like this would need static typing. To gain traction, such a language would need to stick to fairly mainstream concepts (e.g. not purely functional). Perhaps this language could be a subset of JS itself. The trouble with Java and C# is that their standard libraries and most third-party libraries assume multiple threads and blocking APIs; perhaps the compiler to JS could transform the code into continuation passing style.
JavaScript is most emphatically not the assembly language of the web. It is instead the lingua franca of the web. I actually think this is what people intend to convey when they say this sort of nonsense.
114 comments
[ 3.0 ms ] story [ 168 ms ] threadThis is the reason CPU instruction set architectures are so simplistic and "low level" and don't really do things for you -- because if they did, targetting such a CPU would be a major pain with all inefficiencies due to workarounds due to funky and incompatible features.
In terms of your ability to use them explicitly there's asm.js, typed arrays, and various proposals like value objects for the future.
Enter asm.js, where the source code is as readable as a compiler's assembly output. Once again we are back to code that is hard to hack and improve. Sort of similar to the days of Flash except that entire applications are being built on this platform.
It might be a great end user experience, but it is not the best way forward for web development.
But does this still happen?
I mean most of the scripts are minified anyways :\",
Once you get into more complex applications it doesn't really make sense to do that anymore.
$("#datepickerelement" ).datepicker();
and get the functionality you need in a nice reusable package without having to copy and paste giant chunks of code and pollute your global namespace.
What do you mean? Isn't it roughly as readable as C?
If you do not minify the output, then asm.js's readability is somewhere in between x86 and C. It's far easier to understand than x86, but it is still definitely less readable than handwritten C because it's machine-generated and optimized.
From the link you gave, the DiagModule function is asm.js, and every bit as readable as C.
I think people may think I'm trying to be faintly critical, but I'm not. It's just the nature of the beast.
That Gist - what is visible from "View Source" after beautification - is not compiled asm.js code. It is not the result of any compilation. It is the result of minification. Most minified code is as illegible as that.
Hand-written asm.js code is not going to be the norm, for the forseeable future, for a variety of reasons. The rules for the grammar are difficult and tedious to manually write. The fact that everything runs in a massive array, so you've got a lot of memory management to write, is going to be a problem. The existence of numbers like 1384465 and 4980736 is what makes that particularly hard to read. Most asm.js code on the web is going to be incomprehensible; the examples you can read are the exceptions, for didactic purposes, not the rule.
Wow. No, it absolutely is not. I have no idea what you could possibly mean by "not entirely" compiled.
>The rules for the grammar are difficult and tedious to manually write.
There's nothing difficult about the syntax. It's a subset of javascript.
> The fact that everything runs in a massive array, so you've got a lot of memory management to write, is going to be a problem.
No more difficult than managing memory in C.
> The existence of numbers like 1384465 and 4980736 is what makes that particularly hard to read.
The lack of meaning for those numbers is what makes it hard to read. It wouldn't matter if 1384465 were 2 or "a". It's been minified, so the meaning has been stripped away. I agree that it is hard to read, but it's not a result of using asm.js, it's a result of minification and auto-generating code. There's nothing inherently illegible about asm.js.
> Most asm.js code on the web is going to be incomprehensible; the examples you can read are the exceptions, for didactic purposes, not the rule.
Sure, just like most javascript on the web is incomprehensible, by virtue of being minified or auto-generated.
Due to very limited set of expressions available it's too hard to write by hand (e.g. no objects, casts required everywhere, one flat array representing memory), so all non-trivial asm.js programs are spit out by compilers that treat it like assembly and preserve very little structure of source programs.
Q. Is asm.js a new language?
A. No, it's just (a subset of) JavaScript. An asm.js program will behave identically whether it is run in an existing JavaScript engine or an ahead-of-time (AOT) compiling engine that recognizes and optimizes asm.js—except for speed, of course!
Also, the examples in the spec are completely legible. It looks much like C, in fact.
In those rare cases I've done this in the last few years, the sum total has always been to find out which CSS property or JS function I didn't know about was being used, and then simply pop that into Google. I certainly didn't stare at their code for any longer than that.
BTW, it would be interesting to add real $$$ bets in HN. In this way users can play with real money, not only with argumentation.
This does not exist for Javascript. You can jump through hoops to compile other code to Javascript and hope that it works and works acceptably, that's it.
Javascript isn't assembly, it's the only language and it's terrible.
It wouldn't surprise me if we eventually come full circle and discard the DOM entirely. Each web application is just a giant <canvas> with QT or something compiled to JS providing the UI elements.
The shocking thing is that we are almost at a point where a solution that sounds as stupid as that is actually less contrived and complex than the current mess.
At this stage, if asm.js is to succeed, they need to show how us mortals can use it. I.e. it needs to part of a complete toolchain, or an ide.
asm.js using qt (without hacks) would be amazing. How do I help (when I can hardly wrap my head around it)?
The awesomeness of assembly language is that it's perfectly exact, deterministic and thus very predictable and efficient. No unnecessary indirection unless you build it yourself. No implicit type casting(infact, no types at all). Nothing. Just plain instructions with very specific semantics to build from.
Now how does JS(or even asm.js) fare with it's tons of indirection and ambiguous implicit typecasts compared to an actual assembly language? From a technical standpoint for a compile target the comparison is embarrassingly unfair, but hey, this is something which is supposedly "OK" and acceptable, right?
> there's only one language that works everywhere without installation or trouble and that's JavaScript.
This is true. But we've arrived at this situation virtually by chance, and it's a huge mess and we shouldn't be readily accepting it. We need a real bytecode for the web, we need it to be standardised and we need to push for browsers to support it. NaCl seems to be the furthest down the road to this objective so far.
The fact that Node.js, Javascript on the server, is gaining so much popularity in the developer community means that it has benefits beyond its universality in the browser.
Asm.js is not a "hack on the top of the mess", it's a simplification of "the mess" down to it's simplest, most bytecode-esque parts. And it's performance is shockingly close to Native.
Javascript is not the perfect bytecode for the web. But it does work as a bytecode for the web, and with asm.js, it seems that it works decently well. I think efforts are better spent improving Javascript, asm.js, and languages that can target it rather than swimming upstream.
I didn't say it was just for minor workflow events, I said it was created for minor workflow events - it's just good fortune that Brendan Eich was an experienced language designer and created something that was powerful and extendable enough to bring us to the situation Javascript is in today.
It's certainly powerful (particularly considering it's original intentions), I disagree that it's expressive in comparison to other modern languages.
Why anyone thinks server-side javascript is a good idea is beyond me.
That someone would want to use the same language to write both their client and server side code is beyond you?
My feelings towards js are are informed by that experience, and my (happier) experiences with other languages - which are primarily Python, Java and Objective-C, if you're interested.
I suppose you know what's appropriate.
Why would a person of that opinion value a small amount of code sharing over language expressiveness? So, there's your answer as to what they're imagining.
Regarding code sharing - maybe you can answer another post in this thread which I ask, "Where are these mythical Node.js applications that share so much code with the client...?"
Perhaps you believe that in web applications, all of the real computation happens on the server, and JavaScript is just for providing a nice UI. Some people probably want it to be this way, so they can do most of the work in their preferred language and runtime environment, and only deal with JS for the minimum of client-side work. But to take this approach is to leave unused the embarrassment of riches that we have in computing power on the client side, even in smartphones. If we make full use of that client-side computing power, we can reduce server resource consumption and, more important from a user's perspective, the need to incur the cost of network round trips.
Or maybe you think that in modern web applications, most of the complex logic belongs on the client side, and the server is mainly for receiving, storing, and sending data. In that case, perhaps you think the most important attribute of a server-side language is performance. But it's probably quite rare for the server side of a real web application to be a dumb data store. So what happens if you wrote some non-trivial logic in JS, then discover that it needs to run server-side?
I think we're still figuring out what belongs on the client and what belongs on the server. Therefore, I think using the same language on both sides might have some benefit. Admittedly, I've never written a real application with Node.js, and the thought of callback spaghetti everywhere doesn't exactly appeal to me. But I might accept that in return for maximal code re-use.
I think this article says it quite well: Callback Hell is a Design Choice : http://blog.caplin.com/2013/03/13/callback-hell-is-a-design-...
Where are these mythical Node.js applications that share so much code with the client though? What functionality is shared and how much time did it save anyone?
Personally, I wouldn't trust one browser-land function or library in my server application without digging through every line of code to make sure it's not going to do some browser-specific hackery. Then what have I saved? I'd rather go get a separate module that was built specifically for Node.js.
Then there's the time I'd save sharing my own code between Node.js and browser - which would be next to nothing because any time I save would be spent having to think about platform differences anyway.
You have objects on the client that you want to persist to the server but you don't want to have to write two models.
A lot of web applications routinely do many I/O operations per request handler. For example, do a DB query, then do something with that data, then conditionally do another DB query based on the results of the first, then do something with that data, then query a REST Web service, and so on. Blocking APIs make this very natural; add high-level abstractions such as an ORM, and you don't even think about the fact that you're doing I/O. With something like Node, application code of this sort degenerates into callback spaghetti, unless you use something like the fiber module, or a compiler that transforms the natural, straight-line code into continuation passing style. Though I've previously argued for the potential advantages of using the same language for both the client and the server, I fail to understand why something like the fiber module isn't standard in Node, or why the kind of compiler I described isn't more popular. Perhaps that's just dogmatism or a cargo-cult mentality.
An event-driven system might be good for "real-time" applications where many clients connect and wait to have things pushed to them. Even then, I think coroutines or lightweight threads would be fine, as long as they're the norm for a runtime environment and its standard library (e.g. Go, and Haskell IIUC) and not bolted on (e.g. Python's eventlet and gevent).
Node can easily degenerate into callback spaghetti, that's true. But I think that has more to do with the paradigm being new to a lot of developers. Using promises and similar constructs are a very natural way to deal with callbacks, and reduce the spaghetti significantly. Unfortunately, they won't be baked into Node's core.
Even for a standard CRUD app, you can get way more performance out of Node than you can out of, say, Rails, precisely because it is highly concurrent.
I remember those times when Javascript was only used for changing button images in the mouse over event! It was a powerful extra to designers to have this knowledge.
After coding JS by hand for years (while doing other languages) I'm done with it. I'm ready to go preprocessor full time, either static language based but also interested in lisp variants, because if I have to go typeless, might as well do it in style.
I tried CoffeeScript for a while, but the philosophy is too similar to JS to keep my interest. It did reduce the code dramatically though, on avg about 70%.
Not really. We do the strict conventions thing and have had a lot of success with it. Being able to run in a browser is a huge, huge advantage. If I had a nice statically typed language that gave me that advantage as well as javascript does, I'd probably switch to it, because by inclination I prefer the compiler to do more work for me, but there's no way I want to leave behind having my code work for anything with a browser and f5 to see my code in action.
The fact that Node.js is becoming popular is simply a symptom of having a ridiculously large ecosystem of developers, and not much else.
Yup, developers do. But clients and users don't. Just make it work!
The fact that PHP is gaining so much popularity in the developer community means that it has benefits beyond its universality in shared hosting environments.
We had one. It was called Java. Actually, we still have it, but it just has such a bad reputation now; users don't trust it because of "security" and developers don't trust it because of "public static cruft()" and "Oracle".
But it is still quite capable. Did anyone else first play minecraft in a web applet? It worked incredibly well for me. So I argue that we do have a viable bytecode, we're just ignoring it.
You have to download a separate plugin with stupid ads in it. If your version is wrong, it won't work or it won't work right. A number of things won't work unless you use the one from Oracle. If you are lucky, a little tray reminder obtrusively harasses you every few weeks to update to a new version. If you don't, you have to worry about unpatched vulnerabilities. Now you come across a page with an applet in it. This applet stuck inside a little rectangle on the page takes a few seconds to kick off at all. Most of the time it looks terrible once it's up. It isn't at all uncommon that it crashes. Many people have experienced this bringing down the browser or even hanging the computer, which is especially awesome when you didn't even ask for the thing to run.
This isn't a matter of the users being stupid and not knowing what's good. This isn't good. It has never been good.
By this point you could easily have been confused for someone describing amd64 (nee ia32, nee Pentium, i486, i386, 80286, 8088, 8080, 4004.. circa 1971).
Just as we still have a perplexing set of registers and operations that happen to encode efficiently on this ubiquitous architecture due to their suitability to application in our distant ancestors' desktop calculators (binary-coded decimal, anyone?), no matter what kind of cleanliness you're alluding to existing in proposed alternatives that you might hope supplant Javascript.. in 40 years it'll look just as stale and nasty as x86 and Javascript do today.
Not least PNaCl, where last I checked they were busy trying to shoehorn an architecture-specific binary format (bitcode) into something that might run on multiple machines. If that's not enough for you, the original NaCl relied on a vestigial 80286-specific hack (segmentation) that was finally removed in amd64. It's turtles all the way down.
Javascript is a different beast. By building Dart into your webrowser, you don't break the web browser. And while starting over will be an uphill battle, you can address much of the sillyness that holds javascript back and complicates it.
Perhaps we have hit the limit of practical additions to javascript. The post yesterday showed that asm.js isn't actually faster unless your browser actually supports the optimizations, which makes popularizing optimized asm.js almost as difficult as popularizing Dart.
I don't want to be using technology in 40 years that is built upon technology from 40 years ago. At some point we should reset, even the difficult technologies like amd64. How often is not a question I'm qualified to answer but it should happen.
He said "We need a real bytecode for the web" not some architecture-specific machine language like x86 et al.
LLVM or JVM are examples of bytecode. They're highly portable (at least the JVM is), and they're not the mess that practically any real hardware instruction set is.
> last I checked they were busy trying to shoehorn an architecture-specific binary format (bitcode) into something that might run on multiple machines
The bitcode you're referring to is LLVM. It's an architecture-independent assembly that can be used to target most major real ISAs. For instance, the Clang compilers use LLVM as their backend. Any programming language designer could use LLVM and instantly (and easily) be able to generate native code for who knows how many different architectures.
So I think the parent poster was right in what he/she said.
That's what I was talking about, too. Since processors have essentially plateaued in performance improvements by increasing raw clock speed, the only growth options going forward are wider designs – increasingly unorthodox features (e.g. hardware-assisted TM) for which there is no historical precedent.
I'm further hinting that no matter what utterly ideal format we pick, not 40 years from now.. perhaps not 10, perhaps not even 36 months time, some market participant will drop an architectural feature that completely obliterates contemporary thinking about what such an ideal format should look like. And once again we're back to x86-level cleanliness.
So why take the penalty of a brand new mostly incompatible design when non-delusional incremental improvements would have got us there anyway..
> The bitcode you're referring to is LLVM. It's an architecture-independent assembly that can be used to target most major real ISAs
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/4376...
http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-ba...
It is abstracted over specific CPU instructions, but is not portable and not intended to be. It can contain CPU and OS-specific patterns.
It is possible to convert LLVM bytecode into something portable though, or at least a subset of it. That is sort of what Emscripten and PNaCl do.
Seriously, though, if you never see the underlying JS, if you code and debug everything in your preferred language and the result is fast, why would you care what your program compiles to?
Nobody objects to having their programs compile to PE on Windows, nobody requires Microsoft to use ELF or Mach-O instead! Even though, nowadays, PE is a bunch of pieces of cloth sewed together, nobody cares as long as it works!
JavaScript is not a bad language. If you're getting caught up in gotchas and 'quirky' behavior, why not just read EMCA-262 [1] ? It lays out all defined behavior of JavaScript so you'll know exactly what the interpreter is doing when it reads your code.
[1] http://www.ecma-international.org/publications/files/ECMA-ST...
Why? The Web platform is the only non-proprietary platform that has serious market-share among end-users and mind-share among developers. Therefore, it's the only thing that has a serious chance of ending the dominance of proprietary platforms. IMO, that goal is important enough to override any aesthetic concerns that we developers might have.
That has never been the end goal for HTTP or even the WWW. Furthermore, we have proprietary web platforms today: just look at Facebook, Google+, Twitter, etc. It's in fact MORE fragmented than the OS market is right now.
I mean, think about it: if you were trying to design a portable OS-as-a-service, would you REALLY be using a stateless protocol like HTTP for it? We've done a pretty good job of hacking together ways to maintain state over multiple requests, but the fact of the matter is that it's 100% garbage overhead that wouldn't exist at all if we just used a stateful protocol in the first place!
I get that 1) agreeing upon a more sane bytecode-based language for the web 2) implementing it on all major browsers 3) changing the tooling and workflow(no more a .js file, save and open in browser but a compiled file instead) would perhaps be not worth the benefit(more sane target, better support for common programming constructs without performance, safety or determinism issues and so on).
Simply, people don't give a fuck, web works "well enough" and iterative engineering solves the major problems. These just are things we have to deal with, something we can't change, which I find pitiful but understandable, but most definitely not "OK" or acceptable.
Network effect and worse is better.
Any solution that cannot be introduced gradually with backwards- and forwards-compatibility is very unlikely to gain traction on the web. You'll always get a vendor that doesn't like some tech or has multi-year-long development/distribution/upgrade process. Tools can be even slower to upgrade and you'll also need to educate developers and get them out of their comfort zones.
It's not that people don't give a fuck. It's not pseudo-"engineering". It's the best you can get within constrains that are both technical and social.
Reality is Chrome has the majority on the browsers market and since it will contain Dart Virtual Machine my bet is Dartlang is the future technology of the web (seen recent Dart benchmarks? In some cases Dart beats even Java). Dart is done by the same people who have done fastest JS VM on the market (Google's V8)
Even more important killer Dart features JS asm.js and other compiled to JS langs will never have is:
a) snapshoting (allows app to start almost instantly)
b) consistent API (http://api.dartlang.org/docs/releases/latest/)
c) tooling (Dart IDE) for all platforms (Win, OSx Linux) with good ecosystem (Jetbrains, Adobe)
Dart will be what .NET could be if it was open source from the beginning. Hope some day we will see Dart VM on other browsers (it is open source)
I would love to have a memory-safe language that compiles to efficient JavaScript with no intractable semantic or runtime mismatches between the JS and the source language or its libraries (e.g. no preemptive threads with shared memory) and takes full advantage of the JS engine's garbage collection, but can also be compiled ahead-of-time to fairly efficient native code for environments where JIT compilation isn't an option (e.g. iOS apps). I suspect that a language like this would need static typing. To gain traction, such a language would need to stick to fairly mainstream concepts (e.g. not purely functional). Perhaps this language could be a subset of JS itself. The trouble with Java and C# is that their standard libraries and most third-party libraries assume multiple threads and blocking APIs; perhaps the compiler to JS could transform the code into continuation passing style.