Hacker News Reader

Comment by omouse | Hacker News Reader

My only problem with Pocket was that it was proprietary and it was integrated with Firefox. If it's released under and open source license, then I'll be glad to have it integrated.

Pocket makes Mozilla competitive on mobile because Firefox's market share on mobile is very low.

View on HN

The client-side portion of Pocket has always been open-source.

If you mean the server-side then fair enough, maybe this acquisition will help with that.

It looks like their Firefox addon has (https://github.com/Pocket/pocket-ff-addon), and I guess by definition you can get the source of their Chrome addon and getpocket.com, but I don't think they meet the definition of open source unless they're somewhere other than Github. Also their mobile apps seem to be closed source too.

The built-in Pocket feature is an addon that is pre-installed into Firefox:

https://dxr.mozilla.org/mozilla-central/source/browser/exten...

Yeah, but there's for example also a Pocket Android app and iOS app. Those should get open-sourced now, too, and I heavily doubt that they were before.

I agree!

Submitting links to Pocket is open source and has always been well documented, but other client-side portions of Pocket have always been closed, such as the Article View API. [1]

It would be great to have access to article view to build other clients, such as a Linux client.

1: https://getpocket.com/developer/docs/v3/article-view

Pocket will be open sourced.

Is there any official source for this?

I don't think this counts as official, but a Mozilla employee replied to a Reddit comment stating that it'll be open source too.

https://www.reddit.com/r/firefox/comments/5wio45/mozilla_acq...

[edit] also nnethercote is a Mozilla employee :)

Wow, that will include a Linux client because Pocket also runs on the Kobo eReader. I'm curious if they open source that one. It should be doable to port to desktop Linux.

Does that mean I can run my own pocket server at home? That'd be neat and useful, I don't need any more profiling as is.

"If it's released under and open source license, then I'll be glad to have it integrated."

Not me. I don't want a bloated Firefox; even if the bloat is well intentioned and fully open sourced.

I'm so confused with the HN comments that bemoan the death of XUL, alongside comments that complain about bloat in the browser. It's interesting to see how different people use different parts of Firefox differently.

I know! I often see comments that imply HN is homogenous (with the exception of the poster). There's a lot of different people that make up the HN community, which is one of its strengths, and one of the reasons I value it.

One person's bloat is another person's critical feature. Are you thinking of install size, runtime cost, all of the above?

Firefox is open-source and (fairly) easy to build - if you really want the utmost control then I'd suggest this is the best way to do it. You can easily do a build that has no Pocket integration.

There's a cost to the level of configuration that I assume you're advocating here. Not saying we can't get better here, but there's definitely an impact on code complexity, QA test combinations, and stability.

I don't like bloat in web browsers because, often, if just adds features best left as an add-on. Also, in something as important as a web browser, I feel a smaller codebase is wise from a security point-of-view.

This was actually one of the arguments for feature shredding things like browser customization (see Classic Theme Restorer) and tab groups (see uhm Tab Groups).

I agree in principle, although in practice allowing Firefox add-ons to be fully equivalent to other features has been a detriment to security, stability and performance - hence the switch to WebExtensions (which rely on stable APIs purposely exposed by Firefox).

Having the codebase be as small as possible is a laudable goal - with browsers it is difficult since Web standards are fairly complex on their own, and being cross-platform brings along a lot of weirdness.

An important aspect of security is compartmentalization - for instance, using separate sandboxed processes for web content vs. the main UI (which runs with full user privileges).

Sandboxing is a good example here since it improves perf/stability/security but also adds to the size and complexity of the code.

I agree in principle, although in practice allowing Firefox add-ons to be fully equivalent to other features has been a detriment to security, stability and performance

Only in an abstract "we might have been able to implement security/performance improvements faster if we wouldn't have had to worry about breaking addons" sense. Any other effects are restricted to those people actually using the addon and don't affect everyone else.

A powerful extension interface can also be used to improve performance/stability: while e.g. adblocking certainly doesn't come for free, its cost should be more than offset by not running all that crappy code pulled from ad networks.

> One person's bloat is another person's critical feature.

That's what extensions are for. Those who want it, can have it, those who don't, they won't. Everybody wins, no need to raise emotions.

Reply on news.ycombinator.com