
The Elusive Universal Web Bytecode - joubert
http://mozakai.blogspot.com/2013/05/the-elusive-universal-web-bytecode.html?m=1
======
CyberDildonics
I heard about a project called Oak that was supposed to do this, never heard
what happened to it...

~~~
DonHopkins
It got renamed, then somebody made a backroom deal to borrow the new name for
another totally different language in order to trick people into confusing the
two languages, then the other language became much more popular and widespread
than the one that used to be called Oak, totally taking over the browser, and
making good headway at taking over the server too.

Incidentally, Arthur van Hoff just pointed out:

>Time flies. This week it is 20 years since we announced Java...

"Why Sun Thinks Hot Java Will Give You a Lift" \- March 23 1995

[http://web.archive.org/web/20060819094743/http://java.sun.co...](http://web.archive.org/web/20060819094743/http://java.sun.com/features/1998/05/images/merc_large.gif)

~~~
arethuza
I blagged a copy of Java from Arthur a while before that when I found out he
was working at Sun - I'd used HyperNeWS for quite a while and was in awe of
his programming skills.

Edit: Are you this DonHopkins?

[http://art.net/~hopkins/Don/hyperlook/index.html](http://art.net/~hopkins/Don/hyperlook/index.html)

~~~
DonHopkins
That's me. While I was working at Sun in '90-91 on NeWS, we tried very hard to
convince management to hire him to work on HyperNeWS for TNT, but Sun wouldn't
give us a requisition (because they intended to kill NeWS, not save it). So I
quit Sun and moved out to Glasgow to work with him at the Turing Institute on
HyperLook, and ported SimCity to HyperLook.

HyperNeWS aka HyperLook was like HyperCard implemented with PostScript
programming and graphics, plus networking. In that alternate universe,
PostScript would have been the universal bytecode for the web.

[https://www.scribd.com/doc/77192884/HyperLook-Product-
Info](https://www.scribd.com/doc/77192884/HyperLook-Product-Info)

[https://www.scribd.com/doc/77164708/HyperLook-SimCity-
Manual](https://www.scribd.com/doc/77164708/HyperLook-SimCity-Manual)

Arthur's programming and entrepreneurial skills are indeed awesome, and I'm
glad I quit my day job at Sun and left the country for the opportunity to work
with him! He's now an advisor to my current company:
[http://pantomimecorp.com/the-team](http://pantomimecorp.com/the-team)

~~~
arethuza
I actually presented a paper at the 2nd International Conference on the Web in
Chicago in '94 about "Extending W3 Clients" which including a suggestion for
adding a standard bytecode interpreter to web browsers.

I stopped working on that when I found out about Oak/Java in early '95.

~~~
DonHopkins
You might get a kick out of Sun's proposal for "NFS 3.0" aka "NeFS". The basic
idea was to put a PostScript interpreter in the kernel for extensibly and
efficiently executing distributed and even local file system operations. It
not only cuts down on network transactions for the same reason NeWS and AJAX
does, but even locally you can avoid billions of context switches by executing
"find" and tasks like that in the kernel, for example.

The Network Extensible File System Protocol Specification 2/12/90

[http://www.donhopkins.com/home/nfs3_0.pdf](http://www.donhopkins.com/home/nfs3_0.pdf)
(pages in reverse order)

Introduction

The Network Extensible File System protocol (NeFS) provides transparent remote
access to shared file systems over networks. The NeFS protocol is designed to
be machine, operating system, network architecture, and transport protocol
independent. This document is the draft specification for the protocol. It
will remain in draft form during a period of public review. Italicized
comments in the document are intended to present the rationale behind elements
of the design and to raise questions where there are doubts. Comments and
suggestions on this draft specification are most welcome.

1.1 The Network File System

The Network File System (NFS™) has become a de facto standard distributed file
system. Since it was first made generally available in 1985 it has been
licensed by more than 120 companies. If the NFS protocol has been so
successful why does there need to be NeFS ? Because the NFS protocol has
deficiencies and limitations that become more apparent and troublesome as it
grows older.

1\. Size limitations. The NFS version 2 protocol limits filehandles to 32
bytes, file sizes to the magnitude of a signed 32 bit integer, timestamp
accuracy to 1 second. These and other limits need to be extended to cope with
current and future demands.

2\. Non-idempotent procedures. A significant number of the NFS procedures are
not idempotent. In certain circumstances these procedures can fail
unexpectedly if retried by the client. It is not always clear how the client
should recover from such a failure.

3\. Unix bias. The NFS protocol was designed and first implemented in a Unix
environment. This bias is reflected in the protocol: there is no support for
record-oriented files, file versions or non-Unix file attributes. This bias
must be removed if NFS is to be truly machine and operating system
independent.

4\. No access procedure. Numerous security problems and program anomalies are
attributable to the fact that clients have no facility to ask a server whether
they have permission to carry out certain operations.

5\. No facility to support atomic filesystem operations. For instance the
POSIX O_EXCL flag makes a requirement for exclusive file creation. This cannot
be guaranteed to work via the NFS protocol without the support of an auxiliary
locking service. Similarly there is no way for a client to guarantee that data
written to a file is appended to the current end of the file.

6\. Performance. The NFS version 2 protocol provides a fixed set of operations
between client and server. While a degree of client caching can significantly
reduce the amount of client-server interaction, a level of interaction is
required just to maintain cache consistency and there yet remain many examples
of high client-server interaction that cannot be reduced by caching. The
problem becomes more acute when a client’s set of filesystem operations does
not map cleanly into the set of NFS procedures.

1.2 The Network Extensible File System

NeFS addresses the problems just described. Although a draft specification for
a revised version of the NFS protocol has addressed many of the deficiencies
of NFS version 2, it has not made non-Unix implementations easier, not does it
provide opportunities for performance improvements. Indeed, the extra
complexity introduced by modifications to the NFS protocol makes all
implementations more difficult. A revised NFS protocol does not appear to be
an attractive alternative to the existing protocol.

Although it has features in common with NFS, NeFS is a radical departure from
NFS. The NFS protocol is built according to a Remote Procedure Call model
(RPC) where filesystem operations are mapped across the network as remote
procedure calls. The NeFS protocol abandons this model in favor of an
interpretive model in which the filesystem operations become operators in an
interpreted language. Clients send their requests to the server as programs to
be interpreted. Execution of the request by the server’s interpreter results
in the filesystem operations being invoked and results returned to the client.
Using the interpretive model, filesystem operations can be defined more
simply. Clients can build arbitrarily complex requests from these simple
operations.

~~~
arethuza
That sounds interesting - I'll have a read.

------
falcolas
> some people don't like some of those things

What does that even mean?

So why did the author throw out LLVM byte code again? It's BSD, it has
bytecode compilers for most platforms browsers exist on (100% vs. 50% speed),
and doesn't rely on a subset of another language. It also doesn't have the
requirement to fall back to vanilla Javascript. As an added bonus, Javascript
could easily compile down to LLVM bytecode.

Seems like the author already preferred their answer and threw out some BS to
"justify" their choice.

JS probably will remain the "byte code of the web", but this article adds
nothing to that trajectory.

~~~
mrec
LLVM's IR makes no stability guarantees - it can change from one release to
the next, with no backward compatibility. That's not ideal for something
you're slinging out to the web.

I believe this is the same reason Khronos defined their own IR (SPIR) instead
of using LLVM's. Needs to be stable.

~~~
CyberDildonics
That is one reason, the other is being easy and fast to process with tools.

------
Rusky
The article makes the argument that existing systems are easier to improve
incrementally, while designing new systems is more work and not guaranteed to
succeed.

The problem is JavaScript-as-bytecode is not especially easy to improve.
Anything you want to add/change that would make it a better bytecode has to be
balanced with the language's use by humans.

The solution to one-VM-to-rule-them-all is not to cram everything into a
higher-level system with lots of assumptions (JavaScript) or to ignore
portability (NaCl, LLVM), but to use a bytecode that's low-level enough to
implement the various assumptions needed by higher layers.

That way both C++ and JavaScript can run at full speed as well as have their
implementations changed (even across websites!) without pushing every change
through the browsers- just like native apps, with the browser providing _only_
cross-platform and security, nothing more.

~~~
TazeTSchnitzel
> The problem is JavaScript-as-bytecode is not especially easy to improve.
> Anything you want to add/change that would make it a better bytecode has to
> be balanced with the language's use by humans.

There are very few cases where human use causes problems. goto is the only one
I can think of. Yet we've gotten loads of great improvements in ES6 to make it
a good compiler target, like float32 and better integer multiplication.

------
rikkus
I've pondered this a couple of times. One Ask HN I posted:
[https://news.ycombinator.com/item?id=6773980](https://news.ycombinator.com/item?id=6773980)

A reply to a comment I made on another post says that the CLR and JVM suffer
from GC pauses, which would not be acceptable for web apps.

~~~
fla
GC pauses already occur in most JS engine. They are especially tolerable in a
web app.

------
marcosdumay
I'd settle for a bytecode that supported numbers (instead of only strings),
blocking I/O (in addition to non-blocking), and easy integration with system
(or, in this case browser) utilities.

Javascript happens to have none.

~~~
TazeTSchnitzel
Uh, JS has numbers, blocking IO, and easy integration.

What are you on about?

~~~
marcosdumay
JS implement numbers as strings (has bitten me once).

Last time I looked at, there was no blocking IO at all (there is continuation,
but it does not solve the problem because there isn't any locking mechanism -
yep, I'd like atomic locking at my bytecode too). That's even the main
"selling point" Node.js people throw around as if it was a good thing.

By easy integration I mean the hability of using capabilities available at the
system, but not exported into the language runtime. It can be solved by
something that would let me query the sandbox enviroment for the existence of
a "library" that exports foreign functions, and use it. Also, something that
by the other side lets me write and distribute one such "library" so people
can install them on their browsers let JS use its functionality.

~~~
jdmichal
> JS implement numbers as strings (has bitten me once).

What? JS implements all numbers as 64-bit floating point, which happens to be
able to perfectly represent the 32-bit integer space. It can actually
perfectly represent a 52-bit integer space. See Number.MAX_SAFE_INTEGER [0]
for details.

Now, JS _does_ allow for type coercion between values when using the `==`
operator. Luckily, the `===` operator also exists which eliminates this
effect.

[0] [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER)

> Last time I looked at, there was no blocking IO at all.

What does blocking even mean in a single-threaded event-pump context? Does it
mean other events can be processed while the IO executes? Because that's
exactly what an asynchronous AJAX request does. Or does it mean it blocks the
only thread available? Because that's what a synchronous AJAX call does.

Now, if your argument is that JS doesn't have an async / await construct in
order to make asynchronous AJAX look like synchronous AJAX in the code, then
that's in ES7.

