ExoBrowser: The Experimentation Platform to Build a Next generation Web Browser

https://github.com/spolu/breach/wiki/The-Experimentation-Platform-to-Build-a-Next-generation-Web-Browser

by spolu • 13 years ago

62 56 13 years ago

neilk• 13 years ago

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

spolu16• 13 years ago

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).

bachback• 13 years ago

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).

spolu16• 13 years ago

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.

Groxx4• 13 years ago

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/

spolu16• 13 years ago

Didn't know it. Very very cool and interesting. Thanks for sharing the link.

If I understand correctly the bookmark was an URL + the Cookies related to it?

Groxx4• 13 years ago

Basically yeah. I imagine there's more to it (localStorage, other forms of persistent data), but that's the idea.

Importantly (to me anyway), you can have multiple tabs to the same site open at once, each with a different session. Tabs opened from one of those tabs will retain that session, so you can e.g. fire up two Google accounts, open a few YouTube tabs from each, and keep your viewing history separate. It's like Chrome profiles on steroids, with way less memory use, and way easier to use.

Sprint• 13 years ago

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

zamalek3• 13 years ago

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."

roarroar4• 13 years ago

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.

spolu16• 13 years ago

Agreed with direct Webkit bindings in JS... only if you want to handle networking and file storage in Javascript, you'll end up rewriting node.js which is exactly that bindings for libuv... So node.js is not chosen because it's cool or anything, it's just because it's exactly what's needed.

Not sure I see what you mean by HTML and Javascript garbage in "kernel land"?

roarroar4• 13 years ago

HTML and Javascript are a horrible basis for a computing platform, which is why in the end they have resorted to providing a tiny, statically typed subset of Javascript plus some graphics primitives. And now the primitives exist, comically, side-by-side in the privileged base of the system with a bunch of application-level stuff (HTML etc) which could be built out of the primitives themselves. Your diagram doesn't indicate that you're just using libuv bindings for portability - it includes a local server.

lutusp• 13 years ago

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?

There's a little-known emotional factor in software development at work here, apparently not clearly understood, indeed it might as well be a secret. And that is that kernel development is high-status, and user-space development is low-status. Many software developers want desperately to add to their resumes the fact that they contributed code to the Linux kernel. This is why so much user-space code has made its way into the kernel.

Someone powerful should go through all the kernel-space code and order the deportation to user-space of all the stuff that doesn't belong, that has slipped across the border over the years like phony political refugees. This probably won't happen, but it's uncontroversial that much of the kernel code has no right to be there, and much of it is written so badly that it's dangerous for it to be in kernel space.

spolu16• 13 years ago

The ExoKernel[1] principle is even more agressive (and awesome!)

[1] http://en.wikipedia.org/wiki/Exokernel

comex2• 13 years ago

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.)

roarroar4• 13 years ago

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.

dubcanada• 13 years ago

Chances are if you want your browser to run fast you won't have one built in javascript :)

Javascript is nowhere near the performance of C++, asm.js is getting there, but this obviously isn't built in that.

est• 13 years ago

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• 13 years ago

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?

AndrewDucker• 13 years ago

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?

spolu16• 13 years ago

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++.

puzanop• 13 years ago

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

laurent123456• 13 years ago

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.

spolu16• 13 years ago

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.

rajavekedoby• 13 years ago

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• 13 years ago

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

samatman4• 13 years ago

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.

spolu16• 13 years ago

Do you mean a next generation rendering technology?

samatman4• 13 years ago

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'.

DennisP• 13 years ago

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.

spolu16• 13 years ago

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!

DanBC2• 13 years ago

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.

spolu16• 13 years ago

Totally agreed. Any idea?

DanBC2• 13 years ago

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.

teknopaul• 13 years ago

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

spolu16• 13 years ago

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

deerpig• 13 years ago

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.

Jonovono2• 13 years ago

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

spolu16• 13 years ago

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.

ExoBrowser: The Experimentation Platform to Build a Next generation Web Browser

Related Stories