jvilk

Absolutely true. I believe I proposed that in our correspondence, but it was a dealbreaker for bck2brwsr and TeaV M, which is understandable.

I misspoke -- you can polyfill WeakSet, but you cannot polyfill WeakMap, since you do not know when you can shrink the map. (But you still cannot use it to emulate weak references, since you need a strong reference to get data out of the map.)

Actually, those are not sufficient to implement weak references, and have a much different use case! With WeakMap and WeakSet, the keys are weakly referenced, hence the names. If you have a WeakMap, you can't produce a value stored in the map without a strong reference to a key.

You can actually polyfill WeakMap and WeakSet. You can't do the same for weak references.

Haha, I've actually tried to do this. The only missing link, I believe, is to add a Nashorn/Rhino backend to BrowserFS (Doppio's file system library) so that Doppio can access the filesystem that Rhino is running in to load the JDK.

If that sounds like fun, I take pull requests [0]. :)

[0] https://github.com/jvilk/browserfs

If the authors compressed the JAR files into a single bundle, storing the data into a BrowserFS-created IndexedDB file system removes decompression/extraction overhead on subsequent visits.

If they didn't.... then it might be sufficient, but I am not sure how well the browser cache handles large files! How long until it evicts them? Is there an upper bound on the size of cached items? etc.

> It would be really good if gwt,doppio,teavm all agreed on a single api facade for targeting the browser API.

Unfortunately, that is impossible due to differing requirements; I've actually talked with the teavm and bck2brwsr folks [0]. Doppio requires asynchronous function calls to support preemptive multithreading. TeaVM, GWT, and bck2brwsr all map Java methods directly to synchronous JavaScript methods, preventing them from supporting multithreading.

This is actually one of the larger differences we describe in the academic paper that sets Doppio apart from those projects and Emscripten [1].

[0] Start of the conversation: https://groups.google.com/d/msg/plasma-umass-gsoc/uuZk09CGIM...

[1] PLDI 2014 paper (Sorry, I know I'm linking this a lot in the comments thread, but I promise it's a fun read!): https://plasma-umass.github.io/doppio-demo/paper.pdf

It's true that SharedArrayBuffer is coming, but there's no way to share objects from what I understand. Since Doppio maps JVM objects to JS objects, it cannot take advantage of shared array buffers to emulate shared memory threads.

Doppio uses JavaScript's garbage collector. (As a result, it cannot support weak references.) As for concurrency, thread quanta are mapped to JavaScript events, so Doppio can emulate preemptive multithreading. Doppio potentially preempts a "thread" at each function call.

The nitty gritty details are in the PLDI 2014 paper [0]. Some details have slightly changed, though (e.g. DoppioJVM supports JDK8 now).

[0] https://plasma-umass.github.io/doppio-demo/paper.pdf

Actually, Doppio is an artifact from my own research, so there is a very good reason "why" [0]! Basically, if you want to re-use your existing, well-tested code in the browser, it is quite difficult. The browser environment is very different from the environment that most programs expect. Doppio bridges the gap between the environment that these programs expect and the environment that the browser presents, making it possible to bring a full JVM into the browser that can run complicated, unmodified programs.

[0] Doppio: Breaking the Browser Language Barrier paper from PLDI 2014: https://plasma-umass.github.io/doppio-demo/paper.pdf

The main goal of Doppio was never speed -- it was compatibility [0]. It's actually a JVM interpreter at present, leading to noticeable slowdown over a native JVM. Thus, there are many opportunities for performance improvements!

A recent contributor is starting to add a JIT to Doppio, which is a step in the right direction [1].

[0] Our academic paper from PLDI 2014 has more details, although the project has evolved since then (it's now JDK8 compatible, for example): https://plasma-umass.github.io/doppio-demo/paper.pdf

[1] https://github.com/plasma-umass/doppio/pull/443

The last time I checked, doppio can run the Closure compiler [0].

[0] https://github.com/plasma-umass/doppio/issues/317

Yeah, Doppio needs to download the entire JDK to run, since it's a full-featured JVM (JRE for running Java programs, JDK for javac so it can compile them). Compressed, it's ~30MB.

The authors of this project can preload the JDK with a progress bar and stash it into IndexedDB, since Doppio's file system, BrowserFS, supports arbitrary backends [1].

[1] https://github.com/jvilk/browserfs

Lead author of Doppio here! This is quite cool. I don't recognize the authors of this work, so I was unaware of the project and was surprised to see it on the front page of HN!

If you find any issues with Doppio or have any requests, feel free to open up an issue on our GitHub issue tracker.

Actually, the master version of Doppio can run Rhino AND Nashorn!

(I'm the primary author of Doppio.)

I actually embarked on a similar Python VM called Ninia [1] awhile back, but shelved it as other projects became more important. Ninia supports multiple threads and preempts execution to give the browser breathing space, just like my JVM in JavaScript, DoppioJVM [2].

One of the challenges of Python is its objects are quite complex/ad-hoc, and can be overridden by the user. I mapped out [3] how I wanted to map Python objects to JavaScript objects, but never had the time to implement it fully. (That document covers Python 2.7; I'm sure there are differences for 3.) It looks like this project has a lot of work to do if it wants to have parity with a native Python VM! But that's part of the fun of writing these things.

Best of luck on the VM! If you need a file system to plug into the VM for loading modules/implementing the FS API, do check out my BrowserFS library [4], which is currently in use at the Internet Archive [5] and is also used in Ninia/DoppioJVM. You can also cop things from Ninia, as it is MIT licensed.

Oh yeah, and if you need a Python compiler/parser, you can simply run the PyPy interpreter's parser+compiler [6] in your intepreter once it is reasonably complete. It is written in 100% Python!

[1] https://github.com/plasma-umass/ninia

[2] https://github.com/plasma-umass/doppio

[3] https://github.com/plasma-umass/Ninia/wiki/Mapping-Python-Ob...

[4] https://github.com/jvilk/browserfs

[5] http://ascii.textfiles.com/archives/4924

[6] https://pypy.readthedocs.org/en/latest/interpreter.html

> It works, except when the UI thread is blocked, because messages are routed through the UI thread.

This bug actually causes a ~40% slowdown in one of my projects, since I use sendMessage() in a Worker context to quickly yield to the browser. I didn't mention it, since I figured it may have been fairly obscure... I'm somewhat glad to hear that others are experiencing pain from it. It gives me some hope that it'll eventually be addressed!

Absolutely agreed. We should be able to debug Web Workers with development tools (e.g. set breakpoints / examine state / etc), nest Web Workers, use console.log from within a Worker, and construct Web Workers from Blob URLs. It's infuriatingly difficult to work with Web Workers without these features, which are missing from most browsers!

I think there's a chicken-and-egg problem with regards to Web Workers: Developers do not use Web Workers because they are hard to use/debug/develop with, and browser vendors do not improve their Web Worker implementations because they have limited adoption. Someone needs to break the cycle.

BrowserFS actually supports Dropbox integration already... so you could do the same with a Dropbox shared folder.

(Sidenote: I'm the author of BrowserFS, and helped implement this feature.)

Well, it's not infeasible. We don't use localStorage -- we use IndexedDB, which can store gigantic files. But I've never tried stuffing 100+MB into IndexedDB before.

(Sidenote: I'm the author of the BrowserFS library, and helped implement this feature.)

You can also chat with me (John Vilk), the lead grad student/dev on Ninia/Doppio/etc. I'm happy to answer any questions you may have!

Like Sublime Text, it's somewhere between an IDE and a text editor. For example, both Sublime Text and Atom have a TypeScript plugin that uses the TypeScript language service to highlight compilation errors as you type, and to provide semantically-correct autocomplete suggestions. These are features typically expected in an IDE.

However, neither integrates with a debugger like a traditional IDE. You'll likely drop to a terminal or external tools to run / test / debug your program. (I'm sure they both have a plugin to make terminal commands a keyboard shortcut away, though.)

Hope that helps. It's a fantastic editor, although it can be a bit RAM heavy on my aging MacBook Air.

If you're talking about TypeScript, I don't believe that mantra is applicable when the extensions are open source, liberally licensed (Apache License), cross-browser, and developed in the open. There's nothing proprietary or exclusive about it.

Understood. If `ffiFunc()` returns an empty array at a double call site, does ASM.js just accept it as `0`? (`+[]` is `0`). Or are there runtime checks that verify that the return value is a numeric type?

btw, I hope these questions make it clearer why I grumped a bit about the specification, and result in a more robust spec!

Follow-up question.

How does it deduce the return type of a foreign function? Can foreign functions return values?

Normally, ASM.js functions require an annotation on the return statement [0].

[0] http://asmjs.org/spec/latest/#return-type-annotations

The example doesn't use the FFI, though. And I understand the graph of value types and the restrictions that ASM.js imposes on ASM.js code, but there's no clear linkage between that and the FFI.

Some other FFIs require you to encode type information in some manner to uphold the guarantees of the language. It's not clear from scanning the specification if that is the case here, as the FFI is only briefly mentioned in passing.

Finally, ASM.js doesn't validate the return expression of external functions (it does for ASM.js code [0]). How does it deal with foreign functions that return values? What type does the return value take? Or does there need to be an annotation at the call site?

[0] http://asmjs.org/spec/latest/#return-type-annotations

Ah, I wasn't aware there was an actual repo associated with ASM.js. The example doesn't show how you call into the module with `consoleDotLog` defined, though. I know that sounds like a triviality, but complete examples are really useful to cut through any possible ambiguity!

I would definitely lobby to get something smaller and concise into the spec under the "Putting it All Together" heading! You could modify the existing example in the spec to include an external function definition and call.

> What extra info are you looking for?

Essentially, a complete executable example of a simple ASM.js program that involves a foreign function, including processing return values. (I imagine if it's this simple, then return values are handled using the same annotations as ASM.js functions?)

While I understand that specs don't necessarily have to have examples, I believe it would benefit the community to have one in the ASM.js spec.

Thanks for clarifying here, though! I now understand.

Are there any tutorials at all on how to use ASM.js's Foreign Function Interface (FFI)? The specification lacks examples, and seems to be very underspecified. :(

Note that the FFI is a crucial component of ASM.js, as everything in the browser is external to ASM.js (DOM/any strings/any objects/etc). It seems weird that there's so much hype around ASM.js, yet there's very little written about the FFI or how to use it. Any project that uses ASM.js is going to need to interact with it.

Also, are there any projects besides Emscripten that use ASM.js, or is the push to put ASM.js into these browsers due purely to Emscripten?

While I dig the idea, it's important to note a few issues with the dataset. Take the presented data with a huge grain of salt.

First, many repositories are not a single language. For example, this PHP framework is reported as a CSS project [0]. While it has more lines of CSS than PHP, it only has a single CSS file [1].

Second, GitHub has a problem with correctly identifying programming languages. For example, PrimeCoin [1] is identified as one of the most popular TypeScript repositories, but it has 0 lines of TypeScript code. Instead, it has... large localization files with the extension *.ts [2]. BitCoin used to have the same problem, but it looks like GitHub hack fixed it for that particular repository as less popular forks of BitCoin still have this issue.

It took me a few minutes to find these examples, just by examining trending repositories [4]. I'm sure there are many more. So do not be rash in drawing conclusions from this data! :)

[0] https://github.com/laravel/laravel

[1] https://github.com/laravel/laravel/blob/master/public/css/ap...

[2] https://github.com/primecoin/primecoin

[3] https://github.com/primecoin/primecoin/tree/master/src/qt/lo...

[4] https://github.com/trending

> ...TypeScript doesn't purport to analyze the correctness of regions of code that lack type annotations.

TypeScript infers the types of local variables. For example, the following unannotated code would cause the TypeScript type checker to fail:

    // error TS2345: Argument of type 'number' is not assignable to parameter of type 'string'.
    [1, 2, 3].join(4);

However, even when the TypeScript typechecker fails, TypeScript still produces JavaScript output. As a result, you can use TypeScript to incrementally type your program, and simply choose to ignore type checking errors. TypeScript only fails to produce output if there's a syntax error, or if you are using TypeScript import statements without specifying a module type.