App-pocalypse Now - <AUTHOR> http://www.codinghorror.com/blog/2014/02/app-pocalypse-now.html <comment><USER3> On the reason why people will spend $5 on a coffee but not $1 on an app:

I've been thinking about this for a while and noticed this behaviour amongst my friends. I have one friend who is a true apple fan-boy and finishes his phone contract early so he can get the latest iPhone earlier at much cost etc.

I recently finished an app and said - hey, do you mind downloading it for me and checking it out? He says, "but it costs £1?!" I said, "ok, no worries, I'll GIVE you the £1 right now"

He still said "No". Why? Because "he never spends money on apps." Weird, right?

Then last night I'm watching Horizon - "How we make decisions" [1], and they talked about how when we feel we are ahead we are much more cautious than when we feel we are behind, when we experience "loss aversion" and are more likely to take a gamble.

I wonder if this is the best way to monetize apps. So you offer the app for free (no risk at all), then instead of offering "add-ons", you offer to remove "restrictions", implying that the user is already behind and they should take the gamble to get back to their "free" app.

[1] [http://www.telegraph.co.uk/culture/tvandradio/tv-and- radio-r...](http://www.telegraph.co.uk/culture/tvandradio/tv-and-radio- reviews/10658646/Horizon-How-You-Really-Make-Decisions-review.html)

<comment><USER4> I'm currently surveying 600 of my early users of my android app.

What's disconcerting so far is their answer to the following question:

The app will be 100% free for you forever (thank you for the support) however what do you think is reasonable pricing? __Consider, that some of the revenue will be re-invested in making the app better for all users __

It 's early days now but it's trending towards $1/$2 when in reality I believe that it's worth allot more to anyone who gets a fair amount of value from it.

<comment><USER5> Once you get something for free it becomes hard to associate a monetary value to it.

</comment></comment></comment><comment> k-mcgrady >> "I already have 30 apps on my phone, some of them very good. Do I need another one? I don't use the 30 I have."

I hate seeing this argument. Why do you have those 30? Why don't you delete them? Having 30 apps on your phone doesn't mean you don't need more apps. They aren't all the same. It's not like saying 'I have 30 cans of diet coke in the fridge why do I need another?' It's more similar to 'I have sausage and diet coke in the fridge, why should I buy these vegetables'? Because they solve a different problem than the things you already have.

I think the reason people are reluctant to spend money on apps is the same reason they are reluctant to spend money on music or movies no matter who convenient it's made for them - people don't see value in digital goods as easily as they see it in physical goods.

<comment><USER6> >> I think the reason people are reluctant to spend money on apps is the same reason they are reluctant to spend money on music or movies no matter who convenient it's made for them - people don't see value in digital goods as easily as they see it in physical goods.

I wholeheartedly disagree. By your logic, people wouldn't pay money for Windows, or Photoshop, or thousands of other software packages. Oh, and Steam! People pay $20 or more on Steam for some mediocre stuff.

The problem with paying for apps is two-fold: Frankly, 99% of apps out there aren't worthy of my money. Most of the few I actually pay for (Spotify and LastPass come to mind), I don't pay for for the app, it's for the service behind the app.

Second, app developers have done this to themselves, in two ways - first, putting out just really shitty, awful apps (especially games) that aren't worth money.

Also, in perpetuating a race to the bottom and setting the expectations way too low on price. I saw somewhere that Jobs thought the perfect price point for an app is $10 (I might be wrong on the source, but someone said it). I agree with this. If you really believe you have a great app, price that shit accordingly. If you have a great app and price it at $10, if you get a third of the downloads you'd get at $3, you're still ahead. And, your users will feel like part of an exclusive club, and invite their friends to be part of it.

Of course, this is my opinion, and no one ever listens to me.

<comment><USER7> There are a few things inherent in the design and policies of the app store that pushes prices to be low.

One is that there are no demos possible. You can't make an app that works for 30 days and then stops working. You can sort of do this by limiting the app and having it fully unlocked by in-app purchase. I really don't mind that model at all, because I just see it as a demo version.

Another limiting policy is that there is no upgrade pricing. The app is just the app.

<comment><USER8> This is actually possible on Windows Phone, and used extensively. It's the pretty version of having a lite/express/free and pro/full/complete app.

</comment></comment></comment></comment><comment><USER9> Oh, so we've come full circle.

Don't download random Windows apps from the internet, they're bad for your PC!

Hey, here's my nice shiny app store where the applications are curated. Only quality content, categorized, free of spyware and other distractions.

Oh no - market pressure has pushed the bar lower and lower and I once again have to rely on the Internet for reviews and comparisons of apps in order to install only the decent and trustworthy apps.

Kind of sounds like the Windows model all over again. But this time I have to go through your BS systems to publish an app on my own device. Yay progress!

<comment><USER10> And the answer which the Linux world came up with: we're going to offer you a repository with your distro from which you can obtain most or all of the applications you need.

In the case of one particular distro, Debian, this was backed by a Social Contract[1] and Constitution[2], expressed in Policy[3] which was ultimately enacted by A Package Tool (APT)[4] with user feedback and interaction supported through the Debian Bug Tracking System (BTS)[5].

Among the principles of the Social Contract: "Our priorities are our users and free software".

The result: a distro with a _tremendous_ number of packages available (49,614 on my jessie/sid install), in which the significant concerns are user experience (including privacy and security), and freedom of software. The last possibly best exemplified in LWN's coverage of a story ... wow, already a decade ago, on LWN: "Debian and the hot babe problem". It concerned an "ITP" (intent to package) a new piece of software. I'll let Jon Corbet take it from here:

 _The program involved is hot-babe, a graphical CPU utilization monitor. It works by displaying a typical Bruno Bellamy drawing of a minimally-clad, maximally-endowed woman. As the CPU gets busier ( "hotter"), the woman undresses to compensate. Your editor, whose journalistic ethics required that he investigate this utility, found it to be an amusing addition to the desktop - for about five minutes, or until the children walk in, whichever comes first._

 _The Debian developers raised the obvious, predictable objection to the inclusion of this utility: the associated images were covered by a non-free license._

Hot babes notwithstanding, one thing I noticed Debian _didn 't_ have problems with a decade ago were drive-by installs of spyware and adware which were plaguing Windows at the time. That, um, "ecosystem" has now moved into the mobile space, and the negative equity and goodwill associated will, I suspect, play out in time there as well.

<comment><USER11> And Debian got first release on August 16th, 1993; 20 years ago. It saved many from shareware/crapware app-colypse of 90s.

Am I the only on dreaming of Debian (an exactly Debian) developing an app repository (at least for Android), where free apps are carefully supported, building on top of each other where no tricks or crap exist.

<comment><USER12> Google could help kickstart that ecosystem by offering a promotion category for "Best Free/Open Source apps" in Play. Only apps with a GPL compatible license and fully buildable from a public repo are eligible.

<comment> shawn-furyan I'm not sure Google has the incentives in place to be interested in this, but it seems like a perfect fit for CyanogenMod as they try to grow as a platform.

<comment><USER12> The incentive is that Google will benefit form having an ecosystem of high quality apps. A good ecosystem lowers the bar to creating high quality apps - the non-app open source software ecosystem is pretty conclusive proof of that.

But you're right - CyanogenMod is probably a better forum for such an ecosystem to bootstrap.

<comment> shawn-furyan Hmmm, maybe I should have appealed to Google's strategy rather than their incentives. An APT/RPM style model strikes me as counter to the prevailing direction that Android, and Google more generally has been moving.

I think that from their perspective, mass market users don't care about license terms or free-ness as in freedom. They seem to care about free-ness as in sticker price, even when it comes with prohibitive in-app purchase requirements. If we look at mass market targeted app stores based on APT-like repository systems, well, all we really have is the Ubuntu Software Center. And that isn't clearly better than the Android Market to the mass market user, and I would go further to claim that the inverse is true. So I can't see strategically why Google would change direction toward an Ubuntu Software Center style direction, and the higher quality but less user friendly APT/RPM/pacman is just a complete non-starter.

But CyanogenMod seems to have reached its market position by appealing to the ethics of openness. So it makes sense given their prevailing strategies. They also have a history of providing relatively open/customizable alternatives to Android components, and an app repository in the tradition of APT/RPM would fit right in with their past initiatives.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> I saw the WebMD app nag and thought for more than a few moments that it was from codinghorror.com.

And was unmistakably annoyed.

Then I realized that was precisely the point. And yes, it's absofuckinglutely annoying.

Right up there with interstitials and flyovers on webpages. I'm thinking of writing a default Stylebot CSS to simply block any element class / ID starting with "fly".

The other problem, of course (and checking to see if Jeff addresses this -- yes, obliquely) is that _every app comes with its own permissions set(s) which I the user need to individually inspect and vet_. And, frankly, which I'm increasingly reluctant to do so.

Fastest way to get your app removed from my phone? Request additional permissions. Goodbye Pandora, whatever that "identify that song" app was, Facebook, Mr. Number (irony: nominally a privacy-enhancing app) and others.

<comment><USER13> _Fastest way to get your app removed from my phone? Request additional permissions._

Unfortunately there's little the developers can do about it, short of not adding any features. You have to ask for every permissions your app could potentially need to use, upfront. You can't ask at point of use. This is a huge Android flaw.

<comment><USER14> Another problem is that you need some permissions for even the most basic functionality.

Let us assume I'm making a singleplayer game that happens to take more space than 50MB. For that I need internet and external storage write permissions in addition to network and wifi state etc (see [http://developer.android.com/google/play/expansion- files.htm...](http://developer.android.com/google/play/expansion- files.html#Permissions))

And all this because the persons designing android thought that 50MB is enough for all applications and thus made their package manager to cap packages at 50MB. Imagine if .deb or .rpm would be 50MB max.

<comment><USER15> If you want to use 50mb of my phone's flash space then yeah, you'd better have a good reason for that.

<comment><USER13> Requesting 50M+ of storage for a single player game is a good enough reason, that's not outrageous for graphics resources, music etc. But would you understand that this _necessarily_ leads to the app having to request:

        <uses-permission android:name="com.android.vending.CHECK_LICENSE" />
        <uses-permission android:name="android.permission.INTERNET" />
        <uses-permission android:name="android.permission.WAKE_LOCK" />
        <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
        <uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/>
        <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

as well?

</comment></comment></comment></comment></comment><comment><USER16> Surprisingly, in Europe we had that _fade_ two years ago.

Every company wanted a Facebook page and a year later an iOS app. Amusingly the marketing departments and executives of many companies were out of touch with their audience/consumer as most had a Android phone or tablet. Two years ago many disco, bar, smaller shops, etc. had such native apps. The main point was they all were useless as they lacked a lot of features that there equivalent websites offered.

Fast forwards to 2014 (Europe), most such native apps vanished as well as many business related Facebook pages have decreased in popularity or "dried-out". Now, some companies offer hybrid apps for Android/iOS that is basically a WebView that shows a slightly modified version of their HTML5 website.

<comment><USER13> I wish I lived in your Europe.

In mine all those venues still have websites built on Flash.

</comment></comment><comment><USER17> Apps are the new CD-ROMs. The Web will win.

[http://www.hanselman.com/blog/AppsAreTooMuchLike1990sCDROMsA...](http://www.hanselman.com/blog/AppsAreTooMuchLike1990sCDROMsAndNotEnoughLikeTheWeb.aspx)

<comment><USER18> Except the web has always been a Frankenstein mess for development and still is.

As someone with long experience in both fields back to the 8 bit days, I welcome the native renaissance.

<comment><USER13> _has always been a Frankenstein mess_

 _cough_ Android _gargle_

Or for that matter, rewriting your app for every phone platform.

<comment><USER18> > Or for that matter, rewriting your app for every phone platform.

Cordova, Qt/C++, Xamarin Mono, Unity, Cocos-2D-X, Titanium, ....

There are lots of alternatives to minimize duplicate native code. Plus it is not as if one doesn't need to write once, debug everywhere with HTML 5.

<comment><USER13> And how much of the apps written with such frameworks will feel remotely like a native app? How much of the frameworks you mention even support a reasonable amount of target platforms?

I don't disagree HTML5 has porting problems between devices & browsers. I'm just saying that native apps have more.

<comment><USER19> I can't speak for all of them but I use Xamarin at work, and it absolutely does translate to native look and feel for the app. Although once you get to the GUI layer, it's not much more than a thin C# wrapper for the native OS framework and you have to write a lot of platform specific code. But everything else is cross-platform. And you're coding in C# and not Objective-C (or Java), which is a more predictable and less verbose experience, at least for me, and I've made half a dozen apps using Objective-C.

</comment></comment></comment></comment></comment></comment><comment><USER20> Permissions are a real problem of installed apps, but otherwise I wonder if web apps are that much better _if_ they are really applications and not documents/content.

The general functionality provided by web browsers (URLs, the back button, searching in a apge, etc) is very useful as a common basis for different content centric sites. But it just doesn't work very well for applications regardless of whether or not these applications are based on HTML/JavaScript or on some other GUI toolkit.

Yes the back button can be made to do _something_ in any app. But how can users have a reasonable expectation or intuition of what it's going to do? "Go back" used to mean "show me the page I saw before clicking the hyperlink". Bookmarking meant "remember the current page".

But applications don't have pages, they have states. Pages are concrete. States are abstract. That is the real problem, not the specific technology on which applications are based.

<comment><USER16> It's called one-page app. You can control the browser tab history with HTML5/JS5 and create WebApps that offer all the same functionally you see in most native apps.

<comment><USER20> I think you misunderstand me. I didn't say it was technically impossible to create applications based on HTML/JavaScript that have similar functionality to installed apps.

What I said is that if you do that, you get the very same UX problems as well. You can implement back button functionality in either technology, but what it does needs to be reinterpreted for every single app because you have lost the page as a concrete unit of reference.

There may be other useful units of reference, but they are different ones in different apps regardless of technology.

</comment></comment></comment><comment><USER21> Isn't the app-craze just a sign that websites are too complicated, slow, in many cases also somewhat shady and full of annoying ads? Most of them are nearly impossible to navigate using a mobile browser and extremely annoying. App stores give us a tiny bit more security (through moderation) and UIs that will work for our device.

Making websites that work well both on desktop and mobile browsers is a PITA. We already have too many browser versions (and deficiencies) to take care of (yes, we really do not want 2-3% fewer users = customers = revenue), mobile browsers add a whole bunch of new issues to take care of (hover, selections etc. all work differently).

As long as we don't have a framework or set of widgets that works properly everywhere and is fast/small enough for mobile devices, Apps will have a Raison d'être. Now go write one or stop complaining!

<comment><USER22> _Isn 't the app-craze just a sign that websites are too complicated, slow, in many cases also somewhat shady and full of annoying ads? _

1\. Complicated? No, I don't think so. If anything the problem is that web sites aren't capable of being as complex as they ideally would be.

2\. Slow - yes. But browsers keep getting better (iOS excepted, sadly - <USER2> appears to have lost a lot of interest)

3\. Somewhat shady and full of ads - apps are worse in this regard, IMO. They also ask for access to your location, and all sort of other data access web sites don't have.

 _Making websites that work well both on desktop and mobile browsers is a PITA._

Yep. Making websites that work across all desktop browsers was a PITA a few years ago. Cross-platform web development has never really be that easy.

<comment><USER21> > _Somewhat shady and full of ads - apps are worse in this regard, IMO. They > also ask for access to your location, and all sort of other data access web > sites don 't have._

I disagree with that - App stores will reject many apps but search engines will happily index most shady websites as long as they don't serve obvious malware or try "black hat SEO". Websites can also ask for your location, store a multitude of tracking info (cookies, Flash cookies, local storage...) and while they cannot access contacts, SMS and similar information, they can get very sensitive information though phishing and possibly from browser history.

> _Cross-platform web development has never really be that easy._

We could stick to the lowest common denominator (which is still simple HTML apparently), but people would complain about the obsolete UI.

</comment></comment></comment><comment><USER23> The problem with "apps" is fundamentally one of curation which IMHO is, in turn, a problem of centralization.

If you set out to build "the one big marketplace", you inevitably get to a place where mostly what your marketplace offers is crap, because you have optimized it towards _providers putting stuff onto your marketplace_.

Thus, in building "the big marketplace", you necessarily fail to optimize it towards users getting value out of the marketplace, because you kinda sorta hoped that would be taken care of by "free market" pressures. (And also because it's one of those "hard problems" that you would rather forget about and build some neat code instead.) But it's the users bearing the collateral damage.

I'm currently working on a package/application distribution system that is decentralized and the "app-pocalypse" is one of the reasons why I made it so. Being decentralized means that the value you are getting out of it depends mainly on the trust you invest in your immediate channel provider who in turn now has a responsibility to keep you happy. By splitting up the relationship and giving people proper roles instead of the delusion of a grand audience that is fit for whatever some app developers shovel into the system, I hope it will end up providing actual value instead of just a top-down revenue system.

Having worked on it for a while now, it always strikes me as weird how we are all on the Internet (which by its design is fault tolerant and decentralized), building these centralized, monolithic services that inevitably fail (either in a big way due to security reasons or in a slow way, like in the app- pocalypse) for the same reasons.

<comment><USER24> > Thus, in building "the big marketplace", you necessarily fail to optimize it > towards users getting value out of the marketplace, because you kinda sorta > hoped that would be taken care of by "free market" pressures.

In an open and free market most of the stuff sold "is crap", but people generally discover valuable things and will equalize to the right intersection of value and cost, all things equal.

The big problem with a big marketplace is when it obscures the value part of that balance. How do I determine which of these 30 applications has the best value/cost balance?

Isn't straight-up downloads, because who knows how many of those people still use the app. Isn't necessarily rating, because we know those responses don't really answer the big question.

A small curated market solves the hard question (which is most valuable for the price?) but short-cutting the question. The user doesn't need to ask or research, because by the nature of having a small, curated marketplace, the marketplace organizers rely on their own credibility as curators.

Like the news industry, whose job it was to curate the news, eventually a few small curators float to the top and then attract more quality curators, growing that marketplace.

But it's still inherently weak, because you're still not supporting the user answering their own question - which of these has the best value for the cost?

<comment><USER23> What it comes down to, for me, is the question of trust. If there are 30 messaging applications, I will use the one that somebody I trust uses or recommends. Otherwise, I would have to spend a lot of time searching through the options ("collateral damage", as mentioned before).

Managing trust on a large scale (or in terms of the big app-stores, _ultimate_ scale) is very hard because people are very different in their needs and in which providers they would trust in the first place.

Funnily enough, even if you decentralize this process as I'm trying to do, you might end up serving all clients with 90% of the same product. But those 10% make all the difference in the world.

In a sense, what I'm trying to do is to make that dynamic of relationships and trust the main focus of how the network is built. It is a marketplace of marketplaces that rise or fall depending on how much value they provide and how much trust users put into them.

<comment><USER24> That first paragraph does it for me.

I think my question here would be, why do I want to go search out a bunch of smaller, federated, decentralized app stores, then build trust with each of their managing teams, and trust my payment info and PII with them, when I could go to a curated tech blog/info site and get recommendations, then go to one of the main app stores and buy the app?

I'm not sure that I understand what value a middle-man aggregator of smaller markets will provide that beats such a situation.

</comment></comment></comment></comment><comment><USER25> I, for one, am tired of the app-bubble. It will take a few more years, probably, but eventually will go away.

Am I the only one that looks at this whole app-crazy-run as something completely unsustainable?

<comment><USER26> We are slowly transitioning into HTML5 bubble at the moment.

<comment><USER10> Explain?

I'm as curmudgeonly as they get. Other than DRM, I think I'm actually pretty happy with what I see in HTML5, though unfortunately there's still no way to actually force Web developers to use just a minimal markup set.

If I could force every last goddamned Web dev in the universe to stick with <html>, <body>, <header>, <article>, <aside>, and <footer> tags, along with <p>, <em>, <strong>, <a>, <blockquote>, <ul>, (and list items), form and text elements, and <img>, I think I wouldn't shed a tear. And I could then write my _own_ goddamned CSS to render their pages in a sane and readable fashion. Once (as opposed to the 1000x I'm approaching now via Stylebot).

Table elements would be accessible for a fee, waivable for actual data presentation.

<comment><USER27> HTML5 isn't just about the tags. It's an ecosystem of technologies that are breaking down the barriers of the browser to enable more native-like experiences over the web. Take for example how Google Maps in the browser can "access your phone's location". Think about what it's doing - there's a browser API that web developers can call that retrieves data sensed off the user's mobile device. This used to only be possible with native apps.

Also, the HTML5 ecosystem is more exciting because of the renaissance with javascript (nodeJS for server-side javascript, many JS libraries and frameworks) and the entire developer tooling that is making web development workflows much more productive than in the past.

<comment><USER26> "(nodeJS for server-side javascript, many JS libraries and frameworks)" \- the saddest part, as if we don't need language innovation anymore... One to rule them all.

<comment><USER28> If JS is the x86 of the web, then we need to stop arguing about which macro syntax we prefer and move up a level of abstraction.

<comment><USER27> Let's just jump to the Wolfram Language! hehe, that would be awesome.

</comment></comment></comment></comment></comment></comment></comment><comment><USER29> Cross-posting my comment from his blog:

Since the app ecosystem is generally closed, why aren't apps available as Shareware, with 30/45/60 day trials, or with no-questions-asked refunds within 48 hours of buying?

What you said about coffee-vs apps is spot on. I've bought some totally rubbish apps and now it's a hard sell to get me to buy any. Competing apps in a field (e.g. PDF marking up on iPad)? I can't try before I buy, so I haven't bought...

</comment><comment><USER30> At least the "It looks like you're writing a letter" era came with entertainment by Clippy. I avoid going to sites that don't remember my rejection of their "website-wannabe" apps ... Atwood is right about how annoying that is!

<comment><USER10> You call that entertainment?

Back when I had the misfortune to have to use Microsoft software, pretty much the first thing I learned to do on any fresh revision was how to nuke those damned tools with extreme prejudice.

The most gratuitously annoying aspect of the cartoons? The little dance they did when you told them to go to fucking hell and never come back. One more half second just to rub it all in.

<comment><USER31> I liked the cat, I still miss him. [http://www.youtube.com/watch?v=ykGIcXKAXbI](http://www.youtube.com/watch?v=ykGIcXKAXbI)

<comment><USER10> I'm quite fond of cats.

Not that one though. They were _all_ just so gratuitously annoying.

Actually, now that I think about it, Microsoft's tone-deafness on just _how much_ people hated Clippy reminds me of Google's attitudes on G+, Real Names, and the Anschluss of all Google services.

Note that ZDNet (hardly a harsh Microsoft critic) noted when Clippy was finally killed (in 2001):

[http://www.zdnet.com/microsoft-kills-off- clippy-3002085615/](http://www.zdnet.com/microsoft-kills-off- clippy-3002085615/)

 _Software giant Microsoft is laying off one of its most controversial employees: Clippy._

 _The software help system, a long-despised feature of Microsoft 's popular Office suite of business software, is the star of a new Web marketing campaign launched on Wednesday. The campaign and a companion Web site trumpet Microsoft's forthcoming Office XP software as so easy to use that Clippy is out of a job._

And even that didn't take, they had to take out a second hit 9 years later: [https://www.youtube.com/watch?v=VUawhjxLS2I](https://www.youtube.com/watch?v=VUawhjxLS2I)

</comment></comment></comment></comment><comment><USER32> Can we stick to the web somehow instead and bypass the various proprietary walled gardens?

<comment><USER33> We can. Whenever I see "Would you like to install our app? Y/n", my answer has been Ctrl-w to close the tab. This strategy has worked flawlessly for years. It can work for you, too.

<comment><USER10> May I suggest the additional step of an /etc/hosts file entry for the site in question. I recommend '0.0.0.0'.

</comment></comment></comment><comment><USER34> He hits on some good points and misses on some others to me.

Most importantly, the question of why you are building an app in the first place is incredibly important. However, he's also got to consider each app maker is unique. McDonald's makes an app because they have a marketing budget so large that their strategy is to appear everywhere - including your phone. However, I generally agree with his point that not everyone needs an app, and they absolutely shouldn't be giving us the mobile equivalent of the Javascript popup every time we hit their website (personally, I like the sites that just have a header bar drop down asking if I'd like to install the app that is easy to scroll past).

I don't think the web is dead, but I do think mobile apps are the future. The best UX I can imagine based on what is around right now is something like what Facebook is trying to do - apps that deep link to each other without the user realizing they are moving between apps. The key here is that the apps must be specifically designed to maximize the user experience, not just to have an "app." We aren't at that point yet, but remembering where the mobile web was back in 2005 when I got my first data plan compared to now keeps me incredibly optimistic about its future, as does knowing that some of the smartest people out there are thinking about this problem all the time (like the guys at URX).

<comment><USER35> It sounds like someone soon will being reinventing OLE (Object linking and embedding)...which scares me a lot.

Maybe call it MOLE - mobile object linking and embedding?

</comment></comment><comment><USER36> The only good news: If the web is as dead as the PC or Lisp I won't have to care about these problems for a long time. Back to work ..

<comment><USER37> yep, but this kind of considerations define which projects get funded and get traction and excitement.

There is always money in legacy, but you don't read often a about a startup creating exiting products for COBOL refactoring...

<comment><USER38> Isn't that the definition of exiting? [http://www.cobol- it.com/index.php?page=products](http://www.cobol- it.com/index.php?page=products)

"Restructuring COBOL sources" "COBOL-IT is the first company offering an enterprise-class Open Source COBOL Compiler with a wide range of Premium Professional Services"

</comment></comment></comment><comment><USER39> The web is not going to "win" because the average consumer has been trained to look for "apps" from the app store, not to use web apps. Web apps packaged in the app store might be a bigger thing moving forward, but the point remains - on a phone people expect an app. No amount of needing out over how things "should" be is going to change the basic behavior of millions of users. Instead of hoping the web will win, smart devs will accept reality and make the best of it.

<comment><USER40> So make the web look like apps, as Firefox OS does.

<comment><USER18> Which I don't believe will win any usable userbase.

<comment><USER13> You're right, nobody uses websites except for some guys @ CERN.

<comment><USER41> You have slipped _a lot there_ : the difference between website and app is much much bigger than many would like to admit.

<comment><USER13> You might reasonably argue that Firefox OS will not get much traction, but denying it's existence as you're doing is foolish, because it obviously exists.

There is no difference between apps and webpages. None. Zero. That's the point of the original article as well: that most apps are just _worse_ implementations of perfectly working webpages.

</comment></comment></comment></comment></comment></comment><comment><USER27> It seems that the line between native app and web will increasingly blur as HTML5 matures to the point it obviates whatever advantages remain with building native apps. I think this will mean a better end user experience as there will no longer be these walls between the web and mobile experience. It doesn't seem efficient for companies to have to build a website, a mobile version of the website (with responsive design), and native apps (for every platform).

<comment><USER41>
      > It seems that the line between native app and web will
      > increasingly blur as HTML5 matures

Would you care to elaborate on that? Because I see no blurring. Building apps with webtech was a stupid idea to start with, and the current state is just incessant running in circles trying to invent a wheel. I am pretty sure that webdevs touting the victory of HTML5 have _no idea_ what native offers and how many years behind even the best web-based offering is.

Why don't you first replace all the desktop apps with the browser and then talk about mobile? Why this obsession that web should win? Why not everything has it's place?

<comment><USER13> _I am pretty sure that webdevs touting the victory of HTML5 have no idea what native offers and how many years behind even the best web-based offering is._

It's just an example of worse-is-better in action. Many webapps offer mediocre features compared to the real thing, but they have no install latency, better monetization features than pay-in-advance or messing with serials and unlocks, and offer enough features that you can get by with them. When the need to use or access them on mobile arises, they are available, and often the native solutions are not.

I like LibreOffice Calc (or Excel, for that matter) but they don't work on my Android tablet.

</comment></comment></comment><comment><USER42> Many people misunderstand the proper boundary between apps and Web sites.

Web sites that should remain Web sites "go app" to get more eyes. That's the main fault found in the article. App makers that should be thinking "app first" or "app equal," including Google, often have apps that are not at feature-parity with Web sites. That's also pointless and very annoying.

There's a place for both. The Web is great for publishing hypertext information and when you tread that line with e-reader apps, you have to be very careful not to leave out Web functionality. And while Web versions of highly interactive applications offer an anywhere-accessible backstop, if you don't put more effort into the apps, you're missing the point of putting an app in a highly interactive touch device. Apps are inherently better at controlling presentation, direct manipulation, and inter-app cooperation. If you are not accessing these capabilities, you probably cross-trained a bunch of Web UI people to write your apps, gave them a smaller budget, and your product manager wasn't aware there are features that apps should have that are hard to duplicate in Web interfaces.

</comment><comment><USER43> Literally yesterday I got an email to download the new Sallie Mae app. Now I can have my student loans with me wherever I go!

I wouldn't be surprised if the app had a button to "share this loan on Facebook".

</comment><comment><USER44> And yet app revenues keep increasing every quarter ([http://www.asymco.com/2014/02/10/fortune-130/](http://www.asymco.com/2014/02/10/fortune-130/)).

First, I'm not sure poor marketing practices can be blamed on the App Store itself. It is up to those companies/sites to decide how to promote themselves. I'm also not sure it is the App Stores responsibility to provide many marketing channels.

Second, websites are free, that's why most people probably expect apps to be free, too. I think people like to pay for experiences. A coffee is an experience. And you get a friendly barista, a nice store with wi-fi, a whole table with extras to mix in, etc. Software in comparison is really abstract. Out bodies tell us they are hungry or sleepy, and pressure us to do something about it. Our bodies do not pressure us to try out a new calendar app.

</comment><comment><USER45> I think this blog (and some other sentiments I've heard lately) is chaotic enough to be boiled down to: "Something's not right here!" I'm not sure that fragmentation, inconsistencies, nag screens, hamburger apps and a general refusal to pay $2.49 for an app are explainable in one easy way.

One insight (I think) is - " _My son 's iPad has more than 10 pages of apps now, we don't even bother with the pretense of scrolling through pages of icons, we just go straight to search every time._"

If search turns out to be a game changer again, that's an interesting result.

</comment><comment><USER46> One way to deal with app platform fragmentation is to develop your app using a technology that supports multiple platforms -- Sencha Touch comes to mind as one example. Not that it solves the problem entirely, but it does make it cheaper.

I'm not sure what makes the app ecosystem that much different from the web at large -- if anything, I think the amount of trite, junky apps mirrors the amount of useless noise found on the web in general.

He does make a good observation about there being an opportunity for some startup to come along and do to apps what google did to the web.

</comment><comment><USER47> >Have you ever noticed that the people complaining about apps that cost $3.99 are the same people dropping five bucks on a cup of fancy coffee

Every single time there is a post like this we beat the same dead horse.

<comment><USER48> You can certainly be forgiven if you stopped reading the article at that sentence, because that is a frequently-beaten dead horse.

However, Atwood is actually making the exact _opposite_ point: he goes on to say that people _are justified_ to gripe about $3.99 apps because the quality of apps is so uneven and there's no real way to ascertain the quality of an app before you buy it.

He says we'd certainly be justified about complaining about $3.99 cups of coffee, too, if only 1 in 5 $3.99 cups of coffee was actually a decent cup of coffee!

</comment></comment><comment><USER49> "Would you like to subscribe to our Newsletter before you read this article?" is an equally poor, if not worse, way to welcome a visitor. Atleast give me a chance to evaluate that decision.

</comment><comment><USER47> Reading this, I was left with the impression that iOS apps took off by offering high quality at low cost. However, the cost differential was wrong and eventually the developers figured it was a scam and changed up.

Some provided lame platforms for pump and dump html to apps. Others made their games free and played off their users addiction.

Each day app developers burn more and more consumer trust. Eventually we will get to a point where quality matches cost, we may be there already.

</comment><comment><USER50> The app purchase process is definitely broken. You can't trust ratings, and it's hard to know what you get. In the end it's just "I'll toss a few dollars and roll the dice."

I really want high quality education software for kids. The only thing that works is word of mouth. App store reviews don't help. Googling the topic produces mostly reviews that may or may not be ads.

I'm waiting for Netflix of the App World.

</comment><comment><USER51> Jeff is really talking about a very specific kind of app: one that provides an interface to a web service, and that has (or could have) a comparable service accessible through a browser.

There are a lot of apps that make the bulk of the "millions of apps" that do not fit this description: games, productivity apps, apps making use of mobile hardware (microphone, camera), that couldn't possibly have web alternatives.

It's totally true that App stores have pricing/quality/discovery problems, but I'm not sure that there is a duality with the web (which could be resolved by "product x"), just an intersection.

</comment><comment><USER52> Meanwhile there are decent sites that run fine in the browser. E.g. I had no trouble with [http://thrillbent.com](http://thrillbent.com) adapting to my PC/phone screen size.

</comment><comment><USER53> There should be some universally recognized icon, like RSS feed icon, which would be on sites offering app versions, and user could press it of he wants to.

<comment><USER27> It's going that way. Hopefully not some annoying icon featured prominently on every page, but instead a subtle browser-based recognition that the site also has a web app and puts a tiny mobile icon in the browser bar that will launch you to the app's install page.

<comment><USER54> This functionality is actually built into the Metro side of IE 10/11 on Windows 8. Which sadly means that nobody (especially nobody who reads HN) will ever see it.

<comment><USER27> Cool, didn't know that. But HTML5 will enable this in a platform-indepedent manner which is good for the web.

</comment></comment></comment></comment><comment><USER55> One of the main reasons companies want people to download their free app is that it's a great marketing channel. Once enough people download the app, it goes up in the App Store rankings. When you are up in the rankings, you get free marketing for your product. Thousands/millions of users are seeing the app and by extension the product.

</comment><comment><USER56> I think that the move from the web to apps the web brought on itself.

Fundementally the web is a linked document viewing system. Later it needed scripting and a bletcherous system was hastily added. But the web had huge momentum, the system stuck, and here we are with three+ major browers all interpreting the morass of HTML, DOM, CSS and Javascript slightly different. Yes, HTML5 tries to rectify some of that, but it's sadly too late.

As a developer of a mobile or tablet application you have a choice of the technology cesspool that is the web or the nice tidy mobile development tool of your choice (mostly) with sane UI tools and a language that probably didn't need a "good parts" book. You also get a better system for collecting payment, easy access to the customer's data, and when it's installed and then compromised it's on someone else's computer, not yours. And that computer is relatively easy to use. No calling nephews to figure out where the internet went ("It used to be right here on the screen..."). To view a usable 1024x768 web page you need one of those complicated general purpose computers, which really aren't practical or even understandable for 95% of the population.

It's so easy to make an app we now have a gajillion of them cranked out daily that no one cares about. Then they get thrown in the the cesspool that is the mobile app market and the suckage continues.

If you want to have the web continue to flourish (and I'm not aligning with the trolling and utterly stupid Mr. Rabois here) we should have better tools for creating applications for the web. I'm not sure what that would be (bytecode runtimes, mature HTML5, a new language?) nor how to wrest control from the oppressive JavaScript Empire. But unless that happens don't be surprised if the web turns a bit gray.

<comment><USER28> This is one reason why MS had significant developer mindshare ten years ago: they invested a ton of resources into creating great developer tools, be they IDEs, languages, or frameworks. While many have derided MS for their frantic pace with this, it does convey an attitude of "developers are important to us: have some new toys." While those tools weren't always the most advanced, they did build on each other.

The web today is still dominated by the same tech stack I learned in HS: HTML/CSS/JS. The DHTML of yesteryear has mainly had hordes of libraries built on it to make it more palatable. But accidental growth tends to spawn a lot of needless complexity. The web is a fantastic delivery mechanism, and I love that it's open. But it's just so painful for app development compared to the walled gardens that I don't blame developers for sticking with something that is more cohesive.

</comment></comment><comment><USER57> Imagine an environment that was not connected to the Internet but you still needed to deliver services through handheld and desktop platforms. Would you go native or a web (internal) based solution?

All devices would be the same and all users would have access to same services.

</comment><comment><USER15> Funnily enough I've found ebay and similar stuck-in-the-90s websites are very easy to use on my phone. It's the ones from the late '00s fancy css and rounded corners era that are less usable.

</comment><comment><USER58> This seems to me like a straightforward extension of Sturgeon's law: 90% of everything is crap. Should hardly be surprising.

</comment><comment><USER59> Jeff Atwood is a horrible analyst and populist writer with mediocre knowledge. Noone should read his blog...

<comment><USER60> Jeff: sorry... who are you?

</comment></comment><comment><USER61> tl;dr. Jeff loves Apps and would like all of us to make more of them.</comment>


How to recruit a developer and keep him happy - <AUTHOR> http://www.devtich.com/recruit-keep-developer-happy/

<comment><USER2> That's a nice guide!</comment>


Tumblr builds post-by-phone feature in only 3 hours w/ Twilio - <AUTHOR> http://blog.twilio.com/2009/02/things-you-can-do-in-3-hours.html

<comment><USER2> Awesome. This is a perfect illustration of all that is right about web services!

</comment><comment><USER3> very cool -- this would have taken weeks/months to do, without Twilio...</comment>


The elegant timing contraption of the Nenana Ice Classic - <AUTHOR> https://www.adn.com/opinions/2017/05/01/this-antique-engineering-marvel-records-spring-breakup-in-alaska-like-clockwork/ <comment><USER2> I can't miss this chance so: When someone uses the word debacle to describe a minor problem I get to rebut with my favorite joke (that only works when you are in Alaska and a nerd): Namely "That's not a debacle the Nena Ice Classic is a debacle."

See definition 3: [http://www.dictionary.com/browse/debacle](http://www.dictionary.com/browse/debacle)

Also: It's not nearly as good with "bets on a debacle", but it a good bit more accurate.

Also: Yes all of my friends _hate_ my sense of humor.

</comment><comment><USER3> I found this article fairly confusing. It seems to be geared towards readers are already very familiar with the whole Punxsutawney-Phil-esque event, eschewing any establishing pictures and bringing up "the tripod" and leaving me to puzzle whether it was part of "the tower" or not, etc.

<comment><USER4> It's a type of lottery.

A large wooden "tripod" (it actually has four legs) is placed on the frozen river in winter. When the ice breaks up in spring and the river starts flowing, the current carries the tripod downstream, pulling a rope attached to a tower built on land to trigger the mechanism described in the article to stop the clock.

People buy tickets to place bets on the exact minute the clock will be stopped. The closest bet wins, and if there are multiple bets on the winning time, the winners split the prize. The prize has been over a quarter million dollars in recent years.

<comment><USER3> I understood that it was a lottery, I'm just grousing that 5% more set-up would've made it much more approachable.

It doesn't quite say what happens when the slack runs out on the _other_ ropes, come to think of it. Unless the cleaver cuts them all at once somehow.

</comment></comment></comment><comment><USER4> I lived in Nenana as a child. I had no idea it was this complicated. I figured it just pulled a pin to stop the clock.

</comment><comment><USER5> I actually won this one year.

I was in a pool of 14 people and we spread our guesses across the most likely times on the most likely days. Of course, that's what most people do, so there were several winning tickets. It wound up being a few hundred bucks.

</comment><comment><USER6> I don't understand what the stopped clock is supposed to signify. It's a device that show the current time except off by a bit—the number of large changes in the ice flow? like my microwave?

<comment><USER7> There's a yearly lottery pool based on who guesses closest to the time when the Nenana ice jam breaks up. The tripod falling over signifies when the river's moving.

[http://www.nenanaakiceclassic.com/](http://www.nenanaakiceclassic.com/)</comment></comment>


Ask HN: Probably a dumb idea to lose focus, but.. - <AUTHOR>

I am experimenting with an offer and wanted to publish this without bothering my developers or messing with our production servers.
https://docs.google.com/a/monchilla.com/drawings/d/1xrOqlfrBiw-XPs3_Yarf4X58VVlU_BqF7NNMl1o26FA/edit
I thought that would be easy, but after an hour of digging I gave up and was about to pass it off to my team and than I realized this would be impossible for most of my users (small business owners - non tech) so I thought I might pay someone to build a real simple UI that would allow users to specify a background image and change the 6 lines of text and then publish it on our servers. Here is why it might be a good idea: 1. Its cheap and would give some free value to my target market (Most of my users don't have a web page). 2. If it is hosted on my domain I might get some SEO benefit and some exposure since my domain name would be in the url. Here is why it probably isn't: 1. Its a distraction from the problems I'm trying to solve for my users.
Let me know what you think and if you don't think it's stupid, if you want some side work ;) <comment><USER2> What it looks to me like you kind of sort of have is a really basic brochure site service. I could definitely see this doing well with local clients and small businesses.

Looks like it would be ridiculously easy, too. If you can make some money on it than why not?

</comment><comment><USER3> It may be a good idea, or it may not.

You should discuss this with your clients. Also, set some price for it (people tend to discount the value of free, plus just b/c your customers will accept a free x does not mean they value x). My $.02.

<comment><AUTHOR> That's a good idea. I actually just bounced it off one of my users and they thought it would be great, but I often get flattering responses when I ask my users if they would like X because they already like us for solving a real pain.

<comment><AUTHOR> I just realized you're saying I should give them a price even if I plan to give it away for free. That's smart. Thx.

</comment></comment></comment><comment><USER4> If you are looking for for-hire development with a small scope and clear objectives, might be worth checking out elance or odesk.

<comment><AUTHOR> Do you think it would be a useful tool even for a more high tech (non dev) audience? Could you imagine a need for a quick and easy splash page in the next 12 months or would you just write the html and use your own web server?

<comment><USER4> I would probably pay $4 for a nice pre-made bootstrap theme (e.g., [http://wrapbootstrap.com/preview/WB07T0755](http://wrapbootstrap.com/preview/WB07T0755) ) and throw it up on one of the servers I have around.</comment></comment></comment>


Math.random() and 32-bit precision - <AUTHOR> http://jandemooij.nl/blog/2015/11/27/math-random-and-32-bit-precision/ <comment><USER2> It's nice to make full use of all the significant bits in a double-precision float, but I don't think it matters much in typical use cases.

Mike Malone's original code sample [1] uses only 6 bits from each invocation of Math.random(). Most people who use the multiply-and-floor method to obtain a random integer are probably using no more than 31 bits, either.

On the other hand, even the full 53 bits is woefully insufficient for unique identifiers or any serious cryptographical purposes, where you need at least 128 bits to be safe. So you'll still need to call Math.random() multiple times.

[1] [https://medium.com/@betable/tifu-by-using-math- random-f1c308...](https://medium.com/@betable/tifu-by-using-math- random-f1c308c4fd9d)</comment>


Mail Rail: What is it like on the 'secret' Tube? (2014) - <AUTHOR> http://www.bbc.com/news/uk-england-london-25145632 <comment><USER2> See also: the New York pneumatic mail system (although that didn't move people). [http://untappedcities.com/2013/03/15/nycs-pneumatic-tube- mai...](http://untappedcities.com/2013/03/15/nycs-pneumatic-tube-mail- network/)

(not to be confused with Beach Pneumatic Transit, although that didn't move mail: [http://www.columbia.edu/~brennan/beach/](http://www.columbia.edu/~brennan/beach/) )

</comment><comment><USER3> > _That year, Royal Mail said the line cost five times as much as using roads > and the network shut down._

I wonder if that calculated cost of using roads included the externalized costs of using roads – exhaust emissions, traffic congestions, road wear, etc.

<comment> UVB-76 Many of those costs are internalised by vehicle taxes, which were likely taken into account.

<comment><USER3> 1\. Do vehicle taxes even adequately cover road maintenance costs, let alone all the other costs I mentioned?

2\. Does the Royal Mail actually pay taxes on its vehicles?

<comment><USER4> In the UK, petrol tax is over 1 USD per litre. Tax on new cars is ~30% (10% car tax, and 20% VAT). Plus a couple of hundred pounds per year for road tax.</comment></comment></comment></comment>


Ask PG: Is RFS3 "Things built on Twitter" still sensible to prioritise? - <AUTHOR> Given Twitter's capricious enforcement of its API Rules of the Road, their willingness to allegedly crib features from apps in their ecosystem, and increasingly misaligned incentives vis-a-vis 3rd party developers and users, how long is it before this RFS becomes inordinately risky for YC to specifically solicit? <comment><USER2> It certainly doesn't seem as promising a territory as it used to. Not so much because it's more dangerous as because Twitter hasn't turned out to be a "platform" in the same sense as say iOS has.

<comment><USER3> Does the same apply to Facebook? And if not, is it likely to within the next 12 months?

It seems like a lot of developers/startups put their eggs in the FB basket. I wonder if, from a funding perspective, that behaviour would set off alarm bells today?

<comment><USER2> Facebook seems somewhere between Twitter and iOS.

<comment><USER4> Would you consider iOS and Android similar in terms of risk and developer potential?

<comment><USER2> To most startups we fund, iOS is way more important. Nearly all build for iOS first and then maybe one day port to Android. There are a few exceptions like Kyte (<http://kytephone.com>) who use Android to do things you can't do on iOS. And of course Apportable (<http://apportable.com>) has been very successful auto-porting iOS apps to Android.

<comment><USER5> > Nearly all build for iOS first and then maybe one day port to Android.

It's unfortunate that this persists even though Android now has twice the smartphone marketshare iOS has. It doesn't seem like things will be changing any time soon either.

<comment><USER6> And China has more than twice as many internet users as the United States. However, I'm pretty sure the American users spend more money per capita and that it's not an accident that most YC startups target them first.

<comment><USER7> I'd argue the fact YC is an American incubator also has a lot to do with who YC companies target. A lot of internet VC-backed startups don't particularly depend on their users spending money.

<comment><USER6> My point was (fairly obviously) an analogy. However, almost all startups have one of two business models: either they sell things to their customers, or they sell advertising space to people who want to sell things to their customers. Both require customers who spend money.

<comment><USER8> Remember, if you're selling ad space, the advertiser is the customer. The user is the product. Nitpicky, but important. Your explanation works if you replace "customers" with "users".

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> My how things have changed so quickly. I applied to YC for W10 with RFS3, got in, quickly abandoned the idea since the market didn't seem big enough, did something else (Notifo) on mobile platforms which seemed more promising, watched Twitter quickly destroy it's 3rd party ecosystem, decided never to build on top of Twitter again. All within about 18 months.

<comment><USER10> Is open sourcing Notifo still in your plans?

I recall that you mentioned that quite some time ago.

</comment></comment><comment><USER11> See @pg's answer here <http://news.ycombinator.com/item?id=2341567>

</comment><comment><USER12> There's actually a generally interesting question here:

When is an RFS considered "closed?"

<comment><USER13> If one cannot answer this question themselves, it's most certainly closed for them.

</comment></comment><comment><USER14> I think there is still a lot of potential in twitter as a platform, specifically for the data they hold. There is a lot of information shared on twitter which previously didn't exist on the internet. It would be shared by people chatting to each other, maybe msning colleagues or emailing links to friends etc. That information suddenly being available is what I think is interesting, and still worthwhile building on.

Back in the day, building a twitter client may have seemed reasonable but ultimately turned out to to be 'snatching coins from in front of a steamroller'. I think if you're building something which is a replacement or improvement on the twitter browser UI you're clearly taking a risk. I don't know that other uses of the data they hold are such a risk. Obviously I could be wrong but for me it's at least on the opposite end of the risk spectrum from twitter clients.

[disclosure, my current side project uses twitter data. It's in my profile if you want a look]

</comment><comment><USER15> Twitter is more a part of a distribution strategy than a platform to build an entire business off of <http://t.co/r6wdLpMc> $ZNGA $FB

</comment><comment><USER16> Pardon my ignorance, but what is RFS short for?

<comment><USER17> Request for Startups. See <http://ycombinator.com/rfs.html>

</comment></comment><comment><USER18> What are your thoughts as to OStatus?</comment>


Okcupid Acquisition was 50 Million + 40 Million earn out.  - <AUTHOR> http://plentyoffish.wordpress.com/2011/06/05/okcupid-acquistion-was-50-million-40-million-earn-out/ <comment><USER2> I think OkCupid has been doing to POF what Facebook did to MySpace. Mediocre products that serve a real need will survive for a while, but long-term people gravitate towards quality.

That may all end now that they've been acquired by a mega corp though.

Look at this trend: [http://trends.google.com/trends?q=okcupid%2C+plentyoffish...](http://trends.google.com/trends?q=okcupid%2C+plentyoffish&ctab=0&geo=us&geor=all&date=all&sort=0)

<comment><USER3> I also wonder if there are just limited lifespans for these types of sites. Dating, community (slashdot->kuro5hin->digg->reddit->hn), social networks (friendster->myspace->fb), etc. These sites seem to move in waves like fashion or gentrification.

<comment><USER2> Friendster dropped the ball technically, at one point they had 10 minute page load times.

Kuro5hin was never as popular as Slashdot.

Slashdot didn't evolve their submission model and was left in the dust.

Digg screwed up their product and pissed off their community.

MySpace sacrificed user experience for in the name of short term profit from pageviews/ads.

HN hasn't replaced Reddit except for a tiny minority of startup/hacker people (many of whom continue to use Reddit).

I think it only _appears_ that users are fad driven, when in reality they're just smart enough to move on to better options.

<comment><USER4> Even if it wasn't fad driven, there seems to be a significant trend of the number one site getting eclipsed by new up and comers. Whether that trend is coming to a halt with Facebook or not is debatable (they seem to be staying on the leading edge and more than willing to adapt and take in the ideas any competitors would push, along with the most extreme network effect possible).

On the other hand, I doubt that reddit isn't going to suffer the same fate that slashdot and digg did when something better comes along, though I doubt they are going to make as drastic a mistake as digg did.

</comment></comment></comment></comment><comment><USER5> Seems naive to think they bought OKCupid just for the revenue. The OKCupid guys were awesome at data mining, visualization, and viral marketing. Their ability to enhance the value of Match.com's existing client base is huge.

</comment><comment><USER6> There's a way to cover your competitors and this isn't it.

This just comes off as juvenile. "They didn't buy us even though we make more money!"

<comment><USER7> Well, PoF just isn't going to get bought. OKC has a special algorithm. PoF is a cheap free copy of dating website ("select users with X miles of Y where gender = Z").

Which one would you want to acquire?

<comment><USER8> A dating site is more than just an algorithm; its main asset are the users. Match, PoF, etc. have no fancy algorithm, but they are still among the top because of their users. It's the "network effect".

</comment></comment></comment><comment><USER9> It's curious. Lots of people I know use okcupid; nobody I know uses PoF. The one time I tried joining several years ago, my account was repeatedly deleted. PoF has a target audience, but I have no idea what or where it is. Does anybody?

<comment><USER10> I was not aware that nobody uses PoF, seems pretty popular to me. I am in Canada (Montreal) though, and this is the first time I've heard that Canada is a PoF niche, so I guess that explains it.

For those who say PoF is an inferior product: with dating sites, it all boils down to 1) number of local users, 2) easy results filtering, 3) easy communication. For me PoF had all three.

I met my wife on PoF, by the way, so: Thanks!

</comment></comment><comment><USER8> OKCupid is already going downhill post acquisition. Friends that are on OKCupid (exes) who were ~70% match earlier, are now ~90% match. It's a shame that OKC tweaked their algorithm just to make a few bucks. Based on their general demeanor, I had assumed they would be above such shenanigans; but it turns out to have been a flawed assumption.</comment>


A new film captures North Korea's 'bold and audacious' millennials - <AUTHOR> https://www.washingtonpost.com/news/worldviews/wp/2017/12/15/the-jangmadang-generation-new-film-shows-how-millennials-are-changing-north-korea/?tid=pm_world_pop&utm_term=.36ee2b1c9305 <comment><AUTHOR> A 52-minute documentary on how entrepreneurs operate in North Korea. And you thought Silicon Valley was tough!</comment>


Inside a fast CSS engine - <AUTHOR> https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/ <comment><USER2> I always wonder, who puts together nifty little blog posts on this kind of thing complete with graphics just for the article? By that I mean, literally what title do they have?

Myself and my colleagues would/could write up a technical breakdown of something neat or innovative we might have done to solve some problem at work, but we sure as shit can't make cool little graphics interspersed between opportune paragraphs, nor could we figure out how to make the thing entertaining to read.

Is this kind of thing done in coordination with like a PR/graphics department?

<comment><USER3> No, I created Code Cartoons in my spare time. After I worked at Mozilla for a while, I pitched the idea of me making Code Cartoons explaining the things we were developing in Emerging Technologies. My (current) boss was super into the idea.

I talked more about this on a recently recorded Hanselminutes podcast. It should come out soon.

<comment><USER4> your cartoon explanations are wonderful :)

By the way, what program are you using to make your art?

<comment><USER3> Thank you :) I use Photoshop on a Wacom Cintiq.

</comment></comment></comment></comment><comment><USER5> Isn't it just crazy that we're gonna get all this cool tech in a browser that is completely free and open source?

And along the way, Mozilla created what is perhaps the most disruptive programming language of the past decade. For free. And open source.

It's really hard to appreciate the gravity of this.

</comment><comment><USER6> I turned this on a couple of weeks ago on Nightly and have noticed precisely zero problems, and a really nice little speedup on CSS-heavy sites. Really good to see large chunks of parallelised Rust code start making their way over from Servo to Firefox.

<comment><USER7> Are there any plans for Servo to be a "real" browser, or will it always be more of a R&D playground for Firefox?

<comment><USER8> It's a possible eventual goal but we don't have concrete plans or a timeline.

Stylo and the like let us get improvements out to users well before we need to deal with that.

<comment><USER9> Also, all the discussion so far seems to focus on desktop firefox, are these improvements coming to firefox for android, or is that a longer term project, perhaps when servo is ready?

<comment><USER8> We're hoping to have stylo in 57, and I would expect it to be on android in the next release (58), but no promises.

Basically we intend for it to work eventually on android, but it didn't get prioritized.

<comment><USER10> I can turn on `layout.css.servo.enabled`, on Firefox 55 Android (and Desktop). What does it mean? If I understand correctly, Firefox will have this property turned on by default in 57/58 but it's possible to have it early?

<comment><USER8> No, it won't do anything on 55. Or on 56/57 Android.

Stylo can be disabled at build time, and this was the case for 55 and is still the case for android. We don't remove the associated prefs in that case (about:config doesn't have UX because it's not exactly user facing).

You can go to about:support to see if stylo is actually enabled. There's a "stylo" column. It's not there in 55, but no 55 release has stylo enabled at build time; so if you don't have that column at all, stylo isn't there.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> You may want to actually read this code. You can start by searching "LayoutStyleRecalc" at [https://github.com/servo/servo/blob/master/components/layout...](https://github.com/servo/servo/blob/master/components/layout_thread/lib.rs). Following is verbatim copy.

      // Perform CSS selector matching and flow construction.
      if traversal_driver.is_parallel() {
          let pool = self.parallel_traversal.as_ref().unwrap();
          // Parallel mode
          parallel::traverse_dom::<ServoLayoutElement, RecalcStyleAndConstructFlows>(
              &traversal, element, token, pool);
      } else {
          // Sequential mode
          sequential::traverse_dom::<ServoLayoutElement, RecalcStyleAndConstructFlows>(
              &traversal, element, token);
      }

<comment><USER12> What am I aiming for on this read? I'm assuming the hard parts are swallowed elsewhere, which is good. I'm a little surprised there are two methods for the traversal, depending on the parallel versus sequential. (I'd expect that could have been switched based on the "pool" parameter passed to a single method. No, I don't actually care.)

<comment><USER11> What do you consider hard parts? The actual magic is that there is no hard parts.

<comment><USER12> I haven't read it. That snippet just seemed odd to me.

The hard parts, in this case, would be in Rust, most likely. I'm assuming that flipping CSS to parallel is not a trivial process. I'm further assuming that there is still some sort of locking mechanism so that you don't fire off two parallel traversals at the same time. Or allow updates during a scan. (Or abort running scans if an update happens?)

<comment><USER11> Ah yes, parallelism (locking etc) part is entirely handled in generic Rust library (Rayon in this case), and not specific to Stylo at all. Here is where Stylo meets Rayon, [https://github.com/servo/servo/blob/master/components/style/...](https://github.com/servo/servo/blob/master/components/style/parallel.rs)

      //! Implements parallel traversal over the DOM tree.
      //!
      //! This traversal is based on Rayon, and therefore its safety is largely
      //! verified by the type system.

      /// A parallel top-down DOM traversal.
      ///
      /// This algorithm traverses the DOM in a breadth-first, top-down manner. The
      /// goals are:
      /// * Never process a child before its parent (since child style depends on
      ///   parent style). If this were to happen, the styling algorithm would panic.
      /// * Prioritize discovering nodes as quickly as possible to maximize
      ///   opportunities for parallelism.  But this needs to be weighed against
      ///   styling cousins on a single thread to improve sharing.
      /// * Style all the children of a given node (i.e. all sibling nodes) on
      ///   a single thread (with an upper bound to handle nodes with an
      ///   abnormally large number of children). This is important because we use
      ///   a thread-local cache to share styles between siblings.

<comment><USER13> It looks like Rayon is the same thing as Java's ForkJoinPool and parallel streams but with the neat trick (really, Rust's neat trick) that it can statically check that the code is safe to parallelise through the borrow checker.

<comment><USER11> Yes, that's a good summary.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> It's great to see any company going into detail about their technical implementation, so I'm extremely hesitant to be critical, but I'm really curious who the target audience for this one particular article is.

It's a very very odd mix of language that sounds like it's directed at a very young child and standard technical speak. Not the usual for the Hacks blog.

Not to fault the article too much, but I just found the tone a bit confusing. Even veering towards condescension in some parts, though I'm certain that's entirely accidental and wasn't the author's intent at all.

<comment><USER15> Presumably it's trying to bring technical details to the widest possible audience. So some details may fly over the heads of some folk, whereas more domain knowledgeable people might think some parts sound condescending. It's a hard square to circle.

I think Chrome tried something similar when they were introducing the chrome browser, although maybe with a different balance.

<comment><USER16> You're probably thinking of this Chrome comic:

[https://www.google.com/googlebooks/chrome/](https://www.google.com/googlebooks/chrome/)

<comment><USER17> When you said "Chrome comic" I assumed it was this one [http://i.imgur.com/bhfYx6R.jpg](http://i.imgur.com/bhfYx6R.jpg)

</comment></comment></comment></comment><comment><USER18> This is really great of Mozilla. I'm really excited to see such a large rust project used on such a scale; after that I think there will be few doubts it's a really really impressive language. Also the fact that Mozilla knew this and decided to take such a bold step as rewrite their engine is super cool. I've done rewrites and they never go well so hats off to them.

</comment><comment><USER19> The writeup is inspiring. I found it very clear and yet reasonably in depth. It helps me to understand how much work modern browsers are doing.

Also, excellent use of Rust.

<comment><USER20> > excellent use of Rust

I should hope so! It was one of the major motivators behind Mozilla's stewardship of Rust.

</comment></comment><comment><USER21> > 4\. Paint the different boxes.

Is this really what happens under the hood?

1\. If I overlap 52 html
s like a deck of cards, does the browser really paint all 52 div rectangles before compositing them?

2\. If I overlap 52 <g>s like a deck of cards, does the browser really paint all 52 <g>s before compositing them?

3\. In Qt, if I overlap 52 QML rectangles like a deck of cards, does the renderer only paint the parts of the rectangles that will be visible in the viewport? I was under the impression that this was the case, but I may be misunderstanding how the Qt QML scenegraph (or whatever it is called) works in practice.

edit: typo

<comment><USER22> > 1\. If I overlap 52 html
s like a deck of cards, does the browser > really paint all 52 div rectangles before compositing them?

Browsers don't typically do very good occlusion culling in general.

WebRender aims to change that, by using the hardware Z-buffer. :)

<comment><USER23> You may want to be careful with that approach.

Not all GPUs have the Z-Buffer fillrate to make that approach viable(esp on mobile). I've seen more than a few cases where it was actually faster to turn off Z-Buffering and do the overdraw. More than a few architectures share Z-Buffer bandwidth with other pipelines.

On tiled architectures it'll also increase your tile count which can impact your per-drawcall overhead.

For low-tri things like UI you're better off doing the rect-culling yourself in software(ideally on another thread) and only falling back to the Z-Buffer if you have actual 3D transforms that need per-pixel culling.

<comment><USER22> Not in our experience. WebRender 1 used to do the rectangle culling on CPU and it ended up being way slower than using the Z buffer on every architecture we tried, including mobile. (Overdraw was even worse.) There are a surprisingly large number of vertices on most pages due to glyphs and CSS borders. Note also that rounded rectangles are extremely common on the Web and clipping those in software is a big pain.

Generally, we are so CPU bound that moving _anything_ to the GPU is a win. We had to fight tooth and nail to make WebRender even 50% GPU bound...

<comment><USER23> Fair enough, my data was from about 4 years ago so it may be out of date. There's some embedded GPUs that have some pretty 'interesting' architectures.

I would argue though if overdraw vs z-buffer hurt your performance then you are more than 50% GPU bound :).

</comment></comment></comment></comment></comment><comment><USER24> Congrats! Beyond the CSS engine itself, I also very much appreciate inside development stories like these. I'd also like to read a meta-story about the development efforts in terms of time spent, prior knowledge required etc., and CSS spec feedback, with a reflection on the complexity of implementing CSS from scratch.

</comment><comment><USER25> Haven't even read it, just looked at the drawings and now i know how a browser parses css.

</comment><comment><USER26> Really late to this discussion but wow. Having worked as a web developer/tech writer and editor, this writeup pushed all my buttons. High-level concepts broken down in an exciting way. Nothing turns me off quite as much as clicking on a tech blog post and suddenly feeling like I am reading a whitepaper or portion of someone's Ph.D. dissertation. This is the kind of post I love — stripping things down to the nuts and bolts but keeping me engaged in a way that gives me that excited feeling in the pit of my stomach like I am watching something important take shape.

This is a fantastic technology and I feel like Servo has a pretty amazing future ahead of it. Exciting stuff.

</comment><comment><USER27> I wish this post included some benchmarks or measurement.

<comment><USER22> Just asked Emilio on IRC for some quick numbers.

emilio: pcwalton: wrt gecko we have stuff like [https://bugzilla.mozilla.org/show_bug.cgi?id=1342220#c25](https://bugzilla.mozilla.org/show_bug.cgi?id=1342220#c25) and similar

emilio: pcwalton: there's also the tp6 numbers, though those also measure CSS parsing and other stuff that isn't the style engine per se

pcwalton: emilio: our tp6 numbers are improved over Gecko at this point, yes? :)

emilio: pcwalton: amazon by a huge amount, facebook not yet I believe, but patches are on the queue that should make it turn around :)

emilio: pcwalton: happy to talk with mjs about impl details too, if he wants. I know a bit of WK stuff too :)

<comment><USER28> This is an easy benchmark for rejecting a lot of selectors:

[http://bholley.net/testcases/style-perf-tests/perf- reftest/b...](http://bholley.net/testcases/style-perf-tests/perf- reftest/bloom-basic.html)

Firefox with STYLO_THREADS=1 gets about 160ms on my machine, which is basically parity with safari and chrome. With the parallelism, Firefox gets 40ms. :-)

You can also simulate sequential mode in recent nightlies by ctrl-clicking and loading the tab in the background (we disable parallelism for background loads).

<comment><USER27> Thanks, that is the kind of thing I was looking for (though a bit of a narrow test). Cool to hear that this gets a solid speedup from parallelism.

</comment></comment></comment></comment><comment><USER29> Very nice writeup! One thing I found strange is that multi-threading is ELI5, but the reader is expected to know what DOM means.

</comment><comment> c-smile Parallel processing demonstrates benefits only if you have physical cores to run code on them. If just one core is available for the app then parallel processing is a loss due to thread preemption overload.

Is there any real life examples of achieved speedup?

<comment><USER12> I have similar concerns. I'm all for using my machine to its fullest, but in large, applications like web browsing should be an additional thing I am doing on my computer, not something that thinks it can take the full computer.

Though, I have to admit I am also a little torn on this. Yes, browsing is typically done "during compile" or some other task. However, I have also begun doing most of that work remotely so that I can save battery on my laptop. To that end, it is now less of a concern on preserving cores for my tasks that actually need it.

<comment><USER30> If that's what you want to do, the you should 'nice' your web browser (or use whatever priority mechanism your environment had available). Artificially limiting performance is absolutely the wrong approach!

<comment><USER12> It isn't artificially limiting. If my browser didn't need all of my cores to perform, we wouldn't be having this discussion. :)

And I seriously question whether my browser needs this to perform well. I am not completely closed to the idea, but I am highly skeptical.

<comment><USER30> The fact that it's been done is some evidence that it's required. If it weren't, it's hard to imagine why limited resources would be wasted on it!

Almost every modern device running a browser has multiple cores, and that trend is almost certainly going to increase – so it definitely feels like allowing a core part of the web platform to expand across cores will be beneficial.

<comment><USER12> I challenge that. That it was done is as much evidence that it was doable as that it was required.

It is also a bloat race. Web pages are getting increasingly complicated. With very little benefit to end users. I'd wager a growing number of the cycles and network requests are going to tracking, nowdays. Not to mention the ui language doing more and more contortions to give us a page that could be much more succinctly described.

None of this is to say I want it stopped. I just have a feeling of concern that this is leading to an ever increasing march to faster and faster machines to do basic work.

</comment></comment></comment></comment></comment></comment><comment><USER31> It's such a shame Firefox (including the nightlies) kills my Mac (making most other applications hang/break), since the new versions are otherwise way better than Chrome.

Does anyone know what it is about Firefox that makes the rest of my system unable to spawn new processes?

<comment><USER6> That's weird. If you're not attached to your profile you could try resetting it (go to about:support) and see if that fixes it. Otherwise I'd file a bug.

<comment><USER32> "Refreshing" your Firefox profile from about:support is not as scary as it sounds. :) It creates a clean profile and imports your old profile's bookmarks, passwords, and browsing history. You just lose any settings tweaks and old add-ons you had. Your old profile directory is also backed up in case something goes wrong during the new profile import.</comment></comment></comment>


Will crime maps work? - <AUTHOR> http://news.bbc.co.uk/1/hi/magazine/7577659.stm <comment><USER2> I did a study of the utility of GIS (mapping) systems for a very large metropolitan police department years ago. My results:

\- GIS systems revealed nothing that officers and staff did not already know. It is difficult to impossible to know more about a location than an officer who treads the site every day.

\- Not a single application of GIS or mapping software was proposed that was not already done as well or better by some existing software. This despite my extensive querying of potential users, who included police staff at all levels in the department.

\- Mapping data was often incorrect: the officer on the beat knew that the data was wrong but most map users did not. About 20% of the data was in error. another 7% was formatted improperly and data cleanup (guessing the correct values) had to be done.

\- Map update was a haphazard process handled by multiple groups with little to no verification. In the end, aerial photographic proved superior to maps, although subject to the same update problems. Perhaps by flying UAV drones 24x7 police departments can maintain the views they want.

\- The only new application for the test systems was the use of maps for public speaking by the various chiefs of police. And citizens at those meetings were quick to point out missing or incorrect data in even those maps, leading even the chiefs to question the utility of the maps. Nobody hates being publicly pointed out for being wrong more than the chief of police.

\- The location of crimes is useful in allocating patrols. But that was already handled by systems that did not require a GIS/mapping system: allocation was done by beat/zipcode/street address.

In the end my study was buried, several million dollars was spent on a CAD system with the justification that it would be used to do real-time tracking of probationers wearing electronic boots. The system languished for years and at last check had been retired.</comment>


Patents show Google Fi was envisioned before the iPhone was released - <AUTHOR> http://www.networkworld.com/article/2914833/opensource-subnet/patents-show-google-fi-was-envisioned-before-the-iphone-was-released.html

<comment><USER2> If Google can prove its case to consumers and increase coverage and capacity by enlisting more mobile carriers, Google could outflank Verizon and AT&T with a larger, faster, and more reliable network. Google convinced the third and fourth largest mobile carriers in the U.S., Sprint and T-Mobile, to become partners in Google Fi, indicating that at least some carriers agree that this model is a promising business venture.</comment>


What are the Differences Between Java Platforms from Desktops to Wearables? - <AUTHOR> http://electronicdesign.com/embedded/what-are-differences-between-java-platforms-desktops-wearables <comment><USER2> Well, you could always wear one of these...And use standard Java, or even Scala: [https://goo.gl/2t5hBX](https://goo.gl/2t5hBX)

</comment><comment><USER3> Nothing irritates me more than having an unnecessary virtual machine slow down my code by a factor of 2 or more, hogging memory, and putting a huge headwind on startup times. It all just grates against my engineering soul. It's like riding a bicycle wearing platform shoes. And it's the #1 reason that I will never target Android for my code (also being forced to OOP).

It's not like there are thousands of architectures out there. There's x86 and ARM. Which language doesn't already do both, natively? We don't need this JVM anymore, especially in the era of LLVM, though I acknowledge that corporate intertia means it will never die. However please, corporate drones, do not try to push Java into IoT. Give us a break.

<comment><USER4> it grates against my engineering soul when so many of my fellow engineers forget that the x86's themselves are virtual machines, microcoded architectures that implement x86's. And that any OS's job upon booting is to present a new virtual machine to the user--which is why the same box can be booted as a Windows machine, a unix machine, or a Macintosh--and so to add some additional code to simultaneously present additional virtual machine abstractions is not bad engineering, it's the very stuff of engineering.

Abstractions are an efficient way to reduce the complexity of complex problems, and a virtual machine that allows the same code to run on top of different architectures can't be said to be "unnecessary".

<comment><USER3> There is no need for the JVM abstraction anymore, since the multiple architectures of the 90s such as Sun SPARC, SGI, Mips, PowerPC, X86, DEC Alpha, AS/400, have been pared back basically to two. Moreover, the more modern abstraction is the LLVM, which is targeted at the right level - compiler writers - without saddling the programmers and users with a bloated code translation layer that they must cart around everywhere they go. The JVM does nothing for a programmer, abstraction wise, that makes Java easier than, for example, Golang.

<comment><USER5> Well, Android also supports MIPS, so there's three.

Then there are the 64-bit variants, making six.

Then there are the various levels of ARM compatibility and extension instruction sets, like Thumb-1 and Thumb-2. Android supports two broad sets of 32-bit ARM platforms, so in total you have seven target ABIs [1].

All of which I'm sure LLVM makes completely transparent to the developer and ekes out the same level of performance as an on-device JIT. Note that the preceding sentence was sarcasm.

In reality, the VM mostly does not exist on Android beyond what's needed for a compatible runtime. The ART compiler emits machine code [2], or with the latest iteration, mostly machine code with stubs for JIT targets. Said code is in ELF binary format.

[1] [http://developer.android.com/ndk/guides/abis.html](http://developer.android.com/ndk/guides/abis.html)

[2] [https://source.android.com/devices/tech/dalvik/#features](https://source.android.com/devices/tech/dalvik/#features)

<comment><USER3> "ekes out", that's rich. After taxing your native performance at least 50%, it's now eeking out performance. Haha.

<comment><USER5> 50% over... C? That's quite respectable for a fully-managed OO language. Go can't even get close to that for the non-assembly-implemented parts of the standard lib.

The synthetic benchmarks on ART agree with you, BTW.

At that level of performance, your primary hits are I/O and UI, and that's not something a faster language target is going to improve. If you are writing tight loops for, say, scientific number-crunching, you should be writing assembly or doing GPGPU anyway. In the real world, with real applications, Java is not the bottleneck on Android; bad programmers and bad APIs are.

Swift is pretty cool though.

<comment><USER3> I meant to be somewhat flippant. "Sarcastic..." You have made some good points, tadfisher, especially with respect to the ARM architectures being fragmented, and the ART compiler. I take those points, and indeed, I do respect the JVM because it is an awesome piece of engineering to be giving up very little for the consistent target it provides. And let's be fair, Java and Scala are not slow languages. I have more of a philosophical problem with the JVM on the desktop and server ecosystems as these don't really need it anymore - arguably - and also, you have to admit that JVM languages still force you down an OO route which is not always very elegant. Even Clojure (apparently) needs to breathe in some ugly OO syntax if you want to touch the (admittedly huge) Java ecosystem. Look I use JVM tech: Cassandra in particular, am very impressed with it (I also code in Java to the Bloomberg API - less impressed with that). I don't love the JVM as you've gathered, for purist reasons and the fact that it takes me into a slightly dull corporate sort of culture, but I know that it has advantages. Anyway fun sparring with you. good points.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Quite an advertisement here. I love how many languages are the most popular. This says Java is. Many say Javascript is. Obviously C and C++ can claim this. Who cares?</comment>