Review: Copperhead OS - <AUTHOR> https://www.adventuresinoss.com/2017/01/18/review-copperhead-os/ <comment><USER2> I think there are some misconceptions in this thread (due to the title).

Personally I use CopperheadOS as my daily driver because it stays continually ahead of Google (and groups like AOKP, LineageOS etc) in terms of Android hardening. It goes well beyond just not having Google Play services.

See their details on their approach and design: [https://copperhead.co/android/docs/technical_overview](https://copperhead.co/android/docs/technical_overview)

They make continued patches to Android as part of a security and privacy first approach. Many of their patches get upstreamed by google months later (if at all) but CopperheadOS users get them right away.

Google has their engineering efforts focused mostly on new features and compatibility. They are happy to let firms like CopperheadOS be further ahead in security research and take their patches where it does not break compatibility.

It really depends on what you want to optimize for. Security/privacy or being able to run all the latest games and social media apps and the consequences that come with them.

<comment><USER3> Copperhead uses Grsecurity, and I used to use Grsecurity, when it was widely available, now that it's not and the developer has decided to act in hostile ways to the Linux community(1), it's made me rethink using his work and/or supporting him. Plenty of consultants make do fine without resorting to closing off their source code, and decide to act better with the community and/or companies.

(1) [https://www.theregister.co.uk/2017/12/22/grsecurity_defamati...](https://www.theregister.co.uk/2017/12/22/grsecurity_defamation_perens_dismissed/)

<comment><USER4> CopperheadOS doesn't use grsecurity anymore afaik. [https://twitter.com/CopperheadOS/status/933684025624993792](https://twitter.com/CopperheadOS/status/933684025624993792)

<comment><USER5> Actually, copperhead itself is sort of loosely following grsec's model, which is rather unfortunate. Their licences, where required will be GPL or compatible with upstream, but otherwise copperheadOS itself is not FOSS. I kind of get that it's hard to make money in such projects, but I really don't see how this strategy works for them, unless the goal is just to be bought out by someone.

</comment></comment></comment></comment><comment><USER6> Sometimes I am wondering what Google employees think when they read headlines like this one. I mean they probably have no problem giving the personal data to Google, but at the same time many of them are probably open source proponents and would support a world where the Google services would be entirely optional to Android.

A few days ago I was thinking about a new smartphone and because my main problem with my current android is the outdated kernel and driver setup, I was searching for smartphone with open source drivers. Wikipedia tells us since the start of the Smartphone era about 22 phones had open source drivers (with the exception of the proprietary baseband firmware):

[https://en.wikipedia.org/wiki/List_of_open- source_mobile_pho...](https://en.wikipedia.org/wiki/List_of_open- source_mobile_phones)

Doesn't look like something where you can select the hardware specifications you prefer. So I feel a little lost.

In general, I like Android but for my taste the Google services are too intrusive. Uploading my data before I had a chance to deactivate it is just unacceptable. Asking me every day to add photos to Maps sucks too. I can accept giving some of my information to Google to improve the product, but lately Google feels like the data mooch on my smartphone...

<comment><USER7> > Sometimes I am wondering what Google employees think when they read > headlines like this one.

Hello Google employee here! I suspect we don't all have the same opinion but I can share my own since you asked. Note that I work in Cloud so I work in an area far far away from this stuff and opinions are obviously my own.

Frankly the headline makes me a little bit sad because of course I would like to make things which people are happy about. On the other hand, I also realize that it's not easy to make a product which fits every single person's use case, and in this case I suspect most this level of privacy is overkill for most people, and it's wonderful that there is something for those who want that extra privacy and security.

I also think it's awesome these people contribute security patches to AOSP!

> I mean they probably have no problem giving the personal data to Google, but > at the same time many of them are probably open source proponents and would > support a world where the Google services would be entirely optional to > Android.

I like to think I'm a proponent of open source as I try to contribute but to be honest I don't actually think it really matters for Android to be independent of Google services because as far as I can tell, most people like Android with Google services?

Is there a reason that removing Google services would be better for the users? I can understand from a philosophical or ideological standpoint why it would be better but not really from a product point of view since I think I can confidently say 99% of Android users do not care or even know that it is open source..

<comment><USER8> You might be a Google employee, but you do not seem to be an Open source proponent. That's you prerogative, but you completely miss the point of the discussion if you ask why should users want to be independent from proprietary services. Sure, 99% don't want that and would click any colored and shiny button if it promises them a free Justin Bieber ringtone, but this is not the topic of the thread.

<comment><USER9> Cloud services are probably the thing that is the farthest away from being open-source non-proprietary software... and he is working on cloud services, so I can understand where he comes from...

<comment><USER7> While I understand what you were getting at, we actually do open source some of our software as well as contribute to an early open source project so I wouldn't say it's the FARTHEST away..

<comment><USER9> The software that you are open sourcing, is it software that allows you to access the back-end or are you actually releasing software that could allow someone else to start his own cloud service?

<comment><USER7> We have an incubator project for Kubernetes as well as software to access the backend.

I don't think our team is releasing software to let others start their own cloud service if I understand you correctly. Are you thinking of something like what GitLab does? If so our team isn't doing that sorry!

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> I love Copperhead OS on my Nexus 5X. Amazing battery life, great trustworthy apps and strong security. Frankly I think the project would be a lot more successful with lower prices. I'm willing to pay $50 per year for the OS, right now the price to get Copperhead OS installed on a Pixel phone is $400. That's just out of whack when taking into consideration the phone price (I paid around $180 for a used Nexus 5X a year ago) and the usual software prices. I guess I'm not the only one not buying a Pixel with Copperhead OS for that reason.

The Copperhead guys should get a copy of [http://www.dummies.com/education/economics/how-to- determine-...](http://www.dummies.com/education/economics/how-to-determine- the-ideal-price-with-price-elasticity-of-demand/)

<comment><USER11> You don't need to pay them for a phone. You can install it on the device yourself for free.

<comment><USER12> Builds are only available for free for Nexus devices, though -- if you want to install it on a Pixel, you have to either build from source or pay up.

<comment><USER11> This is true, but building from source isn't very hard. (I also don't care for the Pixel -- I have no desire to upgrade from my Nexus 6 and recommend it to others seeking a de-Googled phone.)

<comment><USER13> I had a nexus 6 for 2 years. Just replaced it last month with an iPhone 8+. My experience with the nexus was horrible and I will never buy another android phone. The quality of the hardware is just abysmal. I hope the iPhone proves itself better.

<comment><USER11> I have had only a single problem with my Nexus 6, as far as hardware goes: the USB port on the bottom sucks. On the other hand, there is an obviously superior way to charge the phone, since it supports Qi charging, which I have stations for at my office and home. I only need to use the port when flashing a new ROM (it works, but only in precise alignment).

You should provide some actual claims about the problems you had with the hardware rather than just complaining.

</comment></comment></comment></comment></comment></comment><comment><USER14> I'm overall quite pleased with my Copperhead phone, and very much appreciate getting actual OS updates.

I have one issue however that I thought I'd put out there from a customer service standpoint. If you buy a phone from them, you pay what seems to me like a nice premium (Pixel XL $1,269.00; though it's hard to find a good comparison point), and it comes with a service plan. Copperhead (as I understand) takes stock AOSP and (among other things) swaps out some of the default applications. Notably, the SMS application is something called Silence (silence.im).

Here's the issue. I've had a problem or two with Silence, and I contacted their customer support. They suggested trying other SMS apps to see if that solved my problem, which is in itself fine. However, at that point they closed the issue, because they claim that they're not responsible for 3rd party apps, even ones that they bundle and (I presume) update with system upgrades. The reason given is that they don't control the source for those, unlike the OS. I don't accept this at all. I paid a good premium (unless I'm mistaken) for the phone, I expect a _working phone_. This, these days, includes a functioning SMS client. How they go about making that happen is _their_ responsibility. They can work with me to find a suitable replacement, they can submit a pull request or a bug report, etc. But I argue they should consider the issue open until it's fixed or I decide it doesn't matter.

Anyway, not a big deal, I worked around it. Perhaps if I pressed enough they would have been okay with me returning the thing on these grounds, but it's nowhere near worth it. I just disagree with their philosophy on this issue. I understand it must be _really_ hard to deal with all this as such a small operation. But then they should put this point in big bold letters when you buy it, or something. ¯\\_(ツ)_/¯

</comment><comment><USER15> Sadly it has turned its open source license into a code available but non-free one.

That, coupled with the fact that Pixel devices are way more expensive than Nexus used to be limits its usefulness.

<comment><USER16> There's always LineageOS

<comment><AUTHOR> I use that but it's all Google based. Not sure if you can decouple it from Play Services without breaking everything.

<comment><USER17> LineageOS runs fine without Play Services. It's actually the default mode. It just limits your app choices. My needs are simple so I don't really mind, and I appreciate the improved battery life and speed.

It turns out many apps from the Play Store don't actually have a hard dependency on Play Services. Example: Slack works, except for notifications and (IIRC) receiving calls, which is good enough if you don't need to be reachable all the time.

<comment><USER18> "me too"

I run LineageOS v13 now (Galaxy Nexus), and before that Cyanogenmod back to v7 (maybe v6 not sure) and have never had Gapps installed, its been F-Droid all the way. I guess that means I can't appreciate the improved battery life or speed..

</comment></comment></comment></comment></comment><comment><USER19> > do think it will happen, however. The use case involves corporations, > especially those involved in privacy sensitive fields such as health care. > Wouldn't it be cool to have a locked down "business" VM that is separate > from a "personal" VM with your Facebook, games and private stuff on it.

This already exists for businesses with Samsung Knox / Android for Business. No it's not a full OS but it fits all of their needs and separates data. Having one OS in a "vm" on a phone sounds horrible UX wise.

<comment><USER20> Sometimes I don't understand all the hatred toward Google having our data on their servers. Most alternative solutions offer fragmented services (as opposed to the all-in-one experience I get with Google) and are too cumbersome to setup. Yes, I know data is sort of power these days. But before bashing at Google/Apple/Microsoft... and banning their services, people should ask themselves: "What sacrifices are they making and for what?" I mean, I would totally feel convenient when my contacts are synced on my devices and I get a unified experience. Google knowing about my contacts is just the price I pay to get that service and honestly, from my experience, it's better for Google to have my data because they keep adjusting the service I get in return.

<comment><USER21> It's the competing incentives of a company that provides data services to end- user customers and a company that mines as much information about people to sell advertising to companies.

Without strong controls about what they _can_ do, we are always at the whim of what they _might_ do. Google feels like a fairly bipolar company from the outside, because they present two faces depending on who they are dealing with, end-users or companies looking to advertise.

As an end-user, Google knowing all the little details about everything I do and many places I go (because analytics JS, G+ button inclusion, etc) is disconcerting. For a company looking to advertise, them _not_ doing this all of a sudden would be disconcerting, and they would probably look to some other company that _is_ doing so. It isn't just Google. Facebook knows a startlingly large amount about you too.

I'm increasingly convinced this is one of those places where the market is failing us because the negative externalities are mostly hidden. Those are good places for targeted regulation. I wouldn't be entirely appeased, but a law about the ability to review all information collected about you from a company and strong controls about the access, sale and use of this information would go a long way towards making me less worried about Google (or whoever) changing quite a bit in the next decade and selling off the information.[1]

Because think about it, how far away are Google, Facebook and the umpteen other ad agencies with complex profiles of you from usurping the credit bureaus?

1: Maybe what we need is an interesting billionaire to buy a lot of personal information on all the U.S. politicians from one of the less public agencies and publish it. I'm sure we would get a law passed in record time.

<comment><USER22> What happens when someone steals your identity/credentials and gets to see all of that information Google, FB, etc have about you?

<comment><USER21> It sucks. Hopefully, they are held accountable.

But do you honestly see an outcome where information is not collected at all? Because I don't, so as I see it we need to put the correct incentives in place to not only make it less likely but to handle when it inevitably does.

Maybe a fine up to $X per account leaked with a soft cap (but absolutely no less than $1 or $2 per account) is levied. Losing 1 million accounts would hurt, so companies would make real decisions about what and when to collect data for liability reasons, and protect it better in many cases when they did.

</comment></comment></comment></comment></comment><comment><USER23> YalpStore [1,2] makes getting Play Store apps a lot less painful than going through the process of extracting an APK from one phone and side loading it onto another. There are some that simply won't / don't work without Google Play Services, but most do. This made switching to Copperhead OS much easier for me.

[1] [https://github.com/yeriomin/YalpStore](https://github.com/yeriomin/YalpStore)

[2] [https://f-droid.org/packages/com.github.yeriomin.yalpstore/](https://f-droid.org/packages/com.github.yeriomin.yalpstore/)

<comment><USER24> And if something doesn't work without Google Play Services, it might work with microG instead.

</comment></comment><comment><USER25> Reviewer touts "security focused" OS, promptly disables "trusted sources" check for installed software.

Turn it back on, sure, until the next time you want an APK that's not listed in F-Droid. Seems like a bad idea. How about writing to your favorite app developers and asking them to list on F-Droid instead of sideloading?

<comment><USER26> Not only this, he won't receive security updates for his apps any more.

Thank you, I'm staying with default Android and continuing to read what I am prompted for. He could've just opted out of most data collection, no, he had to skip it without even reading it like a 60 year old office worker at a insurance company.

<comment><USER27> Some of us using Copperhead OS never enable unknown sources. Yes, the author is a doofus for the reasons you specified, but sticking with "default Android" (whatever that is.. you mean AOSP?) is arguably worse than running Copperhead OS.

</comment></comment></comment><comment><USER28> The article mentions launchers; all the launchers in the app store seem sketchy. Does anyone know of a good Open Source launcher, maybe a version of the AOSP launcher compiled for current Android? I'd love to have something that reclaims the pile of space (thumb-reachable space even) devoted to the Google search bar that now stays on the bottom of the main screen all the time.

<comment><USER29> KISS. I love it. It's a input bar. You get the history when you click on it. It's common to find whatever you want to do here. You also get favorite apps bar. You can search contacts, wikipedia, shortcuts (awesome with http post shortcuts or chrome webpages shortcuts). Contacts have a sms/call button on the side and they also appear on the history list. I use it on all my phones. It's lightweight, open source and half my friends don't know how to use my phone.

[https://f-droid.org/en/packages/fr.neamar.kiss/](https://f-droid.org/en/packages/fr.neamar.kiss/)

<comment><USER28> Tried that one, but I do actually want widgets and a home screen.

<comment><USER29> It has beta support for widgets now, if you still looking.

</comment></comment></comment></comment><comment><USER30> It's kind of hilarious that copperhead OS is considered de-googled when all the hw support and firmware updates still rely on google. After google drops hw support for a device copperhead discontinues support.

</comment><comment><USER31> Re: having a switchable mobile hypervisor I have some free/unencumbered IP for you courtesy my employer Google in case anyone would like to implement.

[http://www.tdcommons.org/dpubs_series/500/](http://www.tdcommons.org/dpubs_series/500/)

</comment><comment><USER32> > CopperheadOS currently supports the Nexus 5X and Nexus 6P as a free > offering. Pixel and Pixel XL support is available as a product.

They show a Nexus 5 on the landing page for CopperheadOS. Why not show a supported device?

</comment><comment><USER33> I've used copperhead OS for months.. and believe me when I went back to my 5x that had it and had to attempt to break into my own phone because I forgot the password.. that thing is secure! It does suck to side-load somethings, but the worst part is a lot of things use google play services more than you think.. which is always weird to me. If anyone has any questions let me know, but I enjoyed it. Without google battery life is pretty awesome.

</comment><comment><USER34> Hardening the OS is not enough. As the infamous Intel ME taught us in a different context, unless one uses only 100% open hardware, security cannot be guaranteed by software. We need open (documented, reproducible) hardware rather than alternative OSes; until that day security on current platforms is to be considered a myth.

</comment><comment><USER35> I use CopperheadOS on my Nexus 5X and I am extremely happy with it. My job is android development and I have some personal paid apps on Google play and one Foss app on F-Droid. Access clipboard in the background and record audio in the background have been lately added to the security features available on CopperheadOS, and I can't imagine now using my phone without COS hardened implementation. I use FDroid for all the apps I need and yalp for a couple of other apps not available on FDroid. The majority of apps now depends on Google play services and that is flattering and disappointing: all those GPS APIs are very appealing to developers and teams because makes things easier and all but IMHO using all those services is contributing to data mining and I don't think it is fair.

</comment><comment><USER36> I may have to go this or a similar route, to go back to using WiFi and Bluetooth on my ~5.5 month old Motorola G5+ [1].

I mean, come on! Ship a patch/update, already!

1) That replaced a bootlooped ~1.4 year old Nexus 5X. Wasn't going to spend big bucks after that burn and while waiting for the Pixel 2 or Samsung whatever, or Apple's new line, to drop in a month or two.

And now, with all the crap going on with all those various new models...

I've griped about this, before, but damn it, they deserve the criticism. And the only time they make positive changes seems to be when the public image and pressure get bad enough. (And things get worse again, as soon as that pressure relents -- or gets distracted.)

</comment><comment><USER37> A hypervisor on a mobile OS you say?

[https://techspecs.blog/blog/2017/3/15/fuchsias- hypervisor](https://techspecs.blog/blog/2017/3/15/fuchsias-hypervisor)

</comment><comment><USER38> I don't think it would be that hard to have two separate CPU's on a phone, then use a hardware switch to wake one OS up and put the other to sleep.

</comment><comment><USER23> Copperhead OS is a great project and seems to be short on funding (based on threads on Twitter and Reddit). If you'd like to support it, donations can be made at [https://copperhead.co/android/donate](https://copperhead.co/android/donate).

(I'm not affiliated with the project, I just use it as my primary phone OS.)

</comment><comment><USER39> Ain't here maps a good alternative to google maps? I use both of them 50/50 and I love the offline capabilities of here maps

</comment><comment><USER40> Dated 18 January 2017, almost a year ago (but not quite long enough to add it to the title) so some info might be out of date.

</comment><comment><USER41> In the post the author complains about the lack of a VM inside current phones to run Google instances in it. I believe BB10 had that feat to overcome the limits of its native app ecosystem. My old Passport nowadays could almost reach the objectives of the author. Too bad due to licensing the Android kernel is stuck on 4.3

</comment><comment><USER42> Any idea why all their phones are out of stock? (Are there more on the way???)

</comment><comment><USER43> Anyway to install this on an Amazon Fire tablet?

<comment><USER23> Unfortunately, it's currently only supported on a handful of devices [1], and that's not among them. Supposedly (based on some threads on /r/copperheados), Project Treble may improve this situation, but I haven't seen any new details on that front recently.

[1] [https://copperhead.co/android/docs/install#supported- devices](https://copperhead.co/android/docs/install#supported-devices)

</comment></comment><comment><USER44> why that Name in particular did they not know its provenance in English :-) it was what a proslavery northerner was called aka Traitors.

<comment><USER45> No one uses that definition anymore.

<comment><USER46> That's never stopped anyone from taking offense if they want to.

</comment></comment></comment><comment><USER47> its very easy to just not install google play services on any non-stock rom. there doesn't seem to be much that is 'security-focused' about copperhead besides that decision.... i would definitely recommend lineage over this, as it has a much larger development community & works on a much wider range of devices</comment>


Sorry, Adults, No New Neurons for Your Aging Brains - <AUTHOR> http://text.npr.org/s.php?sId=591305604 <comment><USER2> Different write-up, same topic: [https://news.ycombinator.com/item?id=16541444](https://news.ycombinator.com/item?id=16541444)

</comment><comment><USER3> Somewhat related: I think this title should not be read as an hypothetical confirmation of the usual layman's asumption that 'kids learns better and faster that adults'.

Which is a misconception I'm often confronted with and irritates me quite a bit, especially when it comes in its extreme flavour of 'I just can't learn this new field/langage/tool/technique because I'm not a kid anymore'.

And I think you've already guessed what's the reaction when I try to explain in simple terms brain's plasticity and the fact that neural pathways can be made/upgraded threw sheer willforce. Something along 'well, don't try to teach me (about learning or whatever), I've already said that I can't learn anymore!'.

<comment><USER4> "kids learns better and faster that adults'.

Which is a misconception I'm often confronted with and irritates me quite a bit, "

Why is that a misconception?

The example you give are from people saying can't learn at all, which is something different.

<comment><USER3> Actually I've put said example in a precise context:

      especially *when it comes in its extreme flavour* of 'I just can't learn this new field/langage/tool/technique because I'm not a kid anymore'.

As for the misconception itself: 'kids learns better and faster that adults' can only be false, because if it was true then _every kid_ would learn _everything_ better/faster than _any_ adult. Can a random kid learns cutting edge brain surgery techniques faster than every living adult? Nope, and here goes our misconception.

Now I get what those persons are really trying to say: they mean 'When I was young I was required to learn, but now I'm grown you won't get me back to school'. Which is still irritating to me (in the context).

<comment><USER4> "Can a random kid learns cutting edge brain surgery techniques faster than every living adult"

If both would have the same level of knowledge, then yes, the random child would for sure learn the new techniques faster than the random adult.

"'kids learns better and faster that adults' can only be false, because if it was true then every kid would learn everything better/faster than any adult"

You simply mix up things here to support your basic, wrong claim. Children do learn faster than adults. Countless study's support that. But nobody claimed, like you wrongly did, that it is meant, that they can learn every skill faster, when skills have prerequisites, which they are missing, but the slower learning adult already have.

And that there are obviously retards as well, sure thing. But again, nobody ever claimed that every child learns faster than every adult. "in general" is the catchphrase.

Learned something?

edit: to put away a bit of snarkynes. I do support your intentions and very much agree, that as long as we are alive we can and should learn new things. Stopping to learn equals death for me. So people who use that "can't learn as I am no child anymore" I pity their lazyness. But it still doesn't change the fact that children learn fast, because they indeed have to learn EVERYTHING and we already know quite a bit about the world ... so they are "optimized" to learn, while we are more "optimized" to using our knowledge and skills ...

<comment><USER3> Indeed, your edit is way more civil ;) Let's agree on not agreeing then (and sorry, no, I did not learn anything).

<comment><USER3> And please allow me to refer to real and actual scientific studies.

The critical period for language acquisition

Snow, C. and Hoefnagel-Hoehle, M. (1982) - [http://grammar.ucsd.edu/courses/00-OLD/lign179/snow.hh.82.pd...](http://grammar.ucsd.edu/courses/00-OLD/lign179/snow.hh.82.pdf)

On the precise point of learning a L2 language, teenagers and adults learn faster and better than children: "The crucial findings of relevance for the CPH were that the 3- to 5-year olds scored consistently worse than the older groups on all the tests and that the 12- to 15-year-olds showed the most rapid acquisition of all the skills tested. These findings are basis for rejecting the hypothesis that the period 2 to 12 years constitutes an optimal time for language acquisition."

And a second one:

Maturational Constraints on Language Learning

Newport, 1990 - [http://onlinelibrary.wiley.com/doi/10.1207/s15516709cog1401_...](http://onlinelibrary.wiley.com/doi/10.1207/s15516709cog1401_2/abstract)

Different rates of L2 may reflect psychological and social factors that favor child learners, instead of mere brain chemistry: "The evidence from several studies of both first and second language acquisition suggests that normal language learning occurs only when exposure to the language begins early in life."

<comment><USER4> Ok, I will look into it, they sound interesting, but I lack the time right now. And the "learned anything" ... was kind of a joke. So you didn't learned anything ... see, you are too old ;)

Edit: but after a first glance:

\- well, besides, that those study's are old, they are also controversy and explicitly state that. And they look to me like the point I raised, that they maybe didn't account for prior knowledge in their findings. But I will look more into it.

<comment><USER3> Well, then yes, please, be my guest and look into it.

And kindly point to me any study (may I say the _countless_ studies) that can support your claim: 'Children do learn faster than adults. Countless study's support that.'.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> Marijuana promotes neurogenesis in the adult hippocampus [1].

[https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1253627/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1253627/)

<comment><USER6> The old hypothesis was that many things — famously anti-depressants and excercise — promote neurogenesis. This study is refuting that whole bank of research, which was based on indirect observations.

</comment></comment><comment><USER7> I think that the number of neurons is not the single parameter to take in consideration. At birth the brain is a kind of "soup" made of disconnected neurons - except a small kernel structured during the pre-natal life for basic managementof organs. Then repeated external stimuli create connections between neurons, stronger and more complex, leading to a functional brain with memory, "computing" capacities, redundancy, associative capacity. An old brain loses neurons, more and more, but thanks to brain's plasticity and permanent stimuli, it can keep most of its capacities for a long time. The problem is that the small hippocampus is a bottleneck. When it begins to be buried below beta-amiloid and tau-protein, the rest of the brain is still functional but no more reachable. It's the end.

It's how I see those things. What do you think of that?

</comment><comment><USER8> "Thats okay kids, enjoy the process of making new ones, while you still can."

;)

</comment><comment><USER9> "cells whose functions aren't yet fully defined", so we have 'unprogrammed' neurons maybe, some spare capacity, created, defined but no value, good to know it's a static language in there :)

</comment><comment><USER10> I dunno. I feel smarter and sharper at 40 than I ever did in my 20s. Something else happening.</comment>


Topic mining with LDA and Kmeans and interactive clustering in Python - <AUTHOR> http://ahmedbesbes.com/how-to-mine-newsfeed-data-and-extract-interactive-insights-in-python.html <comment><USER2> Hey Ahmed, nice write up!

One thought I had was that I would be careful using KMeans on tSNE transformed data. From my understanding, while tSNE preserves local relationships between data point, it (heavily) distorts long-distance relationships. What this means is that (if I get this right), you have almost arbitrary clustering results if your k is chosen such that it is not equal to the number of local clusters (a thing you don't know in advance). So clustering on distances between data points in tSNE coordinates seems to be a risky way to draw conclusions. I am not saying this is wrong, but if what I am saying is correct (please point out if I got something wrong), then your analysis may perhaps work better if you did KMeans on say the final 5-dimensional PCA space or something like that, and leave tsne to visualize the data (and perhaps label the data points by the clustering on PCAs?). Do you agree / does that make sense?

<comment><USER3> He fits and transforms Kmeans on the output of TfIdfVectorizer and not tSNE. tSNE is only used for 2D visualisation.

kmeans = kmeans_model.fit(vz)

kmeans_clusters = kmeans.predict(vz)

<comment><USER2> You're right. In that case, I would worry about the high dimensionality of that array. Does MiniBatchKMeans do some internal dimensionality reduction?

</comment></comment></comment><comment><USER4> I'm still waiting to see interesting topic modeling results on non-news data. The news has this tendency to follow a relatively low amount of topics, making it easy to discover meaningful word distributions, but reviews, messages, and comments written by "normal humans" almost never seem to.

<comment><USER5> I have done countless LDA on tweets and it worked great.

here is an example of taking tweets that have 'diabetes' and correlating topics with counties. [https://www.linkedin.com/in/karl- dailey-02557b65/treasury/po...](https://www.linkedin.com/in/karl- dailey-02557b65/treasury/position:755225215/?entityUrn=urn%3Ali%3Afs_treasuryMedia%3A\(ACoAAA3JzV0BT9zF9Db_PxdLfE28gQQfK_PzmhM%2C1486424963566\))

The original topics were actually better, but I was asked to adjust the language to wipe out common language across all tweets. You can still see interesting things going on though. North East: Charity, Hospitals, Research. South: Koolaid, sweat tea. etc.

I had also done topic modeling on customer surveys for Comcast (I cant show them), but the topics identified 3 key features that lead to low customer satisfaction.

I have also used LDA on grocery purchases (for mere fun), and it worked out really great as well.

<comment><USER4> But what real insights do the topics give? The only LDA results I've seen are "fairly obvious" or "not understandable". Seeing a "car, road, light, drive, trip, ..." topic is not insightful - this is a topic that is obvious to most humans.

A more interesting topic would be one that is understandable but was not obvious, even to the people intimately involved in data's subject matter. These are harder to discover, but they do exist - and I have never seen LDA surface them.

<comment><USER5> I see quantifiable and visualizible insights. Its also good for generating features, and I can also create interaction features with important n-grams.

If it cant give you what you are looking for, maybe you are asking a fish to climb a tree

</comment></comment></comment></comment><comment><USER6> Good stuff ... if you're interested in this stuff, you might be interested in Richard Socher's Stanford NLP class - [http://cs224d.stanford.edu/](http://cs224d.stanford.edu/)

I have a dumb question about Bokeh ... if I use RStudio I can create some markdown, export to PDF, send around to team/clients. Typically I can't do anything interactive without hosting on a shiny server or referencing some server-side magic.

If I use Bokeh, is it as simple as creating a Jupyter notebook, saving to HTML, and then anyone can see all the D3 magic? Or are there any drawbacks like file size, compatibility, browsers not letting you open due to security or whatnot? If any pointers, tutorials, examples anyone has would love to hear them, look me up if it's not deemed on-topic.

<comment><USER7> If you only need basic filtering and brushing for interactivity there's a new library called crosstalk that can do that. Some htmlwidgets like Plotly also support some interactivity without the need for a server.

[http://rstudio.github.io/crosstalk/](http://rstudio.github.io/crosstalk/)

Edit: Note that you can knit rMarkdown to HTML as well, which is what enables most of this stuff.

<comment><USER6> hmmh, thanks, might check that one out.

for next project maybe I'll try both ways, with ggplot and rmarkdown to HTML, and with Bokeh in python.

The ggplot will just knit to PNGs, would be interesting if ggplot could output D3 with intelligent rollovers, maybe eventually some scriptable animations.

One could use ggplotly but I don't want to post anything to, or host anything on a server, has to work 100% offline.

<comment><USER7> The R version of plotly has been fully offline ever since they open sourced it. Alternatively you could also try ggvis, but it's not as polished as ggplot yet.

<comment><USER6> thank you! I did not know this, having started with the online version...will give it a shot.</comment></comment></comment></comment></comment>


Choosing Ember over React in 2016 - <AUTHOR> https://blog.instant2fa.com/choosing-ember-over-react-in-2016-41a2e7fd341#.7vyetlgrb <comment><USER2> Ember is a really good choice for running a feature-rich web app where you want to focus on business and features instead of solving issues about tooling and deciding on which pieces to bring into the bundle to make everything work. This is especially crucial for small teams on a budget. Also, upgrading to newer versions is incredibly easy, deprecations paths are very verbose and clear. I've been working in Ember for three years, and a few times in between I jumped into React. I adore React's ideas, and grasping its concepts made me a better Ember developer. It's just React tooling that's horrible, but I hear there are great improvements in that area.

<comment><USER3> I've been keeping an eye out for a project on which to use Ember. Unfortunately, I've been in that exact mode for literally years. I already trust that it's solid stuff from having learned a load about software development from Yehuda back in the jQuery days.

Three or four times I've been about to pull the trigger and every time the things that's stopped me is that when I go to look for a sample project to have a read of an actual app using it in anger it seems impossible to find one that meets my criteria: 1. Uses current version of Ember. 2. Uses idiomatic ember. 3. Big enough to not be a toy, ember-data, being the recommended way of doing things, I want to see how it's formatted.

Every time a look it seems like everyone is saying something along the lines of "Here's a good example project except it's N versions old." or "… except it doesn't use insert-feature-that-docs-heavily-recommend-using because that wasn't around when this project started" or "… it uses local storage in place of a database".

I've read the documentation end to end multiple times over the years. I'm not sure why that's not enough for me. I just assume I'll run into trouble and I'd like to see an application with routing, component composition, backend calls, and understand a bit about the recommended backend before diving in.

<comment><USER4> Here are a few open source Ember applications that you might be interested in.

Ghost admin: [https://github.com/TryGhost/Ghost- Admin](https://github.com/TryGhost/Ghost-Admin)

Hospital Run: [https://github.com/HospitalRun/hospitalrun- frontend](https://github.com/HospitalRun/hospitalrun-frontend)

Hummingbird: [https://github.com/hummingbird-me/hummingbird- client](https://github.com/hummingbird-me/hummingbird-client)

<comment><AUTHOR> It helped a lot to see it in action. I got lot of help from the Ember Global Meetup[1] and live coding with buddies at the Ember Community Slack group.

[1]: [https://www.embermeetup.com/videos](https://www.embermeetup.com/videos)

<comment><USER5> @jeanlucas what's the link to that slack group?

</comment></comment></comment></comment></comment><comment><USER6> I have a pretty fair amount of experience with both Ember and React (along with Ember Data, Redux, Redux-Saga, React Native, webpack, etc etc).

My opinion, for whatever it is worth, is that Ember might be good for smaller companies and smaller codebases. The cognitive overhead of using Ember is massive for me and several people on my team. I find that I have to store the contents of many files in my head at once to understand how a given component is being rendered and how it is receiving its data it requires. Your view code is implicitly coupled to promises all over the place which can really bite you in the ass. Mutable APIs abound and it is an extremely unpredictable and volatile way to develop web applications at our scale.

My personal, largely unfounded belief (based both on intuition and anger from dealing with Ember) is that the supposed gains from Ember's severe convention- over-configuration ideology don't pay off nearly as much as is advertised.

I never want to work on an Ember project ever again.

<comment><USER7> > at our scale.

Care to elaborate what that scale is? We're using ember for a new app that expects very large traffic volumes on continual basis with realtime components etc... I've worked with ember for the past few years and opted to use it but always interested in hearing other viewpoints esp for "high scale"

<comment><USER8> Parent may not be talking about scale in terms of Traffic but big project code-base where you and team have a hard time keeping something in head and how something is being rendered.

<comment><USER6> yep, this

</comment></comment></comment></comment><comment><USER9> Great write up.

It sounds like an interesting but probably relatively common situation these - relatively experienced developers, but inexperienced where it comes to the front end, who are accustomed to working in a non-javascript language. In this case, sounds like it's python.

Sounds like their senior developers, who previously worked in Python, will now be doing at least 50% of their work in javascript.

If you have to do this, it sounds from this article that Ember is a good way to go. On a related note: I'm so bummed that this is the trend in languages. Just so bummed. Python and Ruby are really nice languages. To have to switch from that to Javascript feels like a big step back in developer happiness.

<comment><USER10> There's a hope in webassembly

<comment><USER11> That'll probably never catch on. Front end dev already have 10 frameworks and 5 browsers to worry about. Let's not add 10 more languages for a total of 500 different combinations.

<comment><USER12> 500 combinations of what? Other platforms too have n languages and n frameworks and so on. We'll be fine.

I'm quite sure it will catch on with Apple, Google, Mozilla and Microsoft working on it.

I'm intrigued by the server side Swift frameworks coming out right now. If they could replace JS on the server _and_ browser that could be interesting.

</comment></comment></comment></comment><comment><USER13> I don't think I have a strong opinion about Ember, though you can take the React rendering model away from me when you pry it out of my cold dead hands. But I think I object a little bit to the way they complexify the React stack:

* ES6

* React

* redux and redux-saga

* react-router

* fetch

* lodash

* webpack

* post-css

* karma/mocha/sinon/chai

Of all of these things, to build a decent React app, you only need React.

It seems chintzy to bill React for the cost of webpack/browserify. I understand why someone would: it's the worst part about working in modern Javascript environments. But it's a build tool, not a library.

You Don't Need Redux. Most applications that use redux (or any other Flux library) probably shouldn't. Even redux's author has been taking pains to point out how overused redux is.

You _definitely_ don't need react-router, which is an inner-platform disaster.

Billing React for fetch and lodash also feels chintzy (especially when you try to add a surcharge for switching from underscore to lodash).

I'm also not clear on how ES6 is somehow React's problem. Ember developers use ES6 too. Because ES6 is better than ES5.

I'm not saying the Clef team is wrong. If they're happy with Ember, God bless them! I'm just wary of tech advocacy articles that try to make these kinds of stack complexity comparison arguments; I usually find them to be pretty dubious.

<comment><USER14> I think this is a fair criticism and I agree that I might have used this comparison in a simplified way to make my point, but I think the primary thesis still holds: when building a React app, you necessarily need to make a very large number of choices that you don't need to make when building Ember.

This isn't because React is bad, it's because React is just the view layer! If we look at it this way, we can re-examine that list as:

* language

* view

* data modeling

* routing

* network connections

* functional utilities

* build

* styling

* testing

And, with React, when you have just a view layer, if you want to build an advanced application, you likely need to add on a bunch of other layers to get everything working. I hear you about being able to "just use React", but I also think that's a an oversimplification the other way: how many applications on the web today are built with only the view layer and none of the others?

After evaluating all the decisions we made in the past when building a React app, we decide to trust someone else to make them for us :)

p.s. the original title was "Choosing Ember of the React ecosystem in 2016" but I ended up shortening it :)

<comment><USER13> Ok, and fair enough, but a simple question as a response: am I required to buy into the idea that I need a library to cover all of these cases?

Any attribute of constructing an application you break out, people will build libraries for. But are they necessary? In some of the cases we're talking about --- routing and network connections, for instance --- the answer seems to be a clear "no".

<comment><USER14> Ha — I'd never ask you to buy into that idea!

I think this article could easily have been titled "Choosing Ember over building our web framework"

</comment></comment></comment></comment><comment><AUTHOR> Seriously, Ember philosophy of slowly aggregating what's good in web dev and even adopting early some things (like components, and cli) makes me feel very good using it in projects with teams. For solo projects I like to try what is new.

</comment><comment><USER15> I'm a big fan of React, but I agree styling is a mess.

CSS in JS has many limitations and virtually every alternative adds either another library or some other convention/configuration overhead.

Other frameworks struggle with this as well but it feels like React really shrugs off styling as the community's problem and subsequently there's a hodgepodge of solutions that work in this or that scenario but no gold standard.

<comment><USER16> I've been doing SPA's in react for a while and have had 0 problems whatsoever with styling. As long as you stick to good standards and naming conventions and use SASS or Stylus or something to keep things organized.

What tends to give people so much trouble with styling?

<comment><USER15> It's not a huge issue, but that you have to use some third party library for styling in a view framework just seems inadequate.

Other comparable libraries include styling into their philosophy, but React is irritatingly unopinionated about it.

<comment><USER16> Isn't that part of the React mantra? Everything is completely unopinionated except for rendering HTML based on data? Like it makes no opinion on how you should do state or HTTP requests as well as no opinion for styling, which is something I love since it avoids duplicating code or incompatibilities with standalone libraries.

</comment></comment></comment></comment><comment><USER14> Hey everyone - OP here! This was a really fun blog post to write and I think I learned a bunch in the process: if you have any questions, would be happy to answer!

<comment><USER17> FTA: >When evaluating Ember, We were excited that with ember-data there were established patterns for how to do things — even if some of those patterns felt a little outdated.

Could you elaborate a bit on how the ember-data patterns felt outdated?

<comment><USER14> Absolutely! I would say that with Ember + ember-data, the framework conforms to a pattern where data is represented as models on the frontend, which can be updated and persisted to the server. These updates happen through a CRUD / REST API (in our case we conform to JSONAPI) and are generally triggered in a controller (or a route that contains logic and acts similar to a controller in a traditional MVC framework).

In the React ecosystem, I think there's been a pretty stark departure from that general pattern with things like redux and GraphQL, so while we love it, compared to what we'd been using , it felt a little behind.

Does that make sense?

<comment><USER17> Yes it does, thanks!

</comment></comment></comment></comment><comment><USER18> Thanks for an interesting writeup. Something I'm curious about for devs who've used ember on projects that had a maintenance period of 1-2 years: how do you feel about it as your app grows and changes over time?

With most kitchen-sink or CoC frameworks, this is kind of the achilles' heel. patterns get codified because they're easy and "good enough" but they DO NOT age well. How does Ember deal with this? Also, what about the ecosystem? Is Ember work driven almost entirely by the core framework, or is there a plugin ecosystem that attempts to have an answer for every problem? (yes Rails, I'm looking at you.)

<comment><USER19> I started on Ember around the 1.12 timeframe and left that job about a month ago and we were on 2.6. There were a couple hiccups going to 2.x but nothing more extreme than I've experienced with any other major version update. The Ember team also does a stellar job providing useful deprecation notices and not breaking any minor version update, i.e. if you're on 2.1, you can upgrade directly to 2.6 and be reasonably confident it'll still work. Your console might get flooded with deprecation warnings, but they helpfully link to the release docs for the change.

The only thing I'm not a huge fan of is their JSON-API as a default data adapter, since there's a _ton_ of immature JSON-API server-side libraries with varying levels of spec compliance and completeness. If you're backed by Rails, you're in good shape. If you're backed by Java, you're fairly fucked.

<comment><USER20> Some of the engineers in my office developed [http://elide.io/](http://elide.io/) which Is an actively developed Server side Java Json-api library.

</comment></comment></comment><comment><USER21> I just took a look at the Instant 2FA app.

What exactly about this thing warrants the use of a behemoth of a framework like Ember?

The entire app looks like an optimization of a poor experience in another web service. I'll conserve my cynicism for their actual app, which could have been implemented without even the need of a framework.

What is exactly complicated about a few different screens? I fail to see the need for even a web app here.

Also, I'm not sure I understand any of their arguments. Does it really take days to setup a test harness in anything?

Also, the bit about progressive enhancement -- are we really talking about this still? When using a single page application framework? For an app that does two factor auth. I'd also be concerned about the security surface area for an app like this that pulls in a dependency like Ember, on a third party site during the login/auth experience. It's bad enough that we have third parties pulling in react to display some simple forms and buttons.

<comment><USER22> I also find it annoying that it seems people have transitioned from progressive enhancement meaning 'detect if we can use JS' to 'detect which features of JS to use' to 'detect how much processing power we can abuse without the user noticing'.

As someone who really enjoys his <0.3s page loads (that is fully fetched & rendered, less when from cache) even on mobile it feels annoying to not have a 'middleground'.

For example my current project, which is basically a small website where people can upload artwork, does not need to be a SPA. However, I'd like to integrate some interactivity to make browsing easier. Like a 'browser' view when you click a picture, or in place reloads (so the CSS doesn't need to be reloaded, nor perhaps the JS. However there doesn't seem to be a library for that to my knowledge. All I know are either on the jQuery level where you have small seperated pieces, or the React/Ember/Angular level where you have to write all or nothing in that language.

I wonder if it is even possible to have an 'augmenter' library that just makes existing HTML better (Perhaps with some hints in the 'data-' attributes), or maybe my google-fu is just bad.

<comment><USER22> As a followup I don't seem to be the only one thinking like this [1]. [2] comes close to what I'd like, but the last update is from 2012 and the author doesn't seem to have done a lot lately.

[1]: [https://allinthehead.com/retro/367/why-is-progressive- enhanc...](https://allinthehead.com/retro/367/why-is-progressive-enhancement- so-unpopular) [2]: [https://github.com/jamesallardice/Progressive.js](https://github.com/jamesallardice/Progressive.js)

</comment></comment></comment><comment><USER23> I'm a big fan of Ember, although a word of warning: To get the most out of Ember you should follow the Ember way of doing things, we found our selfs wrestling with Ember data, and APIs that don't follow standard responses (this is to be expected mind)

Still a great framework for large web apps.

<comment><USER24> > APIs that don't follow standard responses

Interesting. In my experience the clean separation of layers in Ember-Data (network, serialization, models) make it quite suited to non-standard APIs. I found writing a custom (de-)serializer for a non-standard API to be relatively easy.

Care to elaborate on what were your issues precisely?

<comment><USER25> Not OP, but it's possible to not write any ember-data code if a server implements json-api...

Otherwise, you have to write the same code that you have to write in other places... except that w/ Ember Data there are core patterns and its easy to add tests.

Writing Ember against an API that speaks json-api is a magical experience :-D

<comment><USER26> So happy to hear JSON API is working that well for you :)

</comment></comment></comment></comment><comment><USER27> I cut my teeth on Ember at a marketing company in 2013, and actually found my current job through acquaintances made by attending a weeklong Ember training session in Boston (led by yehuda and tom). It had been a great fit for me at the marketing company because the apps I was developing were more restful oriented crud apps. apps with a lot of routes that were more or less their own thing (not too much shared state).

The company that I joined was using Ember, but their app was more of an analytic dashboard and it didn't really have more than a handful of routes. the amount of views and logic and state that lived on each route / controller was insane. Also, between the few routes you really needed to share state and things got very messy. I'm still with the company today, and the app's routing is still controlled by ember, but we have switched entirely to react + redux and are a lot closer to being off ember completely.

The real boon for us has been the single source of truth and the connect function from react-redux. Basically any component can just declare the data it relies on via store query functions e.g. getLabelsForUser(state, userId), which breaks you free from the uber painful process of passing properties down the entire view tree to child nodes.

I also got a lot better at developing when I started developing for react, because I was no longer writing framework code, I was writing and utilizing my own functions and abstractions.

I'm not saying ember is inferior, but of course there are trade offs to both. I absolutely love yehuda and tom, they are so prolific, but I would be interested in seeing how ember apps fair when there are only a couple of routes but a ton of view logic and state; where does the state live and how is it coordinated. How do you coordinate data across the app hierarchy? Asking because I really failed at that 2 years ago and ended up with a mess, it definitely felt like uncharted territory. Would totally accept developer error.

<comment><USER28> agreed - checkout the official redux bindings for ember (a cargo cult of the connect api from react-redux)

[https://github.com/toranb/ember-redux](https://github.com/toranb/ember-redux)

</comment></comment><comment><USER29> Note that you should not choose Ember if you are creating an app intended to be used on mobile, as it doesn't yet have code-splitting. This talk explains about why this is a hard requirement: [https://www.youtube.com/watch?v=4bZvq3nodf4](https://www.youtube.com/watch?v=4bZvq3nodf4)

<comment><USER30> It isn't just worse on Android it is BRUTAL on Android.

I was deeply unhappy with the 3x-5x widening iOS and Android JavaScript perf gaps through 2014 and 2015 (TL;DR Qualcomm has completely lost the plot) but in 2016, it's.. even worse.

The good news is, Ember 2.10 looks like a major speed improvement! The bad news is, Android is still 10x slower with Ember.

[http://discuss.emberjs.com/t/why-is-ember-3x-5x-slower-on- an...](http://discuss.emberjs.com/t/why-is-ember-3x-5x-slower-on- android/6577/59)

It would be a bit more even if Apple wasn't delivering substantial speed improvements, year after year, consistently.

<comment><USER29> You're talking about rendering performance, but I'm talking about performance issues caused by bundle size.

</comment></comment></comment><comment><USER31> Instant2FA sounded like a great thing to pitch internally, then I saw they want 10 cents for every login, ouch

<comment><USER32> Assuming 1 login/day and 85k/year annual employee cost (practically a joke, especially in the Bay Area) and 250 work days/year, it comes out under 3 bps (0.03%) of the employee cost. Probably not crazy for two factor, vs distracting yourself from your actual business goals?

</comment></comment><comment><USER33> I like the author's focus on results and team productivity. Standardized tools are key for that. This is also my main concern, when it comes to JavaScript frameworks and libraries. While Ember seems very good at that front, when talking about a single project or multiple very similar projects, I would like to add another point:

As soon as you are working with different platforms (the author mentioned WordPress), you should not necessarily integrate everything all the way up. Because now you have your Ember based build process and maybe something gulp- based for WordPress.

I always try to find frameworks, which has all the things only concerning itself integrated into (say server-side rendering etc.) but then stops there and makes use of preferably the two or three leading tools (e.g. grunt/gulp plugin) for all the other concerns.

That way you can choose a standard stack and only consider new frameworks if they work reasonably well with it.

</comment><comment><USER34> "...the thought of Ember making all these decisions for us — enforcing a convention over configuration — was very alluring"

Alluring, yes. Good? You shall see. When you embark on using an opinionated framework development can, at first, seem easy. It's when those opinions change that you can easily get hurt, however.

<comment><USER29> I find that convention over configuration often is trying to solve the wrong thing. It puts a tremendous burden on the user to know all of these conventions when being simple and direct usually works just fine.

One example is an Ember RFC I read recently about the required folder structure of Ember projects. It wasn't clear to me at all _why they were even doing this_. Like, what were the gains? It turns out the entire point is some magic auto-discovery of things like Handlebars helpers.

<comment><USER34> Yeah. Those sort of nuances can often be the hardest to discover and/or debug.

</comment></comment></comment><comment><USER35> I don't have much experience with Ember, but I have a spent a lot of professional time with React development, well over a year now. Initially I quite loved it but that love affair is over.

My problem with React aren't complaints about front-end tooling and build systems. My problem with React is its emphasis on a tree like relationship among components. This is an unnatural paradigm for application development. Certainly user interfaces can be thought of in the form of a tree, but another way to think about application development is to consider the view a canvas, with areas to fill in.

React's strong tree type architecture makes some forms of common user interface development feel unnatural and ungainly, things like modals, toasts, or things that just don't fit into a neat little area of the screen in a sibling child parent relationship. Also anything that happens after a render, like animation, also has the same kind of unnatural cludgy development process and I often have found myself fighting what to render when with shouldComponentUpdate.

I'm not saying these things are impossible or even hard, it's that they're unnecessarily ungainly when those things should be simple. I've also think in practice that components far down the React tree become second class citizens, the source of bugs, less well designed and often quite dependent and highly coupled with parent elements.

Another problem I have is tooling related, it's the wave updates that you have to deal with whenever React updates. React and many well maintained libraries do this really well but there's always some bad actor in the ecosystem that makes it a pain and frankly I never look forward to a new React version. Again I understand that all these things are problems that can be overcome and I have, but I'm frankly over it.

I know I'll probably be writing React based applications for an employer for a very long time, but I would no longer recommend it. I think vue.js is a promising new library. I think there are things to be said about how React is very good about enforcing modular component development and I quite like flux and redux, but React in general. React is just not great.

<comment><USER36> "things like modals, toasts, or things that just don't fit into a neat little area of the screen in a sibling child parent relationship"

That's actually where React is very strong compared to other functional-style UI frameworks (eg: Elm's). Portals in React are really elegant and makes dealing with modals and toasts (or anything that doesn't fit in this model) quite nice.

I was working today with someone who was making a browser extension to inject stuff in host pages (think something like LastPass or those rulers for designers).

We made a set of components that create arbitrary elements at arbitrary locations, or highjack existing ones, and from there you get to manipulate things like you would any other functional-style UI. It's quite lovely (all thanks to the lifecycle hooks and React's ability to render subtrees anywhere on the screen). Very few tools do it as well as React does, otherwise I'd be writing Elm all day instead of JavaScript.

<comment><USER35> You're achieving that with separate calls to render. In an ideal React application you only have a single render call. So no, you're not demonstrating a good use of React and you're certainly not showing this to be a strength in React. Imagine, you wouldn't call react.render from inside an existing React component. That's ridiculous.

<comment><USER36> React's escape hatches ARE its strength. If you don't need them, you can just use any ol vanilla virtual dom library.

The entire reason for React's existance is to slap escape hatches on top of a vdom so you can work functionally in a non-functional environment.

</comment></comment></comment></comment><comment><USER37> As I do understand, conventions manifest often in the setting of defaults for configurations. These defaults are inherently opinionated, and therefor hinder the free development of innovation in a open source community. As it will always favor a specific solution over another.

Conventions over configurations comes to the benefit for small team, beginners and is in general more fun to code with. But it comes at the cost of being much slower in adopting new patterns and innovations. As there is currently so much speed in javascript development happening, I wonder if for now configuration do outpace conventions, until the battle field has settled.

React has acknowledged the situation and tries to get the best of both world with its quest for a React CLI. Did they know about it at the time of writing?

</comment><comment><USER38> Ember is an excellent choice. We use it in a real large scale project and really love the 'addon' way of managing modules. Its simple and comes straight out of the box. Our teams follow BEM for css and maintain 1:1 for a component/route and css file.

</comment><comment><USER39> Wow, this is great. It's good to hear an considered opinion piece that lays out good and bad points of the technology, especially from someone versed in a different space.

As the perlers wisely said: TMTOWTDI

</comment><comment><USER40> In the React ecosystem, there are several really good tools for managing build, deploy, and test harnesses. See kyt [1] for example, or the list of Create React App Alternatives [2].

[1] [https://github.com/NYTimes/kyt](https://github.com/NYTimes/kyt) [2] [https://github.com/facebookincubator/create-react- app#altern...](https://github.com/facebookincubator/create-react- app#alternatives)

</comment><comment><USER41> There are a lot of people out there making such decisions every day. Does anyone know a guide for making the right technology decision?

</comment><comment><USER42> Ember seems really cool, but I've never had anything big enough I've wanted to use it on. In fact, I have not used a JavaScript framework for a while (unless you count an Ionic app a few months back. Ember's learning curve seems a bit steep too.

</comment><comment><USER11> To be honest, I really miss the good old flex + wsdl days.

Component architecture, check. Two way binding, check. Optional type, check. IDE, check.

My favorite, typed components, check.

</comment><comment><USER43> The article should have been titled 'ember tooling vs react tooling' I guess. The explanation is only about the tooling rather than the framework. Good write up though. Intriguing to try Ember this weekend!

<comment><AUTHOR> If you try, send over the link for us to test.

<comment><USER43> Oh sure.

</comment></comment></comment><comment><USER44> the lesson here is not to choose a bunch of random libraries you have no experience with. there was likely no need for you to:

1\. create your own build system when something like create-react-app exists

2\. use something like redux-saga when promises and async/await would suffice

3\. likely you probably didnt even need redux, the application looks fairly small and doesn't look like it has a lot of internal state.

tl;dr you did it to yourself

<comment><USER45> How do you get experience with a library if you never choose a library with which you have no experience?

<comment><USER44> You reach for a library because it solves some particular need that you have, not just because.</comment></comment></comment>


A/B Testing is Expensive - <AUTHOR> http://jamiequint.com/ab-testing-is-expensive <comment><USER2> If you want both a strategy for testing with limited data, and information about the kinds of errors you are likely to encounter, you may want to read [http://elem.com/~btilly/ab-testing-multiple- looks/part2-limi...](http://elem.com/~btilly/ab-testing-multiple- looks/part2-limited-data.html).

<comment><AUTHOR> Awesome! Thanks for sharing.

</comment></comment><comment><USER3> Great post!

When you're first starting out, positioning matters. At [http://yesgraph.com](http://yesgraph.com) we've found copy AB tests to produce incredible lift.

For example, people don't want to "invite" contacts. They do want to "email" contacts though. It's the same flow, but a few words triggered massive lift. The reason it is massive is because it is so unoptimized. So it is specifically at the start where such small tests can matter.

<comment><AUTHOR> Absolutely, small tests can make large differences.

However, you only have so many "bullets" to shoot at tests with a small audience so you have to be very picky. Sounds like contact inviting is a key viral feature of YesGraph so it makes a lot of sense to optimize there.

I'm not anti A/B testing at all, but anecdotally a lot of people I talk to about this stuff fire their test bullets on the wrong things and end up with not much to show for it.

A better understanding of psychology goes a long way into intuiting where you may actually be able to see gains, and how to go about achieving them. Sometimes this can be small changes producing large gains, although I have seen large changes produce larger gains more often.

<comment><USER3> Agreed

</comment></comment></comment><comment><USER4> One cheap (in time and money) complement to A/B or multivariate testing that the author doesn't mention is usability testing, specifically remote testing. Before we launch a test, we always run remote usability tests.

Feedback like this should be taken with a grain of salt, since these people are testers, not necessarily like your users in all respects. But it's still really valuable. I've caught numerous errors that test data would not help me understand easily.

Combine remote usability testing through something like usertesting.com with prototyping, and you've got a really rapid way to get feedback on the cheap, even if you don't have enough site visitors to get statistical significance on a reasonable time frame.

</comment><comment><USER5> If you want to test a sales page prior to product launch, it will be expensive to A/B test because you can't use natural visitors.

I have a site with a few thousand visitors per day. I had a product I was going to release. I was working up to a big product launch, building up the anticipation over my email list and on the site itself. In that case, I couldn't use natural traffic from the site to test the sales page prior to launch. I had to use cold traffic such as adwords to see which version of the page people responded to. I probably spent about $8k on traffic just crafting and A/B testing the sales page.

But it was worth it. It was like a university education in marketing. Marketing can be so counter-intuitive. So many things I expected to work did not work and vice-versa. But once I had the final tested sales page in place it worked and it worked well. I still get about a a 4% conversion. And most importantly, I knew that when I did finally launch, I had a well-tested and solid page that would convert the large initial influx of customers I got from the building up process before the product launch.

</comment><comment><USER6> Interesting read, but I would have to disagree. It's not difficult to reach 90% confidence with very a small sample size:

      - Variation A and B each receive 20 visits
      - Variation A receives 10 clicks while variation B receives 5 clicks
      - The confidence interval for Variation A is 90%
      (Source: https://mixpanel.com/labs/split-test-calculator)

Also, I wrote an article titled "Creating Successful Product Flows" that is very relevant to this post: [https://medium.com/design- startups/c41ffbce49a1](https://medium.com/design-startups/c41ffbce49a1)

<comment><USER7> Can someone with expertise comment on this? I once worked in a company where the founders thought that the small samples were adequate. I thought that the calculators were misleading with such small samples sizes, even though they gave "high confidence".

But that was only based on my intuition, not math, and I've never seen anyone give a good discussion of whether "90% confidence" is as definitive as it sounds in the context of a very small sample.

<comment><USER8> It's a bit awkward to give a full answer to this, but this is to the best of my understanding and explained as simply as is reasonable:

A small sample has less statistical 'power' to identify significant differences where they exist. Put another way, a large sample is more likely to give a true significant result than a small sample.

But, if you do see 10% significance(/90% confidence) in a small sample, this is just as good as 10% significance in a large sample. Although the cutoff point will be more rough in a smaller sample, it's a good standard practice to round conservatively to account for this.

10% is unlikely to be considered a good result for statistics in either case - you can engineer a result by doing 10 tests on nothing and there's a danger you would have unknowingly or unconsciously done this, maybe (for example) by not deciding the sample size in advance. However, there's also presumably strong enough evidence against a harmful difference that you aren't likely to lose anything by following these results.

It can be good idea to do numerous small investigative tests as justification for bigger tests - relying on lots of small tests alone requires consideration for multiple testing (e.g. Bonferroni correction).

<comment><USER9> "But, if you do see 10% significance(/90% confidence) in a small sample, this is just as good as 10% significance in a large sample". That is not true, strictly speaking. You are assuming that small sample describes the underlying distribution well. But this may not be the case due to non-normality of the distribution itself or potential biases

<comment><USER8> Cool point and I agree.

The sample has to represent the population, that's fundamental. If the sample is so small that it can't characterise the population distribution, then you have a problem anyway. If you're measuring a events that happen 1% of the time (or 99% of the time), a sample of 100 is not nearly enough.

If you chose an appropriate non-parametric test to cover an unknown distribution with a small sample, it maybe would have zero power (impossible to give a significant result)

</comment></comment></comment></comment></comment><comment><USER10> I agree with your points re: A/B testing early on for startups but I don't think the conclusion is that A/B testing is an expensive option, it's more like the wrong option.

Yes, you'll need moderate levels of traffic for split tests to be effective, so if you don't have the traffic or time to wait around, you should be talking to your users.

</comment><comment><USER11> I recently wrote a calculator which will tell you how many days it will take to run an A/B test to 90% significance.

You just plug in

1\. the number of pageviews your page got in the last month

2\. the number of conversions that resulted from those pageviews

[http://abtestcalculator.com](http://abtestcalculator.com)

</comment><comment><USER12> Here's an article on how to do conversion optimization with little to no traffic [http://conversionxl.com/how-to-do-conversion-optimization- wi...](http://conversionxl.com/how-to-do-conversion-optimization-with-very- little-traffic/)

</comment><comment><USER13> An alternative could be cloud based eye tracking testing services such as [http://www.gazehub.com/](http://www.gazehub.com/) where you can get a lot info about how visitos navigate... and you dont need large volumes of traffic

</comment><comment><USER14> In a lot of cases, I would say it's ridiculously cheap -- you can make some very small changes and get a huge response. But in the context of a site that isn't getting many visitors yet, this make sense.

</comment><comment><USER15> As a practical matter, with limited data, you can't do A/B testing. You have to just move forward, guessing on each step -- yet carefully tracking whether the change brought an improvement.</comment>


The Rise of the 'Edupunk'  - <AUTHOR> http://www.insidehighered.com/news/2010/11/05/cref

<comment><USER3> As someone who spent 5 years working for an agency that was supposed to connect educators with technology, I feel quite qualified to say:

 _HA HA HA HA!_

I read quotes like:

 _In a bow to the "Edupunks," Sullivan explained that Virginia is incorporating student habits into its pedagogy. For example, the university is experimenting with "flash seminars." Just as "flash mobs" summon young people to engage in some simultaneous bizarre act in a specified place at a specified time, the "flash seminars" alert students to an edgy topic -- no examples of how edgy -- that will be discussed in a professor's living room. To raise the hype level, only the first 25 students who show up are allowed to participate in this non-credit-bearing activity._

and I think of the endless papers I've seen on how _social networking/ipads/location based services/mobile computing/cloud computing/whatever was hot in the tech sphere six months ago_ is going to revolutionize education. I'm continually reminded of cargo cults (<http://en.wikipedia.org/wiki/Cargo_cult>: _A cargo cult is a religious practice that has appeared in many traditional tribal societies in the wake of interaction with technologically advanced cultures._ )

Education systems have huge budgets, but they are always run by such second rate people that the money is never used as a lever to get what they need. Education systems are quite happy to spend millions of dollars on consultancies and studies, but because the focus is on risk avoidance they never actually achieve anything.

(And yes, there are a few exceptions. Having destroyed myself trying to achieve anything in that sector I applaud all the more for those who have managed it.)

For anyone considering doing a company in this space, read all the warnings you hear about doing enterprise software, and then take away the fact the most enterprises are at least rational (if slow). Then also remove the fact that enterprises pay people well, so they are usually a few decent people who you can deal with. Then add in politics, the election cycle, unions, teachers, lectures, "duty of care" considerations. If you are still considering that sector, then good luck!!

<comment><USER4> I am just getting in to this sector. It would really be great if you could write about your experiences in this domain. Those would help people like me avoid making some obvious mistakes, and also help us learn a thing or two for our ventures.

<comment><USER5> Your obvious mistake was going into this sector, unless you are targeting either pre-k or graduate students. Otherwise get out now, unless you're just doing lead gen or something.

<comment><USER6> But why? Please explain.

<comment><USER5> So let's say you have some software that legitimately creates $30-100 dollars of value per student. In order to sell that software to the school, it's going to take 8 months and $20,000 dollars. That means you're going to have to sell it for at least $125,000 dollars to make it worthwhile. That you're A) reading HN B) asking this question suggests that you probably won't be able to make this sale. And even if you can, you'll essentially just be conning the schools out of money because your software is worth vastly less than what you're selling it for, so you're essentially just depriving kids of things that would actually help them learn.

</comment></comment></comment></comment></comment><comment><USER7> It's an interesting analysis of the current situation, but the proposed methods for changing the system are depressingly trendy:

 _Just as "flash mobs" summon young people to engage in some simultaneous bizarre act in a specified place at a specified time, the "flash seminars" alert students to an edgy topic -- no examples of how edgy -- that will be discussed in a professor's living room._

If they want a good model of popular education and intellectualism, they do exist. Take the amateur astronomy community, for instance, or Wikipedia culture.

<comment><USER8> Yes, though Wikipedia's internal wrangling and deletionist slant can be ugly.

</comment></comment><comment><USER9> If I were thinking of something to call "edupunk", I don't think this weird flash-mob-based, social-media-tinged approach to education would be it. What about the methods of education punk culture has actually promoted for decades? Stuff like: disseminate information to let people do things themselves (the DIY ethos), free courses, free or low-cost zines, volunteer-taught skills workshops, etc.

<comment><USER10> It is somewhat comical hearing these $40k+ a year schools talking about what they perceive as a coming paradigm shift within academia. If people are taking free courses online, or teaching themselves or others with the only cost being the time they put in, how could universities possibly make money off a situation like that?

To me it seems that this shift isn't happening within academia, but is a shift _away from_ academica. Who needs them anyway?

<comment><USER6> In my opinion the very definition of academia today is proof of its lack of necessity. And that is the exact reason why they need to change - and change, not be destroyed - there is much need for such institutions still. Even the most ardent self-learners can benefit from mentorship relationships, so that's where universities need to focus.

<comment><USER10> Why do we need academia for mentorships?

Certainly academia is not useless (though I guess I was implying that in my previous post with the "Who needs them anyway?") but I do think that academic institutions will likely become less and less relevant. I'm currently in a PhD program studying Environmental Engineering and its so structured and balkanized and specialized that its really pretty ridiculous (and I'm at one of the more progressive, liberal Engineering programs in the country). It occurred to me that it would be incredibly interesting if, instead of having to research at Universities and thus, working within their outdated framework, what if people began researching at places like Google? What if companies like Google funded imaginative, interdisciplinary research? Stuff that gets bogged down in the highly procedural academia?

I might try and think of a way to better articulate this idea and see what the HN community thinks of it...

</comment></comment></comment></comment><comment><USER11> My spouse teaches part-time in the UoP (University of Phoenix) system. Their interface is sparse, the classrooms are largely asynchronous, and the faculty largely anonymous. It works because UoP knows what it's selling - <USER2> Degrees.

Public universities can't admit to themselves that selling degrees is what they do for political reasons - doing so is anathema to alumni and academics. So they are compelled to "deliver rich media," hold classes at scheduled times, and cater to the traditional leanings of brick and mortar professors. It's a model that doesn't scale.

The opportunity in higher education is cheaper degrees with higher customer service...I personally believe it is quite achievable. Particularly if one replaces accreditation with reputation.

<comment><USER10> Can you elaborate on what you mean by "reputation"? I think it's potentially a really interesting point and I'd just like to have a better idea of what you mean by it.

<comment><USER11> Some further remarks:

Accreditation is a minimum standard, and is applied to the institution as a whole. As I'm carelessly throwing it around, "reputation" would refer to the effectiveness of an institution's graduates due to their education.

I guess I'm getting at a vocational measure, e.g. how well is a graduate prepared as a professional. The issue with online education is that accreditation is typically purchased through the acquisition of an existing brick and mortar school. See: <http://www.pbs.org/wgbh/pages/frontline/collegeinc/view/>

However, if you are hiring a fresh graduate as a programmer, accreditation doesn't differentiate the candidates because they all have accredited degrees. What matters more is the ability of the school to turn out people with a higher caliber of skills, knowledges and abilities...the number of books in the library and Phd's on the professor's office walls aren't the important metric.

Accreditation matters for graduate schools and for licensing boards (law, medicine, etc.). Building the rest of higher education around it, doesn't make a lot of sense.

</comment></comment></comment><comment><USER12> Does anyone else find it just a little bit chilling that the idea of a group of people educating themselves independently is seen by modern society as weird?

</comment><comment><USER13> As a student at a university, I totally agree. i hear more and more students complaining about the education, and more people (such as myself) starting to look elseware. A group of us have formed a "class" around some of the open courseware so that we are still in the class-like atmosphere. we want to learn. the university just refuses to teach us what we want and how we want to learn it.

</comment><comment><USER14> ...you motivate people by helping them to learn what they're interested in learning and not through gimmicks like a flash mob. If you think you have the ability to 'trick' people into learning then you are mistaken. This is thoroughly embarrassing.

The establishment needs to realize that learning can be enjoyable for people that take pride in it or see it as a way to an end. Edupunks, Autodidacts and the like come from people having real passions and learning how to harness this to learn.

</comment><comment><USER15> The term 'Edupunk' being as vague as it is, this article could also be focused on auto didactics. Punk meaning individualism and free thought.

</comment><comment><USER16> I don't understand where is the problem in accessing students who learn from open courses (I am not saying there is no problem, but I just don't understand it). Most of the grading is done based on quizes, mid terms, terms, term papers etc. All these can be given by these students and you get the assessment.

<comment><USER17> Testing in post-secondary is usually very idiosyncratic. At best they teach to a textbook and test that textbook evenly. More likely, a professor teaches their angle on a subset of the topic, and then grades based on that.

Because of that, if you understood the 3rd year Algorithms courseware from MIT, you would likely fail the midterm for 3rd year Algorithms at your local university.

Fixing this is very difficult, since it would mean you need standardized tests to measure post-secondary topics. Implementing that (and keeping it up to date) would be extremely difficult and contentious.

<comment><USER6> I believe it's perfectly OK that you can succeed in Algorithms at one school and not do perfectly at another with the same knowledge.

The area where I believe the problem is in specifically teaching to a test, rather than general deep understanding (of algorithms in this example). Tests in a lot of cases don't test for deep understanding, but rather memorization and understanding of very specific algorithms. The focus is completely off. It's the "meta-algorithmic structure" that matters for the future of students (when they themselves have to go learn/create algorithms to solve future problems), not just recall the small subset of algorithms they learned in school.

<comment><USER16> _I believe it's perfectly OK that you can succeed in Algorithms at one school and not do perfectly at another with the same knowledge._

How is this OK? Its the fact, but its most certainly not the right thing.

</comment></comment></comment></comment><comment><USER18> tl;dr:

They don't _get it_.</comment>


An Android fan's take on the Galaxy Nexus - <AUTHOR> http://www.thetechblock.com/articles/2012/an-androids-users-take-on-the-galaxy-nexus/

<comment><USER2> I've had a Nexus for two months now (since launch day on Verizon) and I have only two real gripes about it. Otherwise, performance has been good, the screen is gorgeous, and I've been happy with ICS.

The camera quality is really bad. When using the flash indoors, the colors seem to be off by a mile. You can turn off the flash but then images are (obviously) dark and blurry. It's disappointing because things like the zero- shutter-lag and panorama features should make this an awesome camera phone, but it seems like they skimped on the camera hardware. Or maybe I just have a bum unit and I should make a warranty claim?

My other issue is the size. It seems that every flagship device (that is, one with specs worth buying at all) on the Android platform is engaged in this arms race for bigger and bigger screens. Frankly I think the old Nexus One and the iPhone are the perfect size.

Apple seems to have no problem selling 3.5" screen phones like hotcakes, so I don't know why the Android manufacturers think that the only way to sell phones is to have giant devices.

<comment><USER3> Screen size is a matter of personal preference. Few people like yourself fancy small screen sizes like that of the iPhone.. but for me, 4" screens have proven ideal and ergonomically the best of the many. Having different screen sizes is good because it offers the consumer the choice of choosing what he/she might feel best..

Having said that, I do agree with you on the GNexus screen size. 4.65" seems a little over the top..

<comment><USER4> For me, I actually think 4.65" is still a little small -- 5" would be best for me. Much to my very slight irritation, the only 5" phone currently is the Galaxy Note, which doesn't use T-Mobile US's 3G or 4G bands.

I do know a few people who prefer smaller screens, but it does seem that 4" is around the sweet spot for most people.

</comment></comment></comment><comment><USER5> I got my galaxy nexus last week, and I am over the moon about it. Came off a droid x, and it is just hands down awesome. The battery isn't all it could be, might have to go after market for that, but the screen is great, ics is finally competitive with iOS, and the fast camera is really nice for shots on the go. (which is all you should ever use a cell phone for anyways. If you want a real camera, BUY ONE.) it's not perfect by any means, but I couldn't find another android device that was comparable.

</comment><comment><USER6> I bought the Nexus One for AT&T about 2 years ago, am totally contract free, and even grandfathered in on an unlimited data plan at AT&T. I do some develop on Android, as well as iPhone, and have been trying to figure out what the best Android developer phone would be to upgrade to in the next 6 months or so. Preferably, I'd have something like the Nexus One that I can just buy outright and plug into my unlimited data plan at AT&T even if it costs a few more $$$. I'm pretty much underwhelmed by all the Android offerings at this point. What are developers looking forward to in terms of contract-free developer Android phones in the next 6 months?

<comment><USER7> An unlocked GSM Nexus S or Galaxy Nexus is really the only way to go.

<comment><USER6> I was somehow under the (mistaken?) impression that the unlocked Galaxy Nexus would not work on AT&T or at least not work on AT&T 3G. A bit of research suggests this is not the case.

<comment><USER2> This was an issue for the Nexus One and the Nexus S, but not anymore with the Galaxy Nexus.

The Nexus S comes in two GSM versions, one that would only do 3G on T-Mobile's AWS band, and one come in a version that would do 3G on AT&T's 3G band. The AT&T model would only do EDGE on T-Mobile, and vice-versa. I think the AT&T version is only sold at Best Buy:

[http://www.bestbuy.com/site/null/Google- Nexus-S/pcmcat224600...](http://www.bestbuy.com/site/null/Google- Nexus-S/pcmcat224600050004.c?id=pcmcat224600050004)

The GSM Galaxy Nexus has a pentaband radio and so you'll get 3G on T-Mobile or AT&T all on the same model.

<comment><USER7> I also get 4G on T-Mobile but not sure if that will be the case on AT&T as well.

</comment></comment></comment></comment></comment><comment><USER8> It's upgrade time for me and I'm debating whether to stick with iOS or wait out for the Galaxy S3. A lot of people have recommended the S2 but I'd prefer to have the latest model before getting in to a contract for another 2 years

<comment><USER9> I'm a current Galaxy S user, with an upgrade available. I'm holding out to see what HTC announces at MWC, and comparing that to the S3.

If HTC really does come out with a Tegra 3, LTE phone, that's gonna be hard to pass up. Especially when you add in the HTC build quality and unlocked bootloader advantages.

</comment></comment><comment><USER10> Let me guess: Android fan tries Nexus, doesn't like it switches to iPhone, etc. etc.? Somehow I don't think "Android fan tries new Android phone and likes it" would be as newsworthy.

<comment><USER11> No, he's still using Android, he's just underwhelmed by the Galaxy Nexus.

<comment><USER12> I was a bit underwhelmed too. Both because the menu button isn't always in the same place anymore, and because the back button doesn't interact in the expected way with the new way of switching apps.

<comment><USER13> Could you elaborate on the latter?

I'm currently on an Incredible (CM 7 - so Gingerbread), and the back button is the third from left (home, menu, back, search), and the back button has unpredictable functionality (depending on the application).

<comment><USER12> Lets say I open up the web browser, then I use the application selector to go to my Twitter app. If I hit back I'll go to the homescreen, rather than the web browser. The app selection button somehow flushes out the entire back stack, which is really, really annoying. As to unpredictability regarding views within apps, its a bit worse but not hugely different.

<comment><USER13> I'm confused - I thought they were trying to get devs to standardize that, and that they also changed things in ICS?

The way it currently is (for me on Gingerbread) that some apps have the back button go back to the previous view, but some go to the homescreen. And if I (say) open a browser link in an app, the back button will take me back to the application. (That may also be app-specific, but I just tried it out with one app).

So what's different on the Nexus, and what part of that is ICS-specific changes (as opposed to things that app developers have to implement independently)?

(Apologies for the confusion, but I still haven't seen an ICS device, and I don't develop for Android, so my knowledge of this is fairly passive, as a consumer).</comment></comment></comment></comment></comment></comment>