I'm trying to put this as constructively as I can: Proudly dismissing Windows on the second line of your copy makes me not want to take you seriously. There's nothing wrong with not supporting certain platforms, but bragging about it makes you seem a bit snobby.
EDIT: And I'll grumpily admit that this also bugs me because Windows is me favorite OS and Breach looks like a thing I would actually use. I hope its just circumstance. And not some goal in itself to not support it out of some far fetched principle.
>There's nothing wrong with not supporting certain platforms, but bragging about it makes you seem a bit snobby.
A modern, HTML5-capable browser which performs well on a A2000, A3000, A4000, or A1200 running AmigaOS 3.1, with 128mb of RAM, a 33-50mhz 680030+ processor, and a 2 or 4mb Picasso video card would make one "seem a bit down to earth". It would also make a lot of us old-time Amigans happy.
You just write, "Available on OS X and Linux" (or using the logos if that's your style). Simple, professional, conveys the message without drawing flak for being some angsty kid.
Yo! I'm very happy that you didn't intend it to be like that at all. In fact, I first wrote a way snarkier comment and then I remembered the "Show HN" guidelines (and basic human decency) and deleted that comment :)
I'm impressed how something as simple as reading "only available on $NOT_MY_OS" in a nicely laid out box gives me the complete opposite emotion than what you intended. My comment got a large number of upvotes, so apparently many felt the same. And still, if you look at it, there's nothing wrong with the text in and of itself. Only on this and that OS. Fine, good to know.
So apparently, writing it with that word ("only"), with the OS logos instead of the names maybe, and so happily and centrally and proudly laid out, was what changed the perceived intent. I really thought that you guys were some kind of anti-Windows crusaders. And probably, the exact same text elsewhere, or slightly different text in that spot, would completely change that.
suggests that it was previously available but not on those platforms. You're going to find a lot of people searching high and low for the .exe file IMO.
Personally I'd stick with "Available on [apple]/[linux]", drop the "only" if you're worried about it sounding like it's a choice for exclusivity reasons. Then you probably need to add a by-line below the button indicating "MS Windows and other OS versions not yet available, please contact us through the forum [or whatever] for details". Or have a click through to gather email addresses so you can contact users later if MS Win or other versions come out.
Don't try to butter me up. We all know you are still angling for cyan with Wilma from accounts. Well that dream is dead my friend, the CFO was spotted playing golf and all his clubs have turquoise handles.
I'll take it a step further--it usually indicates to me hipster script-kiddies that don't know how to properly support multiple platforms beyond pasting together makefiles from Grandpa Google.
EDIT:
Downvote all you want--how many times have you had to deal with packages that magically only build on Windows, OSX, or Linux? Or only on a particular version of Ubuntu?
I've done 'nix development, and agree that for certain things it's much nicer.
On Windows, VS debugger beats everything else I've seen hands down.
It's not hard to support Windows if you're writing good cross-platform code; there are a lot of libraries (Qt, Boost, etc.) that make things much easier than they used to be.
Again, I see lack of Windows support mostly as programmers being lazy (and I've said the same thing about lack of 'nix support, so don't think I'm being biased).
If you don't write portable code you're doing it wrong.
> I see lack of Windows support mostly as programmers being lazy
"Lazy" would imply that Windows support is somehow a requirement that's being shirked by developers, which frankly it isn't. Microsoft is not entitled to have developers support, expend effort on, or even give a moment's thought to their platforms.
Windows is still by far the primary platform users (maybe not devs) use, and yes, for any serious project, it is most definitely a requirement. I didn't get the sense from the website that it wasn't going to come to Windows, just that they haven't had the chance to get it working yet. I don't find the devs attitude lazy unless they actually come out and say screw it we aren't going to both to support Windows.
And this attitude being displayed toward Microsoft is just lazy (and very likely the province of the young), because while they did give us a crappy browser and Webforms for way too long, and they are fun to poke fun at, they've done more than most companies to push both the computer revolution and the Internet as a whole forward to what it is today. So give them a little credit, pull your head outta the sand and actually take a look at what they do once in a while also. You might be surprised what you find.
A lot of us "young" devs grew up on windows and remember what a hostile place it was to learn. My disdain for Microsoft is anything but lazy, I have worked very hard not to have to develop for Windows.
I think if you pull your head out of the sand you'll find many serious projects that don't depend on Microsoft. 99% of Web servers run *nix and any project done for the web doesn't need windows. How many billions of dollars are being made on Android and iOS?
As far as I'm concerned Microsoft has squandered any goodwill they may have been due, if they deserve any credit it is for driving me to open source.
Do pray tell, how many more people were brought onto the web using IE and AOL than some janky 'nix browser?
As much as everyone bitches about them, the entire reason we even have affordable desktops and laptops enabling this magical open-source revolution is because of the work Microsoft did in the 80s and 90s.
Because no one else would have filled that void...
That's like saying if Henry Ford had never mass produced cars, no one would have figured it out...
Yes MS created the PC ecosystem in the 90's, but if they hadn't, someone else would have (Apple? IBM? Maybe even Sun?). Market pressure would have eventually driven down prices, it always does...
Apple was busy shooting itself in the foot as a boutique brand. IBM was not interested in lowering prices. Sun (and SGI for that matter) were heavily wed to the workstation and high-end server market.
Microsoft (and Intel) by careful work made it possible for cheaper hardware to still run a product people wanted, and so create the market pressures you're referring to.
They were a pure software company, and used that to enable competition in the hardware market.
I'd argue that the web, Android and iOS are the primary platforms that 'users' use.
Who uses Windows for native apps that are truly Windows exlusive? Even Microsoft Office is a web app now, it's on OSX and iOS, and can even be run on Linux if you're crafty enough. Windows-only games? Fewer and fewer.
I'd definitely argue that Windows is not a requirement, though going cross-platform is a bonus.
As far as giving MS credit, they have been open sourcing many of their projects, and playing a little nicer with the non-Windows ecosystem...
None of my serious projects over the last 14 years have had Windows as a requirement at all. Over the last 19 years, I've only worked on two serious projects were Windows support was a requirement - they add up to a combined about 2 months of effort.
You need to narrow it down substantially for that claim to make any sense.
(as for their contributions, I'm not going to get started on what would just end in a flamewar - suffice to say we have very different views on what the computing world is likely to have looked like without MS)
Users can use whatever platform or platforms they like. Developers are not punishing users by only targeting certain platforms, and platform developers like Microsoft are more than capable of providing a compatibility layer for other platforms, should they choose to.
I think the downvotes are more for your tone than whatever point you're trying to make.
Also, code portability for a project like this is important, but that's not universally true. Having a hard and fast requirement for code portability imposes a set of concerns, design and maintenance issues that complicates a project. It (almost) never comes for free, and is a legitimate concern for any project--even ones where a portability requirement is almost a given.
If it is useful at all on anything, for anything, then it is doing pretty well.
And, unless you are the sort of person for whom using another platform when necessary is no great stress, then perhaps you shouldn't even be looking at installing untested alpha-level software releases anyway.
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.
OK, it's not quite the same but last week Robin Berjon wrote "Web 2024" which spoke as if from the future and he said: "This is 2024. In terms of the ecosystem, not only do all browsers have large chunks implemented in JavaScript but at some point someone started a pure-JS browser from scratch. It was initially meant as a joke, but this 'Inception' browser caught the fancy of the ever-resourceful JS community and quickly grew in usability."http://berjon.com/web-2024/
This is a great idea. I've wanted to build something like this for a while, but never got around to it.
I think people here are missing the point. Firefox and XUL is also a JS-scriptable UI over a browser, but it's a terrible environment to work in.
The UI is the main thing that differentiates web browsers. Our tabbed browsers have looked the same for years now. This is going to enable all kinds of awesome experimentation and customization. I'm super excited to see where this project goes.
This is a neat hack on current technologies. Reminds me of uzbl [0] in the separation of modules, each one being good at only one thing and doing it well.
What eventually killed uzbl [1] was the difficulties working with IPCs; I hope you overcome this and build something even greater !
I suspect that asm.js will obliterate the existing space of web browsers soon. They are bloated dinosaurs from the last millennium. In fact, a "browser-in-browser" project along the lines of jslinux and vim.js, where the entire browser tool chain is emulated (in the browser) is possible.
If a browser can be shown to be a lightweight dev tool with integrated toolchain servicing CPython, C, and JavaScript, rather than a glorified porn watching device, then there is hope for civilization.
It is really very nice that the source code is available. I do hope that open source will eat Capitalism alive soon. Not to mention copyright law. Right now, the tech industry looks like a bunch of crackpot inventors and psychopath totalitarian wannabes.
Yeah I thought the same thing, it should be fun to hack on. There's not much I need that Chrome and Firefox don't already do for me, but trying to write some of the modules myself as well as try some new stuff sounds like it would be a good learning experience.
As a newfound convert to the Conkeror browser, which basically allows you to configure everything through JS and use MozREPL to talk to your browser instance purely through JS, how is this different (notwithstanding the obvious choices in architecture and JS engines)? I mean, it seams like the minimalist JS-run browser has been around for a while (and if not JS, Uzbl did Python as mentioned below, Luakit does Lua). Granted the others do not really run up and down the JS stack, with or without a separate conf language, but I do see this as Conkeroresque.
This is very cool - I just figured out how to shrink the top strip to 25px from its original 45px in about 5 minutes. Very refreshing compared to modifying Firefox.
Seems to be very unstable on Yosemite Beta 2. I tried loading this thread, and it the HTML view froze immediately. I then tried to load up Reddit, and it just wouldn't load.
It's a really cool concept, though, I look forward to seeing where it goes. It would be super cool if it became stable enough to be my main browser, because I love the customizability.
I would be very interested in seeing a tutorial for how to build a custom developer tool in this.
Something I've been very interested in over the last couple of years is the idea of creating once off, task specific, development and introspection tools. Breach seems like the perfect environment for that kind of thing.
I find the amount of files these JavaScript projects require astonishing. On OSX this app's application bundle contains 4046 files and 1018 directories.
Contrast that with Google Chrome wich has "only" 388 files and 577 directories in its application bundle. (a lot of empty directories apparently)
I am getting the same issue. I used AppCleaner to delete the app and any supporting file. It ran again, but crashed at the exact same spot. I'll try on my iMac
Well, I think this is extremely cool. The concept is great, the minimalist mod_strip is thoughtfully designed, and even as someone who isn't a fan of JavaScript I think it makes a lot of sense in this case.
I don't use Firefox anymore because it's so much slower than Chrome, especially when using firebug. Speed IS important. Whenever I see Mozilla release new versions like every day, with new features that I will never use, I wish they would just drop everything and focus on improving performance.
There are many of us are Mozilla who focus primarily on performance improvement. The fact is, though, that performance improvements usually are not splashy enough individually to be added to release notes. "Improved performance measure X by 15% in circumstance Y!" is not going to thrill anybody, even if it is important. Please don't take the release notes as representative of where our engineering effort is spent.
I switched back to firefox about 6 months ago now. I'm using nightly, and the built in developer tools are good enough that I don't worry about using firebug anymore. I find the speed pretty good, faster than chrome for some things, slower for others. One area it does shine is implementation of es6 features, and syncing with my mobile firefox browsers.
I hear a lot of firefox hate, and while it certainly used to be true that it wasn't very good, it's no longer true.
When is the last time you used it? Or, what sites do you visit? The current speed of Firefox is quite good. Maybe Chrome could surprise me and be faster. I don't see how, right off.
I've generally found the opposite to be true; Chrome/Chromium have lately been slow as heck and buggy for me on the majority of the computers I've used, whereas Firefox has been less so (but still slow as heck and buggy).
Really, every browser is slow as heck and buggy, so to each his own ;)
I'm not a browser expert, so please enlighten me on this. How can it be named "A new browser written in JavaScript" if it's not actually entirely JavaScript?
Every companies can build their own browser. It's a good thing for WEB developers. The companies can limit their works internet behavior. For me, may be some day I can use this to build my own browser.
Anybody reminded of Sencha? I don't think any UI should be coded in JS, especially one that's built for the browser. At least Sencha/Ionic et al is targeted for phonegap apps...
I think you might need to re-read the link. This is a browser UI and infrastructure (powered by Chromium) written in JS. It's not an app which runs inside a browser, therefore I'm not sure the comparison is useful.
Absolutely love this! Great job, but I'm kind of annoyed that writing breach modules to improve my web experience threatens to derail my side projects.
One thing that hit me was typing a URL wrong provided no feedback to me that my input might be wrong (no dns records found, or server not on https, but happens to be on http)
I made a mini web browser in PHP. It's command line usage only and doesn't have a GUI and can't display images, only text. Also it's really difficult to click links since you have to type in the link number.
While I'm aware of what you're implying by "hackable," that word has horrible connotations when it comes to browsers. I would never want to describe my browser as "hackable." If I were you, I'd consider using a different adjective. Best of luck with the project!
The result is an executable exposing a NodeJS REPL with a special API to control browser windows and frames direclty from Javascript. Some people will note the resemblance with node-webkit. Well, the building blocks are very similar but the overall architecture is fundamentally different: here we expose the Content API into a NodeJS context to have the necesary semantics and security model to build a browser using only Javascript code. Node-webkit, on the contrary, exposes nodeJS API within the renderer of a trivial browser (one window, one webcontents view) to make it super easy to build native apps using Javascript code.
Thank you! If I am understanding correct then the tl;dr is: node-webkit is made for building native apps using JS. breach is a web browser made for hacking with JS.
Well node-webkit is made for bulding native apps using JS. Breach is made to build browsers using JS (very different security requirements between a native app and a browser and who tabs interact within it)
Since everything in the browser is replaceable and implementable with JS/HTML/CSS then isn't Breach a layer above node-webkit? That is, everything can be changed, so you can write a Breach based app that has no regular browser component in it. I am trying to get a feel if Breach is perhaps more accessible way to do native app dev than node-webkit, which seems to require a lot of boilerplate that is necessary for basic apps.
I am a bit confused how Light Table and Atom can implement tabs if node-webkit is only one tab.
Neat project, but the marketing's a little disingenuous. It's not "entirely written in Javascript", it's a Javascript layer on top of Chromium, an enormous codebase written in C++.
The post had a couple title edits which is fine but the last edit is really diminishing the impact of the whole project: "Show HN: Breach – A new browser UI written in JavaScript"
I appreciate that Breach is not entirely written in JS, but it's as much a browser as Opera is and qualifying it of a "Browser UI" does not convey a realistic image of the project.
Maybe we could edit the title again to something like:
Show HN: Breach - A new modular Browser built on top of Chromium/NodeJS
EDIT: And I'll grumpily admit that this also bugs me because Windows is me favorite OS and Breach looks like a thing I would actually use. I hope its just circumstance. And not some goal in itself to not support it out of some far fetched principle.