On Saturday, September 29, 2012 2:37:58 AM UTC-6, David Wright wrote:
Ah, but npapi and mp3 are super easy to implement when compared with
And don't forget you also need to have all of this evil cruft fully
represented in the DOM. On the one hand modern browsers are marvels of
engineering. On the other, they had to be, because everything was designed
by committees, some of which were entirely comprised of people who would be
intensely pleased to if their competitors were entirely incapable of
building this ridiculously baroque and questionably useful thing they'd all
met to describe.
Web browsers are amazing. Web standards are quite often absolutely
laughable. I'm frankly astounded that the thing works as well as it does
Yeah. On both parts. Well, speaking of the DOM, its API was a fundamental
mistake on just about every level. Pity.
JS implementations are one of the things that really shouldn't be
considered subproject. I'd presume to plug in something like V8 and be done
with it. However, I'd like to have some middle-ground/infrastructure like a
"go-libc", whereby without too much effort, cgo dependencies could compile
without needing to link into anything non-exotic, even statically, aside
from a shim into the go runtime. I agree that for small problems cgo is a
good shim until common facilities get natively written in Go, but for big
projects, like a web browser, it makes little sense to try to rewrite
something as big as v8 or webkit, just to have it "pure". My own stance is
that if I can statically compile it as mentioned above, and in the way that
has been done for sqlite, for example (replacing all libc stuff with calls
back into go), then it's pure enough.
As for stuff like webkit -- a lot of the brower ideas I want to do in a
clean, consistent, non-hackish way are non-mainstream enough (and certainly
not for the average user) that I'm not sure if webkit will produce a lot of
friction, or make some things impossible based on design assumptions. I
haven't looked into it enough, though. The best analogy I can make are all
the programs that run on X11 that either assume the presence of
non-standard "desktop environment" quirks that go above and beyond (or
around) netwm, while utterly failing to work as expected on, e.g. tiling
Regarding flash: I'm not suggesting there will be some abrupt exodus of
developers away from flash and toward html5 equivalents, but to my
knowledge, the only thing that flash really provides that the combination
audio manipulation/synthesis, and that was only added to flash in version
10, iirc. As for the other stuff:
Video Chat: yes, in standards process, some working examples.
3D stuff: (shockwave in this case): kinda -- webgl has security setbacks,
but is eventually doable.
Prerecorded Audio: yes -- APIs are much saner in html5.
Microphone Input: yes.
Low overhead messages: websockets
Input device handling: wrapping libraries like JQuery make this reasonably
Fullscreen: something is in standards process, iirc.
Font/typographic stuff: yes. Much cleaner, more capable with much less code
than flash now (using css).
Background File Uploading: will probably be addressed at some point, if not
At any rate, many systems do not have flash installed anyway -- while much
to recall that Adobe has been pushing a lot of sub-specs that make a lot of
the "killer features" of flash obsolete. My understanding is that Adobe is
considering flash to be a "phase out" product, instead focusing on
(as opposed to flash through their acquisition of macromedia) is much more
attuned to doing (for one thing, "editors" only need to support mac and
windows, as far as they're concerned).