Mozilla Research Projects
mozilla.org
mozilla.org
Of course with hindsight we can see that the Mozilla folks played the long game. Quietly working in the background they produced a product (Firefox) that actually did largely kill IE dominance. You can argue the role that Chrome had in this, but my opinion is that Firefox created the market for non-IE browsers. Without this trailblazing Chrome would not exist.
Congrats to everyone responsible, from the beginning to the present day.
Sweet.js is pretty awesome (I was going to say it's sweet, but that's stupid). Broadway.js and Shumway look pretty awesome, I'm going to check them out tonight.
Regarding Parallel JavaScript, does anyone know how this relates to Khronos' WebCL project? Hardware manufacturers seem really interested in WebCL, but software developers aren't.
Looking through some discussions on Google Groups related to chromium development, it looks like they thought WebCL might be safe to use eventually, but not in the near term.
Implementation of Typed Objects is progressing very nicely in Firefox; if you want to play around with them, just download a Nightly build.
solverStates = {
numVars: uint32
numConstraints: uint32
numStates: uint32
solverStates: solverState[numStates]
}
solverState = {
los: uint32[numVars]
his: uint32[numVars]
constraintStates: *void[numConstraints]
}
> In particular, binary formats often need expressive and dynamic data dependencies that are decidedly out of scope for this API, such as being able to specify an array whose length is determined by a preceding integer
That's probably the right decision for js, given the constraints of sane gc implementation. It still looks like my best option is to use asm.js and have full control over layout.
Either way, I am grateful that Mozilla continues to push for a fast, open and portable language. I don't have much love for js, but it's a damn sight better than trying to deliver portable native code to non-technical users.
I did some issues on Firefox, but stopped, because the Bugzilla/Mercurial workflow was so bad.
I did some fixes for other OSS projects on Github later and it felt like a charm.
git bz attach -e HEAD
...and then it will figure out which bug to attach it to, bring up a little file to edit so you can change the commit message, and it will automatically attach the patch to the bug. You can also set reviewer flags, obsolete other patches, etc., at the same time.
See https://mozilla-version-control-tools.readthedocs.org/en/lat... for details
The old model felt rather clunky. I always had the impression that the coding was the easy part, getting the patch-creation right felt like a chore.
For Microsoft, all the RCE were either use of C/++ or loading .Net into partially trusted scopes (like a browser).
I think Rust would have perhaps fixed a few of the managed runtime vulnerabilities, but probably not the majority. Forget sandboxing and you're done.
Yes. Memory corruption flaws are still found with some regularity in the JVM, but they probably represent less than 10-20% of browser security issues.
There is little that Rust safety could add over Java memory safety.
There have been talks that Hotspot might eventually give place to Graal, but no plans were ever given.
It's interesting to see Shumway on there as I was under the impression the project was put on hold.
No. Mozilla Research and Mozilla Labs were distinct entities. From http://www.ianbicking.org/blog/2014/09/professional-transiti...:
"Note that Mozilla Labs is distinct from Mozilla Research – Research is the home of projects like Rust and ASM.js. Mozilla Research is still going strong. To make a broad distinction between the two groups: Research has worked on foundational technologies for the web, especially related to programming languages, while Labs was product-focused. Also Research has been led by Brendan Eich and now David Herman, with what appears to be a fairly clear vision and succession. Labs was led by a number of people with different interests and different visions – some people with an eye to external validation, some looking to spur disruptive (also uncomfortable) changes in Mozilla, some hoping to enable and include external contribution."
> It's interesting to see Shumway on there as I was under the impression the project was put on hold.
Shumway is definitely under active development. See https://github.com/mozilla/shumway/ for details and commit history.
Having interned at Mozilla Research last summer, I can assure you that there is a small, passionate team of paid developers working hard on it.
My own anecdotal evidence is completely the opposite. I've never heard anything but praise. Being able to open pdfs right in my browser with no stupid plugins is downright heavenly. There's only a couple PDFs I've ever seen that made pdf.js choke. I absolutely love it and am very glad I don't have to mess with some external PDF viewer or annoying plug-in ever again.
For the ones that do fail it's easy enough to download them and open them up in a different viewer.
("Initially flaky software improves over time" is a common story, albeit a boring one, and bad first impressions can be hard to shift.)
I'm always happy when it fires up and saves me having to switch to an external PDF viewer.
[citation needed]. remember that people bitching on web forums does not equal the general population's impression. firefox has extensive telemetry in the browser -- i'm certain that if australis hurt usage metrics, there'd be changes, or at least discussion in the mozilla community (which, of course, is essentially all publicly visible)
Those metrics tell us everything we need to know about Mozilla's efforts these past few years: people in general are not happy with them, to the post of abandoning Firefox.
As of recently, that trend has finally stopped: Firefox has started gaining (very) small amounts of market share recently. The point where the speed of user attrition slowed down was actually slightly before the Australis launch, but after that, the development sped up considerably.
Thus, it looks like Australis helped substantially with winning back users.
Plus, a few years ago, the competition was essentially IE6/7. Not hard to gain market share against that. Now there are several great browsers to choose from. Which I'd say is a fantastic development, even though I work for Mozilla.
Finally, there are the billions of dollars that e.g. Google pours into advertising for Chrome, which might have something to do how market share developed.
PDF is pretty good and people generally like it and don't think twice that they're not using, say, adobe reader.
As for Australis, there were loud outcries when it happened (as it always does with big UI changes, see 3.x to 4) but it quieted down quite fast.
That's because "loud" doesn't equal majority and this vocal minority got used to, moved elsewhere or simply used some addon to keep things how they liked them.
I usually configure PDFs to be saved, so that I can enjoy a native PDF viewer instead.
Daala is a very exciting project. The current mess of codecs support on the Web is just horrible.
So Shumway can solve this (at least in context of Flash) replacing the Flash plugin altogether.
For more details, see https://bugzilla.mozilla.org/show_bug.cgi?id=627699
As for Brick, it is mostly made by people from the Apps team and last time I checked it was going thru a rewrite to base it on platform.js instead of x-tags. You can check with someone from that team on #apps on irc.mozilla.org. Brick is not research, it is just a collection of Web Components.
pdf.js was the brainchild of Andreas Gal, now our CTO but at the time a cofounder of Mozilla Research along with Brendan Eich and me. That project started briefly in Research but was shepherded to product pretty quickly.
Shumway is a separate project but similar in spirit. It's not a converter per se, but rather an emulator including a full ActionScript Bytecode (ABC) JIT, implemented in pure JavaScript. Right now we are interested in getting Shumway to the point where it can be used in Firefox as an alternative to the native Flash plugin for certain kinds of web Flash content, to provide better security, stability, and performance. Over time as Shumway matures the ultimate goal would be to eliminate the need for the Flash plugin entirely, but we'll walk before we run.
But Shumway is usable as a standalone project as well, and others have begun taking notice. For example, Prezi has invested in Shumway as a library for rendering vector graphics:
https://medium.com/prezi-engineering/how-and-why-prezi-turne...
Mozilla is the only independent vendor pushing technology and principles focused on people over profit.
You can find the donation page at https://sendto.mozilla.org/page/contribute/givenow-seq#page-...
That it is the only independent vendor doing so is categorically false.
That it always puts people over profits is questionable. It's relationship with Google and reliance on ad revenue runs counter to those principles. Perhaps it is doing so as a survival tactic only, but they do compromise on the principle.
Why don't we see a true plurality of programming languages supported within the browser?
I'm talking about proper implementations, too. Not hacks that use something like Emscripten to mangle C code down to JavaScript (which is all that asm.js is, after all).
NaCl and PNaCl are a much more general and sensible approach, rather than trying to contort JavaScript into a psuedo-bytecode.
If Mozilla really does care about openness and freedom, then we'd see more emphasis being placed on languages other than JavaScript. But CmonDev is right, we just don't see that happening. We see a monoculture developing around JavaScript and only JavaScript. In general, monocultures of any type are an unhealthy thing, and lead to stagnation.
The great thing about JavaScript is that it can be used as a compilation target, like bytecode. There are already many compilers that do that, like ClojureScript and Scala.js, I'm working on a mixed JVM/JS project in Scala right now. And I get the secure sandbox, the portability of JS and the tools for free. Which is the advantage of a standard, otherwise I might as well go native.
And given that you can compile C++ to JavaScript with really good results, I really don't get what problems you're trying to solve. And yes Mozilla is responsible for making this happen, getting everybody on board with ASM.js, even Microsoft. And I find that to be a great development.
Compile C to a subset of LLVM bytecode.
I fail to see how the second is harder than the first. In both cases, there are major implementation issues to overcome. The difference is that LLVM bytecode was designed to deal with this while asm.js is contorting an already problematic language and making unofficial (non-spec) guarantees.
The argument that compilers to JS exist is a non-issue because there already exist compilers from JS to LLVM (eg. javascriptCore). LLVM already has advanced optimizers that are well tested, so writing compilers targeting LLVM will already give a performance head start.
The argument that the bytecode is somewhat implementation specific does not matter for three reasons. The first is that a monopoly on implementation does not matter unless the choice was wrong (and even today, all the major JS engines share a lot of similarity in their high-level structure). Secondly, there are multiple LLVM JITs and native compilers around with each one having it's own take on implementation which seems to indicate that LLVM isn't that closely tied to a single way of doing things. Finally, in JavaScript itself, new features are not simply designed with the programmer in mind. A major factor is whether the big 4 find it easy to implement showing that JavaScript itself is implementation specific to those 4 companies opinion. Couldn't a bytecode do the same if necessary?
As there exists a way to compile LLVM code to JS code, backward compatibility with older browsers is simply a matter of adding an additional step in the compilation chain. The JS could check if LLVM was supported and browsers without support would simply ignore script tags that use LLVM.
As to the question of "why not just stick with JavaScript". I program in JS every day and really like most of the good parts of the language. This does not excuse the aweful parts of the language nor the problems it causes in real world companies where most programmers aren't "rock stars".
For a programmer new to JavaScript (even if they already have lots of programming experience), takes a disproportionately long time compared to other languages and until this is learned, the programmer is probably installing land mines that will need to be fixed later. Every fundamental feature of JavaScript (with the possible exception of closures) has a gotcha that you will run into (and not esoteric gotchas -- many of these will be run into very early on).
Even the most advanced of us find reasoning about JS inheritance to be nearly impossible for non-trivial systems and teaching this is even harder.
Aside from ubiquity, what reason is there to keep the language around? The only awesome features are that it's very function centric (minus proper tail calls) and it's combined dict/object take on prototypal inheritance is very nice to work with (unless you actually need to use the inheritance part).
How long would it take for Mozilla, Google, Apple, and Microsoft to standardize on a common bytecode and then write compatible implementations for x86, ARM, and other platforms? NaCL or PNaCL are contender bytecodes, but Google is the only browser vendor that is interested.
JS is a standard language that already exists, so asm.js is backwards compatible with browsers that were shipped even before asm.js existed. The arguments for a universal bytecode over asm.js are mostly about elegance and "Better is Better." asm.js is definitely "Worse is Better" design.
http://mozakai.blogspot.com/2013/05/the-elusive-universal-we...
Also, with Rust, they are already developing another language.
You might be right with the monoculture problem, but JS is a big thing with many developers, it would be dumb not to use this resource.
Pandering to language fanboys isn't a good idea. Javascript is a good enough language, and if you don't like it, write in something else and compile it to javascript.
I guess what I am saying is that it seems like we are stuck with javascript for historical reasons and it's a shame that we aren't exploring other options. Of course, I can also completely see that sticking with javascript is the most practical option as well.
Yes, any concrete compilation target has limitations, including JavaScript.
For example, in JavaScript, there are no 64-bit integers, which can slow down some code. As another example, strings on .NET and Python are different, causing Python on the CLR to either behave differently or run more slowly.
I think the important thing to realize is that there isn't a "perfect" compilation target. What we really want is a target that is (1) fast on all languages, (2) portable to run on all OSes and architectures, and (3) safe to run in a sandboxed manner. There is no target I am aware of that maximizes all 3. All we can do is try to get close.
I would say that JavaScript is doing pretty well in that respect already (that is, like all other options, it isn't perfect, but it's relatively decent), and remaining missing features are being worked on.
> it's a shame that we aren't exploring other options.
I don't think that's true at all - such experiments have been done! We had or have ActiveX, Java, Flash with its multiple VMs, Silverlight/.NET, NaCl, PNaCl, and others I forgot.
Given the performance of JavaScript engines today, those experiments of other VMs don't show a big enough reason to prefer them. asm.js code runs fast enough to run AAA game engines, which is a very good test.
The language monoculture problem exists just as much on other runtimes as it's does on the Web. It's just nobody is expected to write in JVM or CLR.
That's why projects like asm.js and Emscripten are important. These projects show vendors what things are needed to make JavaScript into a better compile target so that someday writing in other language for the Web is as natural as it is on JVM and CLR.