Why Sub-Prime Lenders Didn't Cause the Housing Crash (2015) - <AUTHOR> http://knowledge.wharton.upenn.edu/article/why-sub-prime-lenders-didnt-cause-the-housing-crash/ <comment><USER2> This article is little more than an argument about semantics. Whether prime or subprime, the real culprit was mortgage-backed securities. At the height of the bubble, banks were merely underwriting loans and they couldn't sell them fast enough as MBSs/CDOs, a market of which was experiencing its own shadow bubble. Banks were basically shifting risk off of themselves.

When housing crashed (and subsequently the MBS bubble pop), banks like WaMu and Wachovia were left holding too many loans (prime and subprime) and no market to offload them, which quickly lead to their insolvency.

<comment><USER3> > Banks were basically shifting risk off of themselves.

FDIC means that banks are not held responsible for losing depositor money, and depositors no longer pay attention to how risky the bank's financial practices are.

<comment><USER4> The FDIC provides insurance which is paid by the member banks. They're held responsible in the same sense that individuals who pay car insurance are held responsible in car accidents. It's in their best interest not to lose deposits, at least as far as the FDIC is concerned.

[https://en.wikipedia.org/wiki/Federal_Deposit_Insurance_Corp...](https://en.wikipedia.org/wiki/Federal_Deposit_Insurance_Corporation)

<comment><USER3> When was the last time you or anyone you know checked the solvency or the soundness of the financial practices of the bank your checking account it in?

I'm betting on "never". I haven't either.

This wasn't true before the FDIC. Banks tried to project an image of conservative solidarity. They don't bother with that anymore.

<comment><USER4> Can you point to where the FDIC as an institution is responsible for this? The primary banking crises of my lifetime were the S&L in 1980 and the 2008 bailouts, neither of involved the FDIC. In the S&L crises, the responsibilities of the FSLIC (which were responsible for insuring the S&Ls) were transferred to the FDIC, and FDIC banks ended up contributing into the bailout, but I would have a hard time seeing the FDIC (as opposed to the FSLIC) as a direct cause of the S&L crises.

As for "solvency", I frankly _do_ take into account bank reputation (admittedly as a proxy for solvency or soundness) when opening an account. I also know the difference between a credit union, a bank, and a savings and loan company, and other financial services companies. I know the regulations between these differ. I also know that the regulations of accredited banks (as opposed to other financial institutions) are pretty stringent and don't allow them to hand out loans of the type that played a role in the 2008 crisis. One of the reasons these crises happened in the S&L and mortgage industries was because the regulations that covered those particular instruments and institutions weren't as stringent as the banks.

It's easy and understandable to conflate banks and other financial institutions because often they're inter-related, but they are separate, and to really understand what happened requires taking these differences into account.

Please don't read this as some sort of apologia for the financial industry: it's not. In my opinion there are systemic problems. I do take issue with landing this at the feet of the FDIC.

<comment><USER3> > Can you point to where the FDIC as an institution is responsible for this?

The most obvious is to look at bank buildings built before the FDIC and after. Before they were massive stone edifices with spectacular vault doors inside very visible to the customers.

[https://upload.wikimedia.org/wikipedia/commons/f/f8/U.S._Nat...](https://upload.wikimedia.org/wikipedia/commons/f/f8/U.S._National_Bank_Building_- _Portland%2C_Oregon.jpg)

[https://upload.wikimedia.org/wikipedia/commons/thumb/8/87/Wi...](https://upload.wikimedia.org/wikipedia/commons/thumb/8/87/WinonaSavingsBankVault.JPG/300px- WinonaSavingsBankVault.JPG)

After, they were cheap insubstantial buildings in strip malls. The corner Radio Shack here has morphed into a Wells Fargo branch :-)

This one looks like a gas station:

[http://www.jeffarchitect.com/images/projects/exp- websterbank...](http://www.jeffarchitect.com/images/projects/exp- websterbank.jpg)

<comment><USER4> Churches have undergone similar changes in architecture. The local roller rink is now a church. I included a lot more in my comments which is more substantial. If this is what you're going to continue with, it's hard to imagine the conversation is likely to improve. Best wishes and I hope you enjoy the rest of your day.

<comment><USER3> Very few monumental churches were built in the US. The monumental ones in Europe date from eras where the church was able to forcibly extract funds to build them - not volunteer donations.

It's a very different dynamic.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> I think the article is junk but that first comment by Dodson is solid gold.

<comment><USER6> I agree - especially this part of Dodson's comment:

"When sub-prime borrowers began to default in droves and the value of the private label MBS tumbled, investors also pulled away from the conventional MBS market as well, even though these borrowers continued to make their payments. However, with a short period the domino effect of defaulting mortgagors spread and then began the recession."

I've always viewed the housing crash as the result of the bottom falling out of the housing market. I don't know how common it is now, but in the early 2000s, it was very common for people to view homeownership as some sort of magic escalator to riches - one would buy a home, then basically be guaranteed to resell it for significantly more later, and the gains would be used to buy a more expensive home.

I went to a free "how to buy your first home" presentation around 2002, and this was exactly the model recommended by the people giving the presentation - people who worked in the home loan and real-estate field. Basically "buy the most expensive house you can possibly afford now, because you'll be making more money in a few years and what you think is an expensive monthly payment now will seem like nothing. Then you can resell your home and buy something even fancier."

Obviously, this depends upon a constant influx at the bottom of the "escalator", which is unsustainable because it's a pyramid scheme. The collapse of that pyramid is exactly what happened, IMO, and it wouldn't have been possible without the sub-prime lending.

<comment><USER7> > _The collapse of that pyramid is exactly what happened, IMO, and it wouldn > 't have been possible without the sub-prime lending._

imho, housing prices would have declined sooner. The valuation of houses was already wacky in 2001 by many measures. For example, look at the price-to- rent:

[https://3.bp.blogspot.com/-GVhHsBNhPfE/WP-6gJXNhTI/AAAAAAAAq...](https://3.bp.blogspot.com/-GVhHsBNhPfE/WP-6gJXNhTI/AAAAAAAAq6g/KfHIu3Mj86suoDIK- uM_EFCq3wEgVbZfgCLcB/s1600/PriceRentFeb2017.PNG)

In 2001, prices were already at the level of the 1989 real-estate bubble: Older folks will remember the savings and loan scandal, which was the result of the 1989 bubble collapsing. The Fed thought it needed to compensate for the internet bubble collapsing, which was a large contributor to the ensuing mess in housing.

It has to make us wonder: If compensating for the internet bubble lead to the housing bubble (and collapse), what will the result of compensating for the housing bubble be?

<comment><USER8> It's bubble-compensation all the way down.

</comment></comment></comment></comment><comment><USER9> Reading HN version of the events is live stepping into alternative reality. Just for the fun of it I did Ctrl-F for a word "conforming" and it was nowhere to be found in the comments.

Subprime is _irrelevant_. Prime is _irrelevant_. The only thing that was relevant was _conforming_ vs. non-conforming loans. Non-conforming loans started the fall ( oh, and nearly all subprime loans were non-conforming but that's not that relevant as the total amount of money in subprime non- conforming was just not that high compared to the amount of money in prime non-conforming ) because conforming loans were sold to F&F and removed from the books. Originating conforming just did not may that much which is why it was difficult to get them while a barely walking corpse could get NINJA 3/1 loan with a payment _lower_ than the APR and a balloon at 5 years.

And it was not the CDOs that mattered. It was _CDS_ that did not trigger when the underlying collapsed. That was fraud. Fraud that the treasury secretary at the time oversaw.

It was _fraud_ that Goldman became a _bank_ to get the protection of US Government and was allowed not to behave like a bank, etc, etc, etc.

</comment><comment><USER10> In retrospect (as the housing prices have mostly recovered: [http://www.doctorhousingbubble.com/wp- content/uploads/2013/0...](http://www.doctorhousingbubble.com/wp- content/uploads/2013/01/united_states.png) ), the hosing crisis can be seen as an irrational bubble, with the major problem being that the banks were under- capitalized for the risk they were taking on. After several years of injecting capital into the banks for several years, they are fine. Arguably the banks didn't worry about the risk because they trusted the government would help them out.

<comment><USER11> > the banks didn't worry about the risk because they trusted the government > would help them out

This is euphemistic for the banks stealing money from taxpayers through crony capitalism.

<comment><USER12> You're aware that those taxpayers actually got a very good deal, right? Roughly 10% return on investment, we effectively just invested public funds in good companies at cheap prices.

[https://projects.propublica.org/bailout/](https://projects.propublica.org/bailout/)

<comment><USER13> If it was such a fantastic deal, why wasn't someone else willing to step in and take it?

<comment><USER12> I did, and my portfolio is super happy about it. I cheerfully 'bailed out' Ford too.

<comment><USER14> No, you bought after the crash. The relevant question is would you have sold an insurance policy before the crisis and been able to stay solvent through it.

<comment><USER12> I'm not saying that I bought before the crash, neither did the government. I literally did exactly what the government did; bought shares of banks and automotive companies after the crash, at severely reduced prices, and held for a substantial gain.

The government absolutely did not sell an insurance policy before the crash. Even if you're arguing that there was a guarantee that the banks would be bailed out, which argument has merit, the banks didn't pay for that guarantee.

We did it for different reasons (I won't pretend I was either magnanimous or delusional enough to think my investment by itself would buoy the stock price enough to keep the companies alive) but the actual actions are the same.

Edit: technically both the government and I bought during the crash rather than after; my ROI wishes I'd been better at calling the bottom, but that's life.

<comment><USER14> Buying stock was only a small part of what the government did for the finance industry. Guaranteeing money market funds, opening up the discount window, bailing out AIG and paying off counterparties at 100%, sinking $100B+ into Fannie and Freddie, etc.

The government had essentially given the finance industry an insurance policy before the crash that paid off during the crash. And you are right, they didn't have to pay for it in money, perhaps its possible to argue that they paid for it in regulation. If the firms had had to buy such a policy on the open market what would the price have been?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> A lesser known but major contributor to the financial crisis is the commercial real estate market. As far as I know, Lehman went bust because of their massive commercial morgage position, that Fuld accumulated in 2007, trying to catch a falling knife. And commercial real estate blew major holes in balance sheets all over the place.

</comment><comment><USER16> This article is horribly biased against lenders.

We all can agree that lenders did loosen their criterion -- but why? They did so because legislator and judges were criticizing them for refusing sub-prime loans. The government said, hey, you're not giving enough loans to minorities who dominate the sub-prime population.

So, the lenders complied.

</comment><comment><USER17> Knowledge@Wharton: Because of the way the economy was going back then, people were feeling much better, there was more money, jobs were better, salaries were better. So people had that money to basically throw around.

Ferreira: It's like today. If you ask me today who is getting more loans, riskier borrowers or the middle class, [it's] the middle class that sees a market that's stable, that had jobs for the past five, six years, people that were able to save for their down payment — they are the ones getting earlier into this market.

\---

So we're on the cusp of repeating 2008? So soon?

<comment><USER18> It's been almost 10 years already. That is decently long compared to bubbles of years passed. We average about one per decade.

I think it makes sense. Lenders have a never ending impetus from Wall St to grow revenue and profit.

When all of the rich and moneyed people (13.5m people in the USA are millionaires) have already taken on loans, who do you go to next?

It becomes a cycle of just digging deeper and deeper into the question of "how do we sell this large capital asset to someone who barely has the ability to pay it back in the next 30 years".

Eventually, small economic cracks (sub prime defaults) lead to medium economic cracks (minor layoffs) which eventually, if the hysteria is massive enough, lead to massive economic cracks (major layoffs, shutting down business arms, pull backs in investment)

Eventually the govt is expected by market actors to become a lender of last resort, the dust settles, assets are repo'd, and over time...

... the cycle begins anew.

So, keep an eye out for the cracks that may be forming right now. Soon there will be another Lehman, another Enron, another Oil Crisis, another speculative bubble bursting due to credit on credit on credit on credit.

<comment><USER17> Yes. But must we immediately repeat the same series of bad moves? Have we not learned anything?

<comment><USER18> Oh, I completely agree with you! I hate bubbles, I hate predatory lending, etc.

However I am very sad to say that my observation is that this is happening again, either from ignorance or deliberate action.

I would love to be wrong :(

</comment></comment></comment></comment><comment><USER19> Another good reevaluation of the causes of the financial crisis that similarly argues against sub-prime mortgages being the main culprit:

[http://econlog.econlib.org/archives/2016/05/dont_solve_prob....](http://econlog.econlib.org/archives/2016/05/dont_solve_prob.html)

The explanation is much simpler than others offered, but often simple problems are the ones most overlooked.

<comment><USER20> Indeed. The economy could have easily dealt with a few banks failing---if the central banks would have kept nGDP up.

Australia, and even more Israel, barely noticed the Great Depression. Britain also did much better than American and the Euro area, thanks to a competent reaction by the Bank of England.

<comment><USER19> The article points to the FDIC and the misalignment of incentives it creates when it is combined with small undiversified banks, as the primary cause of the crisis. The note on the central bank's monetary policy relates to the Great Depression, not the 2008 crash.

<comment><USER20> You are right. I was interpreting things a bit more liberally: the housing crisis and banking crash would have stayed relatively small, if the Great Recession wouldn't have started:

At some point nGDP started to fall, giving the housing market and banks more trouble.

</comment></comment></comment></comment><comment><USER21> This article has to be founded by some pro-banking group. The article completely misses the part where the ratings agencies were incapable of reviewing capitalized mortgage pools to rate them appropriately. Regardless of the balance of prime to sub-prime, the inherent falsehoods within the ratings returned from Moody's, Standard & Poor, and Fitch are what made our financial system "untrustworthy" and that's what led to the financial crisis.

<comment><USER19> Maybe ratings agencies would do their job and refuse to rate things they can't see into if they were actually competition in the ratings sector, instead of a monopoly by the three ratings agencies, enshrined into law with regulations.

Much of the ratings sector is for all intents and purposes impossible for any outside firm to compete in, because of government regulations that are supposed to ensure high quality ratings. As it happens, the ratings agencies have some of the highest profit margins in the market, which is a classic sign of lack of competition, and rent-seeking.

<comment><USER22> Funny you suggest market competition. In The Big Short movie, it's competition that the ratings agency rep played Melissa Leo cites to explain their corrupt ratings:

Georgia: If we don't give them the rating, they go to Moody's. Right down the street. If we don't work with them, they will go to our competitors. Not our fault. Simply the way the world works.

Vinnie: Holy shit.

Georgia: Yes, now you see. And I never said that.

[https://www.youtube.com/watch?v=mwdo17GT6sg&feature=youtu.be...](https://www.youtube.com/watch?v=mwdo17GT6sg&feature=youtu.be&t=3m18s)

<comment><USER19> At the micro level, that could very well be, but at the macro level, competition for reputation should create a business interest in not giving out inaccurate ratings.

When the entire market is dominated by three agencies (two alone have 80% of the market), with the US government considering ratings given by them alone as sufficient for approval for certain listings, then regulatory management of the industry has effectively replaced reputational competition as the primary driver of quality.

<comment><USER21> I don't think you understand how this works in real life. I worked in the treasury department of a large bank 12 years ago and saw first hand...

1\. mortgages are pooled, usually around 10,000 per pool.

2\. the pool is divided up into tranches by the bank. This means that out of 10k loans, x% are supposedly AAA, y% are AA, and so on down to junk ratings (usually a small portion of the pool).

3\. the bank has their treasury department "validate" the tranches, but this is really just "spot checking" and not fully investigating the details of every single mortgage and its associated paperwork

4\. the bank sends the pool to the ratings agency

5\. the ratings agency sends it back approved, never even spot checking whether the bank's review was accurate or not

6\. the bank creates "securities" or "paper" based on the tranches

7\. investment entities purchase the paper...this is usually municipal bonds and other organizations expecting the AAA rating to be a "guarantee" (though it's really a gamble)

So ... in 2008 when the financial industry figured out that years of securities with false AAA ratings had been sold throughout the world, well, we know what happened...

None of this has changed except they expect the banks to maintain enough cash to handle any wobbliness in the financial markets....but the core problems still exist and has nothing to do with prime or sub-prime mortgages....

It's about accurate and clear information and an industry that literally banks on the lack thereof...

</comment></comment></comment></comment></comment><comment><USER23> One of an endless stream of academia forensics after the fact.

Another argument is that it was wealthy house flippers who capsized the market and not poor people being given large loans they couldn't repay.

[https://qz.com/1064061/house-flippers-triggered-the-us- housi...](https://qz.com/1064061/house-flippers-triggered-the-us-housing- market-crash-not-poor-subprime-borrowers-a-new-study-shows/)

<comment><USER24> At the end of the day most of the theories aren't exclusive. It takes a lot of people to create a global economic disaster.

<comment><USER25> True, but this article is trying to narrow the range of causes.

</comment></comment></comment><comment><USER26> Another recent study confirms this narrative as well. No citation to the 2015 study: [https://hceconomics.uchicago.edu/research/working- paper/cred...](https://hceconomics.uchicago.edu/research/working-paper/credit- growth-and-financial-crisis-new-narrative)

</comment><comment><USER27> The Toronto housing market is starting to crash now. That leaves just 3 housing markets that kept walking on water after the crash - Australia, Sweden, and Norway. Tick tock.

<comment><USER28> Not likely. The Toronto housing market saw its laws changed at the end of April. The market has lost some confidence because of that, but it is likely to only be temporary. Once buyer confidence is restored, it will be business as usual.

Vancouver's market also "crashed" in mid-2016[1] after their new – similar to Ontario's – laws came into effect. Six months later, after buyer confidence came back, an all-time record high was set.

[1] [http://creastats.crea.ca/vanc/images/vanc_chart05_xhi- res.pn...](http://creastats.crea.ca/vanc/images/vanc_chart05_xhi-res.png)

</comment></comment><comment><USER29> " _It was a new type of lending focusing on riskier borrowers who didn't have money for the standard 20% down payment, who didn't have a history of stable employment, or who didn't have a high enough credit score to apply for conventional standard loans, so-called "prime" loans. Lenders became quite creative in terms of finding ways to provide loans to those individuals, to those families._ "

We bought a house in late 2006/early 2007. We had money for 20% down; a history of stable, highly paid employment; and a pair of high credit scores. _We had to twist the goddamn lender 's arm to get a standard, non-whacked-ass "creative" loan._

It was _obvious_ in mid-2005 that they were writing unsustainable loans. It was obvious that as soon as the business cycle had any kind of hiccup, the wheels were going to start coming off.

" _Ferreira: Yes. Let's split the housing market into four major components. There's the prime sector. That's always around 60% of the market. That's the bulk of the mortgage market. There are the governmental loans — HUD, FHA and VA — which are about 10% to 15% of the market. Then there's sub-prime. Sub- prime started in the mid-1990s with about 5% to 10% of the market. And that increased to 20% — big, but a third the size of the prime sector. And then you have all-cash transactions: investors or wealthy people. And that's about 10% of the market. So during the whole time period, even at the height of the housing boom, sub-prime was never more than 20% of the market. And the prime sector was 60% or more and increasing._ "

The sub-prime market was, as expected, the first up against the wall when the wheels started coming off. And the result was that 20% of the market, rather than 5-10%, were forced to sell quickly or be foreclosed. 20% of the market is going to have a bigger effect on overall prices than 5-10%.

On the other hand, that doesn't let prime lenders off the hook, since everyone was pushing bigger loans that overextended more borrowers, as in, "[T]he phenomenon was widespread. It was not concentrated solely on the sub-prime sector."

But this is where Ferriera starts going off the rails.

" _More equity helps. Having a higher down payment helps._ "

No, having lower payments helps. It doesn't matter whether you've got 20% or 0% if you physically cannot make the payments. _Lenders were writing loans that overextended borrowers._

" _So around 2008 and 2009, in certain markets, you had about 10% to 20% of the stock of homes being foreclosed. Those markets were the weaker markets, such as inland California, areas like Fresno and Modesto, or smaller markets in Florida, for example._ "

I seem to recall it being the stronger markets, like Las Vegas. But anyway...

" _Knowledge@Wharton: [...] I guess, in some respects, then, we still don't have a full, true understanding about housing cycles and how they affect the markets, or the potential of the U.S. having another bubble down the road._ "

We may not have a full understanding, but we do have, and did have, enough of an understanding that _you cannot lend more money to people than they can be expected to pay back._ It makes no sense to frame the issue as prime vs. sub- prime or wealthy vs. poor. It was purely a case of lenders not doing their jobs. So, then:

" _Ferreira: Unfortunately, I don't think so. Let me give you an example about lenders. Lenders got all the blame, especially sub-prime lenders, for the crisis. So what's happening right now in this recovery? Are we giving thank- yous to the lenders because perhaps they're helping with the recovery? Absolutely not._ "

And rightfully so! Lenders deserved the blame. And then they didn't "[help] with the recovery"; they stopped making loans _at all_.

</comment><comment><USER30> This article is bunk.

<comment><USER31> Agreed, and not much more needs to be said about it.</comment></comment>


What is a good age for kids to learn coding? - <AUTHOR> https://medium.com/@nutanc/what-is-a-good-age-for-kids-to-learn-coding-a6b27ffc71e4 <comment><USER2> Depends on the kid and what they want, I think as early as possible b/c I think it's good for young kids to exp. many different things at an early age.

Too early may be a problem depending on the kid, if s/he's got a lot of things that take a significant amount of cognitive load day-to-day, then they won't like it b/c it takes a lot of brainpower to learn relative to other kid stuff, and probably stop doing it, b/c ppl tend to gravitate to things that they perceive they're good at and that could hamper their decision making.

I started coding sophomore yr in college b/c I didn't have access to technology until then and I think it worked out, I certainly don't feel behind by any means.

</comment><comment><USER3> I got "Moebius Noodles" and "Avoid hard work" for myself and our kids. Both books are focused on playfully teaching kids logical and mathematical thinking and contain several games which introduce functions, algorithms and other programming concepts.

My kids were 3 and 5 when we started and really enjoy it. There is a number of tips in both books how to make excercises age appropriate even for toddlers. The main thing to remember, keep it fun and let the kids explore solutions (see recent other discussion on HN)</comment>


Show HN: My first node.js app - <AUTHOR> http://orgazers.herokuapp.com/

<comment><AUTHOR> What it does:

It is called "Orgazers" which is a combination of the words "Stargazers" and "Organizations"

It will look at all the stargazers of a repo, and find and list their organizations they belong to.

I got the idea when I received an achievement for having a repo followed my a member of the Github team. I wondered what other team members are following one of my projects. There really isn't any other way to find that info that I know of.

Is it useful? Not really but I though it was interesting.

Sorry for not adding the details in the title. I am terrible at getting people to click on my submissions so I was experimenting different title ideas.

</comment><comment><USER2> Sweet that you made your first app. But the fact that you made an app really isn't that novel, how about teasing us with what it does in the title instead of a now common place technology?

Tell us that you made the "Groupon of twitter" or the "foursquare of plurk" then tell us how you did it all with just node and MangoDB.

<comment><AUTHOR> I added the information you requested in a comment.

</comment></comment><comment><USER3> But what does it _do_?

<comment><AUTHOR> I added a comment explaining.</comment></comment>


"We are witnessing the beginning of the end of Facebook" - <AUTHOR> http://edition.cnn.com/2011/OPINION/01/07/rushkoff.facebook.myspace/

<comment><USER2> Haters gonna hate.

This article upsets me. Not just because it grosssly oversimplifies everything to make a point, nor because of its complete journalistic negligence (what about companies in competitive markets that have dominated their competitors? why isn't FB vs myspace like netflix vs blockbuster? etc etc. And AOL was merged...how does this related to FB? ugh). But for something deeper...

Maybe I just woke up in an angry mood, but this article is written for the sole purpose of being able to say "I told you so" if indeed somewhere down the line Facebook does tank. It is this "contrarian for publicity's sake" attitude that really creeps under my skin and makes me upset at the world.

</comment><comment><USER3> I wish author would have given more details on why he thinks Facebook is doomed than just pointing to other doomed companies like AOL and MySpace. The only other point he makes is Goldman's investment. (I am sure many of the Goldman investments actually paid off not by betting against them).

When it comes to social networks, I think this space remains a natural monopoly (Just like OS was before internet days). And by creating open graph, facebook is eliminating need of another social network.

<comment><USER4> I agree - it would be nice to have a run down of the sequence of events that will lead to its demise.

</comment></comment><comment><USER5> <http://news.ycombinator.com/item?id=2081211>

</comment><comment><USER6> While that is a valid correlation, and that history is a good predictor of the future, Facebook still has a lot of fight left in it. Their Graph API is powerful and their business offerings are strong. Yes, some new service might rear its head and challenge FB, but FB has more staying power and real-world integration than MySpace or Friendster had. (AOL had real-world integration, but their fall was a broken business model).

</comment><comment><USER7> Media companies have a poor track record when it comes to acquiring big internet properties, as the author points out.

Goldman Sachs is a whole different story. Look up their investment profit track record and it tells a very successful story.

So what I'm really saying is comparing Goldman to Newscorp or Time Warner is a very bad analogy.

This may still be the beginning of the end for Facebook, and I wouldn't be surprised if Goldman rips Facebook to shreds to extract maximum profit, but the authors analogy doesn't hold water.

</comment><comment><USER8> Sensationalist article which probably allows the author to say "I told you so". Rushkoff is probably right .. in a decade or so if the leadership at Facebook becomes incompetent. By then, the rich clients of Goldman Sachs and all the private investors are all laughing to the bank to the sound of ringing cashiers.</comment>


Microsoft shouldn't have reinstated the start button in Windows 8.1 - <AUTHOR> http://marakblog.wordpress.com/2013/08/26/microsoft-shouldnt-have-reinstated-the-start-button-in-windows-8-1/

<comment><USER2> _" Microsoft wanted to converge desktop and tablet platforms..."_

I always wonder _why_ we imagine it is desirable to 'converge' the user interface for a device you carry in a pocket with that of a device that has two 30" monitors.

It is _possible_ to play a violin like a cello but not very practical...

<comment><USER3> I do want them converge. However, I dislike MS approach with separate incompatible software stores.

Ubuntu tablet seems to be the right way to do it.

<comment><AUTHOR> "separate incompatible software stores" elaborate?

</comment></comment></comment><comment><USER4> The problem is that they tried to merge desktop and tablet user experiences in the first place. The idea of having to perform a full context switch / screen jump to launch a new app is a weakness of tablets... not a strength that should be forced on PC users. The ability to have N applications on screen at once, and launch others without losing any visibility into current windows, is something they lost... that's the problem.

<comment><AUTHOR> You can still put icons on the desktop and pin them to the task bar..

</comment></comment><comment><USER5> Every one of the methods listed for accessing the Start menu in Windows 8 causes problems in a remote desktop connection.

-The mouse isn't always locked into the active rdc window, so finding the corner of the screen is tedious

-Swiping in from the side of the window with a mouse doesn't work

-Pressing the Start key on your keyboard will open the host Start menu, not the remotely connected instance

Of course rdc is a bit of an edge case, but it's very important for business/power users.

<comment><AUTHOR> Interesting, not something I've yet to do yet I RDP into Windows 7 daily.

<comment><USER5> If you run your RDP client in full screen, don't use multiple monitors, and map your windows key to the remote os then it gets a little better. The break- in period is a little painful though, especially disconnecting (Charms Menu > Settings > Power > Disconnect??). I'm hoping the 8.1 update smooths out some of the issues.

</comment></comment></comment><comment><USER6> It's a great example of compromise vs. full-fledged.

Converging all users to the same UI is going to be a compromise; It won't be great for double-30"-monitor-powerusers, and it won't be great for 9" Tablet mobile users.

The only thing this improves marginally is how much code needs to be maintained, and considering the implications, i'd much rather have twice the code size, than inhibit my users ability to use my product efficiently, and make it more minimalist.

</comment><comment><USER7> I don't get this start button hate. For all the benefits of having a permanent start bar I will happily sacrifice 13mm off the bottom of my screen that I would probably just use as white space anyway.

And I have had the option to auto-hide the start bar since... Win 95?(or was it earlier)

<comment><USER8> It's not that they got rid of the taskbar (it's still there on the Win8 desktop), it's that they took the button for the start menu off of it, and replaced it with a hot corner, and in Windows 8.1 they've put the button back.

</comment></comment><comment><USER8> I don't mind them putting the Start button back, but I wish there was an option to remove it again. I much prefer a vertical taskbar, which puts my Start button in a different corner than the Start hot corner (which is just confusing and annoying).

</comment><comment><USER9> They should've gotten rid of Metro completely. Tablets and PC's are not meant to be mixed. The ideal size for a tablet is around 7"-8", while the ideal size for a laptop (for most people) is 13".

Here's hoping under the new CEO Windows 9 will be a true successor to Windows 7, instead of one to Windows 8.</comment>


Show HN: Learn how to build an Airbnb like app in 10 mins - <AUTHOR> https://appbaseio-apps.github.io/airbeds-onboarding/ <comment><USER2> Nice. Thanks for this easy to understand example of your (?) library.

Personally I never used react. What do these placeholders do:

My guess is the stuff in {{}} is a placeholder that gets replaced by react. But would have expected some identifier like {{ROWSTYLE}} or something. What does {{"margin": "0"}} do?

<comment><USER3> It has actually almost nothing to do with React, it's a part of JSX syntax (which can be used with other libraries, and React can be used without it).

The outer curly braces indicate that there's a JS expression inside, and the inner ones are just a part of an object (think JSON). It could look like this if stored in a variable:

        let styles = { margin: 0, color: "red" };
        …

[https://facebook.github.io/react/docs/introducing- jsx.html#e...](https://facebook.github.io/react/docs/introducing- jsx.html#embedding-expressions-in-jsx)

[https://facebook.github.io/react/docs/dom- elements.html#styl...](https://facebook.github.io/react/docs/dom- elements.html#style)

<comment><USER2> Now I am confused. Why the {{}} at all and not just:

<comment><USER4> You may use both of the syntaxes; but the former allows to easily inject JS variables directly, rather than by interpolating strings.

For example: var userParagraphMarginSetting = '5em'; styles={{ marginLeft: userParagraphMarginSetting }}

Against: var styles='marginLeft:'+userParagraphMarginSetting; styles={styles}

</comment></comment></comment></comment><comment><USER5> I've tried to use a different appbase.io product, Reactive Maps, and was sorely disappointed. They can't be bothered to fix the outdated tutorials, broken manual/documentation links, etc. on their site,

</comment><comment><AUTHOR> You will be interactively building an Airbnb like app using ReactiveSearch, a UI components library built in React. You can read about how this app is built over at [http://bit.do/simplebeds](http://bit.do/simplebeds).</comment>


Mathematical coincidence - <AUTHOR> http://en.wikipedia.org/wiki/Mathematical_coincidence <comment><AUTHOR> Repeating here the relevant section from my comment earlier[2]:

The idea is that there are only so many small numbers, and there are lots of ways of combining things together. The Pigeonhole Principle then says that if you stuff too many things into a small enough space, some of them will be close together. Although apparently obvious, this is more widely applicable than people generally realize. It's used, for example, in one of the proofs that that every prime of the form 4k+1 is expressible as the sum of two squares (Examples: 29=4x7+1=5^2+2^2, 181=4x45+1=10^2+9^2).

Combine this with the birthday problem/paradox[0][1], and you end up with more coincidences than you might expect.

[0] [https://news.ycombinator.com/item?id=1312636](https://news.ycombinator.com/item?id=1312636)

[1] [https://news.ycombinator.com/item?id=4753014](https://news.ycombinator.com/item?id=4753014)

[2] [https://news.ycombinator.com/item?id=7892425](https://news.ycombinator.com/item?id=7892425)

</comment><comment><USER2> Also, [http://xkcd.com/1047/](http://xkcd.com/1047/) .</comment>


If It Weren't for Apple, Hybrid App Development Would Be the Winner Over Native - <AUTHOR> https://hackernoon.com/if-it-werent-for-apple-hybrid-app-development-would-be-the-clear-winner-over-native-ae64fa37ad48 <comment> k-mcgrady Where to start?

>> There are some major advantages to the Hybrid approach: You get to utilize your existing JS, HTML, and CSS skillset to develop a single codebase that runs on both iOS and Android.

This is assuming you have a JS/HTML/CSS skillset.

>> Here's some Apple BS we can't avoid no matter what approach we use >> Xcode

I've done some React Native development and Xcode is almost entirely avoided.

>> Provisioning Profiles

It's been a long time since I encountered issues here as it's all managed by Xcode nowadays.

>> Needing to use TestFlight for beta builds

Why is this BS? You could also use Ad-hoc distribution along with something like Fabric for small scale beta tests.

>> The app review process. Admittedly, the app review time has dropped to about 2 days on average, but when your app gets rejected 7 times like Rizer did (for legitimately silly reasons), your patience can really start wearing thin.

I've been developing on iOS since about 6 months after the App Store became a thing. I've developer dozens of apps and submitted hundreds of updates. I can count on my fingers the number of rejections I've got and there were only one or two that were 'silly' (and those were fixed through a quick appeal). Without the author listing the reasons for rejections it's hard to draw a conclusion here but complaints about rejections are usually BS.

Overall I can't help but feel this was thinly veiled clickbait to advertise the authors app.

<comment><USER6> > I've done some React Native development and Xcode is almost entirely > avoided.

Almost entirely avoided still means you have to go out and buy a Mac and keep Xcode running on it.

<comment><USER7> sort of, I run a VM on Windows using VMWare workstation, involves binary patching the vmware executable, but hey, cheaper than buying a mac.

<comment><USER8> Also illegal, so not a solution for non-hobbyists.

<comment><USER9> I don't think it's illegal in my country. Or most of the world really.

<comment><USER10> Technically it's not illegal as in criminal, but it is a violation of the contract you're agreeing to in the form of the software license. And the macOS software license only permits running macOS on Apple hardware (it can run in a VM, but the VM host must be Apple hardware).

I understand that some of these EULAs aren't enforceable everywhere, in the form of consumer protection laws inhibiting what's basically perceived to be bullying behavior. At least in the U.S. consumer protection laws are weaker, depending on the idea that when consumers are bullied, they'll spend their money elsewhere.

In a global market, asymmetric consumer protection laws aid bully behaviors. The countries were people are safe flaunting EULAs may have higher usage rates of software with unfavorable EULAs, rather than using alternatives with a more favorable EULA.

<comment><USER11> Another reason Apple is BS. "macOS software license only permits running macOS on Apple hardware", I disagree with Apple so hard here. What a scam.

<comment><USER10> They've always been this way. There was a short period of time with Mac clones, but there was still a license that said you could only run macOS on Apple hardware, or Apple licencee hardware.

I totally understand not liking the license, but if you click the agree button when installing the software on non-Apple hardware, you're basically lying.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> The author has a shiny hammer, and sees every problem as a nail.

For example, I just finished implementing an iOS app that uses a background operations queue for network operations. It's super energy efficient. It doesn't care whether there is an active network connection, the queue will regularly check network access and intelligently retry operations until they succeed. It will continue uploads/downloads in the background, and restart them when the app or phone is restarted. It submits some operations concurrently depending on bandwidth and server, to maximize throughput. It has a smart algorithm for syncing server and app data, that also happens in the background.

The user doesn't have to know or care about any of this. They only know that submitting a form always works instantly. And that they can review filed forms from other users even when far out in the boonies, away from any network service.

This is the kind of polish that's really hard to do in hybrid, especially power efficiently.

<comment><USER13> > I just finished implementing an iOS app that uses a background operations > queue for network operations.

As someone who has never developed for mobile, is that OS provided, or something you had to implement yourself? It seems like something like that (at least for HTTP) should be included, and with some rich controls to toggle whether jobs should persist app closes and restarts, or jobs should wait for wireless or are okay on cellular, whether jobs of type X should replace other jobs of type X (no reason for 5 queued requests for latest updates to the same feed to all fire when conditions are right...), etc.

<comment><USER14> Native iOS/MacOS provide a rich set of libraries around multi- threaded/background processing. Look up Grand Central Dispatch (GCD).

[https://en.wikipedia.org/wiki/Grand_Central_Dispatch](https://en.wikipedia.org/wiki/Grand_Central_Dispatch)

</comment></comment></comment><comment><USER15> Probably true, and I'm so glad we have Apple in this industry. Otherwise everything would be optimized for ease of development instead of the end user experience.

<comment><USER16> But the end user experience is still shit on iOS, it's just a more specialized kind of shit, delivered through a fancy sphincter.

<comment><USER17> Shit compared to what?

People really have no context...

<comment><USER18> A naïve utopia that we are being held back from by corporate greed.

</comment></comment></comment></comment><comment><USER19> "A Hybrid version of an app will never be as fast as a native version of the same app, but it doesn't matter as long as the Hybrid version is fast enough. Put simply, if your users never complain about the performance of your app then it is fast enough."

Battery usage can still be a problem even if the app appears to run smoothly.

<comment><USER20> In addition, just because nobody is complaining doesn't mean you aren't wasting their time.

"Well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that's probably dozens of lifetimes. So if you make it boot ten seconds faster, you've saved a dozen lives. That's really worth it, don't you think?"

[http://www.folklore.org/StoryView.py?story=Saving_Lives.txt](http://www.folklore.org/StoryView.py?story=Saving_Lives.txt)

That's probably putting it a bit too strongly, but "nobody complains" is probably putting the bar too low.

<comment><USER13> I suppose the assumption there is that me must stay perfectly still and stare at our phones during this time? My toaster takes a while to toast break. My coffee maker takes a while to brew coffee. I don't really consider that wasted time, because it doesn't require anything of me, and I'm free to do something else.

<comment><USER21> Wait, so when you tap the browser icon on your phone, you set it down and go have a cup of coffee first? No, you don't.

The thing about phones is the _immediacy_ of using it. Nobody uses a phone like you say.[0]

[0] Okay, nobody is a definitive. Almost nobody, then.

<comment><USER13> The example wasn't perfect, but often I'm using my phone when moving between place to place. I don't stop walking to to wait for an app to load. You also don't need to stop thinking just because you are waiting for something.

The idea I'm really calling into question is "So if you make it boot ten seconds faster, you've saved a dozen lives." Waiting for your phone to do something isn't like being in a coma, where the time is irretrievably lost and provided no benefit (beyond what it might have allowed recovery wise), nor is it like sleep, where we spend a significant portion of our lives doing it and we can't do anything else during that period (even if that period itself is beneficial).

Delays are annoying. Making delays shorter is good. Saying shortening delays saves lives worth of time is problematic. Even the original commenter acknowledged that was probably reaching (it wasn't his quote).

</comment></comment></comment></comment></comment><comment><USER12> I understand some of the frustration with Apple. You need a Mac for development, you need iDevices for testing, the dev program is $99 a year, and you need to use their tool chain. Their web views are not tuned for hybrid apps, etc, etc. Lots of that is driven by our experience with open source, where you can usually build and release on any platform and your choice of hardware is your own.

But these complaints are also very selfish, almost delusional. The author wants access to the largest and most lucrative App Store on the planet, yet they don't want to pay for any Apple hardware to do it. And they think Apple should expend resources to ensure their specific cross platform approach should make it easy to write android apps as good as their iOS apps.

Apple makes money only because people buy its hardware. A big reason for the success of the iPhone/iPad is that their apps were historically better than similar apps in android. It's awash with top developers investing substantial amounts to build and update apps.

If you don't think it's worth investing $1,000 to develop for a store that pays out over $20 Billion a year to developers, why does Apple need you? Why should they invest to build developer tools for devs who won't buy Apple?

Why should Apple invest in cross platform or dumb down its own APIs to help eliminate significant differences with Android? Why shouldn't they focus on better native features for their web views instead of making them better for cross platform devs? How will either sell more iPhones?

There is nothing wrong with developing for a single platform. Google Play may surpass the App Store this year, obviously Android is a fine platform to sell on.

But never expect a company to undercut their very business model just to make it easier for you to reach their customers.

<comment><USER22> It is the free generation, they want to get paid but not pay for their tools.

</comment></comment><comment><USER23> If the title were literally true it would be a positive mark in favor of Apple, in my opinion. A good many of the paradigms in web development exist, it seems to me, simply because the desire for cheap apps built with cheap labor outpaced the platform on which these cheap apps are built. Whoever thought using the browser as a substitute, psuedo, or virtual OS was a good idea?

<comment><USER24> What's funny is Apple's original plan for iOS was that additional functionality would only be delivered via cross-platform web apps.

With iOS 1 lot of developers thought Apple was terrible for promoting web apps and that native should be the way forward. And so the app store and native apps arrived in iOS 2.

Now, apparently, Apple is terrible for having native apps and that web apps should be the way forward.

How things go in circles...

<comment><USER25> I'm still convinced this was BS, and they were late with the SDK. I cannot imagine anyone inside Apple thinking they could get away with the quality of IOS 1 (well iPhone 1.0) web apps.

<comment><USER26> It is. There have been interviews. They didn't have the SDK ready (it was a total mess on the preinstalled apps). When people demanded a way to develop they pushed out web development because they could do it fast while they got everything else documented and into a consistent state and secure.

It sounded like they always expected to do native apps, just not nearly as fast.

</comment></comment></comment></comment><comment><USER27> Oh I always have fun trying to break these apps. This one did fairly well, but it's still obvious it's not a native app. Does that matter to most of the end users? Probably not, but they probably don't appreciate the heavy RAM usage and extra CPU incurred from running a language interpreter inside of your application. Here are some notes after I downloaded and played with it a bit on a Nexus 5:

\- Scrolling slowly with your finger held down on the settings page leads to visible stuttering, though flick-to-scroll seems to run at 60 FPS \- Tapping the menu button in the bottom right quickly a few times can lead to a darkened screen with no navigation menu displaying \- Doesn't respect the back button on Android \- The app takes 224 MB of RAM, the next highest is spotify at 176

It's pretty impressive for a Cordova, but I feel like it's _more_ effort to try to mimic native functionality with web dev tools.

I still think React Native (or at least the _idea_ of React Native) holds promise, because at least then you're getting native UI elements which behave much more consistently and are more robust against random tapping and swiping on the screen.

</comment><comment><USER17> > _If It Weren't for Apple, Hybrid App Development Would Be the Winner Over > Native_

Thanks god for Apple, I guess, then...

Imagine a headline like: "If it wasn't for Apple/MS, most of your desktop apps would be Electron based".

How would you like that?

</comment><comment><USER28> The whole article misses the point. The entire purpose of WKWebView is a compromise that let's the user take advantage of all of the features of Safari within an app -- passwords, bookmarks, shared cookies between the view and Safari, native performance -- without the security implications of random apps having access to everything you type in. If you enter your password into a web view, the app has complete access to it. If cookies were shared in a web view like they are in a WKWebView it would be a major security vulnerability.

<comment><USER29> The thing is: There is no fast browser that also is flexible, in contrast to android.

<comment><USER28> Sure there is... the article even said that WKWebView and Safari are faster than his Samsung device. The problem is not that the browser isn't fast, the problem is that he wants to make a sub optimal cross platform app that's not optimized for either iOS or low end Android devices that most people are buying.

</comment></comment></comment><comment><USER15>
      >A resource-hungry 3D game or similar does not fit into my definition of "app"

That's… one interesting definition. Have you consider writing websites instead?

</comment><comment><USER30> I disagree with the author that "the Hybrid approach is the right choice for your next app".

Speaking from personal experience, the time it takes to create workarounds for UIWebView/WKWebView is only slightly less than the time to get familiar with Swift/UIKit. With knowledge of mobile paradigms it is easy to pick up Java/Android.

The advantages of creating two separate native apps are designs that fit each individual platform, better battery life, and overall better performance.

The author's time to market using hybrid development was less than the time it would've taken to learn iOS/Android native development and ship. However, the time difference is not as large as one may think. By continuing to invest in hybrid app development the author didn't learn valuable iOS/Android native app development skills and created an app that isn't as performant or designed to fit each platform.

<comment><USER31>
      the time it takes to create workarounds for UIWebView/WKWebView is only
      slightly less than the time to get familiar with Swift/UIKit

This times a thousand. I have wasted untold hours on clever paperclip-and-gum techniques to get WKWebView to be something it isn't: predictable and usable.

I still develop hybrid apps for clients (glorified web pages, really) but for personal projects I will never, ever go back. Kicking myself for not learning Swift earlier.

<comment><USER26> When my job looked at the JS app idea (3 or so years ago) that was one of my big takeaways. If we made a web app, we would spend just as much of not more time polishing it until it felt native than we would have making it native on the platform in the first place. It wasn't a highly complicated app.

</comment></comment></comment><comment><USER32> There's a fair number of "apps" that could be replaced by a plain old web site as well.

<comment><USER33> Except for that pesky requiring an internet connection...

<comment><USER15> Local storage has been a thing for a really long time

<comment><USER33> You can't even go to the website in your browser if you don't have internet. Local storage is nice, but by that point the problem has already occurred.

<comment><USER15> Nor can you download the App. The first interaction must be online on both cases.

<comment><USER33> Sure, but once you've downloaded the app, you're good. You can open it up whenever.

<comment><USER15> Same with local storage, that's the point:

      https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
      https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API
      https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers
      https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cache

<comment><USER33> Apparently I'm missing something. How do you go to the website to even load the code that talks to the local storage? (Also that last link says it's been deprecated and is being removed).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER34> In the end this comes down to a gripe that you can't use Chrome for web views on iOS owing to platform restrictions (and, secondarily, that you need to use XCode to submit to the App store, which I agree with, although it's pretty painless if you have a Mac). Guess what, you've now got that problem for Windows (the app store is blocking non-MS browsers) too. The problem doesn't exist for Android because Android is the new Windows -- for good and ill.

A lot of web app developers (myself included) are highly reliant today on Chrome in the way that we were dependent on some flavor of IE in the past. In my case, I need WebRTC and the only other major browser that supports it right now (FireFox) does it so badly that in effect I'm developing exclusively for Chrome. That said, all of my non WebRTC code is as agnostic as possible, runs fine on Safari, and Safari/Webkit is supposed to get WebRTC "real soon now".

This is essentially a "Safari is the new IE" meme in disguise. The closest thing to the new IE is whatever browser folks are treating as "the web" and that's Chrome right now. Don't forget that IE became the old IE in part because it delivered features _programmers_ clamored for and was the best browser for most people for a long time. It only stopped being dominant because it stopped satisfying users. By most accounts users _love_ Safari on iOS as a browser. If it's not a fabulous app platform that's because Apple isn't trying to meet the needs of app developers with Safari.

<comment><USER35> I don't agree much with the article posted but I do slightly agree with "Safari is the new IE." The problem with IE was that is was packaged with the OS with no way to uninstall. iOS is worse in the regard that you must use WebKit if the you decide to create your own browser and Safari is packaged with the OS. Chrome is the one of the first to receive new features from what I have gathered but I guess it all depends.

<comment><USER26> My disagreement with the 'Safari is the new IE' is that while Safari may not be deploying feature X, it's still updates with new features every year. It's a preference issue.

IE was totally static (except for some security updates) for YEARS. It's lot they didn't add sexy new thing X, it's they didn't add anything.

I don't think it's a fair comparison because the situations were so different.

</comment></comment></comment><comment><USER36> I downloaded the app (iOS) and even if I'd downloaded it thinking it was something I might use longer term rather than to evaluate the claims in the post, it would likely have been deleted within an hour. It fits broadly with my previous experiences of hybrid apps:

      - touch targets behave oddly
      - touches sometimes don't even register and you have to tap multiple times (e.g. moving between tabs, dismissing modals)
      - menus, scrolling and transitions don't feel right (the "physics" is all wrong)
      - reopening the app gave me the login screen and a spinner while it sorted itself out multiple times
      - I had to actually log in again once because it just appeared to forget the login info (within 10 minutes)
      - the UI in general lacked polish and felt clunky

Honestly if this was a corporate form filling or inventory tracking app, the trade-off might be fine, but if you're trying to gain and retain users it's likely not good enough for anything but an early proof of concept.

Maybe I'm just picky but it amazes me that someone could produce this (given how good we know things can be) and think it's good enough to justify a praise-filled blog post about the merits of hybrid apps.

<comment><USER37> Thank you for the feedback.

<comment><USER36> No problem, I hope it doesn't come across too harshly but it's those little things that can make an app frustrating.

It'll be interesting to see when/if hybrid does get "good enough" as there are certainly benefits if you can pull it off!

I'm already convinced by React Native's approach and have seen really great apps built with that tech (although they keep things easier by sticking with native components) and am intrigued by Microsoft's ReactXP as a more cross platform option.

</comment></comment></comment><comment><USER38> > Mark Zuckerberg: Our Biggest Mistake Was Betting Too Much On HTML5 > [https://techcrunch.com/2012/09/11/mark-zuckerberg-our- > bigges...](https://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest- > mistake-with-mobile-was-betting-too-much-on-html5/)

I think Hybrid has it market and it makes sense for some apps, but for medium/big companies you probably end up with a native app (or a hybrid app with more native).If the app is native you can do more things in the device, there is better documentation for how to do complex things and you don't have to use Javascript. Swift and Kotlin are much better languages to use for apps. But I think the main point is that apps, nowadays, most of the logic of the app resides in the server, so the apps are only front ends. And to make a nice front end with smooth animations it is easier to do it native, because animations are different for every platform, so there is not much code to share.

</comment><comment><USER39> Sigh, this debate never ends.

> You get to utilize your existing JS, HTML, and CSS skillset to develop a > single codebase that runs on both iOS and Android.

This always reminds me of the quote: consistency is the hobgoblin of small minds.

You see this "consistency" argument rear its ugly head all the time. I can remember hearing it when GWT was being pushed ("you can use your Java code on server and client"). The reality of course is far from idyllic. But that was completely predictable.

You also see this argument with Node.js.

The problem when you try and broaden something like this is it's incredibly difficult not to end up with something that doesn't simply combine the worst of both worlds.

Now I'm not an iOS/Android dev but from the sidelines I tangentially keep abreast of what's going on. It _seems_ like React Native has some real potential here. Like some benchmarks I've seen show there's not much of a performance hit. If (and that's a big "if") this turns out to be the case, pulling this off would be a rare feat of success.

Now even if it succeeds, there'll still be a cost. I'm sure there are some things that are easier in iOS/ObjC/Swift and Android/Java. For one thing it would be difficult to abstract away the different memory management models (IMHO ref-counting rather than GC in iOS is a competitive advantage).

Anyway I don't think Apple killed Web apps or hybrid apps. Two things killed those:

1\. HTML/CSS/JS is honestly horrible. Particularly layout in CSS (mainly pre- flexbox). Performance isn't great. People end up with Web apps with 1M+ DOM objects. That's just crazy.

2\. Performance is just so much better on iOS/Android (rather than HTML5). Part of this is you know a lot more about the target platform than with a Web app.

<comment><USER40> Yeah, I think the author is kind of out of date. Even people who go the cross platform route nowadays don't use Cordova, where PhoneGap went to die, they use something modern like React Native, which doesn't have the HTML performance penalty.

</comment></comment><comment><USER41> It's funny. I remember when Steve Jobs announced the original iPhone and said that there wouldn't be any native apps because web apps should be sufficient. I also remember the outcry from developers and complaints about apple's tyrannical closed ecosystem. It's interesting that things are changing now and now people are complaining in the exact opposite way. I guess Jobs was right again, just too soon as usual.

</comment><comment><USER28> If an app is slower but "good enough" on his Galaxy S8, how well does he think it will run on the sub $200 Android phones that most people are buying _?

_[http://www.androidauthority.com/apple-iphone-average- selling...](http://www.androidauthority.com/apple-iphone-average-selling- price-749145/)

<comment><USER37> I wrote the article and just saw that there was a discussion about it here. I actually primarily tested it on an LG G2 and Motorola Moto G 3rd gen. Both of these phones are fairly slow, and my app runs about as quickly as any other app I open on them.

</comment></comment><comment><USER42> Let's completely forget about the mess that modern web development is nowadays with frameworks for frameworks that manage your frameworks making build chains for C++ projects look refreshingly easy all of a sudden, the requirement for tools for fixing really basic stuff like having constants in a CSS file or the hacky way most frameworks "integrate" with JavaScript and your HTML.

Lets forget about JavaScript being forced upon you, a language that has so many holes in it there are a fistful of alternatives that compile more intelligent code to JavaScript just to take the pain away to deal with the intense stupidity of native JavaScript.

Then there's the everlasting "can I use feature x on version y of browser/platform z, and if so does does it use a different syntax?" unless you dumb down to only Android and Safari Mobile and don't support all web based platforms (killing one of the main attractions of a hybrid application by choosing so). Ignore that too.

Then we can talk how you try as hard as possible to run away for the development stack of the company that created the product you are trying to develop for. Nobody ever complained about having to use at least some part of the Visual Studio / .Net or Win32 / Windows toolchain for the past 30 years to build a Windows application that really would look and behave like a Windows app even when you were just using Java (the hybrid app platform of the past), but that was of course something completely incomparably different.

But somehow actually needing a Mac and an iPhone to get work done in the Apple stack: Crazy! Nuts! How can they think everybody has a Mac and an iPhone to spare?

Getting WKWebView to hack into native code and vice versa is a pig, but the way Google allows you to hack into everything all of the time has it's own drawbacks mainly in the form of privacy and security.

</comment><comment><USER43> Hmm. I dunno.

I worked on a cross-platform mobile development tool called Nomad for Visual Studio (from Red Gate Software) for a while back in 2013, since retired. Back then hybrid mobile apps, for the most part, absolutely _sucked balls_ in comparison with their native counterparts. Performance, in particular, was often choppy, and it largely wasn't possible to offer an anywhere near native user experience.

(I know, I know: everyone's going to point at Untappd, which was 2013's poster-child hybrid app, and talk about how awesome that was, but whilst it was decent, it was still noticeably hybrid. And, yes, there were and are companies selling native controls that can be used from a hybrid app to make things easier/better/more performant.)

The experience of working on Nomad taught me one thing: if you were serious about mobile app development, and you wanted to provide users with a great experience, your only option was to go native, be that on iOS or Android.

Four years has passed and, nowadays, the situation has improved quite a bit for hybrid apps. Still, it's disingenuous to suggest that most apps would be better as hybrid.

Sure, your app might run "fast enough" for many scenarios, and the user might not be able to even tell the difference between native and hybrid implementations, but if your hybrid version burns 10 times as many CPU cycles as its native equivalent would you're caning the battery life of the device, which is an aspect of mobile performance that seems to escape a lot of people. Speed is one thing, but how long you can continue to use the app or device also matters to people. (I say this as somebody seriously considering porting a couple of HTML5/JS games to mobile at some point in the future.)

This problem becomes particularly pronounced if you're building an app - <USER2> this goes far beyond games - with any kind of fancy media component, custom drawing, etc., any kind of rendering, doing anything cool/fancy with music or sound. You can take advantage of WebGL and shove a bunch of work onto the GPU, which will almost certainly do better battery-wise, but if you have some idea that you can just hack something cool and flashy together with HTML5, JavaScript, and CSS, and it won't drain the battery and make the device quite warm, you are likely to be disappointed.

I will agree that iOS is an absolute pain in the neck to develop for when it comes to doing anything remotely interesting with web technologies, regardless of whether that's as a hybrid app or even just in browser. But that's a long rant for another day.

<comment><USER44> I agree -- energy use is a shamefully under-exmained performance metric.

Xcode and Instruments has some solid tools for monitoring this, but if he's a developer who refuses to learn Xcode anyway, he's not using these tools.

<comment><USER43> I wonder if there's a way to do that for web apps? Both Safari and Chrome have pretty good support for remote debugging devices but I've not noticed anything like this for tracking energy usage. It would certainly be a super-useful addition.

</comment></comment></comment><comment><USER45> Nah. The main reason why Hybrid web apps suck today is because using a web view to render your ui fundamentally inserts a middleman between you the developer and the underlying memory management and ui rendering systems. This limits the type of apps you can build.

Web views dont allow you to embed native components (I.e uicollectionviews)into HTML/CSS. It's an all or nothing solution. This makes it hard to work around certain categories of performance problems.

Today this no longer the case But historically (around 2011-2012) the frameworks and tools available to web developers (jquery, es5)were inferior to those available to native developers.

Non hybrid approaches like React Native have a much better chance of being the "winner" today over traditional native development.

</comment><comment><USER46> > A resource-hungry 3D game or similar does not fit into my definition of > "app".

Interesting. Why not just say "There are categories of apps that my argument doesn't apply to"?

> You can push updated JS, CSS, HTML, fonts, and images directly to all of > your users without needing to recompile the app's binary and getting App > Store approval.

That's a benefit to the developer. It's only a benefit to the users to the extent that the developer's and users' goals coincide. I strategically refuse to update certain software on my phone. Software that doesn't give me that choice usually ends up uninstalled, because it usually changes unexpectedly in a way that makes it unsuitable for my use.

</comment><comment><USER47> Consumers don't want to download any more apps unless there is a SUPER compelling reason to do it.

If you don't need native functionality, or video capability, then mobile web is going to be a 1000x better choice.

<comment> k-mcgrady App downloads and revenue increasing year-on-year (for both iOS and Android) seems to disprove this

<comment><USER47> Only in volume, not percentage, there are just more people joining the marketplace. Apps vs mobile web as share of user experience is dropping.

Makes sense after all, its easier, faster, cheaper, less storage used etc... and more accessible to get to something on safari or chrome than publishing an apk or ipa

Now, the real question to me is where are people spending their time? Pretty much all in apps, but only for the top 10-20 apps in the marketplace - <USER3> means that unless you have a top 10 app that is going to pull people off of their FB/SNAP etc...app and onto yours, then don't waste your time.

[1][https://venturebeat.com/2015/09/25/wait-what-mobile- browser-...](https://venturebeat.com/2015/09/25/wait-what-mobile-browser- traffic-is-2x-bigger-than-app-traffic-and-growing-faster/)

</comment></comment></comment><comment><USER48> This article would be great with the title "Apple makes it unnecessarily hard to develop hybrid apps". It's obviously not too convincing on the much larger question of Hybrid vs. Native.

<comment><USER43> Agreed. I think you've captured the essence much better than my rather long- winded screed above, although there is a good point about battery life buried in there somewhere.

</comment></comment><comment><USER49> If the complaint is "cross-platform apps would be ubiquitous if not for Player X" why stop at Apple?

Can't we point to this trend more generally being driven by Microsoft for years?

Or IBM before them?

This is a symptom of our economy as a whole. A big player dictates what is acceptable output. Not directly, but through a kind of market capture.

I get tired of these very specific, customized complaints about society, that ignore the bigger picture cause.

</comment><comment><USER50> It seems like this is the authors first time creating a hybrid app, and some of this stuff i highly skewed.

I and others have had horrible problems with performance on android, the Chromium engine for instance is not available on all devices, and rendering is not guaranteed to be universally the same across devices. One fix is to use the Crosswalk add on, which bundles a webview with your app.

</comment><comment><USER51> It looks like the Top Grossing iOS apps are Hybrid Apps or games. So I don't see that "IF Weren't for Apple".

[https://sensortower.com/ios/rankings/top/iphone/us/all- categ...](https://sensortower.com/ios/rankings/top/iphone/us/all- categories?date=5/24/2017)

<comment><USER52> Game are still native. If you take Unity or Unreal engine 4, as of today it compile against metal for the Mac/iOS renderer. So yeah, actually game development is ahead of applications in term of crossplatform dev.

</comment></comment><comment> trey-jones Occasionally I find an article on Hacker News that I both strongly disagree with, and feel I have enough domain knowledge to speak intelligently about. This is my opinion, and may be different from yours.

> Make No Mistake, Going Hybrid Is The Right Choice For The Vast Majority Of > Apps

I think that is very presumptuous. Maybe it is for some developers. I used Cordova sparingly a few years ago. Most of my hybrid development going back to 2012 is using Appcelerator Titanium. In fact, at this very moment I'm putting off working on a project built on the Appcelerator Platform, because of the giant headache that it has caused me.

Here are some of the reasons that I'm in favor of native development, with completely separate codebases for each platform, possibly using some shared libraries when appropriate.

1\. As alluded to in the article, even with hybrid you have to put up with Apple BS. And it turns out, Xcode is not completely terrible; eg. in 2017, building a native app, you don't have to worry about provisioning profiles (much), because Xcode handles this for you. I was shocked when I discovered this after developing hybrid apps for years. If I have to learn it anyway, I might as well use it.

2\. Quality/reliability/ease-of-use of third party libraries is higher. Yes, there are legions of Javascript developers out there, and some of them are trying to build mobile apps. There are also a great number of native developers out there and (trying not to ruffle too many feathers, and with no data to back this up) they are on average more experienced than the average javascript developer. They are also writing COMPLEX apps, and as a result we have a large ecosystem of good libraries that do a lot of the things that one might need to do when writing a mobile app, and they probably work out of the box with your toolchain, because the developer is using the same toolchain as you. Just drop it in, and use the API.

3\. Hybrid app frameworks do not expose the full feature set of native platforms. Yes, Appcelerator just released "Hyperloop" to the masses which claims to do just that. I haven't tried it. Why make native calls through Appcelerator when I could just make native calls to the OS?

4\. Hybrid app frameworks have their own bugs, and limitations that require strange workarounds. One might think that running into these would be uncommon. All it really takes is one, if you then have to sidetrack into learning about the codebase framework you are using, potentially rebuilding from source if there's no way to work around it at the top level. By the time you get it all sorted, you may as well have just done native. Sure Xcode has bugs and limitations too, and Appcelerator has definitely improved in this area over the last 5 years, but with layers of abstraction comes layers of new problems.

5\. Technical support is easier to come by with native. Having a problem with something complicated? Good luck finding an existing question and answer of Stackoverflow. There just aren't enough knowledgable Javascript devs doing complex things with hybrid apps compared to native. Also, the hybrid app development ecosystem is fragmented: the problem you are having with Cordova is probably not the same as the problem I'm having with Appcelerator. Or maybe it is, but it's not readily apparent.

6\. Native toolchains are superior to hybrid ones. I'm stepping out a little bit here. I abandoned Appcelerator Studio years ago in favor of the CLI, so I don't know what I'm missing there today. Well, I do know that I'm missing a decent debugger. Maybe that is in Appcelerator Studio - I have no idea. Feel free to call me out on this one.

In summary, hybrid is probably the right answer for SOME apps, and SOME developers. Based on 5 years of experience building hybrid apps, there are very few apps that I think wouldn't have been better (without consuming additional budget) as native apps. There are too many unknowns for me to commit to building anything more complex than the most basic of apps with a hybrid framework.

<comment><USER53> I've been using Titanium for years now. Since the very early days. It's certainly had its fair share of painful upgrades, but I've learned a lot of Java and Objective-C in the process as I've built a few cross-platform native modules to do things the main SDK can't do.

And recently, they've opened up 'Hyperloop' to the (now) free Indie Tier. Hyperloop allows direct access to native iOS and Android code, modules, pods, Frameworks, jars, aars, etc. right from within the Javascript code.

I used Angular a lot too and have built Ionic apps with that knowledge too. But, my overall opinion is that Titanium is by far the best. (As long as you pick a good stable SDK version! ;) )

<comment> trey-jones I don't really disagree that they have the right idea, and are the best that I've tried in the hybrid space. I've just spent so much time fighting the platform that I feel native is a safer, more powerful, and better option.

</comment></comment></comment><comment><USER54> Peeps tend to forget that back in the days when "Apps" became a thing, responsive design wasn't even a term...

</comment><comment><USER55> _You can push updated JS, CSS, HTML, fonts, and images directly to all of your users without needing to recompile the app's binary and getting App Store approval._

This goes against Apple's terms and conditions. Because of this alone, you can have your app removed at anytime.

</comment><comment><USER56> Much better for the developer, but also a worse experience for the user.

I have installed a desktop application for Slack, and it eats RAM like crazy. I would love to have a fast alternative that's not IRC in the command line.

I want some middle ground like Evolution is for emails.

My take is: when products change too fast, this fast iteration development wins. When products have a stable featureset and performance can be a factor, native clients will win. And this has nothing to do with Apple rules or limitations.

In fact, this is what is happening between SublimeText and Atom. If both had the same price (zero) and license, I don't think anyone would use Atom.

</comment><comment><USER57> The native/hybrid/web discussion has been going on a long time. The general consensus I've found is that web/hybrid is fine for some things, like magazine style apps, and untenable for more complex needs.

The app described seems to fit into the magazine style category (and was developed on a pretty high-end device). So to me this comes off as a "works for me" inappropriate generalization.

</comment><comment><USER58> Of course, if it weren't for Apple, HTML5 development for mobile wouldn't really be a thing either...

So, I'd say give Apple credit for launching HTML5 mobile development, but recognize that they haven't pushed it to become a fully viable platform.

</comment><comment><USER59> > Needing a Mac to compile the app

I remember a recent announcement of Microsoft about using xamarin to generate an iOS app without xcode and with the ok of Apple. It was on HN but I can't find it. I assumed that without xcode means without a mac.

<comment><USER60> You can _develop_ an app without a Mac using Xamarin Live Player, but you still need a Mac to build the standalone package to publish to the App Store

</comment></comment><comment><USER61> AS3/Flash was an amazing language + ide. It included a simple syntax, layers, a great system of events and callbacks, animations built in, timelines, vector graphics, etc. I and other AS3 devs (2011) could write code x10 faster than anyone in obj-c. The concept of AS3/swfs running on an iOS store could mean the end of control of the apple app store and the break down of the obj-c community.

Apple completely fucked over AS3/Flash. Adobe launched multiple attempts to work with apple to build out a system to launch swf files on a iOS device. Apple could have helped. Adobe should have played hardball and yanked photoshop [+studios] from the osX.

<comment><USER15> Except it ran like shit everywhere besides Windows, never mind a 2007 iPhone.

I'm sure it could be made to work great, but it never did.

<comment><USER62> To play devils advocate, we are in 2017 and JS adverts on normal websites can slow the latest phones down to a crawling stuttering mess.

These are probability the same developers that were writing sloppy Flash banners a decade earlier.

<comment><USER15> Sure, but JavaScript is an open standard and you can tune your implementation at will.

Compare that to being at the mercy of a company like Adobe that bundles at least 3 _different_ JavaScript interpreters, a full blown WebKit and who knows what else to Photoshop. All while having a custom made cross platform UI layer across all of their apps.

<comment><USER43> True, although sadly you can't also tune JavaScript developers at will.

</comment></comment></comment></comment></comment><comment><USER63> By all means, we should bring back Visual BASIC for developing mobile apps.

</comment><comment><USER64> Boy is it time for another round of "Hybrid Apps, Wave of the Future!"?

Disclaimer: I've been writing and shipping iOS apps since shortly after the iOS SDK existed, and writing and shipping Android apps for the last couple of years. My opinions may be biased.

First, a couple of observations to get out of the way that may support author's thesis, but IMO not really:

\- A good portion of existing native apps should not be apps at all. These are apps for services that are infrequently used, and should have been websites the entire time. Note that I'm saying they shouldn't be apps at all - <USER4> or hybrid - they should simply be websites. Because of the friction of installation, shipping an app for something users will only very occasionally use, is pointless.

\- If your apps are strictly by-the-numbers CRUD apps _without background activity_ , then a hybrid approach is likely the best bet.

Now that _that 's_ out of the way...

> _" A Hybrid version of an app will never be as fast as a native version of > the same app, but it doesn't matter as long as the Hybrid version is fast > enough."_

This assumes the lack of competitors who _are_ willing to put in the effort to make a performant app. It should be noted that janky, slow UIs that are "good enough" were the norm before the iPhone came around and raised everyone's expectations.

If you're building an app for Comcast or your local utility company - <USER5> competition is definitionally non-existent, then yes, it doesn't really matter as long as the hybrid version is fast enough.

For markets with competition, this simply produces a large window for someone to eat your lunch.

> _" You get to utilize your existing JS, HTML, and CSS skillset to develop a > single codebase that runs on both iOS and Android."_

This seems user-hostile. For all of Apple's warts, one of the great things they did around the iPhone is to rebalance consumer software development _away from developer convenience_ and _towards user convenience_.

The 90s and early 00s was defined by software that was difficult to use, engineered to be just "good enough", and largely the process was geared around developer ease rather than user satisfaction.

Yes, as devs we want all kinds of shortcuts to make our lives easier - and by all means we should pursue them - but the market in many places no longer tolerates the UX compromises of certain shortcuts, and consumers have come to expect apps to respect their platform's UX standards and have a high performance bar.

Case in point: Java apps also allowed devs to ship multi-platform from a single codebase, anybody here actually enjoy using those things? Practically nobody does that any more.

> _" Viewing changes on your device during development is nearly > instantaneous."_

This is legitimately a great feature of web dev vs. native. There is a lot of work being done on iOS and Android to shorten the preview cycle - but it's nowhere near web-quick (and is unlikely to ever be).

But again, this is a developer convenience, not a user convenience, and like all developer conveniences, it should only be pursued without harm to user experience.

> _" You can push updated JS, CSS, HTML, fonts, and images directly to all of > your users without needing to recompile the app's binary and getting App > Store approval."_

This is the part I wanted to touch on most: _DO NOT DO THIS_. This is _explicitly against App Store TOS and can /will get your app rejected or pulled without notice_.

You _cannot_ ship features to the App Store without a binary update. This is also not a hypothetical - Apple has recently started ratcheting up enforcement on apps that significantly modify functionality while bypassing the review process.

If you want to build a hybrid app despite my objections, by all means, but _do not use code push features and especially do not use it to bypass Apple review processes_. This will end poorly for you.

<comment><USER65> >> "You can push updated JS, CSS, HTML, fonts, and images directly to all of your users without needing to recompile the app's binary and getting App Store approval."

> This is the part I wanted to touch on most: DO NOT DO THIS. This is > explicitly against App Store TOS and can/will get your app rejected or > pulled without notice.

I just came here to say the same thing.

I guess it's still useful in 'enterprise' scenarios though, where you are distributing apps to a restricted set of users by some other means, such as through Microsoft's Intune. I don't know why Ionic Deploy and CodePush don't make this plain though.

Edit: I just checked the CodePush FAQ, and they seem to be interpreting the Apple developer agreement such that updates outside of the app store _are_ allowed as long as they don't radically change the app [1].

Personally, I'd be really wary of going down this path, worried that Apple or Google would pull the rug out from under it. Anyone here had any apps rejected or pulled for using CodePush, Ionic Deploy or something similar?

[1] [https://microsoft.github.io/code- push/faq/index.html](https://microsoft.github.io/code-push/faq/index.html)

</comment></comment><comment><USER66> If it weren't for Apple there wouldn't be app development.

</comment><comment><USER67> this is amusing when you consider how reluctant Steve Jobs was the native app development when the iPhone first came out. He wanted everyone to build web apps!

</comment><comment><USER68> try using some nice animations...

</comment><comment><USER69> >> Rizer is a Hybrid app that uses Apache Cordova and its plethora of native plugins

Plethora of native plugins? Why is it a good thing for my app to have a plethora of dependencies on obscure plugins that someone else has to maintain and update otherwise I am completely blocked from developing? Nevermind the fact that I have to learn all the intricacies of said obscure plugins? Just to be able to do what I can already do more efficiently in native?

>> Make No Mistake, Going Hybrid Is The Right Choice For The Vast Majority Of Apps

Why are you leading with this after explaining the app you built? Show me why it's better, don't just act like an authority and tell me so. And you don't appear to be an authority on mobile app development, it appears any experience or credentials you have are in javascript. You made a single mobile app with hybrid and are now ready to declare that going hybrid is the right choice for almost everyone?

>> A Hybrid version of an app will never be as fast as a native version of the same app, but it doesn't matter as long as the Hybrid version is fast enough.

Thanks, and you're right! Native apps are much faster and always will be much faster than the apps you seem to want to make. How one can determine if their hybrid app will be "fast enough" ahead of time is as clear as mud. For apps that do significant things and need to do them quickly, I suspect many hybrid apps won't be "fast enough" and the user will be able to tell that they are on a website. But you'll have to just engineer it and find out later if the framework has an unconscionable defects or limitations. Happy coding (oh and try not to use jQuery)!

>> A resource-hungry 3D game or similar does not fit into my definition of "app"

Games are apps too, but don't worry, there is a real cross-platform technology out there called Unity for you. You won't be able to use JS with it though I am afraid.

>> In these cases a native app is almost certainly your best option

Almost certainly? Certainly.

>> You get to utilize your existing JS, HTML, and CSS skillset

You are assuming that someone who wants to make a mobile app has an HTML, CSS, and JS skillset. Why are you assuming this? Are you writing this because you have a certain set of biases and preferences for web technologies or because you actually think hybrid is the best way? One must wonder.

>> single codebase

Single codebase isn't a selling point if your app is slow and full of workarounds piled on top of workarounds that probably would have been solved with a single line of native code.

>> There are less than 10 times throughout my project that I needed to branch the code based on the platform the app was running on

This is utterly embarrassing, and very telling to me that you think it is a selling point. The entire point of doing a hybrid app is to NOT be doing this. "I only had to do it 9 times!!" should not encourage anyone and truthfully could only be seen as encouraging by someone who was dead set on using web skills in a mobile arena to begin with and was determined to make any justifications to do so.

>> Viewing changes on your device during development is nearly instantaneous.

Great. So are native apps. You click the little play button in the IDE. Nearly instantaneous. Again, it's a mystery why you think this is a win for hybrid.

>> You can push updated JS, CSS, HTML, fonts, and images directly to all of your users without needing to recompile the app's binary and getting App Store approval.

APK upload for the Play Store is almost immediate. Yes, iOS has a significant review time which has been whittled down to about 2 days. I don't think this is really paramount to anyone. You forgot to note though, a downside of doing Hybrid is that Apple rejected your app 7 times which wasted far more time than you would have gained on any of this other stuff.

>> Choosing between these two WebViews sucks.

Not Apple's fault. This was your choice.

>> Thanks to some fantastic work from the Ionic team, some masochistic developers (myself included) are utilizing WKWebView in their Hybrid apps. I will be the first to say that when WKWebvView works, it really works.

Sorry, reading between the lines here -- are you encouraging people to use things that you KNOW don't work? If so, why?

>> Inability to access files that don't exist in the app's root "www" folder.

Not Apple's fault, your fault for choosing Cordova.

>> Numerous CORS (Cross-Origin Resource Sharing) issues, including being unable to extract image data from a canvas that was drawn using a local image.

Not Apple's fault, your fault for choosing Cordova.

>> Unpredictable vertical scrolling behavior, and in my experience, completely broken horizontal scrolling.

Not Apple's fault, your fault for choosing Cordova.

>> No programmatic control over showing and hiding the keyboard

Not Apple's fault, your fault for choosing Cordova.

>> App-breaking conflicts with stable versions of the Cordova SplashScreen plugin

Not Apple's fault, your fault for choosing Cordova.

>> App-breaking conflicts with stable versions of the Cordova In-App Browser plugin

Not Apple's fault, your fault for choosing Cordova.

>> Without a doubt, creating Rizer was a longer and more frustrating experience than I expected it be… thanks to Apple.

Not Apple's fault, your fault for choosing Cordova.

>> In my experience, all of the potential show-stopping issues caused by going with the Hybrid approach have workarounds.

Oh, awesome! Just what everyone was looking for. How to build an app with workaround piled on top of workaround piled on top of a hack piled on top of a workaround piled into a shitty webview.

>> They are frustrating to discover and implement, but they do work.

Here we go again where you subtly or not so subtly admit the thing which you are advocating for actually sucks (and is the most hated technology on stack overflow).

>> It will absolutely take you longer to develop a Hybrid app than it should

Correct!

>> will feel just as fast as to your users

lel

<comment><USER37> Thanks for the feedback. Is there anything I can do for you? Sounds like you are having a bad day.

</comment></comment><comment><USER70> >Put simply, if your users never complain about the performance of your app then it is fast enough

Suppose the users aren't aware that your app is wasting their battery power, because of it's bad performance?

Suppose your users don't complain because ~90% of software is written slow, and so they expect sluggish response. Maybe you could be getting rave reviews about how responsive your app is. Example: saw recently a discussion on reddit where a guy did an Android app in rust, instead of the usual Java/Unity etc. People who tried it out all remarked "wow that was the fastest opening game I've ever clicked on!"

CPU designers have been doing amazing things with hardware, let us not waste it.

<comment><USER26> I remember two years ago I was playing a fun little game on iOS and it felt nice and fast and I had no problems with it.

Until I got complaints from the network manager at my work because it seems that when you skip the video ads it continued to play them in the background and used up the very meager bandwidth we had at the time.

It's very easy for a simple accidental mistake to cause all sorts of issues while the app still feels "fast".

(I'm still kind of surprised/disappointed that got through app review).

Also, just because something is fast enough that people don't complain doesn't mean that it's fast enough that people are happy. I'm used to the speed of my TiVo, it could be MUCH faster.

The truth is: people are used to poorly designed things that don't go very fast. That doesn't make it OK to give them more of them.

<comment><USER71> Why do you think hiding skipped ads was a mistake? Seems a potential way to increase ad revenue if only paid for viewed ads.

<comment><USER72> That sounds like fraud if you mean that the ad counts as viewed even when it isn't.

</comment></comment></comment></comment><comment><USER73> I can't say I buy this for a second. Neither the idea that hybrid apps would be the winners, or that it's Apple's fault.

Lest anyone forget, the iPhone's original "SDK" was web apps. People cried out for a native SDK.

</comment><comment><USER74> If notifications could be brought to Hybrid Apps... that would be the swan song of iOS/Android. HTML5 can access all of hardware on the phone but lacks notifications so it's still not viable to only make Hybrid web apps.

<comment><USER75> I don't think HTML5 can access the phone's camera. For my app, this is critical and another reason why we're stuck on native.

<comment><USER76> Get media device, you get camera and mic

</comment></comment></comment><comment><USER77> Talk about revisionist history.

Apple never had an SDK to begin with because they thought developers would write their apps in HTML5/JS. Guess what ?

They were awful and users hated it compared to the native applications.

<comment><USER78> Why is this down voted? It's absolutely verifiable. You can watch the keynote and then go read the headlines lambasting the decision. It's why the phone launched in Summer 2007 but the App Store launched in Summer 2008.

<comment><USER79> I didn't downvote, but the comment misses the point of the article. Were web/hybrid apps the right choice in 2007? No, but that doesn't mean they can't be in 2017. The hardware is orders of magnitude faster and the software ecosystem has vastly improved.

It wasn't a great idea to start a internet-only business in the mid 90s (with some obvious exceptions), but the same isn't true today.

</comment></comment></comment><comment><USER80> Man, wouldn't it be awesome if there were something to inform the reader what is meant by "hybrid app"?

...because neither "hybrid" nor "app" is an ambiguous term taken on its own.

Hey, look, here's some niche API, that few people are familiar with, but blame Apple about... something. Get mad about it!

      OMG.

         SUCH APP.

      WANT DEVELOPMENT.

       MUCH RAGE.

            HYBRID APP.

      WOW.</comment>


Top programming languages that will be most popular in 2017 - <AUTHOR> http://blog.hackerearth.com/2016/11/top-programming-language-2017.html <comment><USER2> And I'm waiting for Elixir entering the lists in 2018/2019 ;)</comment>