Live data from Hacker News

Mozilla Acquires Pocket

blog.mozilla.org

281–290 of 456 posts

Re: Mozilla Acquires Pocket

#281

Earlier quoted context omitted.

> Allegedly, you can read things offline, but that feature never works for me. Strange, because that is the main use case I use in Pocket. I save article there, and it stores it for offline reading, striping all formatting. It isn't a bookmark manager, it stores stuff and doesn't need internet to read it.

My experience has been GP's: Pocket will claim to save something, but the moment I go offline, it craps out and tells me I need a connection to read the content I've saved. This is much more common on larger PDFs, but I've had it happen on so many sites that there was a point when I literally resorted to PDF'ing the pages I wanted to save - which is a damn shame, because Pocket's reader view really does do a good job…

I used to use Poki on windows phone and never experienced any issues. But since moving to iOS I often add stuff to pocket only to realise it hasn't auto synced or that I forgot to download before getting on the plane. The experience isn't that great IMO :(

If I remember to open pocket on my phone before flying I don't have issues.

Re: Mozilla Acquires Pocket

#282
post #272

Earlier quoted context omitted.

Aside from technical issues, native mail clients are shrinking in use over time, not growing. It does not seem like the right place to invest to continue having relevance in the marketplace.

Mozilla doesn't have to worry about the marketplace.

I disagree. Mozilla doesn't have a table at standards bodies or any sort of lever to make positive change on the internet without a healthy marketshare for its products.

Re: Mozilla Acquires Pocket

#283

Earlier quoted context omitted.

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

Re: Mozilla Acquires Pocket

#284
post #221
post #189

Earlier quoted context omitted.

Yes, but we're talking about XUL the platform. That platform was built with the same use-case in mind that Electron has: allowing people to build cross-platform desktop applications with web technologies (html, js etc). Unfortunately Mozilla failed to execute on that vision, leaving the field open for Electron and friends to emerge. Part of that failure was due to bad technological choices (RDF-XML was terrible ), pa…

But lots of people did write apps in XUL. My first IRC client and my first FTP client were both XUL apps. I'm not convinced that Electron today is any more popular than XUL was back then (aside from Atom (or VS Code, based on Atom), I can't name any programs that use Electron). Additionally, XUL uses web tech, but it is not a standard and was never intended to be a standard (not even an informal specification exists…

> I'm not convinced that Electron today is any more popular than XUL was back then

comex already named two highly popular ones (slack in particular can't be overlooked) but there are more. https://github.com/sindresorhus/awesome-electron

https://electron.atom.io/apps/

Outside of Slack, WhatsApp and Discord (see a pattern? pretty much all new chat apps are using it), I'm not sure if there's any other truly popular (among users) electron app, but among developers, electron definitely is popular and far more often used than XUL was. It's arguably more popular now for new apps than even toolkits like Qt and WxWidgets. People are writing, not one, but multiple competing implementations of things like.. unix terminal emulators in electron. These are not just webapps contained in chrome, they definitely need native access to local APIs. There's a frenzy among devs.

> so it's a stretch to say that Mozilla failed to execute on pushing XUL. What would the web gain by pushing it?

They didn't fail to "push it to the web". They failed to push it to app devs. They were rather enthusiastic at some point:

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Th...

> Whether you need to migrate an existing web application to the desktop, are looking for a technology that will enable you to easily port your applications to multiple platforms, or want to integrate your own cool features into the browser, XUL warrants serious consideration.

And now they are arguably failing to push it to themselves as they're entirely abandoning it for Firefox and will rewrite the UI and extensions APIs to get rid of XUL.

Re: Mozilla Acquires Pocket

#285

Earlier quoted context omitted.

One might care where the patches come from as a volunteer community could be less reliable over time than the paid Mozilla staff. I know I certainly feel that way.

But if you prefer security updates from paid employees of an organization rather than volunteers, surely a commercial product rather than a free one would be more suitable for your needs?

Not necessarily. I appreciate the values for which Mozilla stands, and those values are entrenched in their products.

Re: Mozilla Acquires Pocket

#286

This will give them plenty of data for their ad network, which is a nice strategic move. They always claimed to be privacy conscious so this is perhaps a nicer way to get interest and behavior information.

Interesting that people think Mozilla either isn't or is against being an ad network... every single attempt to do adblocking/protection ends up being an ad network eventually (if there's a corporation behind it).

Re: Mozilla Acquires Pocket

#287
post #132

Earlier quoted context omitted.

I always thought that complaint was kind of odd. It's essentially the same as their Search input. Google/Yahoo/etc. are proprietary but Firefox lets you talk to them directly from their browser. Similarly, the code for the Pocket button (component) for where it handles the user clicking the button, along with what it does to talk to the Pocket server, was all in the open and if you build from source you could just re…

"I don't know what I'm going to do when I can't use treestyle tabs anymore. I guess move to Pale Moon." I hear ya, being in a similar boat. My hope is that Netsurf ends up being a decent contender here by the time Mozilla kills XUL. Else, hopefully TST will indeed be made possible with Firefox-specific WebExtension APIs.

TST will be possible with WebExtensions. For hard evidence, even the Add-Ons Engineering Manager is working on his own, personal vertical tabs webextension to suss out what APIs we need: https://github.com/andymckay/sidebar-tabs

We may not land everything we need by the time Firefox 57 releases, but we'll get there. If we miss, you have options: you can decamp to Firefox ESR for a few months, where TST will keep working, or someone could theoretically convert TST to a WebExtension Experiment which would work on DevEdition and Nightly builds of Firefox.

Re: Mozilla Acquires Pocket

#288
post #273

Earlier quoted context omitted.

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'…

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.

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.

Re: Mozilla Acquires Pocket

#289
post #98

Earlier quoted context omitted.

> XUL was the future of old-school, heavy desktop applications. The old-school, heavy desktop apps seem to be so unbelievably light in comparison to current electron-based craziness. But I guess we deserve all the bloat for not being able to come up with sensible common API for desktop development :(

I know this might sound insane to everyone, just hear me out. I always thought Mozilla should have built a Linux distribution (or rather, forked debian like everyone else ha!) and implemented their Firefox UI kit (Gecko right? I'm not as familiar.) and made a Front end for it that was smooth and easy to build apps for using web technologies, but could still run native *nix apps via debion packages. I believe that now…

I think you might be describing something fairly close to ChromeOS.

Re: Mozilla Acquires Pocket

#290
post #189
post #101

Earlier quoted context omitted.

Thunderbird didn't lose to an Electron-based app, it lost to Gmail.

Yes, but we're talking about XUL the platform. That platform was built with the same use-case in mind that Electron has: allowing people to build cross-platform desktop applications with web technologies (html, js etc). Unfortunately Mozilla failed to execute on that vision, leaving the field open for Electron and friends to emerge. Part of that failure was due to bad technological choices (RDF-XML was terrible ), pa…

In an amusingly ironic twist though, Electron apps with their Javascript frontends also have byzantine and terrible build processes.
Post reply on HN