Mozilla Acquires Pocket - <AUTHOR> https://blog.mozilla.org/blog/2017/02/27/mozilla-acquires-pocket/ <comment><USER2> Mozilla is growing, experimenting more, and can acquire startups.

Mozilla doesn't have the resources to continue with Thunderbird.

I am increasingly baffled by their decisions and how they relate to the strategic plans [0] they've been producing for a while. Despite the worthy words in their plan they seem to have no sense of direction. That saddens me.

That said I'm happier having Pocket as an open source part of Mozilla/Firefox than a surprise integration of a commercial app.

[0] [https://wiki.mozilla.org/MoFo_2020](https://wiki.mozilla.org/MoFo_2020)

<comment><USER3> To be fair Thunderbird is awful. Every single time I try to find a better client I see someone suggesting "oh Thunderbird has gotten way better; give it a shot! I love it!" and every time I fall for it and it's the same slow, horrible application that I've tried again and again.

I'm all for them killing it.

<comment><USER4> My 1K+ folders and millions of archived emails disagree with you. I've yet to find a client that works as well as Thunderbird with my massive email archive.

Why would it be slow? I can only type so fast and sending/receiving mail is mostly dependent on the connectivity, not on the software.

<comment><USER5> I recently downloaded TB to move some offline mbox emails of large quantity. TB became increasingly slow processing few thousand. I downloaded Opera Mail to do the same exact work. I was done within few hours.

I have a need for more people to repeat the same process. There's zero chance I'll be asking them to download TB.

<comment><USER4> Thunderbird sets up a full-text index to allow you to search your emails. This eats up a bit of time while importing large mailboxes but is quite handy once it is done.

<comment><USER5> I tried that (I googled to see what am I missing) didn't help.

</comment></comment></comment></comment></comment></comment><comment><USER6> Oh, what a twist!

In a story that began two years ago with Pocket's integration by Mozilla [1] in Firefox [2], large segments of the userbase spoke out with scathing criticism.

This, at first blush, appears unrelated: Mozilla previously announced its Context Graph initiative, which was a bold undertaking to be built partially upon a new and emerging set of W3C standards to take back some of the control over linkage, metadata, and the consumption and annotation of web content [3] from big incumbent providers who run content portals, content silos, or content aggregators (largely the usual suspects, including Google, Facebook [4], Apple, Microsoft, and Yahoo [5]).

To understand this play, temporarily forget about Mozilla the Foundation, and think about Mozilla as a strategic competitor to the above. In the case of Pocket, a hard-to-deny side effect is that Pocket's presence in Firefox, despite the exact nature of the integration, is likely here to stay. While this is bound to frustrate many, Mozilla's competitors routinely ship software or entire platforms with tight captive integrations, against which competition has proven difficult to mount solely on the merits of values and philosophical purity.

[1] [https://hn.algolia.com/?query=firefox%20pocket](https://hn.algolia.com/?query=firefox%20pocket) [2] [https://hn.algolia.com/?query=mozilla%20pocket](https://hn.algolia.com/?query=mozilla%20pocket) [3] [https://news.ycombinator.com/item?id=13729525#13740110](https://news.ycombinator.com/item?id=13729525#13740110) [4] [https://news.ycombinator.com/item?id=13375451#13375917](https://news.ycombinator.com/item?id=13375451#13375917) [5] [https://news.ycombinator.com/item?id=12863565#12867493](https://news.ycombinator.com/item?id=12863565#12867493)

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

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

<comment><USER9> It looks like their Firefox addon has ([https://github.com/Pocket/pocket-ff- addon](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.

<comment><USER8> The built-in Pocket feature is an addon that is pre-installed into Firefox:

[https://dxr.mozilla.org/mozilla- central/source/browser/exten...](https://dxr.mozilla.org/mozilla- central/source/browser/extensions/pocket)

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

<comment><USER8> I agree!

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> Something I've always wished Pocket would do is download an offline copy of videos I add to the list (using, say, youtube-dl [1]), so I can watch them on the subway, etc. But they never did this, presumably either for legal reasons, or because it was a giant waste of bandwidth considering a huge percentage of Pocketed articles never get read.

Now that Mozilla is promising to open-source this, I eagerly await adding this feature to my own fork :)

\-- [1]: [https://rg3.github.io/youtube-dl/](https://rg3.github.io/youtube- dl/)

<comment><USER12> See Youtube red.

<comment><USER13> Youtube Red is not available in most of the world:

> available in the United States, Australia, Mexico, New Zealand and South > Korea.

<comment><USER12> I guess they'll have to wait.

</comment></comment></comment></comment><comment><USER14> Pocket, for me, is a weird product/feature. I've tried to use it, but it ends up just being like a clumsy bookmarking feature.

Allegedly, you can read things offline, but that feature never works for me. It seems the feature for offline reading doesn't exist at all in Firefox (which I'd assumed was the point of its integration, but my assumption was wrong), and I've tried the Chrome desktop app and the Android mobile app ..nothing I save to pocket is ever readable without a data connection. It must work for some content for some people because I see people talking about it like it does. But, without that feature I see literally no utility in Pocket...it's just a clunky bolted-on bookmark manager, and so I end up going back to bookmarks with tags. I use Sync and I have Firefox on all of my devices. So, my bookmarks go with me.

So, I guess it's good that it's going open source. I wasn't comfortable with the way integration was presented back when they added it...it wasn't at all apparent, to me, that Pocket was a third party for-profit entity when the "setup your pocket" process launched in Firefox, since I'd never heard of it before that. But, it still seems like a solution looking for a problem. I'll give it another look. Maybe I was just unlucky with my choices of what to save...but it seems like if offline reading is not going to work on a page (for whatever reason) it should warn you. It'd suck to get on a train/plane or get lost in the woods, with plans to catch up on some reading, only to find there's nothing there.

But, maybe that's not even the primary purpose of Pocket? I dunno, it's still pretty fuzzy to me wtf it's for, if not that.

<comment><USER15> The Kobo ereaders have had Pocket integration for a while now, and it works great offline. My usual routine is to find interesting articles on Hacker News, and if they are longer than a page or two, click the Pocket button and read them at home on the ereader. A few don't render well (the article on Arrival/Story of your Life not being a time-travel story was a recent fail), but generally it works great.

<comment><USER16> _the article on Arrival /Story of your Life not being a time-travel story was a recent fail_

Loved the book / movie but haven't read that article. Do you have the link? Thanks.

<comment><USER17> Probably this one: [https://www.gwern.net/Story%20Of%20Your%20Life](https://www.gwern.net/Story%20Of%20Your%20Life)

</comment></comment></comment></comment><comment><USER18> I've always liked Pocket, but felt queasy about its integration with Firefox.

I consider this a great move for a better bookmarking experience in Firefox as well as a better pocket service.

<comment><USER19> It is ridiculous though. Mozilla already had a sync infrastructure, it didn't need another service just for bookmarks, "only" a decent additional UI.

To me, the whole Pocket thing always smelled of cronyism. Someone is friend with someone else, and lo, Pocket appears. People get all angry, Pocket's hockey-stick fails to materialise, and lo, Mozilla bail them out...

<comment><USER20> Not only that, but the original Read-It-Later extension did exactly that: it stored links directly in Firefox's bookmarks system in a "Read-It-Later" folder. Only later did it begin using its own, separate database.

</comment></comment></comment><comment><USER21> Pocket's post about the acquisition, referring to the main value their product brings, says, "a platform where high-quality, thoughtful content and free speech can rise above the rest."

Pocket used to have a feature aimed at surfacing high-quality content from the collection of things a user had already pocketed. They removed that feature. I was paying for their premium service before that change. After they removed it, I stopped the premium subscription because I wasn't sure what pocket's value to me was anymore.

Now they have a recommender that recommends things you _haven 't_ pocketed yet. But that just encourages the user to accumulate an ever larger collection of pocketed things, not surface the best things in that collection.

Ever since, I've reflexively kept saving things to pocket, hoping they would bring that feature back. But the only practical thing I have done with it is pull up something I just saved recently, because it will be near the top of the list.

Pocket's CEO also writes, "In fact, we have a few major updates up our sleeves that we are really excited to get into your hands in the coming months." I hope they will bring that feature, or something with a similar aim, back.

<comment><USER22> OK, so it's not just me imagining things.

My view is pretty much as yours: _POCKET IS MY VETTED WEB._ If I've saved stuff there, it's because _that is shit I 've already determined is worth a second look, and I want to be able to find it again._

Increasingly, when I hit my Pocket archive (3k-4k+ items, top 1% user), I find that _I cannot find what I 'm looking for._ This negates approximately 80% of the purpose of having Pocket in the first place, and I've been giving strong thoughts to simply using it as a link dump until I can figure out how to:

1\. Download the content myself.

2\. Download the tags, which are the most important element.

3\. Get the simplified-Web view. Web design isn't the solution, Web design is the problem.

4\. Be able to search and filter _specifically what I 've already fetched_. And filter by more options: date, website, author, tags (positive and negative filters), etc.

None of that currently exists. And it is increasingly frustrating.

<comment><USER23> +1 for searching and filtering. I use Bookmark OS for this. It's more desktop oriented but the sorting and visual nature really helps me browse what I've already bookmarked. [https://bookmarkos.com](https://bookmarkos.com)

<comment><USER22> Interesting.

I've just started speccing out some thoughts on how document references (files, URLs, URIs, ...?) might be improved. A sort of api / multiple- attribute interface strikes me as useful:

1\. Meaningful titles / filenames.

2\. A content hash. Not exactly human-friendly... I'd prefer something shorter to longer, though there's the collisions problem. Still thinking on this. Could tie into VCS (git, Hg, etc.)

3\. Various standard metadata: author(s), editor(s), publisher(s), and their relation(s) to the doc. See various bibliographic or MARC 21 formats.

4\. Dates: Initiated, published, modified, accessed, read date(s).

5\. Classification schema. Here with time I find that working with _extant_ rather than de novo or ad hoc schema is most likely preferable. Dewey Decimal is apparently more logical than LoCCS, but the Library of Congress classification is nonproprietary. That may well be what makes it win out.

6\. Workflow indicators. Unread, read, deep-archive, to-process, etc.

7\. Reputation and ratings. Associated with works, authors, other contributors (editors, fact-checkers, etc.), publishers. Some form of distributed assessment here would be useful.

The question is how to make these visible. My thought is to treat the parameters as, essentially, search. It doesn't matter _what_ name you use, so long as the _set_ characteristics is unique _or determinable_. E.g., returning 3 items would allow me to manually determine which I'm interested in, returning 300 would make that difficult, returning 3,000 would probably require some programmatic determination (or further specification).

A URL scheme, say, URI:/au=clarke&dat=lt:1980&ti: _=imperial &ti_=earth ... could, say, return Arthur C. Clarke's _Imperial Earth_.

A filesystem / virtual filesystem approach might work somewhat similarly locally, either from a CLI or graphical approach. I'm thinking of how that might work....

Very early stages.

</comment></comment></comment></comment><comment><USER24> "We believe that the discovery and accessibility of high quality web content is key to keeping the internet healthy by fighting against the rising tide of centralization and walled gardens" that alone is a reason to welcome this aquisition. Facebook has become for many, me included the entry point to the web much more so than the browser and I really don't like that. I can imagine Mozilla suggest content to users based in what they have saved in the past on pocket and integration with Firefox. Nice move.

<comment><USER25> I suppose then that the strategy will be "the browser as a platform" vs "FB as a platform", with the technical difference that all FF tools will be open source?

That actually sounds promising. Next logical content vertical would be video then (judging from FB's content importance)

</comment></comment><comment><USER26> This is weird. Has Mozilla acquired any startups in the past? Feels weird to me for a browser non-profit to own a web app product.

<comment><USER27> It _is_ weird - the press release itself notes that this is the first such acquisition Mozilla has ever made.

In their defense, it won't be the first time they've gotten into operating a service -- there's Sync, for instance. So if they see expanding FF's bookmarking abilities as a key strategic differentiator, buying an existing read-it-later service they're already familiar with could be a simpler/cheaper way of getting there than building one from scratch.

<comment><USER28> First acquisition but not first investment. For example see [https://blog.mozilla.org/press-uk/2016/08/23/mozilla- makes-s...](https://blog.mozilla.org/press-uk/2016/08/23/mozilla-makes- strategic-investment-in-cliqz-to-enable-privacy-focused-search-innovation/)

<comment><USER29> Mozilla also joined Everything.me's Series C funding round:

[https://blog.mozilla.org/blog/2012/11/28/mozilla-invests- in-...](https://blog.mozilla.org/blog/2012/11/28/mozilla-invests-in- everything-me/)

</comment></comment></comment></comment><comment><USER30> I have been working on a prototype for a competitor to Pocket and other save- for-later services with an emphasis on minimalism, privacy and ease of use.

[https://slushi.es](https://slushi.es)

Very early app, features are rolling out daily. My end goal is to build a recommendation engine out of user data, while keeping things anonymous.

Although social bookmarking has been done plenty times before, I think execution has been sub-par in previous solutions. My aim is to make things streamlined and fast for the user to go from 'what was that link?' to 'there it is' (sidenote: check out slushi.es opensearch, and how it behaves when there's one result (only works for signed-in users)).

A complaint I hear often from Pocket users (and other save-for-later users alike) is that they will save 100s of links without ever going back to reading them. I, too, shared the same sentiment until one day I experienced a 'what was that link again?' moment. It was rare and fleeting at the time, but since using slushi.es more and more, those moments have appeared with increasing frequency.

I believe the best save-for-later app will transform the regular web browsing individual's habits of reading an article and forgetting about it, to reading an article and remembering it later; either a day later, a month later, or perhaps years. The thing is remembering. I think a good save-for-later app works as a memory reinforcer; something that augments your ability to build and recall knowledge.

<comment><USER31> It doesn't sound like you are a competitor for Pocket. It sounds like you are a competitor to Diigo. You might want to re-evaluate who your competitors are and do a SWOT analysis of them.

<comment><USER30> thanks for the tip. diigo is definitely a competitor (was noticed by our analysis a long time ago but attention to it has fell by the wayside). pocket seems like the biggest whale, so naturally have pinned it as one of our competitors. i think any save-for-later app that introduces discoverability is a competitor

</comment></comment></comment><comment><USER32> I have used Pocket for the last five years or so. 99.5% of the articles I bookmark every day I never actually read. Probably should make me think why I use it at all...

<comment><USER33> I read A LOT on pocket (they sent me an email that I was one of their top 1% readers, with having read 1.7 million words).

For me it's a great time saver, I see some interesting article during work, but instead of wasting my time on it during work, I save it for later. Granted I get no signal during the subway where Pocket becomes a really useful app, but it results in me being a lot more efficient with reading.`

<comment><USER34> Same here.

</comment></comment></comment><comment><USER29> The Firefox bug to open source Pocket: [https://bugzil.la/open- pocket](https://bugzil.la/open-pocket)

</comment><comment><USER35> As a former del.ici.ous engineer and user, I'm happy to see that Pocket will be in good hands for a while :)

<comment><USER36> Is there any chance you know what's happening with delicious now? Their last blog post is dated "April 24, 2016" [1], and they are silent on Facebook since May 2016 too [2] despite loads of comments.

[1] [http://blog.del.icio.us/?p=1193](http://blog.del.icio.us/?p=1193)

[2] [https://www.facebook.com/delicious/posts/10153614657337205](https://www.facebook.com/delicious/posts/10153614657337205)

<comment><USER37> a year or two they went down for about a week. That was the final straw for me and pushed me to pay for pinboard.in. I haven't looked back since. it just works and I don't worry about it going down or going away.

</comment></comment></comment><comment><USER38> Pocket is one of my favorite products to use. Congratulations to the team!

</comment><comment><USER39> As I do a fair amount of offline reading, I'm a fan of pocket.

</comment><comment><USER40> Dear Mozilla, I'd love to help out with Pocket.

As a concerned user, I even wrote this a few months ago [http://constantbetasoftware.com/2016/09/02/pocket.html](http://constantbetasoftware.com/2016/09/02/pocket.html)

How can I apply?

<comment><USER41> Pocket is a wholly owned subsidiary of the Mozilla Corporation, so Pocket retains a great deal of autonomy within their organization. Since Mozilla acquired the entire team, I'd start by reaching out to the individuals listed on [https://getpocket.com/about/](https://getpocket.com/about/).

Longer term, my understanding is that we want to use Pocket's expertise and data to help build a recommendation engine for the open Web (Context Graph: [https://wiki.mozilla.org/Context_Graph](https://wiki.mozilla.org/Context_Graph)). This speaks directly to the problem of sites like Instagram which restrict links to external sites: users can enter via URLs, but they can't navigate away. (More reading: [https://www.theguardian.com/technology/2015/dec/29/irans- blo...](https://www.theguardian.com/technology/2015/dec/29/irans-blogfather- facebook-instagram-and-twitter-are-killing-the-web)). If anything could help users route themselves out of these silos, it'd be a huge win for the openness of the Web.

<comment><USER42> Thanks, I'll try to get in touch with them.

I'd love to help on the recommendation engine. I'm (for two years now) at the top 1% of users.

I also happen to live in Brazil, to be a native portuguese speaker and the recommendation system absolutely sucks. I get a lot of articles regarding startups and Trump, but absolutely nothing in portuguese and/or about Brazil.

</comment></comment></comment><comment><USER25> I was shocked to read the news since afaik Mozilla had never made acquisitions like this in the past (which they mention in the post).

I'm excited though, since the reason I hadn't used Pocket in the past was because I didn't want to be part of yet another walled garden (YAWG?).

A quick look at Crunchbase shows that they'd raised $14.5M from investors. Given Mozilla's ~$300M of annual revenue, I wonder whether this leans towards an acquihire or a technology/product acquisition (definitely not a business acquisition). Difficult for me to assess the significance of 10M users for a company like Mozilla.

<comment><USER43> My general rule of thumb is that if they don't announce a price it's an acquihire.

</comment></comment><comment><USER44> I'll keep saying that Mozilla should acquire Fastmail.

Now that would be a strategic acquisition.

<comment><USER45> There's a joke at Mozilla that "Opera did it first". Pretty much every new feature in Firefox, Chrome, etc has appeared first in Opera.

In this case: [https://techcrunch.com/2010/04/30/opera- fastmail/](https://techcrunch.com/2010/04/30/opera-fastmail/)

<comment><USER46> Funny how far Opera has fallen these past few years. Years ago it was setting trends with tabs. Now it's yet another Chromium-based browser.

</comment></comment></comment><comment><USER47> It's fairly early stage but I've been actively building an alternative to Pocket called Filltray ([https://filltray.com](https://filltray.com)). I found myself being overwhelmed by products like Pocket/Instapaper so wanted to build something different. A place to keep things for "short" periods of time but without the baggage of having 100s of items permanently on your never-ending reading list. A "do-later" place that may or might not come around. A couple months ago I put up a public roadmap ([https://medium.com/filltray/public- product-roadmap-3964c3fa4...](https://medium.com/filltray/public-product- roadmap-3964c3fa4398)) and I'm continuing to work hard to produce a product which meets mine — and I think others — needs for a rethink on read-later. Please feel free to follow @filltray to keep up to date with my progress :)!

</comment><comment><USER48> The first thing I do with a new Firefox install is remove the Pocket button, but I still welcome the prospect of seeing the Pocket service becoming open source and part of Firefox Sync. There are definitely some interesting ideas around the Context Graph, and hopefully the Pocket team will be able help move the project forward.

</comment><comment><USER49> That's interesting. I see they plan to open source it. I might even use it after that.

</comment><comment><USER50> Does this mark a strategy shift away from search revenue as the primary funding source? A quick crunchbase search for other aquicisions by Mozilla yeilded nothing, so I'm curious if there are other examples of them buying up for-profits.

<comment><USER51> The only other example is the hiring of three co-founders of Humanized, [https://techcrunch.com/2008/01/15/breaking-mozilla-buying- hu...](https://techcrunch.com/2008/01/15/breaking-mozilla-buying-humanized/)

</comment></comment><comment><USER52> This is an interesting development. I am curious to see how they take this integration forward. Specifically, I have questions whether it will still have a Premium component or will it be made completely open-source.

For those interested in an alternative, I am currently building a simpler bookmarking tool [1] that works pretty much exactly like Pocket or Instapaper. Email This will extract useful content from a page and send it to you via email instead of you having to download an additional app or login to another service to access your bookmarks.

[1] [https://www.emailthis.me](https://www.emailthis.me)

</comment><comment><USER53> I think this is great. I'm weary of add-ons/extensions so only run a couple (which are from providers I trust)

I didn't really trust my saved article data to a random startup. Being under Mozilla means now I'll actually use it.

</comment><comment><USER54> I use Pocket differently than most people here. I never save articles to Pocket — I just use their Recommended engine to find interesting articles to read. Some of these come from sources I regularly read (NYT), but others come from obscure sources or big sources that I tend not to read for whatever reason. In a small way, it helps me get news from outside my bubble, and sometimes I'll end up reading regularly from a source I discover through Pocket.

My only complaint is that a large portion of the Recommended content is junk from Business Insider. Hopefully this will wane as Mozilla's priorities are implemented.

<comment><USER22> The ability to blacklist sources would be fucking awesome.

I'm mostly limited to firewalling domains at my router. Doesn't stop them from turning up on, e.g., Web search.

</comment></comment><comment><USER55> Can Pocket please finally support Facebook links to non-Facebook context? And just strip the Facebook URL junk?

Otherwise, you have to click on a FB link to get the unmangled URL, thus counting against your number of free views every month.

<comment><USER22> Incognito mode.

Or Archive.is

</comment></comment><comment><USER56> I've used Pocket in the past but when I started using Evernote I discovered that I do not need Pocket anymore. Is there any killer feature that I do not know about that Pocket offers and Evernote doesn't?

</comment><comment><USER57> Huge fan of the Pocket App. Any guesses for how much the deal would be worth?

</comment><comment><USER58> When they add ML clustering to one's pages, so that I stop using bookmarks, and find useful stuff automatically grouped together, plus recommendations...then perhaps I'll start using it

</comment><comment><USER59> It sounds like a good plan, making Firefox a platform for organizing information while web browsing, research, etc.

A question: what advantages privacy-wise does Firefox have over Safari on iPad and macOS? I frequently delete all cookies on Safari and set strong privacy options. I ask because I have transitioned in the last year or so to working on my iPad and MacBook, largely letting my Linux boxes collect dust. On Linux, using Firefox was an easy decision. On iPad and MacBook, Safari is more convenient.

</comment><comment><USER60> I use pocket because it is automatically synced with my Kobo e-reader. One thing I wish they would offer is folders. Before I bought the kobo I stuck with instapaper just because of the cleaner interface and the option to use folders.

I get that pocket offers the option to tag, but different people have different preferences and folders would be nice.

Also a bunch of large squares doesn't seem to be the best way to organize information consisting of web blogs and pictures.

Hopefully mozilla will make some UX changes to pocket.

</comment><comment><USER61> I never used pocket, but I use instapaper.

I wonder if Pocket will be completely free now or if mozilla counts on this to fund more of its efforts. Beyond that. I also wonder if this means a read it later service will finally properly support RSS. Forgive me I don't know the features of pocket but as i understand it is does not correct?

I been using the built in firefox RSS feeder for years. with pocket integration it'd be a lot more useful.

</comment><comment><USER62> If you're interested in using Pocket in Chrome/Chromium but aren't ready to hand over the insane amount of permissions required for their official extension, you can run the Add to Pocket (mini) extension.

[https://johnrockefeller.net/use-pocket-without-being- tracked...](https://johnrockefeller.net/use-pocket-without-being-tracked/)

</comment><comment><USER63> I LOVE POCKET! I'm only very happy to hear that it's Mozilla who has bought them. Warm feelings of security and privacy.

</comment><comment><USER64> I was wishing Pocket would offer AWS Polly playback for articles, so I started making my own app to do it. Now that it is going open source I might just piggy back their parser as its a good bit better than mine.

Hope they build in some Context Graph projects into Pocket, as there is some great ideas their.

</comment><comment><USER65> After this, why should I donate to Mozilla? I really don't get what's the difference between donating to Mozilla and donating to Facebook. Facebook open-sources some of their stuff. Facebook buys companies to generate revenues... I guess Mozilla doesn't need help anymore.

<comment><USER41> Donations to "Mozilla" go to the non-profit Mozilla Foundation, which does exceptional, meaningful work. Firefox is developed by the Foundation's self- funding, for-profit subsidary, the Mozilla Corporation (MoCo). MoCo acquired Pocket, using its own funds.

For legal / tax reasons, MoCo can only push a tiny fraction of its revenue up into the Foundation. This means that donations are necessary to sustain the Foundation's initiatives.

<comment><USER25> I feel like sufficiently large numbers of people are confused about the arrangement of the company and the foundation (I definitely don't know the details of the money flow between the two), that this warrants some kind of easily referable page on Mozilla's website.

(appreciate you clarifying this here)

</comment></comment></comment><comment><USER66> I think it would be great if they looked into merging the existing bookmarks system with Pocket!

</comment><comment><USER67> Seems that the user data/behavioral patterns is really always the most important thing for this type of services huh? The aim was mostly to get acquired and it seems that the acquirer always has an eye on the vast amount of data etc.

</comment><comment><USER68> I hope they'll remove some of the "growth-hacker" stuff from the chrome extension. Modifying the new tab page and injecting links on pages by default is super annoying.

</comment><comment><USER69> I've been lately dissatisfied with pocket and related apps for lacking some admittedly fringe features.

The possibility of adding them myself without rebuilding the whole app is exciting!

</comment><comment><USER70> Yeah! At last I can change Feedly! Any advice before migrating?

</comment><comment><USER71> what will happen to pocket premium?

<comment><USER72> did anyone buy pocket premium? i always perceived it as a sales page that got no sales.

<comment><USER73> I did. Mostly because I like/use the tool and I wanted to support their work.

<comment><USER74> I did for the same reasons and also in the hope of having advanced search.

</comment></comment></comment></comment><comment><USER75> this is really great news. i like pocket integration on kobo aura one. i hope they keep making that integration improvements further.

</comment><comment><USER22> I hope this is good news.

I've been using Pocket for a couple of years, and am a top-1% user. It's been useful, though also highly frustrating, and is at best only about a 50% solution.

I've provided considerable feedback to Pocket over issues and features. Over the course of a couple of years, few if any of them appear to be addressed, which has been highly disheartening. (Any Pocket folk: I'm "dredmorbius" at gmail, though not in my account, which is otherwise attributed, because, you know, privacy, Kristalnacht, Snowden, etc., etc.)

I'd previously used Readability, which was nice in fixing a primary problem of online content: Web design isn't the solution, Web design is the problem. But _that_ service shut down, on 30 days notice (though with loud signs for the previous couple of years) last September. I spent several days largely manually transferring information out of Readability (404 links meant that a straight export wasn't useful -- I had to track down alternative references where possible). I'm hoping I don't have to go through that again.

I've looked at other alternatives: Instapaper (no compelling use case), Pinboard.in, by our very own @idlewords (his comment below was ... not particularly useful). Upshot: without a very specific walkthrough of the product, I can't tell if it's worth my time, and my time would be a week or month of trying to reconstruct the structure I already have in Pocket, in Pinboard. I've visited the "Tour" link multiple times, and no, it isn't clear that this offers me anything useful.

I'm thinking that RMS's model of having an email-based web-requesting systsem might actually be more useful than anything else. A Mutt (or Emacs mail-mode) searchable, taggable archive, date-sorted, threadable/groupable, would be a huge win over a lot of other alternatives. I've been thinking through other ways in which I might create my own self-hosted archive repository.

Zotero is another option, though again, I can't quite penetrate the use model / workflow.

In both cases, the prospect of being stuck with as-published layouts rather than as-useful layouts (have I mentioned: Web design isn't the solution, Web design is the problem) is disheartening.

I'd really like to have an offline / commandline tool which could manage webpage decrufting. I'm aware that it's not a fully deterministic process -- the problem with the Web, for better or worse (I've been suspecting the latter for some time) is that there are no publishing standards, and content follows no consistent form. That said, much content can be divided into two general categories: 1) known states of fucked up and 2) unknown states of fucked up. Growing the size of category one, and taking the hopeless cases and simply stripping _all_ markup from it and starting from scratch (something I do myself, manually, far more often than I care to think) is a semi-reasonable approach.

I've written a few times on what's plaguing the Web (as have others, Maciej's rants are particulalry recommended).

Tabbed browsing: a band-aid: [https://www.reddit.com/r/dredmorbius/comments/256lxu/tabbed_...](https://www.reddit.com/r/dredmorbius/comments/256lxu/tabbed_browsing_a_lousy_bandaid_over_poor_browser/)

The Reference Management Problem: [https://www.reddit.com/r/dredmorbius/comments/50o1jv/the_ref...](https://www.reddit.com/r/dredmorbius/comments/50o1jv/the_references_management_problem_readability/)

And some general feedback (wrapped around some specific feedback) to Pocket: [https://ello.co/dredmorbius/post/3eucmp_s0tumjuoxmfclbw](https://ello.co/dredmorbius/post/3eucmp_s0tumjuoxmfclbw)

(Yes, it's heavy on the caps and asterisks -- it's difficult otherwise to indicate important points in email. SoKookMeHarder...)

Borrowing from that last:

Don't put solving your own problems ahead of solving those of your users.

The features I do use, heavily, and would like to see improved, are article view (many websites remain glitchy, I'm well aware this is a whackamole problem, but it does need to be continually addressed), import (I've been working through a backlog of 2,000+ Readability articles migrating to Pocket, slowly, one-at-a-time, there's no automated tool), bulk-action tools, sub- corpus tools (working on a specific set of articles at a time), and tags tags tags tags tags tags tags tags tags tags tags tags tags tags tags tags tags tags tags (did I say tags) tags tags tags. And more tags.

A principle, perhaps the principle problem with the Web as it stands is organisation particularly as concerns quality and vetted content.

There are various sources who can vet content. Some are good. There's one I especially trust, and whose judgement over what I like is strong: ME.

I've commented before, AND CONTINUE TO HUGELY APPRECIATE several features of Pocket, especially the ability to peform full-text searches of my current and archived articles. It's HUGE.

One of my (many) interests is COGNITIVE LOAD. Pocket is a tool for REDUCING COGNITIVE LOAD when reading online media. I see several mechanisms:

1\. A standardised presentation of Web content. I can look at an article, and identify what is the primary content (virtually all of it), what's metadata (usually the top -- you do a good job but I'd love to see this improved as well), and where the controls are (standard Pocket bits).

2\. Elimination of online distractions. Sidebars. Ads. Animations. Videos. Spurious links. Shitty page layout. Shitty font choices. Shitty colour choices. Shitty CSS choices.

3\. Format optimised for my device and preferences. I love you to tears for not having to fuck with zoom, font choices, background/foreground colour, etc., etc., etc., on Every Fucking Webpage. ("Web design isn't the solution, Web design is the problem.") Huge. Or is that "Hyuuuuge!" now?

4\. My own curation. Anything I've saved to Pocket I've seen at least once. There's a familiarity in returning to material which makes it more valuable.

5\. Tags. Again, my assigned classifications for material. (And often picks selected from Pocket's tag suggestions, which are quite good.)

</comment><comment><USER76> [https://blog.mozilla.org/blog/2017/02/27/mozilla-acquires- po...](https://blog.mozilla.org/blog/2017/02/27/mozilla-acquires-pocket/) explanation for this move is very laconic IMO. What are benefits? We already know majority of user were against even basic integration with pocket.

</comment><comment><USER77> I use Instapaper on a daily basis, how does Pocket compare?

<comment><USER78> These are the most salient differences in my experience with both:

\- Apart from saving the parsed, "readable" version of an article, it can also save the web as-it-is. This is very useful for those times when the formatting is important (as it is in articles that include code; you loose syntax- highlighting with the readable view. Pocket can be set to try and choose the best view for each article.

\- It does a great job with videos.

\- It uses tags instead of folders.

\- Instapaper has been less reliable for me (specially the android app), although in fairness I've used it more, so I'd notice it's unreliability more often.

I'm not that interested in recommendations, but I gotta admit that the few times I've looked at them, Pocket's recommendations were fairly good.

I've been using Instapaper for around two years now, keeping Pocket as a bag of less-important links, not-really-reading-material, and very often video. I was thinking of going back to Pocket as my main read-it-later service, specially for the first feature I mentioned.

It being Mozilla-owned and some day also OSS will surely be a further advantage in my mind.

</comment></comment><comment><USER79> Why would someone use pocket over zotero?

<comment><USER9> I just searched zotero in the App Store and got nothing, so because every morning I save stuff from Feedly into Pocket and I have no idea how I'd do that with zotero.

<comment><USER79> Did you try googling that?

<comment><USER9> Yea, I found their website : [https://www.zotero.org/](https://www.zotero.org/) Available for Windows, Mac and Linux. So no mobile apps at all, Pocket apps are great so that's a good reason to choose them over Zotero.

</comment></comment></comment></comment><comment><USER80> Will it become firefox exclusive?

<comment><USER81> It's more likely to get fully open sourced, I bet, which would make that rather hard?

</comment></comment><comment><USER82> "save to pocket" :D

</comment><comment><USER83> How does Mozilla earn money?

<comment><USER84> Search engine deals, and now pocket

</comment></comment><comment><USER85> Two apps I no longer use because they became bloated and unfocused, they deserve each other

</comment><comment><USER86> They're losing their Yahoo search money in the future and need to make it up somehow.

</comment><comment><USER87> I will never again donate to the Mozilla Foundation.

<comment><USER41> Why's that? This acquisition was carried out by the self-funding Mozilla Corporation. The Mozilla Foundation is a separate entity.

</comment></comment><comment><USER88> Ahahahahaha

</comment><comment><USER89> So much for my hopes of them removing it from Firefox. Uhg.

<comment><USER90> You want them to remove one of the most useful feature of Firefox?

You can remove it easily, but I'd advise you to try using it.

It personally helps me go through interesting news and "pocket" it if I don't have the time to read it now, or want to keep my time for more important articles but still think it's an important piece of news.

I have both the desktop Pocket application and the mobile Pocket application. They download the web view offline, like that I can read articles wherever I am, when I have some down time.

It's been a huge time saver when it comes to only reading what is important during the day. Having less tabs. And being able to see what I deemed important to read after a while.

<comment><USER91> The existing bookmark system does pretty much all of that already (with the sole exception of offline viewing, but Pocket's implementation is reportedly buggy anyway), and then some. It also syncs across one's devices.

<comment><USER90> the offline viewing is the only reason I use Pocket.

</comment></comment></comment></comment><comment><USER92> My impression is that most things that Mozilla starts, they shut down.

I was following their experiments, and they shut all of them down while some of them were already working.

I used to use Thunderbird years ago, but they completely stopped working on it.

I just hope they don't kill Pocket, since I use it every day to save things to read later.

</comment><comment><USER93> Mozilla can spend money on this, but not Thunderbird or XUL-based extensions?

<comment><USER8> It's more a question of "won't" rather than "can't".

Why do you think XUL and Thunderbird are good investments vs. things like Servo or the context graph initiative (which the Pocket team is going to accelerate according to the blog post)?

Do you think a non-standard framework for making fat native apps and a mail client built on this framework are going to make Mozilla more relevant?

<comment><USER8> The reason I bring up Servo is that parts of it are already starting to land in Gecko and will ship with Firefox soon - do you think making Servo support XUL is a good use of anyone's time?

</comment></comment></comment><comment><USER94> I have no idea what Pocket is, but as a Firefox stalwart and a person looking to learn Rust, the fact that Mozilla is actually acquiring stuff gives me confidence on its financial stability. Very important issue in the decision making process on future technologies to back.

</comment><comment><USER95> Mozilla has the resources to buy companies. But not the resources to make videos play smoothly. 2017 and Firefox has no hardware accelerated video playback on Linux.

Every time I read about something Mozilla does, I am reminded of this xkcd comic from 2013:

[https://xkcd.com/619/](https://xkcd.com/619/)

</comment><comment><USER96> Wow, I thought it would be the other way around!

</comment><comment><USER97> Synergy: One product that nobody uses is now bundled with another one.

</comment><comment><USER98> _> Mozilla is growing, experimenting more, and doubling down on our mission to keep the internet healthy, as a global public resource that's open and accessible to all._

...by buying a crappy, proprietary app?

<comment><USER81> It has a huge user-base, so we can disagree on crappy. And obviously the latter part is fixable.

Pocket was originally a Firefox add-on.

<comment><USER8> The built-in version is too: [https://dxr.mozilla.org/mozilla- central/source/browser/exten...](https://dxr.mozilla.org/mozilla- central/source/browser/extensions/pocket)

</comment></comment></comment><comment><USER99> 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.

<comment><USER8> I'm not sure which ad network you mean - there was an effort to serve ads on the new-tab "tiles" page but that was shut down a little over a year ago: [https://blog.mozilla.org/advancingcontent/2015/12/04/advanci...](https://blog.mozilla.org/advancingcontent/2015/12/04/advancing- content/)</comment></comment>


Website idea to combat censorship on major platforms - <AUTHOR> After seeing many platforms attempt to silence content creators either explicitly, or silently, I grew frustrated that in order to see certain view points on specific subjects, it was enormously difficult to find these creators. Typically its either via word-of-mouth, or some niche forum that mentions where to look. (note this was long before the current pandemic)
I wanted to find a site where I could find these lesser known content creators. These platforms paint with a broad brush, and categorize many 'dissidents' with the same rhetoric.
My idea is CreatorBytes.com
I'm still fleshing out the details, but essentially the site will allow content creators to create a page where users can find all of their content linked from a single site. Further, they can notify their users who choose to follow their page, in case the content creator's typical communication channel is compromised.
Users can find creator's library of content, without the chance of the creator being silenced on their other distribution channels.
Eventually, with enough creator pages, users can also use the site to discover similar creators.
The website aims to serve a few functions:
One, as a backup in case the content creator's main communication channel goes down.
Two, as a centralized place for users to find content across a variety of platforms.
Three, a place for content creators to share their content with a wider audience, and for users to find new content they otherwise couldn't see.
Further, Creator Bytes is oriented towards privacy, transparency, and value, without compromise.
If you're interested in learning more, and being notified once the alpha site is active, sign up for an email notification at https://creatorbytes.com/alpha
If you have any questions, or comments, you can reach me on this thread, or at firstname.lastname@example.com
I would greatly appreciate any and all feedback from the HN community. Thanks! <comment><USER2> This has been heavily debated here. I would encourage you to check out the search with time filters for recency

</comment><comment><USER3> There is significant overlap between those who are censored on major platforms and those who either advocate violence against people, distribute hate speech, or are otherwise abusive on those platforms.

How would "creatorbytes" respond to a content creator who is interested in having a platform to advocate for eugenics or genocide? What about a phrenologist or otherwise "scientific racist?" How about anti-LGBTQ creators?

I'm not saying there has to be an answer for every "what if" question out there, but the problem of censorship is a hard one, and these questions are the ones society is currently struggling with. I don't know what kind of perception you want to foster, but if your site is the known haven of these sorts of viewpoints, you might run into the same issues that 8chan did: [https://blog.cloudflare.com/terminating-service- for-8chan/](https://blog.cloudflare.com/terminating-service-for-8chan/)

<comment><AUTHOR> Those are good points, some solutions that I've seen sites like BitChute use, or one that Twitter is contemplating, could be a combination of the following:

* Any illegal content would be removed

* Content that is more fringe, can be required to have a flag, where users must opt-in to see such content (bitchute's strategy)

* Non-logged in users by default don't see specific content. But this is made clear to the user, and content creator. Users logged in can elect what level of fringe they would like to see, or not see (sort of like twitter's banned words list concept)

The site would essentially aggregate links, and statistics of the platforms onto one page. So unlike 8chan, users aren't actually posting content, and I'm not hosting the creator's content. Maybe a MOTD from the creator, but I think that's manageable

I would like to hear what you think. It is a hard line to draw, my thinking is the site would be a sort of meta-site, aggregating the hosting platforms to one place, thereby removing the burden from creatorbytes. Domains will go through a manual process as to not be malicious/illegal, and once approved, are whitelisted.

Edit: All users will be able to see all creator pages, but previews for their content feed, or links with titles that are too fringe, etc, would have some sort of filter, and require log in.

<comment><USER3> I certainly appreciate your principled stance against censorship.

I do have to wonder who this site is for. Who's viewpoint is censored on major platforms, but is also not "malicious/illegal?" What can a content creator host on "creatorbytes" that would otherwise be censored by major platforms?

It seems like a lot of platforms have tried to capitalize on providing a space for users banned from major platforms (Voat, 4chan, 8chan, etc.) and they all seem to face similar issues, and don't seem to foster any meaningful discussion that couldn't otherwise exist elsewhere.

<comment><AUTHOR> I'm going for less the egregiously banned crowd, more of the soft-banned crowd. So creators who are de ranked, shadow banned, or what not, but aren't removed completely from the platform. That isn't to say all content not on the platforms are too egregious for the market creatorbytes is going for, but there are cases where after abuse of YT's copyright strike system, the creators are off the platform for no fault of their own. Rather the abuse was from competing creators. Yet they're too small to make a fuss, and largely go unheard.

Typically I've seen this with conservative views. Though I understand I'll inherently be attracting more extreme ones as well.

Again I'd try not to foster discussion on the platform, but aggregate links to other platforms for their discussions to take place, hopefully removing the liability, at least partially.

<comment><USER3> >I'm going for less the egregiously banned crowd, more of the soft-banned crowd. So creators who are de ranked, shadow banned, or what not, but aren't removed completely from the platform.

I'll admit this is an area that I don't know much about. Are there any creators you'd currently recommend who have been soft-banned from larger platforms?

And while I can certainly agree that YT's copyright system needs fixing, that seems like an issue that can't be fixed here, other than linking to another site who will have a different mechanism to prevent copyright infringement.

Is this meant to be like a curated list of content that one might not have seen otherwise?</comment></comment></comment></comment></comment>


Performance First - <AUTHOR> https://tonsky.me/blog/performance-first/ <comment><USER2> I think that's a really bad article. It's (as always) not that simple.

He says "if you want to build a really fast program, pay attention to the performance from the start.". So it's a business requirement from the start (to build a really fast program). That's fine and should be taken into account for development. Put it in your definition of done, start with performance and regression tests or something like that to pay attention to this particular business requirement. Have checks for your performance requirements and handle them as any other requirement for your software.

But most projects simply don't have that requirement and that's fine. Sure, your project will fail if it's unusable and slow but it will also fail if you put your efforts into unneeded optimizations from the start and slow down development of other features. I've seen projects fail due to premature optimizations in the beginning.

<comment><USER3> This is a very good point. In many projects, performance is not just relevant. Of course it makes sense to follow good practices and not make things slow on purpose, but thinking a lot about performance when it is not exactly a goal doesnt make sense.

On startups, I think there is a fine balance. You have to focus on many things, performance might be critical or might not depending on the business case. You have to think about where to spend your focus.

<comment><USER4> I disagree. Performance is almost always an implicit goal. People don't state it very often because it's so obvious. Why wants slow software?

But more importantly this article is a rebuttal to people saying "we can optimise performance at the end". They aren't saying "We never intended for it to be fast and we aren't going to bother trying to do that." they're saying that performance _is_ a goal. Look at the examples he screenshotted. Nobody says "dude, performance isn't a goal of this project; you just have to live with it being slow".

<comment><USER5> Good enough performance is the goal. If the latency is 100-200ms, then it is often not a big problem if your request cycle is 30ms instead of 3ms. Unless you expect heaps of traffic, then the 10x performance improvement means a lot.

<comment><USER6> Lets be realistic, no "apps", front end websites etc are hitting sub-second latencies for anything. Hacker News, and the linked article are stark exceptions where the page load itself was under 200ms for me. Posting this comment of course took about 3 seconds. The amount of latency in the modern web is fairly astounding if we're being honest.

<comment><USER5> > Lets be realistic

Ok.

> no "apps"

Sure?

> Hacker News, and the linked article are stark exceptions where the page load > itself was under 200ms for me

So let's be realistic (sorry :) ), it is possible, but it needs to be a strong requirement up front as its going to dictate a lot of choices that are hard to re-evaluate down the road.

> The amount of latency in the modern web is fairly astounding if we're being > honest.

We can totally high-five on that one. One thing I feel contributes here is that good devs are expensive. So we prefer them to use tools that help m to deliver quickly. Super low latency stuff usually incurs build times, this is not making your devs more efficient. Also less good devs find it often harder to produce optimized code "by default".

<comment><USER6> I can't work out if you're attempting to be a dramatization of the problem or not. Low latency developing "incurring build times" in particular doesn't make a lot of sense. It just takes considered design, nothing about the result is necessarily expensive.

<comment><USER5> I've programmed web stuff in rust and in rails. i can tell you that build times (and REPL on error, and a console with DB connectivity, and lots of pre- existing modules/libs/plugins) do matter.

We can get all that stuff in Rust (C/C++/Zig) too, but it is simply not there yet.

Only Go is both run time efficient AND compile time efficient.

My point: all is possible at unlimited resources, but that's unrealistic.

<comment><USER7> Go is a delight to work with, _if_ you solve new problems in your own way. Not so much unfortunately solving same old problems again, ie. SOAP/XML and similar.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I work on systems where speed is a requirement, and this think-about-speed- from-the-beginning is the way to proper way to do this.

I've also been parachuted into projects that are having performance problems, and usually you can find some nice low hanging fruit. But there's usually some crucial poor-performing part that can't be made faster without a complete rewrite that uses a entirely different algorithm and data-structure. And then it becomes clear that doing so would impact all the other code; basically, its unfixable because of early design choices.

Most of the slowest programs I've had to crawl into have been 'designed for web scale' nonsense from the beginning, and die a horrid performance death through premature distribution and the use of 'scalable' nosql technologies that were much talked about when the project adopted them but now are rather out of fashion, thankfully. My experience is that ipc is bad for performance and having a system on as few boxes as possible is good for performance, which seems to be quite the opposite to the system architectures that were all the 'web scale' rage this past decade.

<comment><USER9> And speed is always a requirement. There are tons of studies you can look up about the impact of page load time on e-commerce revenue.

<comment><USER8> TBH the specific examples I had in mind when I was writing my post were mostly backend systems, including batch ones. A lot of the performance improvements I extract from software is by dividing up what needs to be fast and what can be slow, and slowing down the slow stuff to free up resources for the fast stuff etc. I just chuck this in because I think its interesting how many perspectives and directions people on HN have.

</comment></comment></comment><comment><USER10> > Programmers waste enormous amounts of time thinking about, or worrying > about, the speed of noncritical parts of their programs, and these attempts > at efficiency actually have a strong negative impact when debugging and > maintenance are considered. We should forget about small efficiencies, say > about 97% of the time: premature optimization is the root of all evil. Yet > we should not pass up our opportunities in that critical 3%.

Knuth, "Structured Programming with Goto Statements". Computing Surveys 6:4 (December 1974), pp. 261–301, §1. doi:10.1145/356635.356640

No one has said to ignore optimization, what the quote is actually telling us is to avoid falling into the trap of micro-optimizations which don't really affect the overall performance of the system. Yes, you can spend a week making the world's fastest substring-in-string function, but if you're only checking that your email address has an @ in it, that's kinda silly.

Make your programs fast by concentrating on the areas which give you the most bang for the buck and avoid falling into rat holes where you optimize something which has no impact on the system overall.

<comment><USER11> > No one has said to ignore optimization

Well, maybe nobody is _saying_ that (Knuth definitely wasn't) but, as the author points out, this is how a lot of applications of the "premature optimization is the root of all evil" rule end up: any discussion of optimization if forbidden as premature until it's too late to fix the problems and then it's "good enough" because we "have to get to market".

<comment><USER7> If that's a problem, don't "discuss" it. Just Do!

</comment></comment></comment><comment><USER12> _> VS Code / Atom eventually became faster versions of their original Electron prototypes. And I'm not saying it's impossible to speed up programs after release. I'm saying these improvements are accidental. It's sheer luck they happened._

This is... completely wrong? Those projects have invested considerable work into making them fast.

He _does_ have a point though: there is a path-dependence when developing software, and some of the fundamental choices have an influence on the performance, and they cannot be easily reversed later, when it is time to _make things fast_. Things like:

\- language (JS vs Rust)

\- framework (Electron vs Native)

\- architecture

</comment><comment><USER13> In my opinion, the truth is somewhere between what the author is suggesting and what most developers actually do. I recently came across The Fallacy of Premature Optimization on ACM [1], which I think is a much better take on this topic. It clarifies the statement that started this confusion which, in whole, was "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" [2].

The key words being "small efficiencies", but you seldom hear that part of the quote.

[1] [https://ubiquity.acm.org/article.cfm?id=1513451](https://ubiquity.acm.org/article.cfm?id=1513451) [2] Sir Charles Antony Richard Hoare

</comment><comment><USER14> Uh, sort of. That quote can be abused of course, but it is still correct.

Actually, this article abuses it -- it's confusing performance and optimizations.

If you want performance, you design for it. When you optimize you profile and modify an existing system to improve something (usually speed, but could be other things like memory or requests, or whatever else might be constrained).

I think the article makes a decent point about performance, but just shouldn't confuse it with optimizations.

The right time to address the performance potential of your app or system is at design time. That's when you're going to be able to reduce the overall amount of work your system needs to do its job, and design for contingencies in case this or that box or line turns into a bottleneck.

Now, it is best to do high-level design of your essential components early -- you'll not only be able ensure your system has the performance potential it needs, but other things as well, e.g., to minimize the the overall amount of code you need to write, to make your system more maintainable, etc. So I agree with the general point of the article -- "performance first" but it shouldn't really get mired in confusion over optimizations.

Rather than "performance first" I'd say "do high-level design early, and don't forget to design for your performance goals".

</comment><comment><USER15> Similarly, as Jeff Atwood put it: "performance is a feature"

[https://blog.codinghorror.com/performance-is-a- feature/](https://blog.codinghorror.com/performance-is-a-feature/)

<comment><USER16> Performance takes time and intention. It needs to be planned for _like it's a feature_ or it won't get worked on. Usually this means working with business analysts to communicate to your customer that performance needs to be thought of like a feature -- AKA given its own time and effort and space.

<comment><USER5> Often perf reqs dictate the systems/languages/FWs that may be considered. Thus these reqs are very important to be known up front.

You can add many features later, but some level of perf is hard once you have 50k line of app code on top of, for instance, Rails. This because it's hard to change language/FW, compared to adding a new functionality on top.

</comment></comment></comment><comment><USER17> So the story should better have been: Develop a sane architecture which is fast by design but do low-level performance optimizations at the end

<comment><USER18> Electron out?

But a fast product that doesn't ship will also die.

</comment></comment><comment><USER19> performance first? accessibility first? mobile first? security first? correctness first? ...

There can only one thing come first, that's the definition of the word "first". You know what I do? "refactorizable first". Keep your code in a state that refactoring things is relatively safe and then you can work on the problems when they appear.

<comment><USER20> Look how fast this program is:

        int main () {}

</comment></comment><comment><USER21> I think there are bits of false dichotomy in here. Writing optimised code from the get go and _thinking_ about it at a later stage are not your only two options.

You can always think about performance implications of your implementation and keep them in mind. This is typically the runtime, your infrastructure, your chosen level of abstraction etc. You know your implementation is not the fastest, but you know what your limits are and where the low hanging fruit is.

To make it more specific - I implemented some economic model thingy and all I wanted was for it to compile and run correctly, so I wrote it in a way that I could swap the data storage for concurrency-safe structures without impacting the results - but since that added tons of complexity, I just designed it with a pluggable storage in mind. Then I developed it as a single-threaded program and wrote tons of tests. Once that and the external API were done and validated, I plugged in the concurrent storage layer and enjoyed great speedups.

So no, my first prototype was not performant at all and I was okay with that.

</comment><comment><USER22> I think of performance in a different way: "don't do stupid things" is my mantra. In other words, while not focusing on performance right away, I avoid doing stupid things. This lets me produce software which runs surprisingly well, spending very little time on improving performance.

</comment><comment><USER23> All the performance in the world doesn't matter if your software doesn't work, doesn't do useful things or isn't complete.

Plenty of good, useful software that is well used is kind of slow. I don't know anyone using anything that's very fast but incorrect or unfinished software.

<comment><USER11> > is well used is kind of slow

And users hate that the software is slow, and wonder why it has to be that way, but grit their teeth and deal with it because they feel like they don't have an option. And, until software professionals start behaving like actual professionals, they won't.

<comment><USER24> Clearly from your comment the software is so useful that despite hating it, the users deal with the slowness. Which to me only reinforces they parent's point: correctness and availability is more important than speed. If speed were the _most important_ thing then they wouldn't just hate it, they wouldn't use it.

</comment></comment></comment><comment><USER25> This article makes a strange assumption. That you know perfectly the end result before starting the process, which is a rare case in my experience.

Normally, a product will start with a small feature, and all sorts of random stuff will be added to it to make it grow. Some of them will be abandoned, as they'll fail commercially, and some will expand as they bring money or attention. Creating an architecture that can allow that kind of expansion without crumbling over tech debt is the challenge.

Ultimately, some programs can be reduced to a simple operation, and that can be designed from the ground up to be really performant. Something like the silver searcher ([https://github.com/ggreer/the_silver_searcher](https://github.com/ggreer/the_silver_searcher)) or ripgrep ([https://github.com/BurntSushi/ripgrep](https://github.com/BurntSushi/ripgrep)) have the advantage that they have laser-focus in what they want, and designed to take advantage of that. Most of the developed software have way broader objectives.

The important part of "premature optimisation is the root of all evil" is PREMATURE. Don't optimise things that is still uncertain that required to be optimised. When performance is critical OF COURSE optimisation is a requirement.

<comment><USER26> > The important part of "premature optimisation is the root of all evil" is > PREMATURE.

Right -- I think the examples he's arguing against have slightly misunderstood what "premature" means. The quote is supposed to mean, "Don't optimize until you know that optimization is necessary." The people in his examples are interpreting it as, "Don't optimize until your program is feature complete". I doubt Knuth would agree with that principle. If people are raising tickets saying that some feature is slow, then you know optimization is necessary, and it's not premature any more.

That said, as with any proverb, you have to use some common sense. If you know you're going to be doing key-value lookups in a data structure that's going to contain hundreds of thousands of pairs, it's OK to start off with a hash table, rather than starting with flat list + linear search and switching over only after benchmarking.

</comment></comment><comment><USER27> There might be some confusion of terminology at work here. I tend to agree with the article that you have to think about performance while designing your program, but that is not a contradiction to what Knuth is saying.

Knuth talks about optimization, which is a trade-off to make your existing code faster by sacrificing readability.

This guy talks about proper design, which is a trade-off between time to market and quality.

You can (and should!) have both. Think about what you do before you do it, and then optimize the parts that need more work.

BTW: I think there might also be a misunderstanding about why optimization can be bad. djb used to say "profile, don't speculate". I think this is the core of the Knuth recommendation as well.

If you optimize before you have written all the code, chances are you don't even fully understand the problem the code is trying to solve yet, so you might have to rewrite parts of it, and then it would suck if you had sunk a few months into optimizing those parts.

Also, only after you have all the code and you have test cases do you have an opportunity to profile and find out which parts of your code are contributing the most to its lack of performance. The fundamental insight here is called Amdahl's Law. Or maybe you find out that your code is already fast enough.

I usually spend a ton of time beforehand thinking about how to write code that will not need much optimization later, but sometimes you find out your initial assumptions were wrong.

<comment><USER11> > make your existing code faster by sacrificing readability.

I've seen slow code, and I've seen fast code, and I can't say that I've ever noticed any significant difference in "readability". If anything, the faster design choices are easier to read because they make more sense: I can understand why the original author did what he did.

</comment></comment><comment><USER28> Performance is largely architectural for most types of software. The extreme difficulty of redesigning architecture after the software is feature complete (it approximates a rewrite) makes it a requirement that any performance and efficiency considerations be designed into the system from day one. Optimizations you can add later are always severely constrained by the kinds of optimizations the architecture allows. In most software I see, the "performance later" designs tacitly remove most possibility of macro- optimization.

Not all software needs to care about performance, but I also see a lot of large multi-server monstrosities that could easily be run simply and cleanly on a single server with capacity to spare if more thought had been put into performance and efficiency.

</comment><comment><USER29> It seems many comments in this thread don't get the point.

The "Premature Optimization is Root of all Evil" is about juvenile low level optimizations that sacrifice code readability. They don't give high perf gains either.

But that doesn't mean "Don't think at all about performance in beginning, you can optimize later". That's bullshit notion. Someone will end up paying in AWS bills for that. For instance, every programmer should know how latency varies between disk and memory access, and think about the tradeoffs at design/spec level.

It is true that there are cases where even that doesn't matter. But in most cases where people think so, It ends up they pay double in AWS bills to save two hours of thinking.

<comment><USER30> No, many DO get the point.

Point is that decision-making isn't binary. If I have a form and UI that collects the data, of course I won't try to use enums and weak maps or "the fastest client side framework" to succeed in the actual task: collect and save data.

Before business logic is known, you can't design for performance. That's why "Premature optimization is the root of all evil exists". Now, if you design for performance - that means you KNOW something ahead, and there's less discovery involved.

I'm not sure why people have the desire to create lists or rules for tasks whose workloads are unknown.

We all want to get beautiful code paired with performance and features. But before we know what we have to achieve, it's hard and dangerous to focus on performance only.

I never adhered to hard rules or thoughts from people that think binary-only. Every situation requires analysis before action can be taken. Therefore, the right tool for the job is my mantra and this "article" is extremely dangerous since it's tunnel-visioned.

</comment></comment><comment><USER28> As a tangent to this, the widespread lack of performance/efficiency-first thinking in software design is responsible for an enormous amount of waste that directly contributes to things like climate change. We've normalized using 10x more servers than is required to deliver a workload with performance-conscious architecture because it is expedient. The "throw hardware at the problem" mentality has gotten out of hand in my opinion.

Many people with very eco-aware personal lifestyles write code that is the software equivalent of a coal-fired SUV, oblivious to the contradiction.

</comment><comment><USER31> What is lost in this kind of conversations, can be summed at:

You pay NOW or pay LATER.

Some stuff is VERY hard to add later, and will cost much more:

\- Security \- Usability \- Cross platform \- Accessibility \- Type safety/Type hinting \- Performance

If you delay too much in pay attention to this stuff, then the cost later will increase so much. And then only a massive refactoring will fix it (or worse, like in one of my projects, a total change of langs and frameworks!)

</comment><comment><USER32> I picked up a codebase where people were optimising for performance throughout the development it's now very hard to change or refactor because there are preemptive performance optimisations and caching everywhere (front and backend).

It makes far more sense to create an extensible solution and then identify and fix the bottlenecks as the vision about the "final product" (or version x) becomes more clear.

</comment><comment><USER33> If you've used some heavyweight framework then performance will probably be hard to add later. If you wrote the code yourself then I'm with Knuth, it's not a big deal to optimize it later and that's a much better way to go.

I've found the following rubric helpful for building distributed systems: 1/ correctness, 2/ reliability, 3/ performance. Credit: CochroachDB team.

</comment><comment><USER34> > If someone says:

>> "We are building programs correct first, performant later. We will optimize it after it's feature complete."

> It actually means: performance would stay mostly the same, unless those > people find some low-hanging fruits that will allow them to make the program > fast without changing too much of what they've already built.

I agree with the premise, but not (always) with the overall conclusion of the article. If you go preformance-first, you should also go security-first, usability-first, and accessibility-first. All of those factors are harder to implement afterwards than when it's being done from the beginning. But there's also the other side - you may come up with a performant, secure, usable and accessible application that is lacking core features, making the product useless. There's no silver bullet, but _not_ going performance-first is totally fine in some cases (especially prototypes / MVPs).

</comment><comment><USER35> > I'm saying these improvements are accidental. It's sheer luck they happened.

No. They're not accidental. They're entirely intentional, done by _sheer_ hard work.

On a related note, I am surprised a person who claims to write about UI design has a website with that background color. The contrast is just awful.

</comment><comment><USER36> This is better expressed as "consider performance from the start". Don't make it your #1 priority and don't ignore and neglect it either. Do sensible things:

1\. use hash (or ordered) collections rather than scanning large-ish arrays

2\. use reasonable database schemas and indices for queries

3\. similarly consider correctness (e.g. constraints)

4\. one place where earlier versions can skimp are sometimes algorithms to be replaced by better ones. Think of this as 'doing things that don't scale' which is fine for an MVP but do have a plan for how this will be updated if you're fortunate enough to need it.

5\. good fore-thought is to offload work to the client in the design which does scale better.

6\. don't do any/much caching early on and make choices that are compatible with adding caching later

</comment><comment><USER37> > Let me put it this way: "Premature optimization being the root of all evil" > is the root of all evil.

The disconnect for most people is that optimization does not necessarily mean "performance". It can mean optimizing for reusability, compatibility, objected-orientedness. Basically trying to optimize for a use case that you don't have yet. I see this happen all the time with people optimizing to make their solution more general. It makes the code more complex and it may never be used in a general case.

If you are trying to build a performance piece of software, then you should absolutely be optimizing for that from the start. That's not premature optimization, that's meeting your design goals.

</comment><comment><USER38> The author here seems to be missing the basic point of the phrase. Others have correctly noted that performance is a feature, but even with that taken for granted, it is not often apparent what the constraints of the full system are until they've been built. You may try and guess, but you're more likely to guess wrong than right. Look at OSes, ISAs, DBs, etc. All of those have been rewritten numerous times not because the originals paid no attention to what performance would be like, but rather because they did not know how to improve performance until they had something they could test.

</comment><comment><USER39> Eh, there's a gray area here. Your priorities really depend on the type of project you're making.

Let's say you're building a web app for a SaaS business. Wouldn't it be more important to make your code refactorable and develop features quickly? If you spend lots of time on [Feature X]'s performance and customers turn out to _not use_ [Feature X], you've just wasted your time and money — basically your runway, your livelihood. Basically, if a feature isn't worth making, is it worth making well? :)

Maybe this is good advice if you're working on a different type of project though.

</comment><comment><USER40> I think it depends on if your design is conducive to performance or not and this is the cross-purpose here.

If you've architected a bunch of end points that are chatty and jump layers in a weave of a tangled mess or built an app infrastructure that never isolates expensive operations and just arbitrarily inlines them, then you'll struggle to optimise it later.

But if your architecture is relatively sane and your data model apt for the features at hand and those on the horizon then finding hotspots and improving performance many times fold is totally doable later.

</comment><comment><USER41> High performance code can often be an order of magnitude longer and more complex to write than moderately performant code. When you're not even sure what you're building yet, aiming for performance first is a waste of time and a good way to ensure you end up not realising anything at all.

Optimise for what's important for your specific project. Maybe exploring the design space is the priority to start. Maybe releasing before the end of the year is more important.

Not all projects are the same so it's pointless to argue about general rules like this.

</comment><comment><USER42> Improving performance after the fact is a lot harder than you might think, depending on the nature of your application and it's users behavior, it can be a very steep uphill struggle to realise even small gains. Here's an issue I recently ran into.

When I was tasked to increase performance of a legacy web app, I thought there were so many "quick wins" that I could take a VERY slow application (we're talking 10s long requests for most pages) and get most pages down to less than 3s per request, and at MOST 5s for all of them

One example was permissions being stored in a long "bitmap" string of 1's and 0's that was being parsed on each page load (it was hundreds of "bits" long). The code to handle this was beyond awful complexity wise and added 2s per page load to parse. Some simple refactors and 2s removed from each and every page load. There were a bunch of things like this too, I was on a roll fixing these things.

In my dev environment I set up some performance test harnesses (replaying real world traffic from a representative amount of users) and got benchmarks indicating that i'd increased performance by about 4 times on average. It was still sluggish, but no longer unusable. When I deployed, I found the site was only 1.5 to 2 times as fast. Not quite enough to hit my very modest goal of <5s per request. What the hell happened?

Turns out the site was so slow, but we had so many active users that needed to use it, we were suffering something you'd normally only observe in real life automobile traffic, a phenomenon called "induced demand". When a site is really slow users won't use it unless they absolutely have to. So as you make the site faster they will subconsciously start doing more things things beyond the absolute bare minimum they would normally do. You get stuck fighting some weird kind of "equilibrium" where as the site gets faster you start going below the level of "do what I need and get out" threshold of more and more users who push back by adding more traffic until the site reaches a new equilibrium.

So we made the site 4 times as fast, but the amount of requests more than tripled and negated half our gains. Improving performance on a web app of this nature after the fact is a LOT harder than you might think.

</comment><comment><USER43> Of course you should consider performance when you start a project - if your language, framework or core design is slow it seems unlikely you'll be able to do much to improve it later. You need to at least think about it.

But I don't think "Premature optimization" is synonymous with "performance". Optimizing or perfecting every detail of a feature that might still go through significant changes over time seems risky and wasteful.

</comment><comment><USER44> Slippery slope here is, how far does one take performance first design?

I've seen too many devs rely on caching as the upfront solution. That's performance first design, right!?

</comment><comment><USER45> I'm not sure if performance has to be first. One could for example do proof of concept style of work with some higher level language before starting to create the actual product which then should also take the performance aspects under consideration.

I think we actually waste a lot of energy by not encouraging our selves to pay attention on the performance. Nature sort of demands efficiency in long run. Yes?

</comment><comment><USER46> Avoid "premature optimization" doesn't mean avoid "optimization".

What is "premature" is project dependent.

It is not premature to start 99% focused on optimization for a project where achieving an efficiency threshold is needed to validate project viability.

"Avoid premature anything" is tautological.

"Performance first" violates a tautology. All I need to say about that.

We need tautological reminders, because we humans easily forget obviousness in the face of complexity.

</comment><comment><USER47> Meh, look at Slack. It's a matter of priority. For me extensibility, important features and quick bug-fixing is more important than performance. If working on performance gets in the way of any those things, do it later.

</comment><comment><USER48> I hope he doesn't build software like that website

<comment><USER49> What do you dislike about it?

<comment><USER35> I believe OP is referring to the terrible readability and color contrast, with that background color.

<comment><USER50> Terrible contrast? Firefox's accessibility inspector gives the text a contrast ratio of 15.17, with 4.5 being the minimum for what qualifies as good and 7 as the recommended minimum for good readability.

I change text colours in the web inspector a lot because plenty of websites these days are medium gray on light gray with a font-weight of 100, but this clearly isn't one of them. It's fine to say you don't like the colour, but the contrast is great.

<comment><USER35> It's not that the contrast is low (which is another problem on its own, I agree). It's the other extreme - too high of a contrast [1] by using a fully saturated yellow and black. The same reason you don't use #fff on #000.

[1] [https://uxmovement.com/content/why-you-should-never-use- pure...](https://uxmovement.com/content/why-you-should-never-use-pure-black- for-text-or-backgrounds/)

</comment></comment></comment></comment></comment><comment><USER51> As I see it, performance only matters if you're losing more customers or users over it than you gain by having spent that effort on features. And hardware is cheap nowadays. This is also not a linear relationship, performance focused development generally constrains the system which makes refactoring harder which makes new features harder (because you almost certainly did not get the architecture right the first time around).

<comment><USER52> >And hardware is cheap nowadays.

Cheap and available (and correctly setup) are not synonyms, however.

In the years I observed how - generally speaking - programmers (correctly as it is their work) tend to have the best of the best in hardware (and a fast LAN, and a fast WAN, etc.) so locally where the program is developed it feels fast, responsive, etc.

But the user base may have older processors, less RAM, slower mass storage and slower WAN/Internet access, so at their end the same program will appear slow, in some cases so slow to make it unusable.

I always thought that at the developers there should exist a few reasonably old machines possibly with installed the same services/other tools that the client target machines normally have where the program should be tested for excessive increased slowness compared to what happens on the development machines.

<comment><USER18> Thankfully, Travis, Azure Pipelines and Appveyor are slow as molasses and if you are forced to wait for them before merging a commit you will optimize the speed so that at least CI is reasonably fast.

</comment></comment></comment><comment><USER53> The Knuth quote stands. It has been and continues to be one of my favorites. It has served me well.

</comment><comment><USER54> the prototype should be crazy fast. as soon as features are added, it's gonna be slowing down.

</comment><comment><USER55> I think this is terrible advice. There's plenty of ways to write highly performant, wrong sofware, that contains bugs. What's worse than a slow program? One that doesn't run. 1/10 of the time. Whats worse than a program that runs 1/10 of the time? One that runs with high uptime and resiliency, but handles funds with the wrong sign.

<comment><USER56> Is it really terrible advice for anyone to actually think about performance when programming.

<comment><USER57> No, but you usually don't know what will be the poorly performing part or in need of optimization, beyond the macro level. Don't check your brain at the door, but don't overthink it too early.

Someone else cites old systems with core decisions that are unchangeable because a data structure or algorithm is central to the entire codebase, as an example of "should have thought of performance earlier". My reaction to that was: why is the code structured in such a way that a particular data structure or algorithm is central to the entire edifice.

I think the error the article makes is in describing later performance improvements as "accidental" and low hanging fruit, which is nonsense. If your code can't handle continual refactoring, including to realize significant performance gains, then you have a deeper problem than performance.

</comment></comment></comment><comment><USER58> Using performance as a synonym for only runtime speed doesn't feel satisfying. Shouldn't we include quality of results, such as correctness and fulfillment of requirements, in the evaluation of whether a program performs well?

<comment><USER59> _Performance_ has a variety of contextual meanings. Market performance would be an example. When talking about execution performance, we're usually talking about speed/smoothness, under the assumption that a program is already correct and complete. If we overload this to include basic correctness, we would need another term to capture these other qualities.

<comment><USER58> But we are using other, more precise terms already, no? Speed, fast, slow.

</comment></comment></comment><comment> jerome-jh Javascript has been made fast as a result of huge efforts.

</comment><comment><USER60> The colours of this page are an unfortunate choice tbh...

</comment><comment><USER61> If the author had said, "Performance & functionality over beauty" it would have made more sense.

</comment><comment><USER62> While I agree with the overall feelings that the author expresses -- that people misunderstand "Premature Optimization is the root of all evil"[0] and in doing so treat _optimization_ as something that is "evil" rather than _premature optimization_. There are various misunderstandings, which lead to incorrect assumptions which lead to introducing complexity (which is likely to be counterproductive, potentially performance- _killing_ ) too early in the development process. I consider the following quote to be key:

         > It's never too early to start measuring and working on performance.

Personally speaking, when I start feeling this way, I see it as a _strong signal_ that I'm engaging in optimization too early. I'm guided by the idea that time spent attempting to improve performance at early stages is more often wasted, or even self-defeating, than it is useful. Knowing exactly _when_ is the right time, though, is extremely tricky.

Most languages/frameworks have a set of "don't do this"-es that fall into the performance category -- knowing these and implementing them when the probability that they will reduce a bottleneck vs. overly-complicate code/implementation is important. Too often, though, the "performant implementation" is used because other developers are familiar with it -- not because it necessarily helps anything (i.e. using StringBuilder in C# for string concatenation -- in many common implementations, the result is _slower_ but people are so used to seeing it that it becomes "something many developers just do" even though it is substantially uglier).

Performance shouldn't be an _after-thought_. If I'm expecting that my application _must_ support 10,000 concurrent users on a single host and the work its performing couldn't be achieved by a single-threaded server, I'm going to write the implementation thread-safe from the start. That's not premature optimization, that's designing an application. Provided the hosting constraints are not as rigid, it may make more sense to single-thread the back-end on multiple hosts. Neither of these are as easy to reason about as a single-threaded, single-host, blocking implementation, but the alternative is "it doesn't work at all" (under load, anyway).

The problem with measuring/working on performance too early is that the measurements are measurements of code in isolation. You can't measure what isn't written and once the various dependencies are introduced, your initial measurements/adjustments for performance may be pointless. Yes, you sped up the acquisition of a small blob of JSON that takes a notoriously long amount of time to produce, but because you hadn't completed the rest of the app, you neglected the fact that another request with 250MB of JSON ran at exactly the same time. You traded off memory for CPU to speed up the first implementation, but now you need a lot more memory for the one running in parallel and the lack of resources caused swapping, slowing _everything down_ to the point that the original, slower, less-memory-consuming option for your first request was a better choice.

The "Premature Optimization is the Root of All Evil" isn't a phrase meant to say "Optimization is unimportant and you shouldn't waste time on it". It's a recognition that optimization is _extremely important_ and will almost certainly _never happen_ due to resource exhaustion. The confusion is about what resource is being exhausted -- the resource is _time_. We're all constrained by having to write functionality and make it work. If you want to make it perform well, you're going to burn a lot of time on optimization. You will burn _far less time_ there if you optimize your code when those optimizations are going to have the greatest benefit. Optimizing _too soon_ means you risk spending a lot of time measuring/tweaking with a result that will not improve performance, or worse, has to be undone. "Optimized" code is usually more complex/more difficult to reason about, which makes completing the underlying feature-set more difficult.

Measuring and optimizing _at the right times_ (and identifying the correct "right times") maximizes the positive effects of the optimizations and reduce the likelihood that those optimizations will make writing the rest of the code more difficult. Every program (and kind of program[1]) has a different "right time". Determining that "right time" can simply be a matter of planning your hardware / code architecture early enough to know what is actually _needed_ [2] and identifying when one should start reviewing the application for bottlenecks.

[0] I have much the same problem that I have with the biblical roots of that phrase and its misunderstanding. People will often repeat "Money is the root of all evil" but miss the first part of that phrase "... _the love of_ money is the root of all evil." With appropriate context, its meaning changes dramatically.

[1] Library code vs. a complete program -- My "general libraries" are often micro-optimized to seek the greatest performance while maintaining a balance between memory usage and CPU. This makes them maximally useful to the vast majority of my consumers. I might end up ripping those out of an implementation if I find a better trade-off given a complete program's function, but most of the time it reduces the need for me to optimize around common bottlenecks

[2] Regular check-points / proper planning are as close to a cure for "the roots of all evil" as you can get. Performance is _always a feature_ in that you know in advance what your applications constraints are and what its requirements are. Designing code that meets neither isn't abiding by the "Premature Optimization" advice; the point is avoiding writing complex implementations that eek out a few extra milliseconds of performance for a code path that is blocked by dependent-data, anyway, which is often the end result of premature optimization.

</comment><comment><USER63> I think author also optimized the time it takes for users to click `ctrl+w` from his side. That yellow background is terrible, it gave me a headache.</comment>


Sex workers have created the perfect method for keeping people honest online - <AUTHOR> http://qz.com/621994/trust-and-crime/ <comment><USER2> The "perfect method for keeping people honest online" is to require that you verify your identity. The opening paragraph of this article mentions a mandatory driver's license scan and a call to you through the switchboard at your work.

</comment><comment> xkcd-sucks When people like this ask for license/passport scans, how likely is it that they actually look it up in a database?

My experience suggests that a large portion don't actually verify the license, but i don't know if it's cheapness/laziness or actual difficulty.

<comment><USER2> I would certainly hope a madam doesn't make a query to some sort of license database. That seems like a remarkable operational risk.

Frankly, this whole thing seems like a perfect recipe for blackmail. "Just give me an incontrovertible and non-repudiatable proof of who you are and I'll get right on providing you with an illegal and potentially embarassing service."

<comment><USER3> Worse yet, 1/4 people then pass on service all-together.

How can that be considered perfect?

</comment></comment></comment><comment><USER4> Never thought I would see a submarine article for p411.com.</comment>