LLJS : Low-Level JavaScript
mbebenita.github.io
mbebenita.github.io
* Javascript is verbose because it's plain text and was 'optimised' for human readability, rather than machine-parsability. That means parsing Javascript is expensive, too expensive for high-performance applications.
* Javascript's being a dynamically typed language means a single JavaScript variable may at different times represent a number, a string, or a fragment of HTML. Likewise, JS allows us radically to modify the behaviour of even built-in objects such as arrays. All this prevents the Javascript JIT compiler to optimise as aggressively as we'd like.
* Javascript currently doesn't provide viable concurrency which makes translating languages that do a problem.
Given that Javascript is the undisputed king of browser languages, and the difficulties with Javascript as compilation target are becoming apparent, I expect that WebAssembly support will be something of a priority for browser makers. I also think that, as you point out, VM design in general has mostly focussed on sequential computation, and concurrency is bolted on later. In part that's because concurrency is much harder, and the underlying CPU support for concurrency is in flux.
Really? There are a plethora of JavaScript frameworks out there, mostly client-side but also some server-side, each with its own distinct culture, and new ones are coming out all the time. And each framework imposes its own way of doing things, and that attracts different types of people and creates a different culture.
In fact, the JavaScript ecosystem is so vibrant and diverse right now that "monoculture" is the last word I'd use to describe it.
If you want monoculture, look at Ruby. (Don't get me wrong, I love Ruby and it's my favorite language, but it's basically dominated by the monoculture of Rails.)
_frog is worried by a language monoculture, having to develop for a platform in only one language: the platform mandates the language. Other examples: Java for Android, Objective-C for iOS (Swift now).
You are worried by a framework monoculture, Rails dominating Ruby. That has no parallel in the JavaScript world. Other examples: iOS development dominating Objective-C and Swift?
The common worry is that monocultures harm their environment (JavaScript harming the web and Rails harming Ruby).
Given the success of Rails and the JavaScript-based Web one wouldn't say any of those type of monocultures are bad for making money (and look at real monocultures in agriculture and animal farming) but farming teaches that if you don't have enough diversity you are exposed to problems.
Being able to program the web in many different languages would be both good (pick the tool you like most) and bad (example: "sorry, I can't take over this webapp because it's written in OCaml and I only do Ruby and Elixir, find somebody who knows OCaml") but not different from what we always did when developing for the desktop and the web server. Both did well. If we're heading there we'll cope with that (customers will stick with the "big" languages, as usual).
Are you sure that it's not some sort of stockholm syndrome? Or a case of plato's cave?
But, alas, I'm stuck with Javascript. For the longest time, we had to specify which language we were using as part of the script tag. Which was fine, as long as we specified Javascript.
Who invented that damn thing? Henry Ford?
I have never enjoyed dynamic typing; it has always seemed like TheWrongSolution™ to me. And Haskell really drives that home for me (i.e., it is possible to have a static type system with all the benefits that gives you without any of the headaches).
Additionally, I really dislike the trend of JS moving out of the web browser; it is incredibly easy to write impenetrable JS (particularly with the compile-to-js languages) which makes it much harder for me to understand what is running on my system, how to contribute to it and how to debug it.
Furthermore, JS is fast in comparison to other interpreted dynamic languages, but is quite slow compared to most native code (like the kind you would get with Haskell).
I am not trying to be one of the JS naysayers that gets into religious wars, but I will say that I am generally not a fan of the language, and the possibility of removing it from my life does seem like a net-positive.
But again, my intention is not to start a flamewar, simply answer your questions about my preferences.
What I meant was the idea that everyone is just waiting for JS to go away seems like you're extrapolating your preferences onto other people.
Though, if a significant number of people feel similarly to me (that there are better options than JS and that wasm could catalyze the move towards those better options), then I do not really see a problem with JS going away. Perhaps that is just me.
Again, I did not write this post with any intention of flaming or insulting those who like JS.
I see asm.js and wasm as an evolution path. The same idea as JVM bytecode but twenty year after.
It can provide the cross-platform and ubiquity advantages to most of existing projects and languages.
With wasm supporting VMs providing the same sandboxing and the ability to painlessly run more languages in the client, a lot of the incentive for running JS outside the browser will disappear for a lot of people.
Also I don't think they are being unambitious by not wanting to learn JavaScript since all languages have many warts and learning all of the peculiarities of how to do the same thing in different languages is not going to make you a better programmer.
The language and generator were simple enough to use in a browser-only environment so it's a shame there was never more interest in it. It would've been nice to be able to fool around with asm.js without having to set up a dev environment, which isn't possible in some circumstances.
Read that again. CPU's should be able to be given a binary blob, and nothing bad can happen. It should be native speed because it's running on the actual metal. Like a hardware CPU, for the web.
A multigigaherz processor cannot render an 8-bit (that is 0-255 here) processor running at 1.79 MHz with a whopping 2 kB of RAM that is orders of magnitude slower: https://news.ycombinator.com/item?id=9624483
This is insanity. It's time for new hardware, that you can say "go wild" to by typing in an http address. 90% of the reason for enduring this slowness is security. (It's okay to interpret javascript - what's the worst that will happen. It's not okay to agree to run any binary regardless of what will be in it.)
It's time for Intel to make chips that you can hand to a website and say, "go wild". I think reinventing C in Javascript at 10% of performance (generously), is what is silly. Running Mario at a bit too slow to be called "perfect" is what is silly. It's 2015. Light travels 10 centimeters between clock cycles, with cores at 3 GHz. Do we really have to spend three billion cycles every second, on interpreting javascript?
† "Dedicated hardware would be silly – the current hardware can do secure sandboxing just fine. Cross platform compatibility is an issue with a lot of possible solutions; dedicated hardware would be a far worse case."
It is those points, where it interacts with other sub-systems to display things to the user or receive input from the user that things get dangerous. Even with IPC there is the possibility that there may be a security issue processing the content.
NaCL and others try to solve part of the problem by making it easier to sandbox the application by limiting what it can do, but there is still an interface into the real world.
That's great, but what happens when it wants do to I/O? You need a route out of the sandbox, ie an attack surface.
I don't think it even needs new hardware. Normal OS-level memory protection is good enough. What it does need is new software, to allow you to run a subwindow as another user, with a permissions-granting system for those occasions when you want to allow it access to the crown jewels like the microphone, accelerometer and GPS.
Native Client is a sandbox for running compiled C and C++ code in the browser efficiently and securely, independent of the user’s operating system.
Actually, it's more like a compressed abstract syntax tree. Subtle difference, but there's no stack machine you're targeting in wasm, which I think is quite interesting!
It will be like a VM plus an OS API:
-DOM replace GUI frameworks (like Qt)
-Canvas replace framebuffer (or GDI)
-JS File API replace fopen() (or with emscripten virtual FS)
- ...
We can see JS as a higher level shell and the Web API as a cross-OS POSIX.
A horribly crippled version of that. Where's my inotify? where are my UDP sockets and epoll?
Security is the common objection to providing real APIs. But instead why not just sandbox them into containers which otherwise provide the full experience of what we already have instead of creating a dumbed-down wrapper?
In other words: Creating a restricted subset of POSIX apis certainly is a sufficient approach for security, but it is not necessary.
It's simply not a suitable performant model for a GUI event/render tree.
Does anybody seriously think that the people that try to disable the right-click context menu in a futile attempt to prevent people from using "save as" will bother to re-create copy-paste support? Is anybody delusional enough to believe that businesses will pay developers to add back in proper URL deep-linking support into their "app" with custom rendering that loads page content AngularJS-style?
Sure, those of us that know what we are doing can [decompile and] read the source and bypass the whole mess. That doesn't help normal people, and worse it's a workaround; links will still be broken. Additionally, who knows how courts will interpret "decompiling" WebAssembly. Does that count as a "technological measure that effectively controls access" under the DMCA?
The requirement of rendering to the DOM puts de facto limits on what can be done on the client, which is part of what has made the internet and the web so successful. Giving those that wish to lock up the commons the tools they need to build their own locks will be one of the worst things to happen to the internet. Unfortunately, I suspect that a lot of the people that should understand these issues will be distracted by shiny toys and promises about better tools and faster apps when they should be thinking about how the technologies they support will affect their future.
edit: fixed spelling typo
If some non-renderable DOM tree could be cloned and transferred across threads you could basically operate in a clone-modify-splice cycle across threads.
I think it's salvageable. But before you can even think about concurrent APIs you first need threads/parallel task executors. And Web Workers aren't going to cut it because they dictate what you're allowed to send (structured clone) instead of being extensible.
Or maybe this is a non problem, because everything will become native again on the mobile devices. No more html, no more Dom.
Pnacl already did this anyway without reinventing compiler ir in a goofy way.