From mboxrd@z Thu Jan  1 00:00:00 1970
From: dexen deVries <dexen.devries@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Date: Mon,  2 May 2011 18:48:28 +0200
User-Agent: KMail/1.13.6 (Linux/2.6.39-rc4-l33+; KDE/4.5.5; x86_64; ; )
References: <c1a1206bd085412e359124d3ab9fcc0e@terzarima.net>
In-Reply-To: <c1a1206bd085412e359124d3ab9fcc0e@terzarima.net>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201105021848.29004.dexen.devries@gmail.com>
Subject: Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
Topicbox-Message-UUID: db253644-ead6-11e9-9d60-3106f5b1d025

On Monday 02 of May 2011 18:29:13 Charles Forsyth wrote:
it's hard to see how a fast Javascript implementation,
> (...) it's hard to see how a fast Javascript implementation,
> for example, is especially dependent on the operating system
> on which it runs (...)

<![PESSIMISTIC VIEW[

that used to be the case, but much not anymore. some popular websites are JS-
heavy, and the browser has to do heavy lifting. various speedups were
implemented by popular browsers -- and are practically necessary for use of
those sites. one popular speedup is compilation of JS to native code. this
depends to a good deal on paging for protection (and perhaps GC, not sure).
this requires some co-operation with the OS.


another point of dependence (read: infinite surface of dependence) is the
interaction of JS and DOM with OS-specific input model. today not only
hyperlinks and comboboxes are widgets, but a lot of seemingly plain areas are
made active, both on click and on mere hover, (for good reasons and with good
use).


also the output model: (re-)drawing screen content. both good old 2D APIs and
(for IE, at least, but will in near future for others) interacting with GPU
for access to accelerated drawing primitives, working neatly with composition
and avoiding costly cascades of copying image data around system memory and to
video memory.


yet another point, probably best illustrated with FF: some plugins contribute
functionality via JS code. supporting such plugins also should have some
platform-specific dependencies.


something having little to do with JS itself, but important for website
rendering: font support. the second worst problem in computing, IMHO. some
websites require pixel- or even sub(!)-pixel accuracy, lest they end up
looking all messy and/or end up with overlapping widgets. yes, it runs kinda
contrary to the purpose of HTML and CSS. another fine technical decision by
technically unqualified managerial personnel, sigh.


last but not least, google's NaCl (a.k.a. Native Client) which uses certain
properties & aspects of memory protection for secure execution of binary code
from foreign sources (yeah, i know we've been there; but this one oughta work,
as it depends on silicon, not digital signatures from one gatekeeper company).
it again depends on the OS to a degree for running the code. i believe this is
an interesting thing, and possibly a viable alternative to including explicit
support for countless alternative scripting languages directly into browsers.


to wrap it up: i don't believe in high-performance cross-platform browsers.
they either need helluva lots of maintenance & chasing the evolving platforms,
or not perform all that well.

]]>

--
dexen deVries

``One can't proceed from the informal to the formal by formal means.''