Aaron Swartz v. United States (2011) - <AUTHOR> http://blogs.law.harvard.edu/sj/2011/07/24/aaron-swartz-v-united-states/ <comment><USER2> I hope this comes up in Congress. The United States never should have been a party to this -- it should have been a civil issue between JSTOR, MIT, and Aaron. (or criminal misdemeanor trespassing if they really wanted that.)

Carmen M. Ortiz, US Attorney, should be called before Congress to account for this.

<comment><USER3> _. The United States never should have been a party to this -- it should have been a civil issue between JSTOR, MIT, and Aaron._

Except, you know...the fact that Congress passed a law a while ago that made this a crime.

This _should_ come up in Congress because what Aaron did should not be a felonious act. At best, it should be an infraction (i.e., the lowest type of civil misconduct, like jaywalking).

But the fault lies with Congress for making this a crime, not Ms. Ortiz for enforcing the laws is ethically and legally bound to enforce.

<comment><USER2> She went vastly beyond what was required of her in charging him with a whole litany of offenses, several of which Congress most likely didn't intend to apply to situations like this (CFAA to TOS violations).

This was because Aaron was a bit of a gadfly, and had gotten out of the PACER situation earlier, so he was already on their enemies list.

Congress was also at fault for passing a bunch of stupid laws, but that doesn't excuse Ortiz. It also doesn't excuse Aaron for killing himself and not getting help. There's plenty of blame to go around.

<comment><USER3> I don't know how much more simply to state this:

As a consequence of prosecutorial "discretion" exercised during the jim crow days of the segregated South, federal prosecutors _do not have discretion about which laws to prosecute_. Once they have been presented a case, they are _required to prosecute_ if the presentation of evidence is sufficient to suggest that a crime has been committed.

Only upper management of the DOJ (i.e., above Ms. Ortiz) or the president can issue orders not to enforce certain laws.

Thus, this _does excuse Ms. Ortiz_. She's just doing her job. If you don't like that, _change the scope of her job_ by getting her superiors to end enforcement of the laws at issue.

<comment><USER2> You seem to be a lawyer, and I'm not, so thanks for your information. I know a lot more about computer security theory and practice than the US federal laws; there are pretty clear lines way before "crime" which I try to stay within, myself.

As far as I can tell, CFAA was not violated, at least under the narrow (i.e. correct) interpretation of the 9th circuit. There is a circuit split right now. 1st hasn't ruled at all, so she could easily have looked to the 9th for guidance on this and not included CFAA charges.

There was no "protection" at MIT or at JSTOR, so I don't see how fraud or unauthorized access, etc. applied. He scraped a website. He may have trespassed at MIT. If net-18 restriction is considered "protection", wtf (certainly a server on a secure LAN is protected by being only on the secure LAN, but a server limited to US-only access and accessed via a proxy is not. IMO Net-18 is a lot closer to national restrictions at YouTube than a security policy, since any guest could walk in and have access.

I don't see "recklessly damaging a computer" as applying at all. Wire Fraud is essentially free always.

Turning these into multiple counts for the same offense is also BS.

<comment><USER4> He may be a lawyer, but he is completely wrong in this and most of his other assertions.

Justice.gov. Verbatim quote "The USA is invested by statute and delegation from the Attorney General with the broadest discretion in the exercise of such authority."

[http://www.justice.gov/usao/eousa/foia_reading_room/usam/tit...](http://www.justice.gov/usao/eousa/foia_reading_room/usam/title9/2mcrm.htm)

      The United States Attorney, within his/her district, has
      plenary authority with regard to federal criminal matters.
      This authority is exercised under the supervision and
      direction of the Attorney General and his/her delegates.

      The statutory duty to prosecute for all offenses against
      the United States (28 U.S.C. § 547) carries with it the
      authority necessary to perform this duty. The USA is
      invested by statute and delegation from the Attorney
      General with the broadest discretion in the exercise of
      such authority.

</comment></comment></comment></comment></comment></comment><comment><USER5> If you are unable to make the link between Swartz's absurd criminal indictment and his suicide in the light of this post, and/or if after reading it, you still view the possibility of his suicide being primarily linked to causes other than the indictment as on par with it being linked to the indictment, you should perhaps hear Jacob Appelbaum's recent C3 talk [1], where he details the state oppression he, his mentally ill mother, and his various acquaintances have been under due to his link with Wikileaks.

[1] <http://news.ycombinator.com/item?id=4977338>

<comment><USER3> Aaron appears to have committed suicide as a result of a mental illness (i.e., clinical depression) which was exacerbated by the criminal case against him. It wasn't the criminal case that killed him; it was his mental illness.

The fact that he has a mentally ill mother is strong evidence of this, since mental illness has a genetic component (especially depression and schizophrenia).

<comment><USER5> > _Aaron appears to have committed suicide as a result of a mental illness > (i.e., clinical depression) which was exacerbated by the criminal case > against him. It wasn't the criminal case that killed him; it was his mental > illness._

His family and partner, perhaps the people who have been closest to him in recent times, seem to disagree with you [1][2].

> _The fact that he has a mentally ill mother is strong evidence of this_

Is that indeed a fact, or did you just happen to incorrectly infer that from my sentence? I was talking about Appelbaum's mother, not Swartz's. My point in citing Appelbaum was to denote that Swartz is not an isolated case; the US justice system has been systematically acting as an instrument of oppression against dissidents (and increasingly more frequently, against those active in the production and critique of technology) whom it perceives as adversaries of its federal and corporate sponsors.

[1] <http://news.ycombinator.com/item?id=5049225>

[2] <https://news.ycombinator.com/item?id=5047398>

<comment><USER3> I don't have time to go over the several dozen Aaron-related posts or HN threads from today until tomorrow to provide cites, but many of Aaron's posts linked to on HN (including, especially the Batman post) display many signs of severe clinical depression. I'm not a doctor, so I'm not saying that he did kill himself as a result of a medical illness with any degree of certainty. But I am saying, based on my past experience representing defendants with mental illness, that it probably played a role in his suicide.

Also, the family does not say anything that disagrees with what I said. They state merely that the criminal case "contributed to" Aaron's death. That is an actual quote from [1].

<comment><USER5> > _merely_

That's some rather selective reading on your part. You ignore the context in his mother's statement on HN that he was "depressed about the case and the upcoming trial" (indicating perhaps that his depression and the pressure brought by the indictment are inseparable), and cherry-pick a particular sentence to support your own view, rather than try to _hear_ the tone and spirit of the statement. The fact that the family chose to come forward with such a clear and bold statement condemning particular institutions on the day of their loss alone is proof enough that they strongly believe MIT and the DA's office played a critical part in what happened.

<comment><USER3> _The fact that the family chose to come forward with such a clear and bold statement condemning particular institutions on the day of their loss alone is proof enough that they strongly believe MIT and the DA's office played a critical part in what happened._

Families usually say things like this the same day a loved one dies, so their statements today are proof of nothing. It is their statements _next week_ or next month that indicate how they feel about MIT and the USDOJ's role in Aaron's death.

 _"depressed about the case and the upcoming trial" (indicating perhaps that his depression and the pressure brought by the indictment are inseparable),_

Of course they are inseparable--most defendants do get at least a little depressed when they are facing criminal charges. But the one thing that 99.9999% of defendants have in common is that they don't kill themselves, especially not before they are convicted, unless they have a serious mental illness. The number of white collar federal defendants who have committed suicide prior to trial in the past decade can be counted on a single hand.

Let's get this straight: I do think that the criminal case pushed Aaron over the edge and if you go far enough back in my posts I am usually blaming prosecutors for the overzealous and unethical behavior. If this case had gone to trial, I would probably be railing against the egregious prosecutorial misconduct of the case. But I place the blame for Aaron's death solely on his shoulders, because _he_ is the one who made the decision to kill himself.

<comment><USER5> > _I do think that the criminal case pushed Aaron over the edge_

> _But I place the blame for Aaron's death solely on his shoulders_

Quoted for emphasis.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> the blog links through to this article, which I found quite insightful: [http://www.litigationandtrial.com/2011/07/articles/series/sp...](http://www.litigationandtrial.com/2011/07/articles/series/special- comment/aaron-swartz-computer-fraud-indictment/)</comment>


The Wonders of the Suffix Tree Through the Lens of Ukkonen's Algorithm - <AUTHOR> https://humanreadablemag.com/issues/0/articles/the-wonders-of-the-suffix-tree-through-the-lens-of-ukkonen's-algorithm/ <comment><USER2> So often lately, Ive come here and left disappointed. Reading about Wasabi and hipster sweaters. But this post is exactly the kind of content we should be pushing. Everyone who reads this will become a better hacker for it.

</comment><comment><USER3> This site is currently running a Kickstarter to launch a new programming magazine. If you'd like to see more content like this out there, consider taking a look:

[https://www.kickstarter.com/projects/pekalicious/human- reada...](https://www.kickstarter.com/projects/pekalicious/human-readable- magazine-for-the-inquisitive-developer)

</comment><comment><USER4> Also interesting to get into are suffix arrays which you could construct from a tree. Then there is a notion of generalized suffix arrays, where you mix multiple suffix arrays into a big suffix array. Then you can give fast answers like: what is the longest common prefix between the several tokens, whereas the tokens of your individual suffix arrays could be letters from an alphabet (so you construct a suffix array from words) or maybe words (you construct a suffix array from a sentence)

<comment><USER5> And then you could get into compressed indexes such as the FM-index, which represent a text in a form that is both (typically) smaller than the original, and _also_ supports fast substring queries.

Suffix trees are cool, but they're just the entry point to a world of wonderful data structures and algorithms.

<comment><USER6> The Burrows-Wheeler transform was an interesting thing to see! When I used to teach at an immersive 3 month program for web dev we had a few weeks of playing with such arrays, trees, tries, dynamic programming, and text from Wikipedia.

</comment></comment></comment><comment><USER7> In practice one should typically prefer a suffix array to a suffix tree. A suffix array is conceptually so easy!

1\. Given a set of strings, put all the suffixes into a set. For example "derp" -> "derp", "erp", "rp", "p".

2\. Sort it

It's cheap! The number of suffixes equals the string length, and suffixes can be mere references into the string input. So in practice you use maybe ~2x memory compared to the input - and in big cache friendly chunks (not tries).

Now you're flying. If you want to perform a substring search:

1\. Binary search on the first character. You get a range of suffixes which begin with that character.

2\. Within that range, perform a binary search on the second character. Now you have a range of suffixes which begin with the first two characters.

3\. etc.

Powerful and easy.

By the way this technique of going character by character can and should be extended to the sort itself; look up "three-way radix quicksort" for what you never learned in school.

<comment><USER8> More like 4x or 8x the memory (of an ASCII string) if you just use pointers or size_t's. Abstractly, you need at minimum (n log n) memory to represent a permutation, which is what you're doing.

</comment></comment><comment><USER9> I took string algorithms course with Esko Ukkonen. It was one of the most interesting and fun algoritm courses ever and very useful.

Ukkonen algorithm for suffix trees and Kärkkainen-Sanders for suffix array are very beautiful algorithms.

</comment><comment><USER10> > Introduced to the world in 1973 by Peter Weiner, suffix trees are a > relatively new concept in computer science, with this newness likely fueling > its obscurity.

That isn't really all that new; it's just about when red-black trees and B-trees were invented as well and I wouldn't call those "obscure".

<comment><USER11> You're right, it is not new. It is slightly obscure though. Definitely comes up if you study algorithms enough, but I don't think intro courses usually even mention them, and most working programmers won't have any idea they exist.

</comment></comment><comment> th-th-throwaway Are there some hidden constants/considerations that prevent suffix trees from being used in the real world?

Every time I expect it to show up (e.g., for pattern matching in databases), I almost always see something else used instead (e.g., trigrams)

<comment><USER12> A couple of considerations that come to mind for a database: (a) efficiency, and (b) dynamicity. The tree structure isn't particularly efficient (it has a lot of space overhead, and I think it's also not as fast), so you'd prefer something else if possible. So people often use suffix arrays + LCA preprocessing instead. However, those are hard to make dynamic (your database is constantly changing), so I'd expect that still makes it tough to use them in databases. Though I suspect this isn't the whole story.

</comment></comment><comment><USER13> A suffix array is of similar utility to a suffix tree, more compact to store, and pretty simple to compute: all you need to do is start with an array of each index into the data from start to end, then sort the indices by memcmp'ing the suffix string starting at each index. There are more optimized algorithms, but they're within 2-3x for moderately sized data (megabytes). You need the fancier sorting algorithms if you're constructing a prefix array of something huge like a genome.

<comment><USER11> Just as a side note, that algorithm for suffix array construction has really bad worst cases (consider a string of all "a"s).

It won't matter for experimenting or most likely for using it on smallish realistic texts, but anything where you're taking user data for instance you'd want to step up to a slightly more clever algorithm (there's an O(n lg n) worst case one that's still very simple, called rank doubling I believe).

</comment></comment><comment><USER14> (Ironically, for a site called "Human Readable Magazine" I found that really hard to read.)

</comment><comment><USER15> (Edit: I been curious/confused by this for years)

Can someone explain how this is fundamentally different from a b-tree of the substrings of a string? You'd store each substring by start index and each leaf is where the substring becomes unique.

<comment><USER3> The only thing suffix trees have in common with B-tries that I can see is that they're both non-binary trees.

A B-tree stores whole keys in the nodes, not fragments of values. And a B-tree tries to self-balance, so there's a lot of leeway for what keys get pushed up to the root node. B-trees split and merge nodes based on the number of items in them, trying to achieve a certain fill factor.

A suffix tree, on the other hand, is storing fragments of the values, and I believe (but have not bothered to prove) that there is one and only one minimal and valid way to organize the tree for a given set of data. Suffix trees add children when the data mandate that they do in order to remain correct, not just in order to make room.

<comment><USER15> I should phrase it differently; what does a suffix tree get you that a standard sorting tree doesn't get you. A standard sorting tree would get you all the neighbors in lexical order. What more do you need?

<comment><USER3> The B-tree just lets you quickly find out if a given string is in a set. The suffix tree lets you do things like finding the longest common substring very quickly, or looking for repeating motifs.

<comment><USER15> A B-tree (or any sorting/index tree) allows one to find nearby elements in where sorting order one choose. If one takes a B-tree of strings sorted in lexical order, one find the neighbors of a given string X. If you start with a string X=YZ, where Y is smallest substring in our base string-to-search and Z is the part that doesn't occur, then the (left and right) neighbors of X will be other strings containing Y, if such strings exist. Search of this sort may take O(log(l)) time admitted where a suffix tree might take O(1) time (for all I know) but still, a lot of specialized search trees are not that different from B-tree+special-sort-order, as far as I can tell. For example, B-tree + Z-ordering gives you a spatial sorting tree.

</comment></comment></comment></comment></comment><comment><USER16> This might be a stupid question: why is the fact it's a _suffix_ tree important? (as opposed to building a similar structure with prefixes)

<comment> j-pb A suffix tree contains a compact trie like graph representation of all the suffixes of a long string. So if you want to know if it contains a substring, you can start at the root and just search like in a prefix tree. Since for the queried word to be an infix it must be a prefix of a suffix, you will find the word in O(|query|) time.

So yeah its a prefix tree, but a prefix tree of all the suffixes.

And now to answer your question. If you naively put every suffix into a regular prefix tree, you would get the same lookup performance. BUT, since the suffixes will share a lot of suffixes, which the prefix tree can't compress you have a lot more memory consumption.

The suffix tree avoids this by essentially performing compression on the suffix as well, so that you simply have pointers to shared suffixes of suffixes, which point to the root.

In the end it's like a diamond shape I guess, trie in the front, compression in the back.

<comment><USER17> Why can't one construct a prefix tree of all prefixes, then start process from the right to left (assume that it is an offline algorithm)?

<comment> j-pb Because you can walk search trees from their root but not from their leafs.

</comment></comment></comment></comment><comment><USER18> I remember learning about this in a data structures class, and it is a remarkable data structure. But the author of this article needs to pick up a copy of Strunk and White. This reads like it was written by a high school junior. Awful, awful writing.

<comment><USER19> It seems like the style of the article is deliberately long-winded and poetic to match the type of content that the "human readable magazine" is going for (similar to New Yorker articles). It's likely seeking to cater to a specific niche of reader preferences.

<comment><USER18> You've got to be kidding me. The sentences are excruciating to read. New Yorker prose is in a different universe. The writing is spare and lucid. You can't evaluate the quality of prose with "wc -w".</comment></comment></comment>


Redesigning Reddit - <AUTHOR> http://www.tivix.com/blog/redesigning-reddit/ <comment><USER2> Really nice article. I completely agreed with the concept and ideas discussed.</comment>


Money for Nothing: The Lucrative World of Club Appearances - <AUTHOR> http://www.gq.com/story/how-celebs-get-paid-for-club-appearances <comment><USER2> As I started reading, I was curious about the business model that would allow the clubs to spend this much money, on the basis that they had to recoup it and more within a single night.

They kind of answer that near the end, but I'm still left a bit befuddled. Apparently there's multiple(!) groups of people who will pay $25,000 dollars minimum to sit at a table near Nikki Minaj for an hour?

I can understand (if not condone) the birthday party thing, where you spend millions to get someone famous at your party, as by doing so you are saying "I have so many millions, I can do this ridiculous thing, or buy a famous painting, and still be richer than you". But it seems weird that it's a booming and widespread business model.

<comment><USER3> You're missing the point of these night clubs. Nearly all of them are owned by, or involve criminal gangs because they're a fantastically convenient and efficient way to clean dirty money. Buy a jeroboam of champagne wholesale for $300, sell in night club for $30,000 or more.

<comment><USER4> Any info available about that? Most of the clubs I know of are affiliated with large corporate entities like Wynn or MGM. The highest grossing clubs are all run by the Tao Group.

Also where can you get a jeroboam of Veuve Clicquot or Dom Perignon for $300 wholesale? I'd love a link or more info since I would buy a bunch for parties.

<comment><USER3> Do you live in Vegas? Go to London, LA, or NYC and you'll find popular nightspots are not corporate affairs.

I didn't specify brand. £230 Moet Jeroboam (including 20% VAT) - [http://www.drinksupermarket.com/moet-chandon-imperial- brut-n...](http://www.drinksupermarket.com/moet-chandon-imperial-brut-nv- champagne-3ltr-jeroboam)

<comment><USER4> Are there places that charge $30K for non Dom Perignon/Armand de Brignac champagne? I think at Marquee (NYC) you can get something larger than a jeroboam of Veuve for $30K. (Probably a methuselah or salmanzar since I think they keep one of them on hand for all their venues)

What top grossing nightclubs in NYC aren't corporate affairs? All the top ones I can think of are; Tao, 1Oak, Lavo, PHD, VIP Room, etc. I'm sure there are smaller ones that are purely independent affairs but they aren't doing 10M+/year in revenue.

<comment><USER5> Drais in LV had $250k bottles opening weekend in 2014

</comment></comment></comment></comment></comment></comment><comment><USER6> the average life of a nightclub is not very long, perhaps a few years and that's IF you're popular. as such, there's huge pressure to just create a lot of buzz and ride that wave until inevitably you become old hat.

those people here talking about how it's convenient for laundering are missing this fact. you can point to the mega clubs in vegas as the few examples of those raking in money, but the vast majority of these clubs go out of business and make nothing. living in nyc there are handful of these big clubs that have been around for longer than a few years and even then, the popular ones have to "re-invent" themselves every few years to keep attendance up.

the more common story is that doors open, and you get some mediocre attendance and basically just losing money hand over fist every week thereafter. people come and see that your establishment isn't that popular and the next week even less people come. momentum is crazy important and i can see paying thousands for a guest appearance even if you're losing money that specific week.

<comment><USER7> Yeah this. You don't want to launder in a high regulatory, high crime, high profile, etc business. You want something like a car wash or laundromat on a small scale. Or, better yet, construction, which is notorious for its lax accounting.

Clubs bring in a lot of scrutiny. The 70s mafia movies made them look for but serious criminals have so many other options that dealing with them nowadays seems stupid. Do you really want a drunk or a whore or a gangbanger to bring police into your laundering operation regularly?

<comment><USER8> > Clubs bring in a lot of scrutiny.

One operated here illegally for about five years because every time there was a motion to shut them down they found another avenue to appeal. The legal system can move at a glacial pace at the best of times, and they were clever enough to slow it down even more.

Five years is enough time to bank millions of dollars in legitimate profits and make even more on the side through more shady deals.

I know that many of the clubs here juice up their profits by laundering and taking a cut of the drug trade in their bathrooms. They also make enormous amounts of cash legitimately which makes it hard to find out what profits are legal and which are illegal.

For example if you charge $10 for a double shot, but the product only costs you (at most) $1, you're making 90% profit right out of the gate. If someone wants to launder some money, increase your shot sales by 20%. Pour out bottles if you have to just to make the numbers add up, it's not even hard.

Very few of them are ever snared in legal issues because they have a lot of experience flying under the radar and knowing how to operate without getting into trouble. The number one cause for closing a club is either the place burned out, popularity waned, or in rare cases where there was a shooting which means a much tighter leash.

<comment><USER9> Why pour it out? Sell the bottles for cash to another party.

<comment><USER8> Presumably it's to avoid suspicion and liability. Re-selling is strictly forbidden by the rules here, and losing your liquor license is the worst possible thing to happen to a club.

To put it in perspective: If there's a report of using drugs in the bathrooms nothing will happen, it takes too much police work to amount to anything, but a single incident of alcohol leaving the premises can get you shut down. They're super strict about this.

</comment></comment></comment></comment></comment><comment><USER10> I have a personal rule to never trust anyone who speaks in the third person...this article seems to validate that quite well.

From another perspective though, is GQ effectively proposing Paris Hilton as a disruptive innovation? I kind of except that...she effectively initiated the business of recursive celebrity (rich begets famous begets rich). I honestly wonder what scholars 2-300 years from now will have to say about the development of reality television from Survivor to The Simple Life/Paris Hilton to the Kardashians to whatever will come next...

and I cannot believe I just wrote this on HN

<comment><USER11> > I kind of except that...she effectively initiated the business of recursive > celebrity (rich begets famous begets rich).

Wait, why is the current royal family rich/famous?

<comment><USER12> They were better at killing people+politics way back in the day.

<comment><USER11> Their ancestors, yeah. So I see no different scenario than the rich beget famous recursion we're talking about.

<comment><USER13> Its the much older and traditional "children of rich are rich, children of famous are famous".

</comment></comment></comment></comment></comment><comment><USER14> This isn't surprising. How else does a single night club in Miami pull in over $70M a year (LIV at fontainebleu hotel). For every 25k appearance there are 10 that night paying $5k each for bottle service nearby, and then another 1000 paying $100 for booze.

<comment><USER15> I was at LIV last week (an unpaid appearance :-)). Two drinks + tax + tip came out to $48.

<comment><USER16> Pay for the drinks, stay for the experience... ;-)

<comment><USER15> We did, until 3 AM. It was well worth the price.

<comment><USER17> It's great to see high-profile Amazonians practicing the Leadership Principles in their personal lives. Frugality, Highest Standards, and Learn & Be Curious all in one night of partying!

</comment></comment></comment></comment></comment><comment><USER18> "Without Ray J's dick, there's no Scott Disick. Without O. J. Simpson, there is no business for this family."

Just wow.

<comment><USER19> Certainly crude, but it's not wrong.

</comment></comment><comment><USER20> Famous people can make money simply off the interest that the general public has in them. However, I would encourage the author of this piece and anyone who reads it to consider this point much more broadly.

For example Ronan Farrow and Chelsea Clinton were both paid hundreds of thousands by MSNBC for essentially nothing. I think it's rather telling that people would prefer to focus on someone like Nicki Minaj getting money in clubs, but that's just me.

<comment><USER21> Celebrity culture has always been around, but in some ways it feels more noxious and gamed than it used to be.

Maybe it's just me, I guess. But when I look at someone like the Kardashians, honestly the only real reason they got this opportunity to be "famous for nothing" is their Hollywood connections. They certainly didn't rise up on their acting ability. The celebritization of "lucky sperm club" members as you mention also bothers me.

But, yeah, I don't get the article's attempt to drag other musicians / DJs / rappers into this. Well known musicians / performers going to a club and getting insane sums for simply performing? That's not news. Yes, today its EDM and rap in the club versus rock bands on the stage, but that's what is trendy now; big artists in the 1960s (your Beatles and whatnot) also got (2016 equivalent) six figure appearance fees too.

One can argue about the merits of the winner-takes-all nature of the entertainment industry, but it's a little less "money for nothing" in that case. Lil Jon _did_ have to spin a set.

</comment></comment><comment><USER22> And here I am thinking it is insane that people pay for pictures of people on TV shows at comic con and the like. I have quite a few friends who are traveling the con circuit and always thought it was a strange secondary job market where ex stars get appearance fees and people pay for money (guys like some random Star Wars extra).

Guess that's just small potatoes.

</comment><comment><USER23> This is some next level 0.1% shit.

<comment><USER24> I think we're hitting the .00001% here. Such a bizarre reality.

<comment><USER25> Actually, I think .1% might be right. .00001% is much, much richer than you are probably thinking.

99.9th percentile US net worth is about 30 million: [http://www.federalreserve.gov/econresdata/feds/2015/files/20...](http://www.federalreserve.gov/econresdata/feds/2015/files/2015030pap.pdf)

Arbitrarily assuming a 5% return on that, that's 1.5 million dollars a year, which is about $5K per day.

Go out to the club with a few of your .1% friends, and you are right in the $25K per table ballpark while still staying within budget.

</comment></comment></comment><comment><USER26> For politicians, authors, popular business people: this is called convention speeches.

For rappers, DJs, and Reality stars: this is called club appearances.

</comment><comment><USER27> I don't know what I'm more sad about in this article, the fact that so much economic activity is dedicated to boast oneself's social status by paying to gain proximity to celebrities, or that these parties are insidious to a celebrity's mental and physical health.

</comment><comment><USER28> Isnt this just advertising? I dont really understand how this is any different from other forms of celebrity endorsements such as basketball players pitching nike's. These guys faces are even on the flyers to the parties.

<comment><USER29> I think that there's a sense that, like, if you go and endorse a Nike shoe, okay, you might get paid a lot of money, but you still go and do a photo-shoot and maybe spend a frustrating day being filmed doing a jump-shot and have the director saying, "Okay, but can you do that with more _intensity_ ," whereas going to a club is supposed to be _fun_ \-- indeed, such fun that lots of basically ordinarily people pay fairly large amounts of money to go to it.

So these people are being paid not to, like, fake go to a club in front of cameras and it's work, but literally be paid to have fun.

I expect that the actuality of it is a little more complex than that, but there does seem like there's a grain of truth in it, too.

</comment></comment><comment><USER30> Celebrity culture of US is so bizzarelly different from the nightlife culture I know. I understand that some people just want to waste money sitting at the table with a celebrity, but why call this establishment a nightclub in the first place?

Clubs are places to enjoy the music — without phones, without friends, without stupid conversations. Things describes in that article are the exact opposite of this.

</comment><comment><USER31> The whole things seems incredibly distant and surreal to me, but I'm also the sort of person who would pay money to AVOID going to anything that bills itself as a "night club." I much prefer a cozy pub or a decent wine bar, ideally with the music low enough that conversation is possible.

But, you know, I'm a giant nerd, so what do I know?

</comment><comment><USER32> ahhh... it's "1 Oak", I was reading it as "10 AK". Silly me.

</comment><comment><USER33> They're leaving out the bigger part in that Clubs are a very easy way to launder money. When the hire these celebrities to show up it makes it even easier to move larger amounts of cash.

</comment><comment><USER34> #LateStageCapitalism

</comment><comment><USER35> And Larry Ellison, Mark Zuckerberg, Bill Gates, Steve Ballmer, Ev Williams, Marc Benioff, Sheryl Sandberg, Marissa Mayer, Arianna Huffington, etc... get Millions of dollars per day. Within any one of those weeks, there is an hour or two where they're not doing much more labor than a Scott Disick or Nikki Minaj in a club.

<comment><USER36> The difference is that the people in the article are being paid just to turn up. The business people you mentioned are in charge of large organizations that are making them money while they aren't around.

</comment></comment><comment><USER37> > SKAM Artist

Well, it's certainly a scam!

</comment><comment><USER38> SMSPF

</comment><comment><USER39> I click on this link and immediately my retina screams "please switch off!". It's an entirely different planet and species. An now I need to take a shower. /!s</comment>


Ask HN: Why Python is good choice? - <AUTHOR> I am new to coding, never programmed before. Is Python good choice? Why? <comment><USER2> What is the goal that you're trying to reach? General interest in programming? Implementing a specific solution at your non-programming job? Making inroads into a new career as a software engineer? Hobby?

</comment><comment><USER3> It's versatile, has a good community, and is very readable -- very important for learning imho.

</comment><comment><USER4> it's a good first choice; it introduces you to common concepts easily, it has a nice clear syntax and can be used in a range of paradigms (OO, FP, shell scripting).</comment>


Direct evidence for T-cell immunity as a factor behind Covid-19 heterogeneity - <AUTHOR> https://science.sciencemag.org/content/early/2020/08/04/science.abd3871 <comment><USER2> Misleading headline. From the article:

> Based on these data, it is plausible to hypothesize that pre-existing cross- > reactive HCoV CD4+ T cell memory in some donors could be a contributing > factor to variations in COVID-19 patient disease outcomes, but this is at > present highly speculative

Also I recommend to read this: [https://www.theatlantic.com/health/archive/2020/08/covid-19-...](https://www.theatlantic.com/health/archive/2020/08/covid-19-immunity- is-the-pandemics-central-mystery/614956/)

<comment><USER3> The section _Direct evidence of reactivity to HCoV epitopes homologous to SARS-CoV-2 epitopes_ [1]:

> we designed a peptide pool encompassing peptides homologous to CD4-R30 > epitopes, derived from HCoV-229E, HCoV-NL63, HCoV-OC43, HCoV-HKU1 and > several other HCoVs (see Methods), for a total of 129 HCoV homologs > (HCoV-R129; table S2). Similarly, we synthesized a pool that encompassed > peptides homologous to the SARS-CoV-2 CD4-S31 epitope pool, consisting of > potential epitopes derived from other HCoVs, for a total of 124 HCoV > homologs (HCoV-S124; table S3).

The "speculation" disclaimer, IMHO, is based on the assumption that the designed peptide pools invoke responses similar to their viral homologs. I have no issue with the "direct evidence" heading as this research makes an important step in demonstrating cross-reactivity.

Teasing out the degree of protection this cross-reactivity provides in real- world populations is a much harder problem.

[1] [https://science.sciencemag.org/content/early/2020/08/04/scie...](https://science.sciencemag.org/content/early/2020/08/04/science.abd3871#sec-4)

</comment></comment><comment><USER4> > We demonstrate a range of pre-existing memory CD4+ T cells that are cross- > reactive with comparable affinity to SARS-CoV-2 and the common cold > coronaviruses HCoV-OC43, HCoV-229E, HCoV-NL63, or HCoV-HKU1. Thus, > variegated T cell memory to coronaviruses that cause the common cold may > underlie at least some of the extensive heterogeneity observed in COVID-19 > disease.

Could we just start deliberately spreading these weaker cold viruses then?

<comment><USER5> Maybe, but thats basically developing a new vaccine, and in the time it takes to test that out and make sure it's safe and effective, we'd already have other vaccines on the market that might be more likely to be effective. Theres also the risk of antibody dependent enhancement where a competing immune effect makes the disease worse if previously infected with a different strain as seen in the dengue family

<comment><USER6> It's silly to think we're going to have a safe vaccine on the market any time soon. It'd probably be safer to give everyone coronavirus common cold viruses if it can build an immunity.

..and Immune Enhancement Syndrome one of the serious consequences of the SARS1 and MERS vaccines that never made it past their trials.

There are a lot of factors to immunity beyond antibodies. Traditional vaccines are either close viruses in the animal world (horsepox for smallpox) or heat treated inactivated virus (flu). We know they produce anitbodies, but there are hundreds of other parts of our immune system (complement system, inane, etc.) that might interact and form memory as well.

Vaccines come out of bad places; from eras where hundreds if not thousands of people were going blind, dying or getting paralyzed by disease. It was easier to just test things on people back then too, and a lot of them died (Chinese were inoculating people with actual smallpox 300 years before Jenner discovered making a vaccine from Cowpox/horsepox).

In the 1970s, the Swing Flu vaccine was a disaster. Sure millions of people got the vaccine and were fine, but 3,000 people developed Guillain-Barre syndrome. Some still have trouble walking or smiling (see the 60 Minutes documentary from that era)

Vaccines need a lot of testing. I do not understand why we're trusting the man who gave us Windows 95 to lead the Gates/Gavi alliance responsible for giving us a "safe" vaccine in less than a year. That's insane.

<comment><USER7> The problem is that, at least in some populations, these viruses are only moderately less dangerous than COVID-19. There are recorded nursing home outbreaks (e.g. [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2095096/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2095096/)) where a common cold coronavirus killed 5-8% of residents.

<comment><USER8> Without wanting to sound disrespectful to those affected 5-8% is pretty good for a care home.

<comment><USER7> It is, unfortunately, but it's probably bad enough that it's not something a government could deliberately do.

<comment><USER9> Would it make sense to skip those age groups? We still have social distancing in place; if we try to protect those people from sars-cov-2 they will also be protected by other milder variants we nurse in the wider population.

On a similar note: when a vaccine gets developed, does it make more sense to vaccinate those age groups (on the grounds that it will protect the most vulnerables) or to vaccinate everybody else (on the grounds that the vaccines may not be 100% safe and thus it may be safer for those age groups to benefit from the herd immunity)?

<comment><USER10> You cannot deliberately infect people of any age group anyway. I would skip it and doesn't sound more convincing than measles parties.

<comment><USER11> You mean you can't "ethically" infect people? I disagree, it just comes down to risk. Many vaccines and medications have rare but potentially severe side- effects, but we administer them anyway due to risk versus reward.

Let's say you have a 5% chance of dying from COVID-19, a 10% chance of contracting it, but only a 0.05% chance of dying from some harmless coronavirus that would reduce your chance of dying from COVID-19 by half. It would be irrational _not_ to deliberately contract the harmless coronavirus.

The problem is just that we don't know all these variables, especially for a given individual.

<comment><USER10> A potential COVID vaccine is an example. I doubt you could ethically instruct people to get a shot for such a health experiment. You can require them to get one to use certain services, but bodily autonomy has precedence in my opinion. That is even more relevant for living pathogens.

Being together with other humans is always a health risk if you want to look at it like that. While it might be incredible stupid to not take the lesser risk, you cannot force people to be rational.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> So basically this is saying that previous exposure to various versions of the common cold can lead to some covid resistance?

<comment><USER13> But why are the elderly more susceptible? Shouldn't the probability of exposure by higher, the older you get? Wasn't that the reason the Spanish flu killed more younger people?

<comment><USER14> Are elderly more susceptible to infection or adverse outcome once infected? In the latter case we still can see worse stats for the elderly.

</comment></comment></comment><comment><USER15> How can I get infected with one of those other Coronaviruses?

<comment><USER16> Exchange bodily fluids with as many young people as possible. AFAIK there's no way to be able to get voluntary exposure in a lab. Which is lame, imagine getting a precise dose of cultured $HCOV.

OC43 has like a 9% nursing home fatality rate tho (which is kind of a hint that SARS-2 isn't too special as far as mortality is concerned)

Anyway if you have kids you have probably already been exposed to one of these CoVs at some point. The TL;DR is the more you do real life stuff the more likely you are to have exposure. Add it to the long list of externalities due to lockdown. Natural spread of pathogens is a good thing and not to be feared.

</comment></comment><comment><USER17> From the abstract: "We demonstrate a range of pre-existing memory CD4+ T cells that are cross-reactive with comparable affinity to SARS-CoV-2 and the common cold coronaviruses HCoV-OC43, HCoV-229E, HCoV-NL63, or HCoV-HKU1."

1\. Populations may naturally have a head start towards herd immunity from COVID. 2\. Sweden could be really close in that regard; their current super low daily mortality and declining cases may point towards herd immunity.

<comment><USER18> The usual way to assess herd immunity is by antibody testing

I don't think Sweden got to 10% infection in the pop. at the moment (avg. for Spain is 5% and 15% on the heaviest hit cities)

<comment><USER19> The very article contradicts you.

<comment><USER18> I see, yes, the t-cell assessments are new but while we don't have accurate values for those countries we have to rely on the antibody testing.

(Not to mention this whole t-cell story is being used by negationists and "skeptics" to deny the _actual_ mortality of the virus)

<comment><USER20> A Swedish study has found that for X people with confirmed infection that have antibodies, another same amount have t-cells and no antibodies.

</comment></comment></comment></comment></comment><comment><USER21> What's up with the editorialised title, which clearly overstates the conclusions of the paper?

</comment><comment><USER22> Does this imply that the COVID-19 virus will morph into the common cold virus?

<comment><USER23> No. Mo more than a tiger will morph into a house cat.

<comment><USER24> Well, with a few hundred to thousand generations and a bit selective breeding i see no real problems here... just ask Fido about his wolf-great-great- great-(and so on)-grandfather ;-)

<comment><USER23> Yes, many things are theoretically possible. In relative terms Coronavirus isnt that mutagenic. Every year for many years millions of people get seasonal coronaviruses there hasn't been a "morph" (whatever that means). The SARS and SARS/CoV-2 crossovers did come from somewhere and it was bats which are REALLY good at being virus incubators. We are not. I guess in the environment we all are now in I'd prefer a message not be spread of a seasonal cold turning into a deadly respiratory disease based on such an apparently unlikely hypothetical. Or Let's worry about things like swine and avian flus, which are orders of magnitude better at "morphing" yet much of the population still refuses to vaccinate annually.

<comment><USER23> Just realized I got the original morph direction wrong. Please pardon.

<comment><USER22> That is possible, also viruses can make bacteria deadly, check this [https://www.sciencedaily.com/releases/2009/04/090417195827.h...](https://www.sciencedaily.com/releases/2009/04/090417195827.htm)

</comment></comment></comment></comment></comment></comment><comment><USER25> This would also explain why the anti-body tests have proved so unreliable. A lot of people already have reactive anti-bodies without being exposed.

<comment><USER16> Reactive t cells, not antibodies.

</comment></comment><comment><USER26> I believe Antibody is better than Vaccine [https://en.wikipedia.org/wiki/Antibody#/media/File:Antibody_...](https://en.wikipedia.org/wiki/Antibody#/media/File:Antibody_Opsonization.svg)</comment>


Meet Mycroft: Open Source Artificial Intelligence Powered by Snappy Ubuntu - <AUTHOR> http://insights.ubuntu.com/2015/08/14/meet-mycroft-open-source-artificial-intelligence-powered-by-snappy/

<comment><USER2> Name collision :<. I knew I should have been more original! Everybody who's read The Moon is a Harsh Mistress will have had the same idea.</comment>


Statements about the Mobile Web - <AUTHOR> http://jlongster.com/Radical-Statements-about-the-Mobile-Web <comment><USER2> Let's not kid ourselves here. Most people download exactly zero apps per month:

[http://www.slate.com/blogs/future_tense/2014/08/25/a_comscor...](http://www.slate.com/blogs/future_tense/2014/08/25/a_comscore_study_shows_that_most_people_download_zero_new_apps_per_month.html)

This matches my experience IRL exactly. The whole Native Apps are more popular than the web narrative is a self fulfilling prophecy. People have trouble using websites on mobile because everyone puts up stupid splash pages on sites to force them to download their app. It "educates" people that the web is somehow inferior, when really those sites should be making a proper responsive website so their users can get on with their lives.

Nobody gives two shits about your app and it's smooth animations when they are just trying to pull up a recipe for chicken tikka masala.

<comment><USER3> Are native apps more popular than the web? Probably not. Is it harder to make a web app to the same level of quality as a native app? Absolutely.

Making a "proper responsive website" for mobile is far more difficult than it needs to be. Assuming it can even be done. Some things you simply can't do. Can you reach just short of native quality by expending significantly more time and effort? Yes! Is that stupid and wasteful? Absolutely.

<comment><USER4> It's definitely hard to do animations and touch interactions as good as native apps. Making responsive websites is really really easy for an experienced designer and/or html coder.

<comment><USER5> > _Making responsive websites is really really easy for an experienced > designer and /or html coder._

Migrating old websites that do not respond + adapting web based apps to mobile is however, not very easy. These two cases are probably 90% of the use cases, as opposed to the other 10% that are "really really easy".

<comment><USER6> You can't retro fit responsiveness. Or at least you can, but it's such a bad idea that no one should try it. It's the quickest route to legacy CSS that no one will every want to touch again.

It means starting again, from design and UX all the way up to build. So for the entity that owns the website/web app it's going to be painful, but for every new website/web app, it's the norm and is pretty easy.

</comment></comment></comment></comment></comment><comment><USER7> Here's my guess for the future of the canvas web. JS will render to canvas. Later it will be discovered that the code becomes unmaintainable and multi tiered architectures will go in the browser/js with "BabyHTML" used as a template view language for the canvas to have a more standardized rendering - finally who wants to render pixels or vector graphics?. Then a BabyJS will be introduced inside BabyHTML to manipulate an object model called BabyDOM for the canvas to make more maintainable code and optional animation. BabyJS will be so fast that everything that can be written in BabyJS will be written in BabyJS. Then BabyHTML and BabyDOM will be claimed slow with frameworks based on BabyJS rendering directly to BabyCanvas which will be inside canvas which will be inside browser webview.

And all this repeats ad infinitum.

<comment><USER8> Everything old is new again. [http://cva.stanford.edu/classes/cs99s/papers/myer- sutherland...](http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland- design-of-display-processors.pdf)

<comment><USER9> The introduction alone just made my day, thanks for sharing.

It's about time that we take history more seriously.

<comment><USER8> Cheers

</comment></comment></comment></comment><comment><USER10> I hope 2015 is the year JS devs really start pushing for real async/threaded support in the browser. I was working on the reapp HN reader app[0] for the last few days attempting to find out why Safari would choke for up to 20 seconds on displaying ~500 DOM nodes, and this article just sparked an idea which turned out to be true: flex-box was causing it.

Switching to display: 'block' and it's under 100ms. I think now I'll look at using css-layout to just spit out absolute positions.

I also appreciate the shout out in the article to reapp. I've spend the last few days working with WebWorkers, which have some interesting potential, but without access to the UI are going to be tricky to implement. Again, the React guys have gotten something working, and we had an interesting conversation about using Flux to communicate between Workers/main thread, which I'll be exploring.

Long and short of it is this: We've gotten pretty damn close with the web these days. For anything that doesn't use exceeding long lists of media-heavy content, you can actually get 60fps with react. But you have to be _careful_.

I'd love to see UI workers, async DOM ops, and even Canvas support for better accessibility. Web developers should all be writing and voting up articles like this.

[0] [http://hn.reapp.io](http://hn.reapp.io)

<comment><USER11> Yup.

I'm currently working on a React-like interface over WebGL, and everything is just "absolute positioned" \- read, it's just GL matrices all the way down. It just works.

<comment><USER12> Interesting! Can you share more about it?

<comment><USER11> I've done the very basic ground work: [https://github.com/davedx/lustro](https://github.com/davedx/lustro)

</comment></comment></comment></comment><comment><USER13> To me, this "60fps or bust" notion that seems to have come up recently is complete and utter nonsense. It's masturbatory technofetishism.

In the eight or so years that I worked as a system administrator and the many more years that I have been the go-to guy for all things computer-y for friends & family, I have found the vast majority of people to be tolerant towards the inconveniences and failures of technology to the point of defeatism.

The things people put up with sometimes boggles the mind. Eight minute boot time to a usable desktop? _" Oh, I just tap the power button and get coffee"_. Half a dozen browser toolbars they never installed willingly. Popovers and popunders. Nagging Java updaters and upselling "security software". Forced reboots that kill your unsaved changes over lunch when Windows decides to install updates. And, and, and…

That story hasn't changed one bit on mobile. _" Well, I know know that I have to restart my phone [for two minutes] before I can play this game, because it crashes otherwise"_.

There's a good chance that this is the majority of people interacting with your app, site or gadget.

If you can squeeze out silky animations and buttery scrolling out of a complex web app, go for it. I'm the first to marvel at your ingenuity and applaud.

But if you honestly think that these people care enough about "60fps scrolling" that it warrants reinventing pretty much the whole of HTML and CSS in Javascript — badly —, then I don't know what to tell you.

</comment><comment><USER14> And beyond the performance issues, app design on the web is a massive pain.

Despite the advances with CSS3, we're still working with a layout engine that was designed for documents rather than applications (mobile and otherwise), so many seemingly trivial tasks (e.g. centering and vertical alignment) involve an unintuitive mess that I after 10+ years of experience, I still need to lookup from time to time. [Edit: I should have been more clear--I'm referring to issues that flexbox doesn't resolve such as aligning/sizing elements relative to each other rather than to their parents.]

On top of that, we're seriously in need of better tooling. It feels like we've spend the past 10 years developing a set of powerful primitives but ignored building tools that truly empower our creativity on the web. Sometimes I really miss how fun and simple it was to use Flash to build things when I was a kid...

...and that's the whole point really, isn't it?

<comment><USER4> Just use flexbox. I've recently started doing iOS dev, and I really miss the simple, declarative, consistent web layout tools. In iOS, there's a broken drag and drop editor that can do about 80% of what you need. You then need to go in and call a bunch of arbitrary methods that do various things to different UI modules, with no consistency between modules. Everything is very ad-hoc and one-off and you don't have much choice in what to use. I will say that all the animations are pretty smooth once you call the right combination of weird arbitrary methods to do what you need.

What is this legendary interface system that is better than the web? I'd like to use it.

EDIT: As for tooling, I guess it's just a difference of opinion, but I love the fact that there is none for the web. It forces everything to actually implement elegant and understandable API's. Too many IDE-based systems use the IDE as a crutch allowing them to create inelegant systems that would not be possible to use with it.

<comment><USER14> I should have been more clear with the centering issue: I'm looking at something like GSS [0] as a model of what would be incredibly useful.

As for IDEs, I've always used a text editor for web dev, but there's something incredibly fun about being able to draw components and move them around on your screen as opposed to having to mess around with something like the Canvas API. I built fairly complicated little apps with Flash when I was 10 that would take me 10x longer (at least) to implement in HTML5.

0: [http://gridstylesheets.org/](http://gridstylesheets.org/)

<comment><USER4> Yes I definitely agree on GSS. Can't wait to try it!!

<comment><USER15> CSS grids ([http://caniuse.com/#feat=css-grid](http://caniuse.com/#feat=css- grid)) are on the rise too I think.

</comment></comment></comment></comment></comment><comment><USER16> This is dead right.

The fun begins when you think about how this impacts anything that tries to scrape web pages, because the side effect is going to be a lot of impenetrable data silos.

Google and co will have to actually run web browsers in the cloud and use OCR to do indexing if they aren't already.

<comment><USER17> My guess is we'll come up with a sort of standard API using JSON or such that we will make available the information and ultimately mimic what HTML does now.

<comment><USER18> Let's use an xml-like (but not really xml) syntax instead. And we'll make it so the browser can view this format natively (with no javascript).

</comment></comment></comment><comment><USER19> So, there is a cheap way to communicate between the DOM thread and web worker threads. It's called Transferable Objects. The technique involves postMessage()'ing a Typed Array's ArrayBuffer as your message payload. Rather than making a copy of the bytes in your sending thread's Typed Array, the byte buffer is "detached" from the sender's ArrayBuffer and "attached" to a new ArrayBuffer on the receiver thread. This allows you to do huge bulk operations on a worker thread, generating megabytes of data for the DOM thread and not taking a penalty of allocating memory, copying the data, and garbage collecting a big allocation on the sender thread.

Transferable Objects are not as useful as, say, being able to access the DOM from a worker thread. But there are many tasks that ultimately feed DOM updates, are data intensive, and could be mostly offloaded to a worker thread with the final update payload fed to the DOM thread via Transferable Objects.

[http://updates.html5rocks.com/2011/12/Transferable- Objects-L...](http://updates.html5rocks.com/2011/12/Transferable-Objects- Lightning-Fast)

The DOM/Layout/CSS is a crufty document engine. Is it reasonable with today's hardware to have a 60Hz scroll rate benchmark of quality? I think expanding mobile main memories and CPU advances this decade will make it more reasonable.

How about framelocking us to 30Hz on mobile, could we be satisfied with that? Makes me wonder if there is a way to framelock a browser scroll with requestAnimationFrame().

\-- edits clarifying ArrayBuffer

<comment><USER20> The problem with Transferable Objects is that they only work for raw buffers. This is great for math intensive tasks such as image processing, but not that great for UI related tasks.

We want to be able to share js objects, arrays and strings in a fast way. Otherwise you either need to build your entire app on-top of raw buffer but that doesn't look like JS anymore, or you've got to do a serialization step and you're not gaining much compared to JSON serialization.

I'm super excited about immutability because it lets us share objects between different threads very cheaply and still letting us use normal js constructs. I'm not sure anyone is working on it though :(

</comment></comment><comment><USER21> Nice to see the random Servo reference drop, it's cool to see it gain recognition outside of Rust circles. They're doing so much cool stuff.

<comment><USER22> I used to think Servo would just make the web a little faster, and never understood the true impact it might have until this comment: [https://news.ycombinator.com/item?id=9011215](https://news.ycombinator.com/item?id=9011215) and pcwalton's response in that thread.

Servo is going to completely expose the worst parts of our current web. I'm hopeful it will start influencing standards to expose sane APIs that make it easier for current engines to parallelize.

<comment><USER23> Another neat, releated, thing we can do in Servo is to run all CSS animations off the main thread, even ones that require reflows. I actually think that may be one of the biggest, if not the biggest, wins of Servo's architecture…

<comment><USER22> While that sounds really interesting, CSS animations are somewhat limited and its hard to do gesture or physics-based animations with them. We really need good, fast JS-based animations. Also, whatever handles touch input needs to apply the animation in the same thread.

The React Native devs have a lot of reasons for the above, if you want more reasoning might be good to check it out when its released soon.

Still, that sounds really cool!

</comment></comment></comment></comment><comment><USER24> I wish it wasn't true - but if there is a native app available for a website/service i wish to use - I choose native app almost all the time. Each of these services have a 100% work website & maybe a mobile-web: \- Ebay, Amazon, Mint, SigFig, Homejoy, MerillEdge, BofA BillPay, PizzaHut, Dominos... Somehow using their native app feels solid, real and not flakey. I don't have a feeling that I will loose my shopping cart or be logged out due to an error/network connection etc.

I am a big advocate of truly native mobile web, but honestly the first thing i look for when i love a service or website is: "Do they have an iPhone app?"

<comment><USER25> I think this also speaks to the effort these companies have put into their mobile web apps. For a while I used the web FB app because their iPhone one was fubar.

<comment><USER26> No, it just speaks how far behind (and the wrong origin) of the mobile web apps tech is compared to native SDKs.

<comment><USER25> You're right, that is the only possibility ¬_¬

</comment></comment></comment></comment><comment><USER27> The 60 fps thing is super weird to me. Do people really care if their website/mobile app is 60 fps? Who are these people?

The only place I could possibly imagine that mattering is for fast-twitch video games, or theoretically videos (though most of those are still 24 or 30 fps).

<comment><USER28> Yes. Anything less than this becomes perceptible and starts to make the UX feel janky or sluggish. That is a huge turn-off for a lot of users, even if they can't pin down the exact cause being low framerate.

And framerate in UI is a different beast compared to video. A menu animation running at 24fps feels much choppier and sluggish than a video running at 24fps.

<comment><USER29> No. The amount of fames you need depends on the distance an object moves per frame.

I really don't want to argue about this so I figured I just let you experience it yourself: [http://jsbin.com/qizatugepo/1/edit?js,output](http://jsbin.com/qizatugepo/1/edit?js,output)

Frame _drops_ are a different story entirely. The swap_control_tear extension for OpenGL takes care of that to some degree though.

<comment><USER30> Typically in a mobile app I'm flick scrolling at speed through lists. So the maximum distance travelled per frame is pretty high.

<comment><USER29> Same here. I was trying to point out that frames per second alone isn't a useful metric for "animation quality." Ideally, you'd want to compare the frames per second to how many pixel something moves per second (or something similar).

Having said that, shooting for your monitors refresh rate isn't a bad idea — it's just that you could use those cycles (and watts) for something else. And even worse, if your app is running at 60 fps most of the time but drops to 30 fps every now and then, then it's gonna look a lot worse than the one that runs at 30 fps consistently.

</comment></comment></comment></comment></comment><comment><USER31> I'm pretty skeptical of React Native, for the same reasons you're nervous about the web. The great thing about Native development is you can drop down pretty low and optimize. During native development you do it alot. The native widgets don't suck, but performance can be awful as soon as you want to draw anything remotely special. So you drop down and start writing custom layout and drawing routines. I don't see React being good at that (maybe I'm wrong though, I haven't dug into it).

Those problems aren't that far from the web. There's no reason you can't draw entire pages made of canvas[top="0"][left="0"] and then measure position/transform everything by hand. You'd probably get great performance that way. Its basically what Flipboard did from what I read. Its what native app developers do as well. Phones suck. They have no power. You basically have to do this stuff to make them work. I have no idea why the web-dev community freaks out when someone does it. "You wrote a custom layout engine! Are you nuts!" is not something you'll hear from Android or iOS devs.

</comment><comment><USER32> Layout and performance of the mobile web is a red herring in the argument of why mobile web is losing. It's not just this. There are so many other factors that I rarely see mentioned. Encrypted / protected caches, local databases, far more persistent logins and UUIDS, sensor integration without the annoying Browser requests x feature modals, launching from the home screen, consistency of experiences because of standard human-interface guidelines, background sync and notifications, integrated payment systems, and on and on.

Apps integrate with the entire rich ecosystem of the device and web apps barely / inconsistently do. There is work happening on all of the above things (kind of), but the experiences arent competitive, the work is piecemeal and the pace is far too slow for people who have the webs best interests at heart. The web is losing because the consensus model for standardising and making available the tools for building the web is antiquated and terribly ineffective. Unless there is a massive change in incentives for standards committees and mobile browser providers this wont change.

<comment><USER12> _local databases_ :

SQLite is available on Android and iOS by default, and available for WinPhone 8.

Yet, some die-hard NoSQL lovers stopped the HTML5 _Web SQL Database_ API: [http://en.wikipedia.org/wiki/Web_SQL_Database](http://en.wikipedia.org/wiki/Web_SQL_Database)

It's still available in all WebKit based browsers incl. Android and iOS. But famously Firefox/FirefoxOS and IE/WinPhone don't support it. The proposed NoSQL replacement _IndexedDB_ has a complicated API and never got traction, one has to basically use a shim library. Working with several tables and indexes is trivial in SQL, but complicated and requires a lot of specific code in IndexedDB (NoSQL).

There would be place for SQL as well as NoSQL in HTML5.

* The argument that WebSQL was tailored to a specific SQLite version is nonsense. SQLite supports the official SQL92 standard, as do several other SQL embedded engines like the SQL engines from MS Access, MS Outlook, MS SQL Embedded and many others. Also Firefox already ships with SQLite for its "awesome bar" and bookmark feature.

* Also the argument that it's "hard" to sync a client side database with a server side database is nonsense. But the two argument basically stopped Web SQL as HTML5 API :( The developers who voted against Web SQL were (former) employees of two big server side SQL db vendors (see the related mailing lists and blog).

Nowadays with the rise of NewSQL movement of people who burnt their fingers with NoSQL, one can only hope someone gives some love to Web SQL.

To sum up, NoSQL has it's place and SQL has one too.

<comment><USER33> Can't upvote this enough. If there's anyone here on the W3C, consider this an upvote for bringing back WebSQL.

IndexedDB reminds me a lot of the Drag and Drop stuff the W3C settled on: several different kinds of awful.

</comment></comment></comment><comment><USER34> Question: why didn't any of these issues prevent the web from taking over the desktop during the years between 1995-2005? Native has always been faster and more feature rich, on every platform and at every point in time.

<comment><USER12> Really? If you use Windows, you should be familiar with Windows Explorer. Since Win95 with Internet Explorer 4 desktop refresh (shipped also with Win98) you have a trident (IE) web engine in Explorer. The side bar with the metadata and info is DHTML in Win95(IE4), 98, ME, 2000. And a fork of trident code is used in XP and newer. Also WinXP "Software" application to uninstall programs is basically DHTML based. The newer control panel pages, the newer dialogs, etc. The EU demanded that Microsoft has to document the new UI-engine, used in IE "addons" dialog, Vista/7/8/10 Explorer bars & shell dialogs and Office 2007+, so that there no completive advantage. One has yet to find that in MSDN.

</comment></comment><comment><USER35> Besides accessibility, if you replace everything with JS and Canvas, you lose transparency. Content then becomes opaque, siloed behind services, and requires running code to discover.

If we are to replace with a native-app style model, it needs to be far far more transparent that what is on iOS and Android with respect to exposing links and content in a way that is transparent.

If we convert the Web into a Web of Binary Applications, who query all of their information through private silos, we may as well just close up shop, because we'll be forgoing the greatest values of the Web, Links and Transparency.

We need to stop panicking over mobile native and FPS.

The idea that "60 fps is required" is a complete myth. Most triple-AAA game titles people pay $50 for on consoles don't hit a solid 60fps, most of the time, not even a solid 30fps -- typically frames are dropped in busy parts of the game.

The ideology that Apple has foisted on design, that somehow no one will use your app if it is not perfectly rock solid 60fps (iOS isn't even 100% jank free) is damaging.

</comment><comment><USER36> For performance, I agree with many here, it's not the number one priority. The critical parts missing are:

(1) a way to install web apps that hasn't to be learned, like Mozilla's Intall API, and unlike the bookmark to homescreen UI

(2) offline APIs: ServiceWorkers seem great but, Safari support could come as late as fall 2016 I guess, and be botched up for a year or two like they did with the history API and IndexedDB; in the meantime, offline web apps are screwed

(3) full screen API: not having the ugly address bar all the time which reminds users this app is unlike others and may be substandard; and being able to lock screen orientation

(4) notification API: the users expect anything important your app displays, they can be notified about, otherwise, your app seems unreliable

Except, the notification API, both iOS and Android had all of those from the start. Only then should we worry about performance, sensors, frameworks, layouts, ...

Regarding image decoding, why can't browser vendors do it today off the main thread? Is a change in web standards required? It seems no one has implemented it, so if it was a low-hanging fruit material to performance, it would be done already. In my experience, image decoding is only an issue for infinite scrolling, when javascript inserts images too late for the browser to have smooth scrolling. Infinite scrolling is nice sometimes but not all lists have to be infinite, have they?

</comment><comment><USER37> I realize the web has a huge headstart on anything else, but what prevents someone (or us, as a community) form creating application containers that are not web browsers. Why not something like a "Python Box" where you can download and run applications written by developers in Python, and where the UI is rendered asynchronously in just the ways people say they want it (at least in this thread).

I know that on day one there won't be anyone on your "Python Web" or whatever alternative browsing box you make, but if its nice to developers, and if it really does give users a better experience, then eventually we'll see people use it ... just like any good idea takes root in the long term.

I know the web is already here, and it makes a lot of sense to leverage the fast V8 engines we already have pre-installed on all our users' desktops and devices, but I am really surprised that we haven't seen any alternatives in the two decades since we've figured out that Javascript/CSS/HTML really suck for a whole class of applications.

I suppose you could say the JVM was one attempt to do this ... but the JVM was proprietary and it wasn't properly marketed to end users.

The app box I'm talking about should be something that users feel they have to download because it will be an infinite amount of fun.

Security is a huge problem I know. But surely we can figure out something using containers/VMs etc. to airlock all the random code that will be downloaded into the box by users.

<comment><USER38> There will be no support for any alternative here,it's over. Vendors will never agree on what would be the right solution.

Furthermore. There is already a solution: bypassing the dom and using canvas/webgl for the UI, and whatever language you want for the rest.If you want to use Python or Java, i'm sure you'll find an implementation that compiles to Js. The future imho is clearly C/C++ and EMSCRIPTEM with canvas/Webgl which would allow gpu acceleration for the UI and asmjs optimisation for the code. Which is totally ironic I must say. Using a low level language on a "high level" plateform.

</comment></comment><comment><USER39> The points raised are good, but I think web vs. native is a false dichotomy to be honest. It is quite possible for both to co-exist. The problem I see here is that, by losing the shackles of backwards compatibility, native vendors are able to move much more quickly and that upsets developers in much the same way kids get upset when their sibling gets a shiny new toy.

The pragmatic kid will try to find ways of sharing the toy, or get one of their own, but the stubborn kid will convince the others that their toy is batter, faster, smarter, stronger, and all of the things. The analogy breaks down a bit, but I hope my point gets across.

The web, for all its warts, is a wonderfully resilient system. It can break any which way and it'll still probably mostly work. Most other systems simply don't work that way, because it's damn difficult to build such systems. By working within the constraints of the web, you're almost forced into it.

What we can do to help developers better leverage the web, regardless of whether their UI is native or HTML, is to not be religious about the things that don't really matter – which I think is what James is trying to really say. His points are clear and good, but the underlying (and in some parts quite explicit) message is one of: let's not be kids.

Our toys are sometimes broken (DOM, CSS layouts, single thread execution models) and we should consider changing them for better models or even new ones, that aren't so broken. But we have to stop the in-fighting, zealotry won't get us anywhere.

\---

It should also be noted that James' post while talking about the _web_ is actually more about _rendering_ than anything. There is so much more to the web, architectural principles that transcend platforms – such as hypermedia, stateless message transfer, metadata. Let's not pretend rendering is the end- all be-all that the web has to offer.

</comment><comment><USER40> People keep saying "The DOM is slow", which is true, but they forgot to talk about how "Everything else is also slow". I.e. even with React and make sure every shouldComponentUpdate gets called, we're still getting slow performance. We need to start using all kind of hack to make it faster. Sometimes it's really frustrating to spend a day to make it look native while it'd take 10minutes with native android. I've been trying for years to develop cordova apps to avoid duplicate codebases, but I feel like it's just not worth it. It's supposed to save money and time, but in the end it just take more resources to get a shittier experience. So, definitely looking forward for background task and faster DOM manipulation.

But also, to be fair, if Apple could fix their damn webview, performance would be much much better. I've been told that they're not fixing it on purpose.

<comment><USER41> Apple provides a WebView API in iOS 8 with JIT enabled. Any one who uses the new API will see same performance as Mobile Safari.

<comment><USER42> The WKWebView is buggy/breaking enough that the Cordova team has still not integrated it: [https://shazronatadobe.wordpress.com/2014/09/18/cordova- ios-...](https://shazronatadobe.wordpress.com/2014/09/18/cordova-ios-and- ios-8/)

</comment></comment></comment><comment><USER43> About prediction #1 - here is micro angularjs demo showing angularjs digest cycle running in separate worker [http://glebbahmutov.com/blog/run-angular- digest-cycle-in-web...](http://glebbahmutov.com/blog/run-angular-digest-cycle- in-web-worker/)

</comment><comment><USER44> The DOM is to slow on mobile issue is what spawned [http://famo.us/](http://famo.us/). They go beyond virtual DOM by creating their own layout engine that then outputs to optimized DOM (or canvas/WebGL).

<comment><USER45> React also has its own implementation of the Flex layout system. Implemented in JavaScript and C++ (for react native).

</comment></comment><comment><USER46> There's a progression from _ignore mobile_ => _make it work on mobile_ => _responsive design_ => _adaptive design_ => _mobile first_. But that's not far enough. Native mobile apps are _mobile only_ , so in order for web apps to compete head-to-head, they need to be _mobile only_ too. That's a cultural leap the web needs to make. "The web has failed to beat mobile because it lacks 60 fps" seems premature until we finally figure that out. I'm not saying all webapps should be mobile-only, just ones that truly want to compete with native apps.

</comment><comment><USER47> I am not a "web developer" at the moment but rather into signal processing and I can only agree. Why is it so hard to just draw a pixel on the screen? Or why are there so many ways of doing it?

<comment><USER48> This is absolutely not related to the subject at hand though.

If you're talking in a general case, it's because it is actually hard. Send the buffer to your gpu, have it execute the command, send it to your screen which probably has a CPU of its own. Pushing a pixel is hard, and you have to do it 60 times a second. That's also why you don't just push a pixel but the entire screen at once. How hard it is for you depends entirely on the API. While Direct3D/OpenGL expose all the details, others like XNA or even Javascript's canvas do it rather painlessly.

What's really hard isn't pushing a pixel to the screen: it's doing it fast enough (i.e. same as your screen's refresh rate ideally) so that the user doesn't notice a visible delay. When 75% of the API is blocking AND you do work on the UI thread (Which is absolutely insane that browser developers haven't picked up this practice considering it's been advocated for more than 15 years on the native side of things), it's usually going to be visible.

</comment></comment><comment><USER49> >> _The web isn 't close to competing with higher-end native apps._

I made the switch from web development to native app development after leaning this fact at the HTML 5 conference a couple years ago. Every framework, rendering engine, etc., touted its strength in terms of a percentage of native app performance: this renders 80% as fast as native code, that responds 90% as fast, etc., etc. At the end all I could think was _why are we wasting our time with mobile web?_ "

</comment><comment><USER50> > By now it should be clear that too many users would choose a native app over > a web app.

I, for one, don't.

Why install a 500MB Facebook app when I can get the same news feed with a 1kb bookmark?

</comment><comment><USER51> The point about religion is key. We _really_ need to go back to basics with this stuff and reevaluate what exactly we're trying to achieve here from the ground up. We simply cannot retain first-class support for 20 years of legacy cruft _and_ make meaningful progress. So if we could start again today, what would we want from a 'browser'? How about:

        - A cross platform execution environment
        - Hot code loading
          - Fetch, load, run in seconds
          - Source based; inspectable by user
        - Complete separation from the host OS except via well-defined, permission-based APIs
        - A mechanism for including 3rd party code and UI modules, fetched at runtime, and appropriately sandboxed
        - A suite of strong, high-level, declarative UI APIs
        - A suite of strong, low-level, UI APIs
        - Good crypto support
        - Pain-free concurrency
        - A nice language that behaves well as a transpilation target
          - Ints, floats, and all the other wonderful number types (and not just in arrays)
        - Strong support for displaying structured information
          - Accessibility, extraction, etc
        - etc, etc, etc

I don't know about you, but none of these things scream HTML, JS, or CSS to me. HTML is an arbitrary XML schema that's fixed and subject to standardisation because it's trying to do too much: it cares about layout, content, semantics, accessibility, and programmatic stuff. All of that needs to be parsed out into separate, much simpler data structures anyway to actually be used.

And I'm sorry if I'm offending your world-view here, but JavaScript is a complete fucking mess. If you love it that's great - nothing to do with me - but as the _only_ language on _the_ dominant end-user runtime environment? What a sick, twisted joke. Honestly how much time has been wasted dealing with it's deficiencies? With a language that has a monopoly, every little quirk, every tiny failure in the design process that makes it do something you didn't expect translates to hundreds if not thousands of _man-years_ shat away. I'm not exaggerating either: shit adds up at scale (and if you don't believe me, consider that the subset of British people who actually had reason to call the government(?!) last year spent a cumulative _750 years_ on hold).

So much of everything we do (in the western world, at least) is dependent on the technology we have for creating, moving, and consuming information, and the browser is the king of this world. So it's not just _mission critical_ that we get it right, it's _economy /happiness/progress-as-a-species_ critical too. A big shift here would be in the same ballpark as the switch from steam to internal combustion! And we already know it's possible, we're just too risk-averse to commit - but that's the short term view, in the long term digging this hole any deeper carries significantly more danger.

I suggest we take the plunge and commit to a wholesale overhaul to something correctly designed by the best minds around, and with an aim to deprecate the current system in 5-10 years. We're (slowly) doing it with IPv6 because we have little choice, let's not wait for that to happen here - let's get it done before we're in a corner and are forced to make a tonne of half-baked decisions in a hurry.

<comment><USER52> _> A nice language that behaves well as a transpilation target_

Could you rank your preferences?

<comment><USER51> Lisp

</comment></comment></comment><comment><USER53> Actually, we are building web-first. We believe we'll be able to optimize enough locally by caching files in a bundle and intercepting requests PhoneGap style. We've already tried it, but here's the web (non-cached) version:

[http://qbixstaging.com/Groups](http://qbixstaging.com/Groups)

Built with [http://platform.qbix.com](http://platform.qbix.com)

</comment><comment><USER54> I think major problem is connectivity. Make your site work offline and with slow connection and you are there.

500KB of javascript and CSS code is another problem

</comment><comment><AUTHOR> I think James is on target in many ways, but I just wish it wasn't such a bleak near term outlook for high end mobile web apps. I don't want to write my app differently for different devices. I know that is the reality of today, but it is an unfortunate reality.

That said, many apps don't need to push the limits and PhoneGap or a similar solution is sufficient.

<comment><USER55> It would be lovely if this could get solved. Making an app that works across platforms would be ideal. But every app needs to work smoothly and without jank because engagement is key. Even if you don't mind it matters to more people than anyone trying to avoid native apps likes to admit.

<comment><USER56> Yeah, if you have the resources. But so many native apps are a Web view with a couple controls slapped on and extra ads that I am wary of installing anything at this point.

</comment></comment></comment><comment><USER6> Aren't the browser vendors better placed to fix these issues? Why can't they implement a virtual DOM with super cool DOM diffing? Of course they can, and of course they will.

</comment><comment><USER55> "The DOM is slow": with all the advancement of the JS engines we'll hit a wall if the DOM does not start improving by an order of magnitude.

Is this a fundamental problem or is this a case of JS being so bad that now that it's faster it is exposing a need to focus on the DOM?

<comment><USER57> I write a lot of mobile web apps and find that the DOM is blazing fast. I wish I knew some examples of why people think that it is slow, but I have a few guesses.

1\. Your mobile web framework is slow, not the browser DOM. Ditch your bloated frameworks - writing JavaScript without external libraries is not rocket science.

2\. There are deliberate pauses in the DOM. The _onclick_ event is very slow and unresponsive. I get very fast UIs by replacing it with _ontouchstart_

3\. You are using too many animations. Smooth animations can work in mobile web, to a degree. But honestly, if the big reason nobody wants to do mobile web is because it doesn't support copious animations, I see that as a positive. I'd rather have a UI that just does what it should without having to wait through all the fanciness.

<comment><USER58> I'd love to see some examples of non-trivial apps written in pure JavaScript which:

a) has decent browser compatibility b) is not a rat's nest of shims and polyfills c) could be maintained by more than one person

<comment><USER59> Why browser compatibility? Why polyfills?

I don't understand the logic that goes from "Modern browsers with fast JS engines make fancy web apps practical" to "let's make sure our fancy web apps run in old browsers with slow JS engines."

<comment><USER58> The original commenter asserts the DOM feels slow because we use bloated frameworks rather than pure JS. Sure, you certainly can use pure JS to target a select few modern browsers, but I've yet to see a practical story on how to build apps for the rest of the web at large this way.

Are we saying in order to go fast, we should eschew the progress we've made in compatibility to accomplish it?

<comment><USER59> In some cases, yes.

If you are committed to doing everything in JS, then you have two choices:

1\. Deliver a degraded experience to modern browsers and a terrible experience to older browsers.

2\. Deliver a good experience to modern browsers and no experience at all to older browsers.

Depending on your business model, #1 may be the best choice. But if you're trying to compete with native apps then #2 is the only thing that makes sense.

</comment></comment></comment></comment></comment></comment><comment><USER60> Why is the obvious so radical? Probably because YCombinator loves to delete anti-js comments on here? I mean hellbanning is one thing but completely removing the comments is another.

</comment><comment><USER61> Once you go Canvas, you never go back!

<comment><USER62> Hell yeah! Noticed opentype.js is merging in some of that new Path2D sass too. Lets just use the DOM for what its good for, the slower more form based aspects of an app. Then use canvas for what matters most and be done with it.

IMHO state is where its at. Separate state from function and feed the component changed state and render as fast as possible. Much depends on what you need to render too. In my case I have a ton of rules for variations, which can be exchanged for even more variations, its its own injection solution.

Therefore I'm super happy about the dumb as nails canvas, it just does its thing and the state does its thing, really snappy. I don't need a scenegraph either, just a hit detection system, but hey, thats custom and thats fine.</comment></comment>