What about this doesn't also apply to Firefox? It too is open source and modular, and also written in Javascript (though combined with XUL rather than HTML, and using Gecko instead of Webkit).
That was my reaction as well. I was pretty interested to see a browser genuinely written entirely in JavaScript, which would at least be a new thing.
Since it seems like the developers are posting in this thread, could you talk a little about the differences between Breach's approach and Firefox's? I suspect they must exist mostly in the node.js layer - which tasks is that layer responsible for?
(Edit: I see you replied to the parent comment while I was writing this one. =)
I've detailed a how we ended up building Breach as it is in the introduction of that page: http://breach.cc/hack
Basically, the idea is to take the Chromium Content API and expose it to JS (that's similar to Firefox).
Doing it we figured, why not add some APIs to do interesting stuff in JS as well... and that's how we embedded NodeJS and exposed the Content API within a NodeJS tread....
So you have access to all the nodeJS modules while building your own modules for Breach... makes it fairly convenient :)
Those are interesting projects for sure, but for me neither of those really qualify. I'd want to see the core browser algorithms written in human-readable JavaScript - things like HTML parsing, CSS layout, and rendering.
It does apply indeed! We went one step forward and didn't provide any functionality to the browser to make it entirely built out of modules. And we did it on top of Chromium Content Module.
The basic motivations are totally the same. I also believe that is's probably way simpler to rewrite an entire web browsing experience on top of Breach.
Not sure who down-modded you, I think it's a fair point. It's a little horrifying, considering that the chromium build-process is quite awful too, but still better.
The pages are in fact different, but the latter in the case of Firefox is what I used to complile it myself (disclaimer: I considered building Chromium from scratch but never found the time interest). As build tools go, I know gyp/ninja are more hip, but I see gyp and mach (both Python based build management tools, I will compare those instead of Ninja which is slightly different) as both good, but do things differently enough to make it an apple-oranges comparison. Keep in mind Chromium people started from scratch, but Mozilla/Firefox devs were building a system on top of autoconf (which everyone hates gathering my reading of many such comments on HN) to simplify the build process.
Can someone who is familiar with both explain why gyp/ninja is superior?
I stand corrected, it's clearly been a long while since I looked at the Firefox build process (I believe there was something on top of autoconf at the time, but not quite what mach is now?).
While I don't hate autoconf, the combination of gyp and ninja is quite nice -- although I have more experience with cmake and ninja. From what I've seen of gyp, it has many "typical" "modern" build-tool features -- and I'm really happy they ended up keeping gyp featureful, and ninja simple and fast.
I imagine you'd need about as big as a mess (no criticism, it's a large project with a long history, complex dependencies) as Firefox to have any reason to choose mach over just autoconf/automake for a new project. And if you're going with a "new" build tool, I think I would go for CMake (many people hate CMake, too, though) or perhaps Waf or SCONS.
So, not sure if I think gyp is "superior" (although it certainly is good) -- but the combination of a "smart" build tool and ninja as a build "blunt instrument" is pretty great: ninja is fast.
Chrome has quite a few components that are written in HTML/JS, but not the UI itself (i.e. the tabs and address bar). In Firefox, everything above Gecko is written in XUL and JS. A cool way to demonstrate this is to navigate (in Firefox) to chrome://browser/content/browser.xul. You will see a new browser window inside of your browser window.
It's incredibly satisfying to do that repeatedly, nesting Firefox inside Firefox inside Firefox and so on until you can't paste a URL in anymore.
Interestingly, though, the new menu introduced with Australis doesn't appear to be functional unless it's in the top-level window; the menu buttons in nested windows don't seem to do anything.
Could XUL/JS be used to customize FF for an enhanced view of "related pages"? E.g. the user interface is separated into 2 portrait-sized frames. One XUL frame shows the destination web page. The other shows related information, which could be links, images, thumbnails of other pages, etc. Does something like this exist?
You can do whatever you want from an XUL perspective, but the split-pane behaviour you describe already exists (sidebars). I don't know if there are any extensions that provide a sidebar like that, though, but it's certainly possible.
Good to know. I've only seen the history sidebar that is an outliner tree of links, didn't realize full HTML/JS was available. If a sidebar can respond to pixel-level events in the main window, many interesting augmentation apps are possible.
