plasma-umass

doppio

TypeScript2012–2020

plasma-umass / doppio

doppio

Breaks the browser language barrier (includes a plugin-free JVM).

Web Development Languages & Compilers

Explore on GitHub Read Hacker News discussions

14Distinct people

24Mentions

0Explicit recommenders

2.2KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Breaks the browser language barrier (includes a plugin-free JVM).

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

jvilk/browserfs · linked in 3 of the same discussions
gopherjs/gopherjs · linked in 2 of the same discussions
plasma-umass/ninia · linked in 2 of the same discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year24 dated mentions

Observed mentions: 2012-05-02 12:00:05 UTC to 2020-07-25 09:54:55 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2012	2012-01-01 00:00:00 UTC	2013-01-01 00:00:00 UTC	2	2	0
2013	2013-01-01 00:00:00 UTC	2014-01-01 00:00:00 UTC	6	0	6
2014	2014-01-01 00:00:00 UTC	2015-01-01 00:00:00 UTC	4	0	4
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	1	0	1
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	7	0	7
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	3	0	3
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	0	0	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	1	0	1

What Hacker News says

24 sources

efreak·Jul 25, 2020

There's been a few flash runtimes in javascript and other languages. Most of them have been long abandoned. https://github.com/tobeytailor/gordon https://www.gnu.org/software/gnash/ In development: https://github.com/lightspark/lightspark https://github.com/ruffle-rs/ruffle And then the most recent one, CheerpX, which as I understand it runs the Adobe flash runtime itself via wasm: https://leaningtech.com/pages/cheerpxflash.html Which brings me to Java. Java left the browser even before flash did. Not all of these are javascript jvms, but all of them are intended to run Java applications in the browser (some are transpilers, others require code changes): https://leaningtech.com/pages/cheerpj.html https://github.com/java2script/java2script (this links to some less-complete projects) https://github.com/Jivings/jsJVM https://github.com/nurv/

Read the rest

BicaVM https://github.com/st-js/st-js/ https://github.com/plasma-umass/doppio https://github.com/jtulach/bck2brwsr https://www.keithschwarz.com/+script/ https://github.com/robterrell/orto https://github.com/jdstroy/JavaPoly https://gitlab.com/neoexpert/jvm/-/blob/master/jsjvm/README....

In On how Flash games shaped the video game industry

sandGorgon·Jul 12, 2017

I think it is impolite not to give accurate credit. It is Typescript... and not vanilla javascript. https://github.com/plasma-umass/doppio

In Doppio: JVM written in JavaScript

azakai·Jun 19, 2017

Another related project is Doppio, an open source JVM written in TypeScript, https://github.com/plasma-umass/doppio

In CheerpJ Applet Viewer – Runs Java applets without a local Java installation

muizelaar·Mar 16, 2017

To get good performance on running JVM or .NET WASM will probably need more than just GC support. JVM/.NET JITs rely on inline-caches that aren't currently expressible in WASM. There are ideas about ways to make this work, but it will be a while. The other thing preventing the use of JVM or .NET is that porting the runtimes over isn't easy. i.e. You can already run this bytecode in a browser but it isn't widely used. (http://jsil.org/, https://github.com/decatur/j2js-compiler, https://github.com/plasma-umass/doppio, https://github.com/mozilla/pluotsorbet etc)

In Why WebAssembly Is Faster Than Asm.js

emeryberger·Dec 12, 2016

Doppio (https://github.com/plasma-umass/doppio) is exactly this: a POSIX layer (for a single process), while Browsix is a Unix layer. Both are JS only. Doppio implements a ton of libc functionality, enough to host a full JVM interpreter (see http://plasma-umass.github.io/doppio-demo/). Doppio contains BrowserFS (available separately as https://github.com/jvilk/BrowserFS), an in-browser file system that abstracts over local storage and lets you mount remote filesystems like Dropbox, Zip files, and more. Archive.org is using it for all of its DOS and Windows games.

In Run Unix processes inside your browser

jpolitz·Oct 11, 2016

My conjecture: Scheduling with priority is pretty easy across these systems. The dependency graph transfer would be outside the scope of what they already tackle, and require new engineering. In Pyret, I prototyped virtual threads at one point, and each thread had the same amount of "fuel" before yielding (at the top of every compiled function in Pyret, there's a decrement to a "fuel" counter, and when it reaches zero, the stack is unwound). That could easily be configured on each start/restart of a thread to provide different amounts of fuel, or to re-order the restarts based on typical thread-scheduling policies. Whalesong does the same thing with fuel, so I imagine it could be extended similarly. I don't know how Doppio and GopherJS do scheduling in detail, but here's where I'd start looking: 1. GopherJS looks like it's a simple que

Read the rest

ue based on the code around https://github.com/gopherjs/gopherjs/blob/master/compiler/pr... (goroutines push themselves onto a list when they pause, then the next one starts up again) 2. Doppio implements a thread pool abstraction, so you can simulate JVM threads in the browser: https://github.com/plasma-umass/doppio/blob/master/src/threa...

In React Implementation Notes

jpolitz·Oct 10, 2016

Part of these notes, Fiber [0], reminds me of a half-joking "corollary" to Greenspun's Tenth Rule (credit @shriramkmurthi): Any sufficiently complicated JavaScript program contains an ad hoc, informally-specified, bug-ridden, slow implementation of delimited continuations. Control over continuations and the stack is our main compiler and runtime engineering hurdle in Pyret. Projects like Doppio [1], WeScheme [2] and GopherJS [3] go through staggering amounts of overhead and effort to get pausable, resumable, and stoppable computation in the browser environment. I'm excited to see how this develops in React with fiber. It's much more application-specific, but it's the same underlying problem. [0] https://facebook.github.io/react/contributing/codebase-overv... [1] https://github.com/plasma-umass/doppio [2] https://cs.brown.edu/~sk/

Read the rest

Publications/Papers/Published/yk-wh... [3] https://github.com/gopherjs/gopherjs#goroutines

In React Implementation Notes

jvilk·May 8, 2016

One of Doppio's explicit goals was to leverage existing resources in the browser to bring conventional programming languages to the web on top of JavaScript. Using WebAssembly would prevent Doppio from using the browser's garbage collector; we would have to write our own. It would also prevent Doppio from mapping JVM objects onto JavaScript objects. The WebAssembly standard is constantly evolving, and now contains some ambiguous statements regarding the ability to take advantage of the browser's GC [0]. Considering WebAssembly's current focus on C/C++ code, I do not believe this will come to fruition anytime soon. If it does, I do not see how it would noticeably improve Doppio's current performance, which is bottlenecked primarily by its interpreter. A contributor is working on a JIT right now to make execution faster [1]. Hope that clari

Read the rest

fies! [0] https://github.com/WebAssembly/design/blob/master/GC.md [1] https://github.com/plasma-umass/doppio/pull/443

In Java Polyfill for the Browser

jvilk·May 8, 2016

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

In Java Polyfill for the Browser

jvilk·May 8, 2016

The last time I checked, doppio can run the Closure compiler [0]. [0] https://github.com/plasma-umass/doppio/issues/317

In Java Polyfill for the Browser

jvilk·Apr 16, 2016

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 o

Read the rest

ut 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

In Jaspy – A Python VM written in JavaScript

emeryberger·Aug 10, 2015

We (PLASMA @ UMass, http://plasma.cs.umass.edu) have a project with similar aims that is somewhat further along: Ninia (https://github.com/plasma-umass/Ninia). Ninia is a Python bytecode interpreter in TypeScript. It is also being integrated with Doppio, a runtime system for running "conventional" programs inside the browser (https://github.com/plasma-umass/doppio), also from our group. DoppioJVM uses Doppio to run JVM bytecode in the browser (http://www.doppiojvm.org/). For technical details on both of these, see our PLDI 2014 paper: "Doppio: Breaking the Browser Language Barrier", by John Vilk (https://jvilk.com/) and Emery D. Berger (http://emeryberger.com): https://dl.acm.org/citation.cfm?id=2594293 (@ ACM), http://people.cs.umass.edu/~emery/pubs/doppio.pdf (non-paywall), video presentation here: https://vimeo.com/106106738. Abstract:

Read the rest

Web browsers have become a de facto universal operating system, and JavaScript its instruction set. Unfortunately, running other languages in the browser is not generally possible. Translation to JavaScript is not enough because browsers are a hostile environment for other languages. Previous approaches are either non-portable or require extensive modifications for programs to work in a browser. This paper presents Doppio, a JavaScript-based runtime system that makes it possible to run unaltered applications written in general-purpose languages directly inside the browser. Doppio provides a wide range of runtime services, including a file system that enables local and external (cloud-based) storage, an unmanaged heap, sockets, blocking I/O, and multiple threads. We demonstrate Doppio's usefulness with two case studies: we extend Emscripten with DOPPIO, letting it run an unmodified C++ application in the browser with full functionality, and present DoppioJVM, an interpreter that runs unmodified JVM programs directly in the browser. While substantially slower than a native JVM (between 24× and 42× slower on CPU-intensive benchmarks in Google Chrome), DoppioJVM makes it feasible to directly reuse existing, non compute-intensive code.

In Run Python Bytecode in Your Browser

jvilk·Jun 30, 2014

(Apologies in advance if I am misunderstanding the complaint -- I'm assuming 0 prior knowledge on your end, so my write-up below may sound obvious! Sidenote: I've written a JVM, so I've gained an appreciation for some aspects of the JVM, including class resolution [0].) In Java/the JVM, file names unambiguously correspond to your package/module/class names. Given a full class name (e.g. java.lang.String) and the class path (a list of folders/JAR files), the JVM is able to locate the specific file with the implementation of that class. This feature is crucial to how the JVM performs dynamic classloading, as classes can reference other packages/classes with a simple string, and the JVM will fetch the relevant class dynamically at runtime. For example, in the parent comment, gov.nasa.arc.spife.core.plan is the package name, which translates

Read the rest

to the folder /src/gov/nasa/arc/spife/core/plan/. This package name, while verbose, makes sense for NASA, as it corresponds to that organization's hierarchy. gov.nasa corresponds to NASA, arc = NASA's Ames Research Center, spife is probably the project name, and then the rest correspond to packages in that project. This hierarchy makes it clear who has the right to modify particular hierarchies of the namespace, allowing employees to make new packages within their levels of the hierarchy without worrying about name collisions. As a concrete example, it would be troublesome if every research lab decided to use the gov.nasa.util package name. Or worse -- just 'util'. If both of these are libraries, it's feasible that a client application might use both of them... but then the application will discover that it is unable to use both due to a simple naming conflict in library code! I agree that it appears cumbersome and wasteful to those used to editing on the command line (as the files are scattered all over the file system), but it's less visible when using an IDE that coalesces empty folders together. [0] https://github.com/plasma-umass/doppio

In Code.NASA

sanxiyn·Apr 8, 2014

If JVM is your thing, Doppio is a JVM in TypeScript. https://github.com/int3/doppio

In PyJVM – JVM in Python

perimo·Apr 3, 2014

I contribute to the Doppio JVM project (https://github.com/int3/doppio), which we initially wrote in Coffeescript. About 9 months ago, we decided to port the whole thing (~10kloc) to Typescript, and it proved really useful: - Typescript is a superset of Javascript (mostly), so we ported by converting all the Coffeescript sources to Javascript and renaming them with .ts extensions. There was a bit of cleanup involved in getting modules to play nice together, but most of the code ran without modification. - The JS that the Typescript compiler generates is much easier to read, in part due to less "magic" in the language. - It also makes performance much easier to reason about, for the same reasons. One issue that bit us several times was Coffeescript's auto-return feature, which was invisibly accumulating large arrays of values from our inte

Read the rest

rpreter's bytecode loop! This is no longer a concern with the current Typescript codebase. - The inner workings of the JVM are fairly complex, so enforcing types at compile-time actually does catch bugs before they happen.

In Announcing TypeScript 1.0

Showing the 15 most recent of 24 sources. Enable JavaScript to search and browse every indexed mention.