Consider: Slack, Gitter, Facebook Messenger, Gmail, Hangouts, Google Inbox, Fastmail, web.whatsapp.com and web.skype.com.
You can make an argument that Firefox should stay neutral. But I don't believe that many use Chromium instead of Chrome. For one because you can't find decent builds, unless you're on Linux, but also because people that don't want Chrome because of Google's services probably use Firefox, because Chromium is still integrated with Google (Web Store, Sync), while providing a poor experience (no PDF viewer, no Flash, no DRM, or any other proprietary bits).
Good thing that PDF.js, the PDF viewer from Firefox, ended up on Chrome's Web Store, so you can add it to Chromium. Which is the main difference between Mozilla and its competition: when Mozilla improves Firefox, it tends to benefit everybody.
Humorously, this wasn't the best choice of examples for your point. Chromium displays PDFs just fine because they open sourced their PDF viewer over two years ago :)
I'm completely fine with this (although I don't like JS webapps myself, if they're anything more than a thin client), just that I don't want my platform to come with unremovable third party stuff. Further more, while being a "platform for apps", browsers are still content viewers where sometimes content happens to be an interactive application software.
> But I don't believe that many use Chromium instead of Chrome.
I said many as in "a multitude of people", not to mean "most". My version of Chromium has a PDF viewer, and I didn't install it (Chromium 52.0.2743.116, from FreeBSD pkg).
I think the primary nuisance of Pocket was in making users have another relationship to a 3rd party. Credentials and another service to think about.
- goose (scala)
- python-goose (python port of the above)
- apache tika (java)
- boilerpipe (java)
- boilerpipy (python, not a port of the above)
- libextract (python)
- beautiful soup (python)
In fact, in my chrome setup I have disabled the PDF viewer because I prefer to download and open them in mupdf.
For PDF viewing especially, it wouldn't be impossible to hav an offering of various competing plug-ins, some perhaps offering extra features like annotations and others offering just the bare minimum.
I think firefox is held to a higher standard because "firefox user" is correlated positively with "aware of privacy issues". Those that just want something fast and easy to use might have used to use firefox instead of IE, but most of them have now moved to chrome.
In fact, it sounds more like a recipe for letting others innovate and being perpetually stuck chasing taillights.
For the back-end: Everything that's required for correctly rendering or executing modern web content (i.e., everything that's mandated by the current snapshot of the HTML living standard plus non-HTML formats which are "de-facto" part of the web, like Flash and PDF).
For the UI: Stuff that can be expected to make the task of browsing web pages easier for the average user.
Neither Hello nor Pocket fit any of the above descriptions.
As an aside, I'm looking for this on Android (address bar, tabs and viewport). Habit Browser comes close but is not open source. Basically just a WebView with an address bar and tabs. If anyone has ideas, let me know.
Where's the line?
For example, I know several non-technical users who use the built-in dev tools to remove the annoying overlays that some sites show, but that don't allow to be hidden without logging in or something dumb like that.
These users don't really know what the DOM is, but they do know that they can open the dev tools, click the node selection button, click on the overlay they want to get rid of, press the Delete key, and now they're able to use the site again.
I think you missed the GP's point. Bookmarks can also be very useful to average users. One man's trash is another man's dev tools or whatever.
Drawing a clear line between what's essential for a browser and what's bloat probably isn't possible for any decent sized group of users.
I think it was a login prompt overlay shown on business profile pages. These users didn't want to log in to Facebook, yet needed to view the business' Facebook page. The overlay would cover a significant portion of the page, without any good way to get rid of it. So the users would use the dev tools to clean up the page, essentially, even if they didn't really know what they were doing.
And, as an (occasional) i3 user, I would not want this, because two browser windows seem to use up far more resources than one window with two tabs. Browsers are almost unusable once a certain number of tabs are open; I can only imagine how badly my computer would operate were the 100+ tabs I have open each consuming the resources required by a separate window.
One person's bloat is another person's feature.
No bookmarks? You mean one would have to type in every website address you want to go to?
It's so much easier to click on bookmark in the list, and with today's wide monitors, horizontal space is wasted anyway so I keep the bookmark sidebar open all the time.
Browser history search via the address bar is much faster than searching through bookmark folders for a particular page. Even nicer with Vimium where I can just hit "o" and search for what I want. For everything else, I just Google.
History wasn't part of kgwxd's specification (https://news.ycombinator.com/item?id=12442292), though, which just brings back to the central point: when you try to build a browser with the absolute minimum set of features required, you'll find that everyone's minimum set of features is different.
I find this "Give me only what I want" attitude quite frustrating. Perhaps you could argue for a more modular system that disables any given feature, but I would challenge you 8 days a week that bookmarks are a useful tool for most.
And really, bookmarks? How is that a performance hit? Maybe one would say that the "awesome bar" takes cycles to auto-search bookmarks when typing a URL, but you can disable that already.
Anyway, you can already use uzbl[1] if you want something minimal.
So even with pdf.js present, I end up using a proprietary reader most of the time. The added hassle or reopening PDFs in a separate reader most of the time exceeds the supposed convenience of the reader being built in.
I think they're best to focus on the things that can only exist within that client.
Because any other party can start a 'Hello' like service online. Or write a PDF reader (or a program to open any other file format)
I don't think we should be comparing to Chrome here; which doesn't purport to have the 'noble' aims of the Mozilla foundation. A browser should not be part of an 'ecosystem' of online services; for me, having a strong web means that the two are decoupled.
This, in turn, started the dark age of the web.
Netscape's rewrite was 1997-2000. In 1999, Martin Fowler published "Refactoring", which showed us how to continually improve the technical architecture of a system without trying to stop the world. JUnit, the first really popular testing framework came out about then as well; good unit testing makes it safe to refactor boldly. And the Internet itself gives us the ability to release early and often, encouraging us to do everything in smaller, more manageable chunks.
Giant rewrites were just what you did in the bad old days. But we never have to do it again if we make a point of keeping our technical debt low and our releases frequent.