$1.6B in funding and $7B in exits: Chicago tech just had its best year ever - <AUTHOR> http://www.builtinchicago.org/2015/01/22/16b-funding-and-7b-exits-chicago-tech-just-had-its-best-year-ever <comment><USER2> Eh, three things really grind me gears about the tech scene in Chicago.

1) Lots of mediocre entrepreneurs that seem to have the same story:

      - Little to no hard skills.
      - Probably got an MBA from a good B-school
      - Did a stint at a consulting firm and is going to outsmart
        the competition with all the wisdom they gained at
        Accenture, McKinsey, BCG, Bain, or some big IL firm.
      - Does NOT have a technical co-founder but is being advised
        by some guy with a similar pedigree that attended a coding
        bootcamp/wrote a crappy iOS app/got a CS degree...
        but has written <10,000 lines of code in their life.
          - This person will interview you by giving you a fizz
            buzz test followed by "lateral thinking" brain-teaser
            questions). Very 90s.

I know these people exist everywhere today but there's an unusually large number concentrated in Chicago. Must be something in the water?

2) Developer compensation is roughly 10% lower (when adjusted for CoL) than it should be. And in terms of equity compensation Chicago isn't even in the same league as SV today. Getting >0.25% as the initial engineering hire is extremely rare here - even at companies that lack a technical co-founder.

This causes younger talent to get sucked to the coasts.

3) Many of the startups do not actively cultivate a technology or engineering culture. I think this largely stems from Point #1 - you really do need a tech co-founder to drive that side of the company.

<comment><USER3> I'll offer a hypothesis to explain #1:

It's because Chicago's culture is excessively risk averse. There seems to be a tendency to seek permission or acceptance from peers and others before taking a risk (either in business, fashion, life, whatever).

This is actually great for bootstrapping, because it keeps you in touch with the real world and immediate customer demand.

But it leads to fewer qualified, technical people there with no history of 'business' thinking that striking off on their own and starting a company is a good idea.

The people who do start companies there are often the ones who have gone through some kind of training program (MBA, work experience, etc.) that in their minds has qualified them to start a company.

So I propose that it's not that the MBA types are overrepresented, it's that technical folks and others are underrepresented, because they're tending to not start companies.

Disclaimer: totally conjecture, based on living in Chicago for eight years, but being from California and now living in NYC. In moving from Chicago to NYC the most striking difference (for me), other than the diversity, was the spirit that no one cares about you or what you do, so you might as well do whatever you want or think you can. For some that means starting companies.

<comment><USER4> > It's because Chicago's culture is excessively risk averse

I don't know if the culture is that much more risk averse than SF, but rather that the risk calculation is different. There's such a big tech ecosystem out in SF that "failure" as an entrepreneur might mean raising more money for the next project, or failing that BigCos fighting to hire you. Without the same depth of tech infrastructure, the downside risk is much higher in Chicago (or really, anywhere that's not SF).

<comment><USER5> I would say that the SF failure-is-good culture has good and bad influences from the VCs. They don't care _that_ you failed. They care _why_ you failed. If their evaluation is that you failed in good faith, you get to call it a learning experience and you get an executive position at Google (preferably something with the authority to buy companies, so you can pay them back) or more funding for your next venture. If they judge you to have failed in bad faith, then you're black-balled. So it cuts both ways. It's nice that they'll go to bat for someone they judge to have failed in good faith; it's bad when someone gets blacklisted as having failed in bad faith (or has his successful business taken from him) because he pissed someone off.

Any time you replace objective evaluation of people with subjective holistic evaluations, you get a system that seems more humane and less sharp-cornered, but you also get corruption. It's the question of which is better: sheer cold fairness or sticky warm humanness that can devolve into corruption or even a reputation economy (meaning, "extortion system") if the powerful abuse their roles in the judgment of others.

You can look at it charitably and say that the VCs are doing good by caring more about the reason for failure than the fact of it. Or you can look at it negatively and say that it creates a culture where (a) slimy operators good at creating impressions can play politics and let their companies rot, knowing that their backers will see their failures as "good faith" regardless of the facts, and (b) those with power over the "holistic" element of evaluation evolve into reputation-making and -breaking extortionists. The "right answer" is somewhere between the two.

With Chicago, I think the problem isn't that there's a lack of good jobs for technical people, but that the job-hopper stigma is still very strong in finance (and that's true everywhere; it's not geographical, and the attitude is similar in SF finance). So it's hard for a trader to bounce back if the startup doesn't work.

If hedge funds were willing to hire people with typical startup/tech CVs-- those tend to show the brutally honest behavior of job-hopping (even at 2 years, or 6 months) if one's career is stagnating, rather than sticking around for 5-6 playing the system or slacking like white-collar people are "supposed" to do when passed over, because it's somehow more disloyal to leave than to slack for years-- then people would less afraid to do startups. The fault isn't with Chicago _per se_. It's with finance and the F500 world and their anachronistic hatred of the "job hopper".

There's a lot that I don't like about California startup culture but I think job hopping is a good thing. If you're ambitious and it's clear that you've been passed over for advancement, it's better for everyone to move on than to stick around and suck out a salary and play against the system for 5+ years because the white-collar world thinks you're "supposed" to show "staying power" or "loyalty".

At any rate, I think you're completely right. I don't think that California is more or less risk averse than the rest of the country, nor do I necessarily think that risk seeking is even a virtue. California entrepreneurs get to look more risk-friendly just because there's such a high frequency managed outcomes (acqui-hires and executive positions made available if the VCs judge you to have failed in good faith) that VC-funded entrepreneurs can count on one. Where it's pernicious is when these founders justify massive equity disparities (compared to the 0.5% that the first engineer gets) because they "took all the risk" when, in fact, most of these VC-funded founders don't take _any_ more risk than any other corporate employee.

<comment><USER6> Traders don't want to hire job hoppers because it's a negative signal about their abilities and ethics. First, if this guy is really so great, why has he flamed out of 3 firms in 5 years? Either he's lying or has some serious personality defect. Second, do I really want a guy who's bounced from firm-to- firm glomming up ideas and IP? Won't he do the same thing to me?

Going away to do a startup doesn't send the same signal. I'd gladly hire someone who did that.

<comment><USER5> _Traders don 't want to hire job hoppers because it's a negative signal about their abilities and ethics._

You're wrong. I can make the same argument against people with long tenures. Some people, when they realize that they've been passed over for a promotion or that they're not being groomed for the role they want in the future, bounce (external promotion). That's the honest thing to do. Others stick around, play politics, work the system, slack, and wait for others to fail so they can capitalize on the chaos and move up the ranks. In other words, one could make the argument that the able, confident, ethical, honest people job hop and the political actors stick around and climb the ladder.

I don't _actually_ believe that most people with long tenures are unethical. I'd put the correlation right around zero, to be honest about the whole thing. I think that there are patterns that cause good people to have long tenures and bad people to have short ones, and also patterns that cause good people to have short tenures and bad people to have long ones.

 _First, if this guy is really so great, why has he flamed out of 3 firms in 5 years?_

Maybe he's technically excellent but bad at playing the politics. Perhaps he's an overperformer, like McNulty on _The Wire_. Maybe he's just unlucky. Maybe he didn't flame out, but each move was a major promotion that he wouldn't have been able to get internally.

 _Second, do I really want a guy who 's bounced from firm-to-firm glomming up ideas and IP? Won't he do the same thing to me?_

The problem isn't "job hoppers". It's attrition. When people leave, it's disruptive (and the internal disruption to your own processes is so much more of a threat than IP leakage, unless someone's actually stealing code and then it goes to the courts, that the latter is a rounding error). You can control attrition by treating people well and making sure that ambitious people have appropriate opportunities get promoted on time. It has little to do with the people you hire, and much more to do with how you manage them.

The anti-"job hopper" sentiment isn't really about IP. It's about being mean- spirited, and the IP justification is just made to back-fill an already-formed prejudice.

<comment><USER7> are your comments always grayed ?

<comment><USER5> Ever since I exposed Spiegel for what is probably a self-serving PR move exploiting the Sony hack, I've had at least 4 stalker down voters. It's obvious because they tend to hit at the same time.

<comment><USER8> Have a link to the article which contains your comments about that? I'd like to read them.

<comment><USER5> [https://news.ycombinator.com/item?id=8764572](https://news.ycombinator.com/item?id=8764572)

Not everyone who downvoted that (admittedly, not well-expressed, insofar as some thought I was accusing Spiegel of _causing_ the Sony hack rather than simply benefitting from it) comment was a Speigeloid. The Spiegeloids are the ones who have been repeatedly downvoting random comments of mine just because I wrote them. (Or, an alternative explanation would be that the Hacker News community has suddenly become much meaner... but I doubt that.) In other words, stalker-downvoting (seeking out someone's comments and, without reading them, downvoting them).

I have no idea when it comes to their personal identities, but I know that I have at least 4 stalker-downvoters. They could be sock puppets of one person. For all I know, it could be Spiegel himself (but I doubt that).

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> It's interesting what would be 80s/90s person assumption?

"1.6B in funding! Oh boy, robots, life extension, hover cars!"

"Err, no. But you will be targeted with ads about food delivery and HR services much more precisely!"

<comment><USER10> Remember, you're talking about the 90s which had as a flagship startup a company that sold pet food. Broadcast.com alone was purchased for $5.9B (eq. to $8B of today's money), and all they did was stream video over the Internet.

<comment><USER11> All Youtube does is stream video over the internet. Your argument isn't that convincing.

<comment><USER10> Yes, and Youtube isn't making hover cars nor extending life. Are you sure you read the context of my reply?

</comment></comment></comment></comment><comment><USER12> My impression is that in Chicago -- and really everywhere outside the SF BA and NYC -- has much weaker comp for engineers.

It makes sense, really. By far the majority of SE jobs in these places are in IT departments writing line of business software. These are Java and .Net shops usually and anecdotally it seems they pay from $60-90k.

The companies where engineers are profit centers -- web startups and software companies, etc -- are desirable and attractive. Importantly, these are usually high margin businesses. In competitive markets, these companies meet engineer scarcity with attractive pay and equity packages. In places like Chicago, for every opening at 37 Signals you have 5 applicants from places like Crate & Barrel.

This is unfortunate especially because even here in SF I think engineers are not yet paid what they are worth. I reach this conclusion by looking at the margins of software companies and profitable internet companies. You can clearly see the value software engineers are creating.

To be clear, I'm sure there are thousands of highly paid software engineers in the greater Chicago area. it's a very big city and there is a lot of money there. Hell there may be thousands of highly paid engineers in finance alone. Chicago is certainly the heart of trading in this country. I'm generalizing.

<comment><USER13> I'm getting $75k as a Python engineer with 5 years experience. Am I absurdly underpaid?

My job feels easy, I have flexible hours, little oversight, independence to build cool things, good benefits, and I feel very lucky that anyone would pay me so much money to sit in a climate controlled office playing with a computer.

<comment><USER14> As with any market based pricing its hard to say whether the price is right or wrong. Because the real price is what the market will bear.

I will say, for the broad outlines that you've given that is a low compensation figure. And projecting a bit, I can probably figure out why. First you said yourself, that you don't value yourself much more highly than you are currently getting paid. Why should anyone else?

Secondly, the way you present your product (Python engineer) lowers the prestige/premium it should cost. First, but least importantly, because Python, in general, pays slightly less than other technologies. Second, and much more importantly, being a programming cog to be placed into a programming assembly line is much less valuable than being a business problem solver that uses and builds technology.

I'd recommend going over to patio11's blog and reading:

[http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a- pro...](http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/)

</comment></comment></comment><comment><USER15> If I weren't a risk averse, cowardly lawyer and was planning on starting my own business, I'd go to Chicago.

It's a world class city with tons of programmers and engineer. But it's also much cheaper to live in.

<comment><USER16> Heh, just don't come here looking to start a law practice. Three major law schools plus a couple less-major ones, every one of them churning out way more JDs than the local job market can soak up. I'm pretty sure the acronym now stands for Java Dispenser.

<comment><USER15> I went to Northwester but fled to DC for a job. I'm all too aware unfortunately.

</comment></comment></comment><comment><USER17> Chicago has a significant advantage: it's more "normal" in that it's more representative of the United States, than the Bay Area. This provides a fertile ground for new companies to emerge:

      - Childcare / anything to do with children (e.g. Sittercity)
      - Things for people without college degrees -- SF has 48%    [1] degreed workforce vs. 28% [2] nationally.
      - People in Chicago/the rest of the US have houses; over 80% of SF's population lives in apartments. There's tons of businesses involving housing including lawn care, general home improvement, construction, contracting, etc.
      - People in Chicago have cars; many people in SF don't drive (surprised Uber came from here? I'm not)
      - Anything involving small business
      - Also, world-class financial center

There are other things, the point is to focus on your strengths, not try to be a knock-off of something else (an idea from Richard Florida's "Who's Your City", a book about the relative strengths of various cities)

[1] Saw this in Business Insider a while ago [2] "Coming Apart" by Charles Murray

<comment><USER5> Silicon Valley is somewhat of an aberration at this point. There's an S-curve to concentration (whether in talent, resources, or attention) and while the bulk of American cities are hurting due to a lack of software talent, Silicon Valley is hurting in its own way. It has a lot of engineering talent but a collective lack of political talent (which is what prevents engineers from organizing and getting real equity instead of fucking 1% for the first engineer) and such abysmal HR/management that an exclusionary macho brogrammer culture (that wouldn't fly outside of VC-funded startups) has been allowed to emerge.

So, trying to replicate Silicon Valley isn't a good strategy. It's not very desirable. It's also not possible. Not for New York, not for Chicago, not for Seattle, not for Austin. Should these cities be grabbing a greater share of the new-technology action? Yeah, absolutely. But trying to replicate the culture of a sexist, racist suburban shithole whose high priests think it's OK to block off public beach access (cf. Vinod Khosla) is undesirable. It's happening slowly, but that shit is _dying_ (although it will take two to four decades). Why does the contemporary Valley put such a high premium on pedigree? Because when a society goes into decline, nostalgia dominates. When the Valley was coming up, it didn't matter if you went to Stanford or UC- Irvine or a community college in Nebraska, so long as you were smart and could code. In its decline phase, you see the Stanford Welfare of Clinkle and Snapchat getting funded.

Talent has a natural desire to concentrate, and that might limit us to ~10 strong tech cities in the US, but Silicon Valley has blown past that natural inclination toward concentration. It's deep into the "congested" territory.

What makes Silicon Valley is that it's a condensation point for passive capital. Passive capitalists (teachers' pension funds that invest in VC firms) want returns, and don't seem to strongly care about where or how the capital is deployed. The priesthood that is trusted (in error) to do so are VCs who mostly live in California, and who almost never fund companies more than 30 miles from where they live, so the job and wealth creation is limited to a small geographic area (in which it's almost impossible for an engineer, if he's starting now or recently, to make wealth due to astronomical real estate costs) far away from where the passive capitalists live. Now, if the passive capitalists had a vote, they probably wouldn't want _all_ of their money being directed at a small geographical area where most of them could never afford to live. All being equal-- and by "all", I mostly mean "return on investment"\-- Nebraska police officers would rather their pensions be invested in Nebraska businesses and create jobs there... rather than have that money be funneled off to California. Of course, they'd be completely happy to have their money invested in California if that would bring better returns... but VC has been a low-performing asset class for a decade-- the VCs focus on their own careers rather than building great companies or generating returns on the portfolio-- so the passive capitalists are arguably getting screwed. If concentrating the passive capital in Silicon Valley was generating decent returns, then there'd be no reasonable argue against it, but it's not.

This is a long-form way of saying that I agree with you. Replicating Silicon Valley is a backward-looking strategy that won't work in Chicago or New York. These cities, instead, should focus on their own assets. I think Chicago (or Seattle, or Boulder, or for a longer shot, Minneapolis) is a contender for being a different kind of technical leader in, say, 2030... because Chicago has an unusual advantage of a perceived playing-from-behind while actually not being that far behind; that's fairly antithetical to the Valley's Dunning- Kruger smug cloud... but it won't look like the existing Valley. It'll be something different.

<comment><USER18> Let's say Chicago (or Seattle, or New York) become tech hubs comparable to Silicon Valley. What's stopping the same bro culture from developing there?

Isn't the misogynistic bro culture a function of a sheltered, narrow upbringing and a nationwide cultural infatuation with "apps" (which only the talented, sought-after Software Engineers can provide)?

From my experience, the bros come from all across the US and Canada, and not just the San Francisco Bay Area. I've lived and worked here all my life, and most people in the tech industry actually moved here from other states. So what's to say they all won't move to Chicago as well?

</comment></comment></comment><comment><USER19> As a Chicagoan and software engineer, here's my honest opinion of tech in Chicago: it's a sad, sorry place to be right now. I grew up in Chicago, went to college in Chicago and work in Chicago. It's been a roller coaster love- hate relationship for 30 years.

There's two major reasons I say it's so sad and sorry: a total lack of experienced, aggressive VC here, and a massive deficit of university-business partnership.

1\. Chicago, sans VC

There's a lot of money in this city. There's also a fair amount of capital being thrown around at start ups and small businesses. However, this place lacks having a couple well established VC firms and proper incubators. Without having direct access to solid investors and capital, many of the companies I've seen here flounder and fail. Their boards are comprised of investors who haven't a single clue about how to advise and lead tech companies.

Additionally, tech as a whole is looked as a cheap commodity in Chicago. The salaries are weak, the benefits are meager, and the chance to grow is basically nonexistent. The overwhelming majority of developers I know are either miserable at large companies (banks, trading firms, healthcare, etc) or are being worked to death with virtually no acceptable future benefit at start ups.

2\. Universities vs. Business

Let's look at this for what it is in Chicago: the business community and universities do not work with each other. There are so few partnerships for STEM students that it's basically pointless to go to college in Chicago if you're looking for curricula that is directly informed by industry. There's very little in the way of research being done with the guidance of industry or even an objective to productionize/market any of the work.

The universities themselves are also woefully underwhelming: Loyola, De Paul and UIC are basically glorified baby sitting campuses that blindly churn out subpar programmers. UChicago, on the other hand, has a solid engineering school but doesn't promote it at all. UIUC has one of the best engineering schools in the country, but it's two hours south of the city in the middle of a barren corn field. There's also a massive number of smaller liberal arts colleges in the burbs, but they lack exposure, the funding to recruit STEM students and have fewer still business connections in the city.

/rant; begin pep talk:

There's a lot of potential in Chicago, however (which is part of why I've stayed here). All it takes is an honest, concerted effort to get things rolling. As an example, what's happening in the Merchandise Mart and 1871 is a glimmer of hope of turning things around. It's far from perfect, but it's added a small amount of polish and professionalism to a stumbling tech sector in Chicago.

The article also cites a few large exits - which is nice and all, but it's still yet to be seen what is done with that money. Groupon (who I can't stand) turned their capital into a VC and have been building up start ups in the West Loop for a while. Again, it's not amazing, but it's encouraging to see people invest back into Chicago instead of splitting for the coasts.

The talent that is in Chicago is also top tier. One of the other reasons I've stayed here is because most developers in Chicago are very passionate, dedicated professionals. I've been all over the country and met other developers and interviewed in numerous places. I can honestly say that the caliber of talent here is on par with any other more prominent tech scene. What wins it is soft skills: Chicago is made of people who know how to be people. (New York is close second, though)

I believe that Chicago can be reborn as a tech hub, but it's going to take a lot of time, money and commitment to make it happen. This is going to require a lot from the local and state government, business, and universities. But most importantly, it's going to take people believing that it can happen.

<comment><USER20> I agree with the statement the most (also a Chicagoan). Chicago isn't a tech hub, and people need to stop saying it is. Why is it that our flagship university (UIUC) sends more people to Silicon Valley/Seattle than Chicago, which is only 2 hours away? They need to focus on bringing in some more mature tech companies (engineering teams, for one), and that can help potentially bring some more startups here.

<comment><USER21> There's actually a UIUC alum center in SF - [http://www.sfbayillini.org/](http://www.sfbayillini.org/). The last estimate I heard was that there are somewhere around 40,000-50,000 UIUC graduates in the Bay Area.

I grew up in Chicago, graduated from UIUC, and I live in SF and work in Silicon Valley. When I moved here, I didn't need to make any new friends if I didn't want to - when I got here, my entire friend group and extended UIUC social network was already here. Shit, my girlfriend (also from UIUC) works at a startup in FiDi where both founders are from UIUC and there are many alums.

It's just too damn easy to move here for us.

<comment><USER22> Dumb question- is the SF alum center open to non-CoE folks?

I was a math major that took a handful of CS classes... and am in desperate need of employment, but no one seems interested in giving entry-level dev work.

<comment><USER20> I would guess so. There are tons of startups out there, you just have to find one. Try Angelist[1] or Crunchbase[2] and you should be able to find something. If not, contract work isn't bad either.

[1] [http://angel.co](http://angel.co)

[2] [http://crunchbase.com](http://crunchbase.com)

</comment></comment></comment></comment></comment><comment><USER23> Is funding and exits how we measure success now?

<comment><USER24> Do you have an alternative metric? I suppose we could count jobs created. My experience in the Bay Area is that as long as exits >> (funding * 2), it means that there are non-investors making some money and going on to create additional opportunities (sort of the criticality threshold for entrepreneurism).

<comment> FLUX-YOU Number of customers? Years in business? Profitable quarters? Going from startup to long-term business? Uhh, military contracts awarded? (okay, maybe not..)

Are the majority of startups only ever going to be short term ventures?

</comment></comment></comment><comment><USER25> Speaking of Chicago based startups, Reverb.com is hiring :)

[http://reverb.com/page/jobs](http://reverb.com/page/jobs)

Check out our engineering blog at: [http://product.reverb.com](http://product.reverb.com)

</comment><comment><USER26> Chicago's a great city, and I've spent a lot of time there. But....

\- It's cold.

\- The academic environment itself is better in general business. Two top MBA programs, but the best engineering school is far down state.

\- It has winter.

\- The ecosystem supports growth, but not hypergrowth. Companies like BaseCRM do well starting there, but move to Silicon Valley when it's time to explode.

\- Snow without mountains

\- Not as socially, ethnically or culturally diverse as many other tech hubs.

\- Did I mention that it's cold?

All that said, I love to visit in the summer.

<comment><USER27> "Not as socially, ethnically or culturally diverse as many other tech hubs." Chicago has world class museums, music venues, restaurants and ethnic enclaves like Ukrainian Village, Maxwell St., Devon, Pilsen.. and you mean to tell me there's more diversity up in the bay area? LOL

<comment><USER26> Your chances of seeing multi-ethnic couples, kids and neighborhoods is 10X in the Bay Area than Chicago. (And yes, I've lived in both)

<comment><USER14> I'd be very curious to see actual statistics around that. This is a belief that is highly subject to selection bias.

I myself don't like the Bay Area for my own perception of the lack of diversity there, but again I would not be surprised if that is my bias showing through.

(and for instance I live in a neighborhood that has a history of multi-ethnic families that goes back to before that was socially acceptable nearly anywhere else in America)

<comment><USER20> Chicago is pretty segregated as whole. The North side is predominantly Caucasian and the south side (save for a few neighborhoods) is predominantly African-American and Latino.

<comment><USER14> Sure Chicago is segregated (though I find the North/South boundary, like all generalizations misses a considerable amount of complexity) but this is true of all US cities.

San Francisco for instance is segregated pretty dramatically with the Asian population (and a mixture of Latinos) pushed to the western edge and the white population centrally located. Not to mention the elephant in the room of Oakland.

When we start talking about diversity of other sorts such as income, education, nationality etc the picture is similar.

That is to say, my experience of San Francisco was one of homogeny, the opposite of my experience of Chicago. But I've experienced Chicago more broadly as well, so as I say I'd like some numbers to backup the assertion that San Francisco is more welcoming of inter racial families.

</comment></comment></comment></comment></comment></comment><comment><USER28> coming over!</comment>


Tim Bray and others on The End Of The Free Internet - <AUTHOR> http://www.therealnews.com/freeinternet/

<comment><USER2> free like speech, not free like beer.

<comment><AUTHOR> Martin Fowler blogged a bit about it: <http://martinfowler.com/snips/201012080613.html>

</comment></comment><comment><USER3> Funny, Internet was born in USA and here it has began to die. But US is not the only country with Internet... Hopefully EU will keep itself neutral.</comment>


DNC rolls back Obama ban on contributions from federal lobbyists - <AUTHOR> https://www.washingtonpost.com/politics/dnc-allowing-donations-from-federal-lobbyists-and-pacs/2016/02/12/22b1c38c-d196-11e5-88cd-753e80cd29ad_story.html <comment><USER2> No doubt a move to give Hillary a boost. Unfortunately. Kinda sick of the DNC at this point as a Democrat myself.</comment>


Twitter to Introduce Algorithmic Timeline as Soon as Next Week - <AUTHOR> http://www.buzzfeed.com/alexkantrowitz/twitter-to-introduce-algorithmic-timeline-as-soon-as-next-we#.lm3ABLe6M <comment><USER2> Uh oh.

Myself & many others gradually stopped using Facebook when they started messing with the timeline algo. Then they went and hid the timeline ordering functionality, which meant that I just stopped looking at the front page entirely.

This doesn't bode well for Twitter.</comment>


React Native at Airbnb - <AUTHOR> https://medium.com/airbnb-engineering/react-native-at-airbnb-f95aa460be1c <comment><USER3> "While debugging, React Native attaches to a Chrome Developer Tools instance. This is great because it is a powerful debugger. However, once the debugger is attached, all JavaScript runs within Chrome's V8 engine. This is fine 99.9% of the time. However, in one instance, we got bit when toLocaleString worked on iOS and but only worked on Android while debugging. It turns out that the Android JSC doesn't include it and it was silently failing unless you were debugging in which case it was using V8 which does."

Wow, I can't imagine how frustrating this must have been to debug.

<comment><USER4> I ran into a fun one like that many years ago in IE. The JavaScript I had written was failing, but when I opened up the devtools to debug it, it worked.

It turned out that in that version of IE, the console object only existed when the devtools were open. So a stray console.log call was causing an exception because console was undefined. But when I opened the devtools to see what was going on, console existed and so everything ran just fine.

I suppose that's the kind of error that only bites you once. When you know about it, you tend to never make that mistake again. But that first time you run into it can cause a painful few hours of head scratching and attempted debugging.

Funnily enough, I ran into a React Native error like the one described in the article, where something worked only while debugging. My previous experience with the heisenbug in IE led me to immediately dig into what was different in RN with the devtools open vs without them. So in a way, those hours I wasted in IE back in 2010 prevented me from potentially wasting hours debugging RN in 2017.

<comment><USER5> Programming doesn't change that much after all.

gRPC is just a modern SOAP. There, I said it.

<comment><USER4> Modern SOAP doesn't sound too bad to me! But then again, I never found SOAP to be all that bad.

I might have been lucky, though. Every time I had to use SOAP, it was just a matter of auto generating a client interface in whatever language I happened to be working in and then proceeding from there. I suppose not everyone was so fortunate.

<comment><USER6> I found that autogeneration rarely worked well unless the client and the server were using the same tooling.

The monstrous flexibility of xml and soap meant that in practice every soap server interface I had to consume had _some_ quirk or incompatibility with the client I was trying to use.

The worst offender was security extensions.

</comment></comment></comment></comment></comment><comment><USER7> Yet another company discovers what many of us did ages ago with multi-platform frameworks.

Additional layers not supported by platform owners, mean extra debugging efforts tracking down which layer is responsible, catching up with native SDK features, need to be an expert at both layers, lack of integration with native debugging tools...

But business always wants the Ferrari solution at the cost of a Fiat panda.

<comment><USER8> While I don't disagree with your premise, "need to be an expert at both layers" is absolutely still true if you build your app natively for each platform (more so, even). At least with a common platform, if nothing else, you can share quite a bit of code, and that alone might make it worth the extra layers.

<comment><USER9> And "developing" in RN requires you to be an expert in three fields: iOS, Android and the RN layer, which is often buggy. How is that better?

<comment><USER10> If you are already using React for the web (which I would believe is the biggest reason to use React Native), then the RN layer is pretty much already taken care of in term of expertise.

For the iOS and Android side, that's a constant between the two possibilities.

It's better because now your iOS and Android experts can concentrate much more on what they do best and your React experts can keep working on your UI like they always did.

<comment><USER9> React "experts" are not mobile experts, and often lack (and refuse to learn) basic mobile principles such as platform standards and accessibility.

</comment></comment></comment></comment></comment><comment><USER11> Great article. I started iOS programming in late 2009 and had solid experience of native mobile programming (iOS/Android) and web frontend/backend (RoR/Node.js/React/Go) before I started to use React Native in late 2016. I totally agree with the auther on what work well and what don't work well about React Native. Sad to see Airbnb sunsetting React Native.

In my opinion, 2 of the reasons Airbnb had more and more issues with React Native are:

1\. They don't adopt type checking for JavaScript.

"We explored adopting flow but cryptic error messages led to a frustrating developer experience. We also explored TypeScript but integrating it into our existing infrastructure such as babel and metro bundler proved to be problematic."

"A side-effect of JavaScript being untyped is that refactoring was extremely difficult and error-prone."

This is absolutely not just "a side-effect". In a real project, many developers modify the same code base, and the interfaces (Classes, function paramenters, props, etc) are changed frequently. I think type checking system, e.g. Flow, is a must for writing JavaScript code for either backend or frontend. My team is using Flow, and I ask my team members to adopt type checking as much as possible. When I see something like this funcA(a, b), I always ask the developer to change it to funcA(a: TypeA, b: TypeB): TypeC. It is really very helpful, especailly when we need to change code.

2\. They don't ask engineers to keep most code in JavaScript.

"Often times, it is not clear whether code should be written in native or React Native. Naturally, an engineer will often choose the platform that they are more comfortable which can lead to unideal code."

All logic and UI should be written in JavaScript. Native code should only be used when we cannot do in JavaScript or the performance is very bad.

When I am using React Native, I do miss the simplicity of writing and debugging native code. But when you need to support both iOS and Android, it's great to just keep one code base in JavaScript. Again, espeically when you need to change the code frequently, you don't need to do the some thing twice. (One for iOS, the other for Android.)

<comment><USER11> Typo. It should be "you don't need to do the same thing twice"

</comment></comment><comment><USER12> As a user of AirBnb I would be so happy if they just stopped updating the app. They are making it worse and worse. When I travel and I arrive at an airport, I do not need spiffy animations and "fun things to do" in the city I am in, I need a way to quickly find the address of the place or a way to message the host. Stop with all this experience stuff and give me the facts I need right now

<comment><USER13> Hey, they hired so many people. You can't let them just sit there doing nothing.

<comment> forgot-my-pw Soon to be released: Airbnb Lite

</comment></comment></comment><comment><USER14> Tangential to this, he says Airbnb has 100 mobile devs writing about 80k LoC of app code, 40K LoC of infra, and 220 "screens". We've got an app with about the same "dimensions", developed in a similar timeframe, with some very complex financial business logic and 2 developers working on it... what on Earth do their devs spend their time on? Is their engineering organization really _that_ inefficient?

<comment><USER15> "For reference, we have about 10x the amount of code and 4x the number of screens on each native platform". So the amount of code and the complexity is substantially more difficult than you describe. You probably also don't have as rigorous AB testing, logging, internationalization, contributions to open source, etc.

<comment><USER16> I used to be a CKEditor core dev. The codebase was 150k LOC of (mighty complex at times)JS and there were four of us working on the LTS(4.x) - we were _somewhat_ understaffed, but not "we need a hundred devs for this" understaffed.

On the other hand last year I spent two weeks working on a project for which I was borrowed from another one - they had a total of 120k LOC(Java, TypeScript), twenty people and at least the front-end was a dumpster fire.

I guess people don't scale well.

<comment><USER17> I guess quality is a factor, because CKEditor 4.X might have a lot of lines but it is one of the worst library I had the displeasure to use.

<comment><USER18> I use it extensively in my current project and it is a joy. Different strokes for different folks.

</comment></comment></comment></comment></comment><comment><USER19> Others have been coming out and talking about similar experiences with React Native. This thread made the rounds on Twitter and Medium fairly recently:

[https://twitter.com/sandofsky/status/1002634185566236679](https://twitter.com/sandofsky/status/1002634185566236679)

[https://twitter.com/VivekxK/status/1002694526467653632](https://twitter.com/VivekxK/status/1002694526467653632)

<comment><USER20> The common thread I see is that mixing native and react-native is hard. Doing so while working across organizations that may or may not use react-native is doubly so. Sometimes this boils down to the technology, knowledge, and the engineering systems needed to support both but I've also found native developers tend to strongly dislike react-native and lobby against whenever they can.

For me, I'm using it to successfully build mobile apps for a large tech company with very limited mobile developer resources. We've been able to ship Android and iOS apps in a couple months using 100% react-native. I attribute a lot of this to knowing the limitations of the platform and designing a cross- platform experience from the start rather than trying to get the "best of native" out of abstracted JavaScript.

I'll always argue that native is the way to go for the best user experience but react-native is a great tool to have in the mobile space.

<comment><USER21> _> The common thread I see is that mixing native and react-native is hard._

We've experienced some of the difficulties in this area at Facebook as well. If you're curious, making native <-> JS integration more seamless is a big motivation for the ongoing architectural revamp that we've recently posted about: [http://facebook.github.io/react- native/blog/2018/06/14/state...](http://facebook.github.io/react- native/blog/2018/06/14/state-of-react-native-2018.html)

It's a shame we weren't fast enough to help Airbnb in these areas, but the native interop will get better when the revamp is finished.

<comment><USER20> I'm excited about the proposed changes and think they are a step in the right direction, but I also worry that they will add more fuel to the fire that react-native as a platform is a constant moving target.

You obviously have much more insight into what the re-architecture will entail than I do but I've heard a lot of worry around that post with regards to backwards compatibility of third party libraries and in-house native components.

<comment><USER21> To provide some extra context on this: at FB, we can't ship any RN update (or really, any RN _commit_ ) without updating our own apps for it. No product teams at FB are going to agree to rewrite their code just because an infrastructure team came up with a new way to do something.

The reason updates are easier at FB mostly has to do with atomicity of commits. Because FB uses RN from master (and in practice all code lives in the same monorepo), codemods can be applied to products together with the corresponding infrastructure changes. Since the upgrades have a commit granularity instead of the monthly stable releases we cut in open source, there are no big delays between a regression being introduced and fixed for FB products. This discrepancy is unfortunate, but I don't really see a way around it for an actively developed library--which might be your point.

Undoubtedly RN is in active development, and being a moving target, it's easier for FB teams to "follow" it. Still, large backwards-incompatible changes are just as infeasible for us as for everybody else without either an automated codemod or an opt-in strategy.

<comment><USER22> Wow thanks, that explains a lot. So Facebook basically treats RN as an internal library, a single commit can change the framework API and the implementation at the same time so the constant API churn is not a problem.

<comment><USER21> I'm talking about mostly mechanical changes (think find-and-replace or slightly more involved). Those are easier to do because they can be done on both RN _and_ products at once.

This doesn't work for any larger changes because nobody is able to rewrite a ton of files by hand just to change some API. So this is why we can't make big changes to the API without a gradual adoption strategy, even internally.

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> "Redux is notorious for its boilerplate and has a relatively difficult learning curve. We provided generators for some common templates but it was still one of the most challenging pieces and source of confusion while working with React Native."

Interesting to see even Airbnb struggles with Redux

<comment><USER24> As a Redux maintainer, I'd be really interested to know what approaches they used, and what sorts of difficulties they had.

(I'll throw out my obligatory comment that you are always welcome to use as much or as little abstraction as you want on top of Redux, and there's plenty of options available to trim down "boilerplate" depending on your situation.)

<comment><USER25> "Requires boilerplate" will forever be a criticism of Redux unless redux itself takes the (radical) decision to get rid of the boilerplate.

Just saying "well you don't need to use it" means that Redux maintains all that crust and cruft of boilerplate which remains a huge cognitive impact not only on beginners but also possibly experienced Redux users.

Redux is magnificent, but it should take a lesson from create-react-app which did the job of getting rid of all the crap that webpack and babel disastrously imposed on all JavaScript developers with their "maximum config" approach as opposed to zero config.

The message to JavaScript library and tools developers is "get rid of your config or some other tool will come along and do it for you". Redux's boilerplate is just config. If you apply every brain cell you have to the task of getting rid of boilerplate, what would Redux be left with? That's what it should be.

I think the success of VueJS can be laid squarely at the feet of the complexity of the ReactJS ecosystem - not even necessarily React itself. Every part of the larger React ecosystem needs to reduce the cognitive load it imposes and the primary task there is getting rid of configuration/boilerplate.

My theory is that "all software that CAN BE more simple is replaced by some other good enough solution that IS more simple". Thus VueJS, which whilst I wouldn't use it, is certainly simpler for beginners to grasp.

<comment><USER24> Part of the issue is that _everyone_ has a different definition of what "boilerplate" means.

So, legit question: what do _you_ mean by that term? Use of actions? Action creators? `connect()`? Immutable update logic in a reducer? Store setup?

I honestly get frustrated that people keep throwing around that term, but few people seem to point to a specific _thing_ that can be improved. (People also don't seem to understand the context that Redux came from and the intent behind its original design, something that I tried to capture in an extended blog post a while back [0]).

Early last year, I filed an issue asking for discussion of ways we can improve the learning / getting started experience, and resolve some of these "boilerplate" complaints [1]. There were a bunch of comments and some decent ideas, but I already have a lot on my plate, and no one from the community really stepped up to help push any of the ideas forward.

I do have a small "redux-starter-kit" lib [2] prototype that I've put together as a tool that can help simplify the store setup process and reducer logic. Again, though, I haven't had time to do much more with it myself since I first threw it together.

I am _always_ open to legit suggestions on ways we can improve the docs or find ways to make using Redux easier. Unfortunately, it seems like very few people are interested in actually getting in touch with us and offering assistance in doing so.

[0] [https://blog.isquaredsoftware.com/2017/05/idiomatic-redux- ta...](https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux- part-1/)

[1] [https://github.com/reactjs/redux/issues/2295](https://github.com/reactjs/redux/issues/2295)

[2] [https://github.com/markerikson/redux-starter- kit](https://github.com/markerikson/redux-starter-kit)

<comment><USER25> For me it is specifically this.

Here is a class:

      import React from 'react'

      export default class class ChooseFontLevel1 extends React.Component {

        constructor(props) {
          super(props)
        }

        render = () => foo
      }

And here is the (almost) same class, with the boilerplate required to use Redux:

      import React from 'react'
      import {connect} from 'react-redux'

      class ChooseFontLevel1 extends React.Component {

        constructor(props) {
          super(props)
        }

        render = () => foo
      }

      function mapStateToProps(store, ownProps) {

        return {
          fontPreviewsCache: get(store, `fontPreviewsCache`),
        }
      }

      function mapDispatchToProps(dispatch) {
        return {
          onTodoClick: id => {
            dispatch(toggleTodo(id))
          }
        }
      }

      export default connect(mapStateToProps, mapDispatchToProps)(ChooseFontLevel1)

To use Redux I need to entirely restructure my code.

And if the comment is "You don't need all that stuff", then why is it an option at all?

Also mapStateToProps is poorly named and confusing because it isn't talking about anything to do with ReactJS component state, although it's a reasonable assumption, it's talking about the Redux state... there's a bag of confusion for you and enough to make a beginners head spin because their head was already spinning about what ReactJS state is.

I'd also suggest that Redux has made a rod for its own back by calling "the thing that gets data out" as "reducers", instead of something like "getters". "Reducers".... argh we're now in computer science land and not the land of the practical programmer. A reducer, what is that? Beginners certainly don't know and you have to learn and become experienced with Redux to come to understand that in fact a Reducer is

Equally, cognitive load would have been reduced if actions were named "setters" or something familiar and similar to the actual functionality.

Redux itself isn't that hard once you understand it, but it's put up big cognitive barriers around itself so that you need to be an expert to eventually discover that you don;t need to be an expert.

<comment><USER24> Well, the `mapDispatch` example can certainly be simplified. `connect` supports an "object shorthand" \- just pass an object full of action creators as the second argument, and they'll all be bound up and passed in as props. So, your `mapDispatch` example can just be:

        const actions = {onTodoClick : toggleTodo};

        export default connect(mapState, actions)(ChooseFontLevel1);

Other than that... there's 1 import line for `connect`, 1 function call to `connect`, and the `mapState` function.

Is that truly too much to write? Also, how does that qualify as "entirely restructuring your code"? Your component is still the same - it's getting data as props. It's just now getting them from a component that was generated by `connect`.

The alternative is to write the store subscription code yourself, by hand, in every component that needs to access the store. I've got some slides at [https://blog.isquaredsoftware.com/presentations/workshops/re...](https://blog.isquaredsoftware.com/presentations/workshops/redux- fundamentals/ui-layer.html#/) that show what that would look like, and THAT would truly become tedious and painful.

The point of `connect` is to abstract out the process of subscribing to the store, extracting the data your component needs, and only re-rendering your real component when that data changes.

As for the naming of `mapState`: the word "state", in general, means "data that represents what's going on in my application". So, there's the generic aspect of "state", there's "state that is being stored in my React component", and there's "state that is being kept inside my Redux store". Those are all valid uses of the word "state" (and especially given that the Redux core is entirely independent of React).

The term "action" comes from its original design as an implementation of the Flux architecture (which is part of my point of people not being familiar with where it came from). "Reducers" comes from the `someArray.reduce()` method.

(Also, note that in both of your examples, the constructor isn't actually needed because you're not doing anything meaningful in there, and your `mapState` example isn't making use of the `ownProps` argument and therefore shouldn't declare it for performance reasons.)

<comment><USER25> Easy for you (and me to some extent) to read what you say and see hey yes it could be more simple....

What is simple for any Redux-experienced person is a gigantic cognitive cliff for people who are not experts. I can still remember trying to learn ReactJS and Redux and bailing out on Redux while I tried to make sense of mapping dispatch to props. Redux should not be losing users at that point.

Your earlier post expressed frustration at not being able to get people to be specific about what boilerplate is.... well this is it (or my definition anyway).

IMO, ideally Redux would be nothing more than an object that I instantiate and then call methods and properties on - including defining my reducers and actions. A single object for Redux leaves the question of how to ensure that changes to the Redux store result in a props refresh being pushed down through the component hierarchy, but surely the big brains on the ReactJS project can come up with some other way to handle that behind the scenes rather than me needing to change my code structure.

And may I say I love your work and I'm a big fan of Redux!

Although if I found something that operated like I say - a single object to be instantiated and driven via methods and properties with total immutability, with changes resulting in a props refresh on update, then I'd switch.

<comment><USER24> Unfortunately, the library you describe wouldn't be Redux at all. Part of the core point of Redux is to separate out the act of describing some event or update that needs to occur, from the process of applying that update. That's what makes time-travel debugging possible, and it allows middleware to modify the actions that are passing through the store. In all honesty, if you want objects with methods, MobX is what you're looking for.

Not quite sure what that "single object" sentence is trying to say, but that also sorta sounds like MobX's wrapping up of components with `observe()` (which ultimately does the same kind of thing `connect` is doing, just in a rather different way).

(Also, fwiw, Redux is completely separate from the React team. Dan Abramov and Andrew Clark, the creators of Redux, _do_ work on React at Facebook now, but Redux is not a Facebook project, and Dan and Andrew are no longer active maintainers. We talk with them a lot, and they obviously have a vested interest in Redux, but it's separate.)

And thanks, appreciate the compliment.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> >Due to a variety of technical and organizational issues, we will be sunsetting React Native and putting all of our efforts into making native amazing.

Buried lede. Why not just say it outright?

<comment><USER27> Airbnb has managed to over-engineer a Medium blog post.

</comment></comment><comment><USER28> Very good write-up, thanks for posting.

Some of the frustrations definitely hit home. I think for small teams and indies React Native is an awesome piece of technology that can enable them to target both platforms where it would be nearly impossible otherwise. I can understand how orchestrating the work of a huge team could introduce new issues though.

It would be interesting to know why some of the infra layers that the article mentions (i18n, networking) were behind bridge when they seem like prime candidates for js implementation.

What I'd really like to know though is how other teams are managing the design pipeline (getting from psd/sketchapp to code without hand coding flexbox styles). We've looked at some tools like supernova.studio and BuilderX, and while showing promise these seem like they have a long road ahead.

<comment><USER29> we have a new tool that we're trying internally to design cross-platform components - [https://github.com/airbnb/Lona](https://github.com/airbnb/Lona)

pretty early still, but the idea is that short-term it generates assets that fit into our existing Figma / Sketch product design workflows for consumption. having a cross-platform source of truth for _components_ is higher impact than outputting their _consumption_. this was mostly the reason we first did the things we wrote about here - they laid the groundwork for Lona and a more component-centric design process. [https://airbnb.design/painting-with- code/](https://airbnb.design/painting-with-code/) [https://airbnb.design/sketching-interfaces/](https://airbnb.design/sketching- interfaces/) [https://airbnb.design/the-evolution-of- tools/](https://airbnb.design/the-evolution-of-tools/)

<comment><USER28> Thanks very much. I'll take a look at Lona.

A couple of days after I posted that I started thinking about whether it would be possible to develop a sketch plugin to render react components onto artboards, then I googled my way into your react-sketchapp and a talk you delivered at ZEIT. You guys are doing some really cool and useful work. Thanks!

</comment></comment></comment><comment><USER30> I've never seen anyone do a battery impact analysis of React Native. I wonder why?

Person sally, I don't want to use products where the developer prioritizes their problems over my experiencs but YMMV. Some will argue that an Electron dumpster fire is superior to nothing. I consider that debatable.

<comment><USER31> Eh, I can almost guarantee it has almost no battery impact. JavaScriptCore is fairly fast, business logic doesn't take that long to run (100ms vs 200ms, whatever.), and it all pales in comparison to running GPS or the display for a few seconds. Unless you're playing a game or running some complex algorithm, most of your phone's battery goes to the wifi / cell radio and the display.

<comment><USER32> I agree with you, that for the same 'business logic', having it JavaScript vs native, unless you do lots of sorting/copying of data -- will not have battery impact difference.

However, React itself (not the javascript engine) brings in additional dimensions, that are somewhat unique to react.

For example, React's (and therefore ReactNative) TextInput control, essentially (in my understanding) encourages you to update a state variable, _every single time_ type a letter into that control

(because the values displayed in the control are coming from the state, so the only way to display the character you typed, is via updating the state).

So that round trip of the character update, to updating the object with state variable, calling .setState, forcing the re-rendering, will consume more battery power. In my view

(I know textinput in particular has the 'uncontrolled model').

My point, that the constant 'create new object', update the state with it, and Re-render -- could be slower (and less battery efficient), than doing may be something similar (or more efficient) in Native Code.

</comment></comment></comment><comment><USER33> What is wrong with TurboLink 5? Not Turbolink 3 or previous version, v5 is very much a total rewrite. Turbolinks 5 allows hybrid Apps that offers most of the benefits without many of the complexity, it is HTML after all.

It seems there are sites that uses Rails, including AirBnB. But I have yet to seen a site that uses Turbolink apart from Bassecamp, even Github uses its own version of pjax rather then Turbolink.

<comment><USER34> I use the turbolinks libraries for iOS and android and the experience has been great.

<comment><USER33> I am just wondering if there are any pitfalls. While not many are writing about their technical failure of React Native or whatever tech it is. You will at least know they have changed the stack, or words on the street / twitter they are retrying new things because old things didn't work etc.

But TurboLinks 5? None, not even a mention or beep. As if no one is using it. While we are happily using it someone else may be running into issues we haven't yet doubt with.

It is pretty much like Startup news, I don't want to read about how you succeed this just once. I want to read about your thousands other failure, what works, what not, and what you ( Or I could ) learned from it. By stating your problem, your intended solution, and the results I could make a better informed decision somewhere down the line. And all the time we got on the internet is everyone cheer leading mindlessly.

</comment></comment></comment><comment><AUTHOR> This is a really good write up and I love how they were cautious not to feed the ongoing fanboyism in for and against React Native folks.

Say what you like but this is a very mature move from a young engineering organization.

<comment><USER35> I have to agree. It was really interesting that they highlighted that nearly 2/3rds of their engineers would use React Native again. I also assumed that the last part of the blog series was going to be mostly fluff / product announcements, but their efforts in server side rendered native screens and drastic reductions in build time are legitimate takeaways from devs who are used to development cycles at React-Native speeds.

<comment><USER36> You have to wonder how many of their 100 engineers are going to dislike having to become iOS/Android devs.

<comment><USER37> The vast majority of the 100 always have been and are still Android and iOS devs. React Native never made up more than 10-20% of our mobile engineers and many of them came from Android or iOS backgrounds.

<comment><USER38> How's FB's RN team reacted to Airbnb's decision to move away from RN?

</comment></comment></comment></comment></comment><comment><USER39> Really curious as to how Flutter (and Xamarin, NativeScript, Ionic, Vue-based write-once frameworks, etc.) can overcome the difficulties expressed in this piece.

<comment><USER40> I've tried pretty hard to get into RN with a few hobby projects and I've given up. I'm wondering if PWAs are the way forward for the average data driven mobile app.

<comment><USER7> I would say they can be, depends on how they evolve.

On Windows they have access to the native APIs if signed and delivered via the store, as Microsoft is building on JavaScript development story they introduced with WinRT.

[https://docs.microsoft.com/en-us/microsoft- edge/progressive-...](https://docs.microsoft.com/en-us/microsoft- edge/progressive-web-apps/windows-features?branch=pwa)

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

> Due to a variety of technical and organizational issues, we will be > sunsetting React Native and putting all of our efforts into making native > amazing.

</comment><comment><USER42> While i don't have much experience in RN, but have a decade of mobile native development (android + iOS) and two years of React.

The whole 10 years there were people that think that they can just get "web" technology and speedup mobile development.

Almost always this companies had no mobile engineers that know how this stuff works. Developers that know that you just can't listen to scroll and update animations by sending messages to background js thread. This just completely wrong on mobile. Most mobile devs spend months to make it fast and easy to use. There are no way to do this in most cases on RN. AirBNB's app is a perfect example of this. Trying to deliver "better" experience they completely kill scrolling performance. Even top level iPhones feels laggy. But yay! We have animations! AirBNB's app is barely usable on two-year-old androids. This is just simply wrong, this is not how you can achieve good performance and nice animations on such small devices. In most cases this is a kind of art and a lot of testing and tweaking for every device. This can be done by only ONE talented developer per platform per year. Surely AirBNB has resources. Just take specific screen and tweak it to hell. On the other side, react and declarative kind of state is really doesn't work well for non-page oriented apps. Mapping history of navigation via redux store is just an awful and useless idea that helps with nothing. Right now there are still no navigation library.

Every time i tried to start something in React Native i failed since i wasn't able to apply my skills to make it behave fast there are just no easy way to do this.

React Native for sure is a good thing, but it's evolution shaped by web devs that try to reflect their experience from web development, but building a good mobile app is completely different from web one. For example, there are no dom, UI manipulation is not slow, navigation between pages and keeping it's state is not a problem most of the time (there are no real "back" button that you have to handle somehow). UI frameworks are more mature (while have less API than HTML).

<comment><USER43> > Right now there are still no navigation library.

React Navigation and React Native Navigation are both viable options with their own pros and cons. Been using them successfully in different projects.

[https://reactnavigation.org](https://reactnavigation.org)

[https://wix.github.io/react-native-navigation](https://wix.github.io/react- native-navigation)

<comment><USER44> I think what they meant is that there is no built-in production-ready navigation library, which is honestly atrocious.

<comment><USER45> I never understood the obsession with native navigation libaries.

I built a bunch of apps with JS navs and nobody ever complained...

<comment><USER46> Did you test your app with VoiceOver, the iOS screen reader for blind people? The difference between non-native and native navigation is particularly noticeable in that case, unless perhaps you fire a UIAccessibilityScreenChangedNotification after navigating to a new screen.

That's just the scenario I'm aware of. I haven't done any real projects with React Native, so there may be other pitfalls.

<comment><USER9> Of course not. They are a lazy developer that care little about the user experience.

<comment><USER46> As passionate as I am about accessibility, I try not to use an accusing tone. There's no way we can know the state of mind, priorities, and constraints of the developer in question. Even large companies don't have unlimited resources. So we can't fault developers for looking for ways to do more with less. We just need to do what we can to make sure developers are informed about the pitfalls, and plead with them to consider important user experience factors like accessibility.

</comment></comment></comment></comment></comment></comment></comment><comment><USER47> I haven't used React Native, but I've ready a few posts from people adopting it. They typically test the waters by writing new app views in React Native instead of rewriting everything. But how much cognitive overhead is there in maintaining multiple toolchains (React Native and native and/or web views) and debugging views in different languages in one app?

<comment><USER48> I work on an app that is written with a combination of iOS native code, JS, and server side code.

It's not easy to debug at all. The problem they mentioned where your stack traces just end at layer transitions is a real problem. Even if the server side isn't involved in the bit you're working on.

</comment></comment><comment><USER49> The article doesn't seem to explain specifically why RN didn't work for them but I believe that the real pain for them is to organize 100 engineers to work on the same project.

Often they were confused about native vs RN approach and had to write native libraries and integrated them with RN which requires 3 different teams to write & test and integrate their code. I can see that if one of the teams is either slow or run into strange bugs, they will be the bottleneck and slow down all of them.

From this perspective, similar to why Netflix or other large organization choose micro-services rather than monoliths, it would be better for Airbnb to develop 2 different native apps separately rather than having 3 different teams depending on each other.

</comment><comment><USER50> I remember mid 2017 react native and the upgrade pain distinctly. It took a full week to set exact versions and run yarn outdated over and over, pull up the release notes one package at a time, try bumping the version, see if it breaks, try the next version, no that's broken, try bumping react, no that breaks the other one, etc. It was hell.

</comment><comment><USER51> I have come to same conclusion. Have few production apps and an ongoing one in react native. Dealing with native code has been frustrating, additionally plugins would not be up to date as well. Going native would be a better choice.

I would though love react jsx syntax for building native views in swift/Kotilin.

<comment><USER52> Kotlin doesn't need JSX, as it already has features for building DSLs for such things[1], allowing you to easily express hierarchical structures as perfectly normal Kotlin code.

[1] [http://kotlinlang.org/docs/reference/type-safe- builders.html](http://kotlinlang.org/docs/reference/type-safe-builders.html)

</comment></comment><comment><USER53> None of the recent articles or HN comment threads about React Native spend much time evaluating Haxe. I guess it's not that widely used for CRUD apps and is more popular for games?

Anyway, I'd love to know how it would work for an Airbnb-like org.

<comment><USER54> It is same with Xamarin. They don't have people that would know these languages, and they would be passionate about them.

<comment><USER55> Xamarin and co suffer from the same dual layer issues that react native has when I last looked into it.

C# isn't that popular from a silicon valley engineering perspective, since the first class C# implementation wasn't open source until very recently. Yes mono has always be OSS, but it has also been a second class citizen too.

<comment><USER54> Only Xamarin.Forms introduces another layer for you (it is the same concept as React Native). If you use Xamarin.iOS and Xamarin.Android you call underlying APIs directly. Although there can be issues with bindings, nothing like you will face with React Native.

I am aware of why C# isn't popular among startups. It is sad because C# is a great language that has amazing tooling support. It runs everywhere - <USER2> for apps, ASP.NET for servers, Blazor for browsers, and it is getting only better, and I cannot imagine how awesome it would be if other companies helped Microsoft. But I can only dream.

<comment><USER55> Even with Xamarin.Android/iOS I read about unique bugs that resulted in you needing to be an expert in both layers to understand. And bugs in the wrapper themselves.

It's a problem with the entire design type, which has been shown throughout computing history to not work that well.

And why use C# when the Java ecosystem is pretty much the same tooling wise? C# feels like a 1.2x better Java, which isn't enough.

<comment><USER7> As someone that works daily with Java and .NET platforms, C# still has a better stories around AOT and value types.

Also Sun really bombed their Java Gaming initiative (who remembers that JavaONE?) with C# becoming the C++'s complement in most studios.

</comment></comment></comment></comment></comment></comment><comment><USER56> I wrote a few weeks ago about how ridiculous it was for AirBnB to spend 18 months testing a new font. A _5_ part series on React Native is again next- level indulgent.

Why am I not surprised engineers at Airbnb have so little to do than to write a novel about a framework?

<comment><USER57> Yeah nothing weirder than engineers writing about their experiences with different technologies.

<comment><USER56> A 5 part series. 5!!

</comment></comment></comment><comment><USER58> I was looking forward to using RN but I guess I fell victim (again!) to whishful thinking and the "No silver bullett" fallacy. Come to think of it, why have we accepted React as the go-to approach to this degree? React doesn't even make an effort to isolate from HTML and DOM at the conceptual level, and I'd wager an opinionated framework about "panels", "fields", "field groups" and events is more representative of what folks typically want to do with React, rather than manipulating pseudo-markup using JSX however elegant and neutral.

</comment><comment><USER59> I feel like we're missing a lot of the story. Many of the React Native issues sound painful, but they handwave away a lot of the complexities and drawbacks of their new architecture.

For example their answer to RN's one second rebuilds is a custom Android build configuration that eliminates most of their _5 minute_ builds. They are proposing a custom server rendering setup and don't know how to solve the hardest problems like wiring up events (HTML anyone?).

</comment><comment><USER60> It looks like if you have small team and you want to develop iOS / Android prototype fast RN is good choice. This case you're looking not for "best user- experience" but "okay user experience fast".

But for big companies java/kotlin or/and Objective-C/swift native apps will be more efficient.

</comment><comment><USER61> well, its unfortunate that React Native didn't work for them. i think RN is great solution and direction for mobile in general. sure it can be improved but at the moment, it is the best we have for cross-platform mobile development.

<comment><USER62> Have you tried Flutter? That's looking promising.

<comment><USER63> Yeah... but... dart.

<comment><USER39> Is there actually something wrong with the language? If it's a matter of the issue of having to learn a new language, it's not as if there were many Objective-C, Swift, or Kotlin developers before mobile.

</comment></comment></comment></comment><comment><USER64> If you are a small startup using react native makes sense. If you are a billion dollar company why not just have a team for each platform. Or better yet have have 2 teams for each and let them compete for whose product gets shipped.

<comment><USER65> Resources, even at a semi-large company, are finite. Teams have limited head counts and usually an ever increasing list of asks from Product team. Being efficient is not optional.

<comment><USER64> Lets do a little math. FB has 25k employees. Lets suppose they pay everyone a million buck. That is 25billion. Their gross profits were 35 billion. They can afford to have two teams or 3 teams or 4 teams working on the app. I don't know what Airbnb's numbers are, but I am sure they can afford to have multiple teams.

<comment><USER15> I can't tell if you are trolling or not.

</comment></comment></comment></comment><comment><USER66> tldr; [https://medium.com/airbnb-engineering/sunsetting-react- nativ...](https://medium.com/airbnb-engineering/sunsetting-react- native-1868ba28e30a)

</comment><comment><USER67> Reading a bit between the lines and keeping in mind that rumour that Facebook was removing RN from some of their projects…

Could it be true? Does AirBNB see the writing on the wall somehow?

I know that RN is open source and people will continue to support it and everything will be great, but without Facebook behind it, I wonder how much traction it'll have.

<comment><USER68> That rumor was thoroughly debunked (see the discussion in the original HN thread: [https://news.ycombinator.com/item?id=17216628](https://news.ycombinator.com/item?id=17216628)).

Please don't repeat and spread false rumors. It cheapens discussion about legitimate technical choices that organizations make.

</comment></comment><comment><USER69> Isn't React Native end of lifed at Facebook? The effort is taking the best principles of React Native and focusing on Litho [https://fblitho.com](https://fblitho.com) or ComponentKit - the effort to have a unified framework for both iOS and Android is pretty much abandoned.

I think React Native is in legacy support mode rather than active innovation.

<comment><USER70> I can't find any reference to that with Google. Mind sharing a link?

<comment><USER71> This was recently making the rounds, I suspect this is what OP was referring to:

\- [https://twitter.com/sandofsky/status/1002637340291018754](https://twitter.com/sandofsky/status/1002637340291018754)

Responses from someone at FB:

\- [https://twitter.com/sophiebits/status/1003101478427357184](https://twitter.com/sophiebits/status/1003101478427357184) \- [https://twitter.com/sandofsky/status/1003104331833532416](https://twitter.com/sandofsky/status/1003104331833532416)</comment></comment></comment>


Show HN: PyFilesystem 2.0 – A Python interface to filesystems of all kinds - <AUTHOR> https://www.willmcgugan.com/blog/tech/post/announcing-pyfilesystem-2/ <comment><USER2> Oh, this looks really nice. Thank you for posting it!

A while back, I had an idea for modelling a filesystem as a dict, so maybe this will inspire me to get off my ass and actually write it.

Basically, the idea is that this:

        foo = rootfs['home']['amyjess']['stuff']['foo.txt']
        rootfs['home']['amyjess']['stuff']['bar.txt'] = bar

would be equivalent to this:

        with open('/home/amyjess/stuff/foo.txt', 'r') as foo_file:
            foo = foo_file.read()
        with open('/home/amyjess/stuff/bar.txt', 'w') as bar_file:
            bar_file.write(bar)

I really want to implement that now.

<comment><USER3> I once made something like this to mount json files as a fuse filesystem. It's not maintained and one of my first projects, so the code is somewhat questionable, but it does work.

It basically mounts a dict on a filesystem, the exact opposite of what you want :)

[https://github.com/yhekma/datamounter](https://github.com/yhekma/datamounter)

<comment><USER4> My big question is why? you wanted to navigate or display a JSON dataset using filesystem-viewer tools? i.e. "Explore" the JSON dataset?

<comment><USER3> Well, mostly because I wanted to play with fuse, but it started out as an ansible thing (doesn't work with >2 though).

The ansible setup module returns the system information in json, and if you mount it with the --realtime flag, when you open a "file" like ram for instance, ansible fetches the current value for you. That way you have your infrastructure mounted so to speak. Sort of a /proc filesystem for your linux infrastructure.

I never got further than a working poc though. It works, but there are some bugs and there is no regard for security.

</comment></comment></comment></comment><comment><USER5> pyfilesystem is great!

My only suggestion would be to improve the search optimization for pypi.

It's the ~10th result for [https://pypi.python.org/pypi?%3Aaction=search&term=pyfilesys...](https://pypi.python.org/pypi?%3Aaction=search&term=pyfilesystem&submit=search) and a page down on [https://pypi.python.org/pypi?%3Aaction=search&term=fs&submit...](https://pypi.python.org/pypi?%3Aaction=search&term=fs&submit=search)

It's really not clear what it's called since the package name is 'fs' but the project is 'pyfilesystem'.

<comment><AUTHOR> > pyfilesystem is great!

Cheers.

> My only suggestion would be to improve the search optimization for pypi.

Fair point. Not entirely sure how to fix that. I'll look in to it...

<comment><USER6> PKG-INFO, line 2:

Name: fs

Looks like it's also registered in PyPI as "fs", from the URL: [https://pypi.python.org/pypi/fs/](https://pypi.python.org/pypi/fs/)

<comment><USER7> Maybe have a proxy [https://pypi.python.org/pypi/pyfilesystem](https://pypi.python.org/pypi/pyfilesystem) that has `fs` as a requirement? That way even if people install with `pip install pyfilesystem`, you're good.

<comment><AUTHOR> Hmm. That's an idea. Feels like a hack though. Do you know if there is a precedence for that?

<comment><USER7> We're planning on something similar to move a big open source library somewhere else (so that dependencies don't break).

</comment></comment></comment></comment></comment></comment><comment><USER8> As long as you can recursively process folders and files without stopping early due to an UnauthorizedAccessException-equivalent (which .NET didn't straighten out 'til v4).

[http://stackoverflow.com/a/2663779](http://stackoverflow.com/a/2663779)

</comment><comment><USER9> Would this work with any object implementing the PathLike interface introduced in Python 3.6 ?

<comment><AUTHOR> You generally won't need to. PyFilesystem hides the differences between paths from you ([https://pyfilesystem2.readthedocs.io/en/latest/concepts.html...](https://pyfilesystem2.readthedocs.io/en/latest/concepts.html#paths)).

An exception would be in the constructor for OSFS Objects, which take a system path. I'll look in to adding support there...</comment></comment>