
ExoBrowser: The Experimentation Platform to Build a Next generation Web Browser - spolu
https://github.com/spolu/breach/wiki/The-Experimentation-Platform-to-Build-a-Next-generation-Web-Browser
======
Groxx
It may not have syncing, but Stainless[1] has a very clever notion of
bookmarks that _are_ sessions. Makes it ridiculously easy to e.g. have a
bookmark for each account you use on site X, and open them all simultaneously.
I absolutely loved it. Unfortunately it's a mostly dead project, though it's
open source now.

[1]: [http://www.stainlessapp.com/](http://www.stainlessapp.com/)

~~~
Sprint
Opera has sessions too, super nice if you want to clean up those 100 tags that
accumulated in research.

~~~
zamalek
I was certain that I had seen it before - I think it was in Opera. The UX
around it was horrible, it somehow got in my way (I can't remember why). I
think the more important problem is how to solve sessions from a UX
perspective.

Another problem is that when you are building up all of those tabs you are
setting up a lot of context in your mind, returning to that context is going
to be jarring or impossible. Maybe a replay feature (to show how you created
that session, link-by-link) would be a nice idea: "remind me what I was
doing."

~~~
mkr-hn
> _Maybe a replay feature (to show how you created that session, link-by-link)
> would be a nice idea_

That sounds like browser history.

~~~
zamalek
That's a valuable and thought-provoking comment that deals with the meat of my
comment.

To make it crystal clear:

Lets say you have 7 tabs open. Your browser history may include many more
websites than were present in those 7 tabs: websites that you skimmed,
rejected and immediately closed during your research, or websites you visited
while slacking off. The history also doesn't describe how you reached those 7
tabs - it describes everything you have seen. 2 of them could be search
results, 5 of them could be pages opened from the search results, and 2 of
those 5 could be navigations done without opening new tabs. There may be 20 or
so tabs that you opened that are now closed. It is not straightforward at all
to manually derive that information from a simple list of sites that you saw.
The replay would consist of seeing yourself navigate to that current state
(ignoring all the abandoned paths a.k.a. closed tabs) - screenshots with the
links you used highlighted as an uninspired example.

 _Live action replay_ might have been more appropriate.

~~~
mkr-hn
It sounds like you mistook my comment for flippancy. I think it's a good idea,
and it sounded like browser history was a good conceptual starting point.

~~~
zamalek
Indeed I did. Thanks for the feedback none-the-less, I guess my comment did
need clarification. This would be really interesting to try out with that
ExoBrowser tech - if I ever had the time.

~~~
spolu
We'll release builds on OSX & Linux in the coming days. It'll then be quite
easy to hack the default browser. We'll write a doc about it as well!

------
AndrewDucker
Isn't this similar to what Firefox does - where the browser UI is written
using javascript and XML - which is why it's so easy to write add-ons for it?

~~~
spolu
There are lots of similarities indeed. Though, the ExoBrowser API goes deeper
than the UI and provides much more leeway to implement stuff directly in JS
and out of C++.

------
est
While the project objectives are very nice, I hope it solves one other
problem, the "contentEditable" problem

In the pre-historical days, web pages are static, served as a file blob, in
one way, or both ways (FTP)

Then there came server side templates, we now have dynamic pages.

Then CGI and Perl came, we have <form> so user could put their contributions
to the server.

Then there's AJAX opened the possibility of "Web apps"

However, all of existing efforts left behind a very basic concept of
HYPERTEXT: It is always read-only or partially read-only. The browser is good
at display HYPERTEXT or manipulating part of it, but not create those.

We have WYSIWYG editors, and the famouse Markdown (and alternatives), they
lowered the level of entry of a "writable" Web.

I hope in one day, users can write hypertext freely, as easy as make an edit
on contentEditable, the user input & interactions could become parsable data,
and the developer's layout/css tweaking and js debugging could be made from
web browser Firebox/DevTool directly back to LESS/Coffeescript.

Browsers, really, should consider shifting from a consumerism tool to an
authoring platform. Branched, incremental and versioned.

My two cents.

~~~
gioele
> I hope in one day, users can write hypertext freely, as easy as make an edit
> on contentEditable, the user input & interactions could become parsable
> data, and the developer's layout/css tweaking and js debugging could be made
> from web browser Firebox/DevTool directly back to LESS/Coffeescript.

If you only care about the content, then a wiki engine with support for
flexible styles should be enough to fulfil your hope.

Instead if you want to be able to completely rewrite a page, including its
layout and behaviour, then you need to take into account that the page you see
is not just "content" but "code + data".

I always wanted to have a "Edit source" button in applications, but then, what
does it mean to "edit the source"? Decent web pages are produced by quite deep
applications stacks composed of megabytes of running code. To show a link to a
certain resource you need, in current frameworks, something like a 20-level
deep stack of functions calls. At which of these points would your editor
works?

If applications where completely client-side you could think of editing most
of it in the browser, but still, which client could handle the client-side
creation of a Wikipedia page, for example?

------
samatman
Cool project, not what I expected from "Next Generation Web Browser".

I was hoping for a project to build an HTML/CSS/JS suite using OpenCL and
OpenGL directly, in a functional style which can be parallelized and make use
of immutable data structures in a sensible way. Backed by a built-in object
store database.

I do a lot of OpenCL, so if anyone wants to write _this_ browser, let me know.
I will join your mailing list.

~~~
spolu
Do you mean a next generation rendering technology?

~~~
samatman
Sort of. My ideal is a suite of rendering primitives, html/css parsers, DOM
constructors, JS virtual machines etc. that are:

* Functional (OpenCL is a good platform for this, you basically have little choice other than few-to-no side effects)

* Immutable (Everything the user does, sends or receives is tracked and stored in a distributed database)

* Detached from OS level concerns insofar as possible. It should be possible to run with a _very_ minimal set of OS services, mostly the drivers and network stack.

Last but not least:

The HTML and CSS portions are rendered into a homoiconic data form within the
language, which is all that programmers and users ever interact with. Any JS
is wrapped as a library in that language.

Without wall-of-texting, it's hard to go into the advantages this set of tools
would provide. The short story is, I'd like to be able to edit the Internet
and have the edits stay up (from my perspective) for as long as possible.
Also, expose those edits/annotation to people in my 'network'.

~~~
Jonovono
Have you seen NiDIUM? Not exactly what you say, as they are trying to do away
with CSS and HTML. But still interesting:
[http://www.nidium.com/](http://www.nidium.com/)

~~~
samatman
Yes, I'm watching them closely. Doing away with CSS and HTML on the underlying
level is crucial: CSS and HTML should be a compatibility layer.

------
deerpig
Actually a lot of their ideas are similar emacs. Have a few core pieces
written in C and then everything else is written in elisp. Even the stackable
navigation and WebViews are the equiv of buffers.

Conkeror already has stackable navigation and can be extended using
javascript. In many ways the ExoBrowser is simply taking Conkeror to it's
logical conclusion.

Very interesting, I'll be interested in seeing where this goes in the future.

------
DennisP
With stacked navigation allowing lots of open tabs, I hope we can also have
efficient maintenance of those tabs. I don't need them to keep running
javascript in the background. My machine shouldn't sag under the weight of a
few hundred open tabs. After they've been inactive for a while, archive their
state to disk and replace the view with a screenshot. Pull everything back
into ram when I go back to the tab. If I take a second or two to look at the
page before I try to interact with it, I won't notice a difference.

Let me whitelist a few exceptions, like gmail.

Built-in buttons to save/bookmark all open tabs would be nice too. And when
saving a page, if there's a page title use that as the filename.

Optional feature: insert a meta tag to the html that gives the url of the
page, so when I mention it online I can dig up a link to it, without having to
bookmark in addition to saving.

Also I'd like a complete implementation of Vim and a pony.

~~~
spolu
Tabs that are not visible are generally "frozen" (timers limited) by Chrome. I
wonder if it's a Chrome or Content API feature. In any case, archiving tabs to
disk makes a lot of sense!

A web-based implementation Vim is probably the hardest!

------
bachback
Very interesting, but I can't quite rap my head around the idea. Aren't the
protocols and the execution engine the plattform on which a browser is built?
I find it very interesting to think about it what the minimal executable code
is and how we ship it over the wire. Chrome was originally an OS as well as a
browser (that's how I understand the history).

~~~
spolu
I'm not sure I understand what you mean by "Aren't the protocols and the
execution engine the plattform on which a browser is built?". But I'll try to
elaborate.

Chrome is built on the Content API. So it's a whole lot of C++ and GUI code on
top of an API that lets you create a view and display web contents in it. The
ExoBrowser wraps this Content API (part of it for now) into a JS API so that
you can do all the GUI and specific browser code in Javascript instead of C++.

Additionally Chrome is not really an OS, Chrome OS is an "OS" (more a window
system on top of Linux) based on Aura (View Management, kind of like GTK) and
Chrome to run the apps.

------
teknopaul
Looks like a clone of a project I did in xul a while back.
[http://nochrome.tp23.org/](http://nochrome.tp23.org/) Got stacked tabs. And
comes as expanded hackable js. Good to see movement in the browser space.

~~~
spolu
Very cool project. Will definitely look at the code, I'm very curious of
seeing how you did it in XUL!

------
laurent123456
Interesting project, but I think it would be useful to write a simple tutorial
on how to customize the browser.

I've looked at the API but that doesn't really tell how to setup the browser,
how to run custom code, etc.

~~~
spolu
Hi laurent, this is definitely planned! The goal here is to share the idea of
the ExoBrowser. We need to package the whole thing a lot more!

If you want to have an early look at an example you can look at the app/
subdirectory which is a full implementation of a browser in javascript.

------
DanBC
I'd be really interested to see some innovation around bookmarking.

My bookmarks are a hopeless unsalvageable mess. I have around 900 bookmarks,
but have little hope of finding the one I need when I want to.

~~~
spolu
Totally agreed. Any idea?

~~~
DanBC
My only idea is a huge pinterest style layout, with horizontal rules, and the
ability to give those horizontal breaks big section headings, and then the
ability to drag and drop book marks around to different sections.

Every now and then the bookmarks would connect and bring back a favicon and a
screen shot thumbnail.

~~~
danielfernandez
We are working on a solution for this. It is an horizontal layout application
were you can create boards (like sections) and drag the tabs to bookmark
directly from your synced browser. You can check it out here:
[http://listboard.it/](http://listboard.it/)

------
Jonovono
How does this compare/contrast (if at all) to the recently announced new
browser engine, NiDIUM: [http://www.nidium.com/](http://www.nidium.com/)

~~~
spolu
I think Exo is more focused on the browsing experience rather than the
rendering technology. It's based on Chrome Content API which is based on
WebKit/Blink... and have no plan to go deeper than that for now.

------
neilk
I don't know what experimentation you plan for synchronizing browser state,
but Chrome and Firefox already can sync practically everything, securely.

~~~
spolu
Except the cookies, which seems interesting to sync. Additionally we'd like to
experiment with pushing your session to any instance of the browser (running
on a machine you don't control).

------
roarroar
Why not go all the way and move the rendering engine out of the privileged
base of the system? Why is all this HTML and Javascript garbage in "kernel
land" anyway? Why not make your browser kernel concerned solely with providing
asm.js or PNaCL plus WebGL and some other primitive services? Then everything
else can be preloaded libraries. And what on Earth does Node.js have to do
with any of this? Why not just create some Javascript bindings to WebKit and
V8, then.. write the browser in Javascript? The browser needs less of this
kind of ridiculous bloat, not more.

~~~
comex
You can't make a JavaScript engine run anywhere near fast enough in PNaCl, so
you need at least all of V8 in your "kernel". You could run WebKit on top of
PNaCl with some magic V8 bindings, but I don't think this has been done
before, and considering how big WebKit and NaCl are, it would probably be a
lot of work. Useful work to do, but a lot of work...

(And of course, Chromium already supports a process sandbox, so while this
could theoretically be a really cool win for architecture, having less
platform specific code to maintain, it wouldn't necessarily be much of a
security win - the analogy of the kernel only applies so far.)

~~~
roarroar
I'm aware of all this. I'm not saying it would be easy - and the belief that
high speed Javascript is necessary is one reason we've been held back for so
long. Nobody should be writing a browser in Javascript (when I mentioned this
possibility I was simply humoring the poster's ideas). An "Exobrowser" (or
perhaps "Microbrowser") is what we should have by now, but the linked project
is not it. NaCl and asm.js are only necessary because operating systems have
failed to successfully implement process separation (more crap, monolithic
design at work), so now it's being reinvented in user land with the resulting
performance overheads. Javascript doesn't need to be fast! The whole idea of
high performance programming done in Javascript is stupid, especially if it
means saying "no" to a better architecture designed around security and speed
for better systems languages. Even Mozilla's penny has dropped on low-level
code execution - hence asm.js. If operating systems had been done right in the
first place then you could have the following arrangement:

\- Each browser tab is a separate OS process w/o any access to system calls
except for calling browser services

\- Browser provides services (e.g. graphics primitives, input)

\- Processes from the same domain can talk to each other

\- Browser comes preloaded with some preferred, but optional portability
layers for the processes

\- Everything else is libraries, with one domain being able to provide
services to another. So mozilla.org could provide its rendering engine either
as a library or as a background process (to reduce memory overheads).

And so on. This way there's no more waiting 10 years for Mozilla to implement
whatever it thinks you need, with their 640k ought to be enough attitude.
Their rendering engine has to compete with others. The most popular engines
are most likely to already be in cache when someone visits your site, so there
is room for lots of vigorous competition. This is all so painfully BASIC, but
it will likely be decades before people get it right, if they ever get it
right.

Chrome is going in the right direction, the poster's linked project is not.

~~~
comex
On NaCl I partially agree and partially disagree. While it's true that the
_sandboxing_ is only necessary due to insufficiently flexible kernels, imo the
most interesting part of NaCl and asm.js is their use of a portable bytecode
that compiles into native code. Portability really is necessary - CPU
architectures don't change that often, but if people started distributing
websites as native code a decade ago, none of them would have envisioned that
a large portion of web browsing is now done on ARM based devices. Yet you
cannot make a fast portable JIT. You say that JavaScript doesn't need to be
fast, but it's really nice to have a high-level, dynamic language that still
runs fast - in fact, it was compelling enough to be one factor in the success
of JavaScript on the server, despite the language's weaknesses.

However, there's no reason JavaScript (or some suitably compatible dynamic-
language bytecode) JIT couldn't be provided as a fundamental API in addition
to the static compiler. Yeah, it doesn't feel like a clean architecture when
you want to use Python or Lisp and it almost translates neatly to that
bytecode but with little runtime differences that end up adding a lot of
overhead... but it's better than nothing.

I think that your hypothetical arrangement would be very cool. I'm not sure
that it would actually be better than what we have - for example, writing a
screen reader would likely be a nightmare if some random webpage might be
using a browser library that didn't support it; good luck implementing
anything like user scripts/custom CSS, scrapers, Readability, magic text
reflow for iPhones, smooth zooming, etc. Good luck doing something like the
transition to hardware accelerated rendering browsers did a few years ago
(sure, you could only support it for new sites, but as is I get smooth
scrolling for all sites). And since different engines would now be very
fundamentally different rather than the usually relatively thin layers over
HTML that are currently popular, developers would have to spend more time
learning different APIs. If some engine stopped being maintained, then it
would be very difficult to retrofit websites that use it to support the newest
features. Et cetera. Meanwhile, these days browsers move pretty damn fast,
lessening the advantage of non-standardized development - and many new APIs
are hooks to the OS anyway, not things that UI layers could implement on their
own.

But it would be cool. I don't mean to be too negative: there would be a lot of
advantages, and it would be interesting to try out.

I suppose it might happen. PNaCl and asm.js are soon going to be supported in
two of the most popular browsers; alternatively, if JS engines get good enough
that specific support for asm.js isn't required to achieve performance for
low-level code
([https://bugzilla.mozilla.org/show_bug.cgi?id=860923](https://bugzilla.mozilla.org/show_bug.cgi?id=860923)),
with the competitiveness all major browsers already have on JS speed, the
latter will be "supported" everywhere on short notice. It might not be that
long until the first serious attempt to make an alternative UI stack for
browsers...

~~~
roarroar
NaCl is not a portability layer. It is a security layer. PNaCl is a
portability layer, built inside NaCl more-or-less in the manner I just
described, but with all the overheads and limitations of NaCl (which are
real). So NaCl is in total agreement with me. asm.js is basically a joke,
rolling portability and security into one layer, but when you're dealing with
the web you take what you can get sometimes.

>Yet you cannot make a fast portable JIT.

So? What difference does sticking this in the browser as a privileged
component make? There's no reason google.com can't provide a DOZEN
compilations of V8 in the setup I described. The difference is I can write my
own portability layer. Maybe some authority can control which portability
layers are valid to prevent too much native code. Mozilla is the perfect
candidate with their police-the-web attitude.

>However, there's no reason JavaScript (or some suitably compatible dynamic-
language bytecode) JIT couldn't be provided as a fundamental API in addition
to the static compiler.

Did you even read my list of points? You don't need this! You just give the
user access to properly sandboxed native (not NaCl, which has limitations and
overhead) and provide portability layers plus the ability to add new
portability layers. There is NO reason Javascript needs to be privileged in
the manner you're suggesting.

>for example, writing a screen reader would likely be a nightmare if some
random webpage might be using a browser library that didn't support it

How is it any different if people start building all their stuff with WebGL?
What about when people use tonnes of images without alt tags? Accessibility
never works automatically! And it can be provided properly as a browser
service, which different renderers hook into. Hell, it could probably even be
in userland. Mozilla could even provide disincentives to non-compliant
renderers. They love playing the policeman, so why not do it properly instead
of doing it by holding technology back as much as possible?

>good luck implementing anything like user scripts/custom CSS, scrapers,
Readability, magic text reflow for iPhones, smooth zooming, etc.

Firstly, HTML would still most likely be the standard for most web pages. So
there's no need for "luck"; it would be done the same way it always has been.
You're trying to set up an opposition between my ideas and HTML. My ideas are
opposed to HTML, DOM, Javascript as privileged entities. And they would have
to compete with other markups and document models and languages. Just like
C++, C# dominate on the desktop, but they have to compete with more
specialized languages - to everyone's benefit. And aside from the most basic,
unstyled HTML, it has always taken some forethought on the part of the webpage
author to get things like accessibility and compatibility with different
window sizes to work. I can tell you this because I have terrible eyesight and
view many pages zoomed a long way in.

>Good luck doing something like the transition to hardware accelerated
rendering browsers did a few years ago (sure, you could only support it for
new sites, but as is I get smooth scrolling for all sites).

Why on Earth would this be a problem? Even though the renderer is in user mode
it's not baked in statically, or even necessarily linked in at all. It could
be spoken to via message passing. First ask the system to give you a shared
rectangle inside your tab, then send the handle to mozilla.org along with some
web content, saying "please draw this". Similarly for input events etc. And of
course, you can have preloads that do all this for you so on the server-side
you just send down the HTML in the usual way. These kind of arguments are
always such rubbish, just like when Mozilla says binary codes can't evolve as
easily as source code. What does that even mean? Source codes ARE binary
codes!

>If some engine stopped being maintained, then it would be very difficult to
retrofit websites that use it to support the newest features.

Which is why most people would use HTML, and people who are trying to do
things that HTML is totally unsuitable for would not, paying the resulting
costs.

>Meanwhile, these days browsers move pretty damn fast, lessening the advantage
of non-standardized development - and many new APIs are hooks to the OS
anyway, not things that UI layers could implement on their own.

The browser is a technological slug. V8, Flash, NaCl and Unity are the only
reason we have had any real advancement, and it's an advancement back to
decades ago. Web developers just have extremely low expectations and are
always trying to resist the approach of superior technologies. I can remember
telling people years ago that sockets were needed (there's this wonderful
thing called interrupt driven programming you see) and got much the same sort
of criticisms you outlined above from all the "web experts". Of course it has
since been implemented.

>many new APIs are hooks to the OS anyway, not things that UI layers could
implement on their own.

I already said this! Perhaps you missed the point of the post, which is that
the point of such primitives is to implement applications (e.g. UI layers). It
is a post against the monoliths.

>JS speed

I'm sorry: "JS speed" doesn't exist on current hardware. The reason asm.js was
so fast with minimal additions to the optimizer is that the JS optimizers all
work best on statically typed code (in other words, not Javascript), which is
of zero surprise to anyone who knows anything about compilers or optimization.
Essentially, the people working on "Javascript" engines have really been
writing optimizers for a small subset of the language that discards everything
dynamic. Whether this was intentional or not is irrelevant; that is what they
have done. That's how bad Javasscript is for this task, and how GOOD the old,
statically typed ideas are: so good they couldn't help but do it, even when
they were trying to optimize their "dynamic" language.

------
puzanop
Ever heard of Adobe CQ Authorisation tool ? It already does these things and
was released 2 years ago..

------
rajavekedoby
up to I looked at the draft for $5082, I did not believe ...that...my friend
was like actualey earning money in their spare time on their laptop.. there
moms best frend has been doing this for less than eight months and as of now
cleared the loans on their villa and purchased a new GMC. look at more info
big57.com

~~~
gordonguthrie
I voted that up when I meant to vote it down - how the hell do I fix that?

