4 ms·

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

by shawnz 12y ago

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

spolu 12y ago
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.
swift 12y ago
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. =)
- spolu 12y ago
  I've detailed a how we ended up building Breach as it is in the introduction of that page: http://breach.cc/hack 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 :)
- Excavator 12y ago
  How do you define "genuinely written entirely in JavaScript"? Is it covered by something like links/lynx in a JS based RISC emulator¹ or the Firefox OS web browser app²? [1] http://s-macke.github.io/jor1k/ http://s-macke.github.io/jor1k/ [2] https://github.com/mozilla-b2g/gaia/tree/master/apps/browser https://github.com/mozilla-b2g/gaia/tree/master/apps/browser
  - swift 12y ago
    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.
math0ne 12y ago
Yup Yup Yup, seems exactly like how ff works.
colordrops 12y ago
Same as Chrome. At least the developer tools are written in JavaScript. Perhaps other bits are as well.
- shawnz 12y ago
  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.
  - yellowapple 12y ago
    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.
  - walterbell 12y ago
    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?
    - shawnz 12y ago
      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.
      - walterbell 12y ago
        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.
Touche 12y ago
The Firefox build process makes me want to cry.
- e12e 12y ago
  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.
  - 616c 12y ago
    I did not, but am considered it when I saw it. Have either of you used the Mozilla build process? Chromium/Chrome Build Process: https://code.google.com/p/chromium/wiki/LinuxBuildInstructions https://code.google.com/p/chromium/wiki/LinuxBuildInstructio... Firefox Build Process: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/mach https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g... 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?
    - e12e 12y ago
      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.
niutech 12y ago
Rather Firefox OS Browser. It's made of only HTML & JS & CSS: https://github.com/mozilla-b2g/gaia/tree/master/apps/browser https://github.com/mozilla-b2g/gaia/tree/master/apps/browser

by shawnz 12y ago

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

spolu 12y ago

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.

swift 12y ago

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

spolu 12y ago
I've detailed a how we ended up building Breach as it is in the introduction of that page: http://breach.cc/hack 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 :)
Excavator 12y ago
How do you define "genuinely written entirely in JavaScript"? Is it covered by something like links/lynx in a JS based RISC emulator¹ or the Firefox OS web browser app²? [1] http://s-macke.github.io/jor1k/ http://s-macke.github.io/jor1k/ [2] https://github.com/mozilla-b2g/gaia/tree/master/apps/browser https://github.com/mozilla-b2g/gaia/tree/master/apps/browser
- swift 12y ago
  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.

math0ne 12y ago

Yup Yup Yup, seems exactly like how ff works.

colordrops 12y ago

Same as Chrome. At least the developer tools are written in JavaScript. Perhaps other bits are as well.

shawnz 12y ago
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.
- yellowapple 12y ago
  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.
- walterbell 12y ago
  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?
  - shawnz 12y ago
    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.
    - walterbell 12y ago
      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.

Touche 12y ago

The Firefox build process makes me want to cry.

e12e 12y ago
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.
- 616c 12y ago
  I did not, but am considered it when I saw it. Have either of you used the Mozilla build process? Chromium/Chrome Build Process: https://code.google.com/p/chromium/wiki/LinuxBuildInstructions https://code.google.com/p/chromium/wiki/LinuxBuildInstructio... Firefox Build Process: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/mach https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g... 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?
  - e12e 12y ago
    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.

niutech 12y ago

Rather Firefox OS Browser. It's made of only HTML & JS & CSS: https://github.com/mozilla-b2g/gaia/tree/master/apps/browser https://github.com/mozilla-b2g/gaia/tree/master/apps/browser