I used to work at Airbnb.

Airbnb does not, in fact, have a CTO who dictates the company tech governance and/or stack. They prefer to run things in a federated manner, with individual teams making the decisions that they feel are best for them. While they're encouraged/required to draw up design docs and have them reviewed by an architecture review group, the group's recommendations are non-binding.

This model has advantages and disadvantages. On the upside, it creates an environment where people can take risks and do things that haven't been done inside of the company before. On the other hand, it means people sometimes go out on a limb and push the company into supporting something that turns out not to be sustainable in the long term.

As a matter of personal preference, I like to have a set toolchain that a company is built around. But it would be unwise to suggest that Airbnb's strategy hasn't worked out pretty well for them overall.

FWIW, I regularly use Airbnb for my travelling lodging needs. I usually find what I'm looking for (an apartment with washer, WiFi and many good reviews in the lower price-bracket).

But I always open the site with some apprehension, since I know I'm in for a bad user experience. It's sluggish, and I can't bring myself to appreciate how the layout and even menus differ (or even disappear) depending on which area on the site I visit. It makes navigation cumbersome, and hard to remember how to navigate between visits.

I would switch to a similar service in a jiffy if it had solved these problems.

I always suspected a lack of a top-down coordination to be the reason for these issues, thanks for confirming. I've come to believe that this kind of loose federation strategy mostly suits junior devs (on which a startup might be deeply dependent by all means), hardly a serious long haul business. I expect they will change policy in due course, or perish.

I've had the exact same problems using AirBnb. I can never rely on things to be in the same place one visit to the next, if they continue to exist at all.

I don't think AirBnb is alone in this. There are many sites and apps that change UI's radically with disturbing regularity. I've begun to wonder if there is a glut of UX/UI people in tech right now, and that this endless cycle of zero-value-added change is just an attempt to justify their continued employment.

I actually think the problem isn't a glut of designers or UXers, it's an obsession with A/B testing and multi-armed bandit scenarios. I'm sure that at any one time there are dozens of A/B tests running on the site, and the inconsistency we all see is a direct result. Netflix is a similar offender in this area, I never have any idea where "continue watching" is going to be when I open up the app.

I think AirBnb's strategy has worked out well for them for reasons completely unrelated to any of their technology choices. We're living in a time of cheap airfare, insanely inflated real estate in popular markets, and overburdened local governments unable to enforce regulations. That adds up to great success for Airbnb, regardless of what software runs their website.

I think this is an underappreciated point. It's tempting to believe that every tech company succeeded because of the tech, but what if Airbnb succeeded because of aggressive advertising and incentives, financed by hundreds of millions of dollars in VC funding?

I don't even think most of these supposed "tech" companies are actually tech companies: Uber is a cab company, Airbnb is a holiday lettings company, WeWork is a commercial real estate company. None of them makes their money by building and/or selling software.

They're serving inventory that can almost entirely be described in static content caching layers with a booking system layer.

How many risks and how much necessity to do things no one has done before can there really be?

I disagree. I think you're thinking primarily of AirBnB's main listing pages.

What about recommendations? What about map or multi-constraint search? What about fraud detection/prevention, activation/reactivation email triggers, an analysis system to help hosts be more financially successful on the platform, building an ecosystem of services where people can make money while helping hosts make money, SEM optimization, the ratings/reviews system, the communications between guests and hosts or guests and support, or 20 other things that are likely going on under the covers? Their mostly static content is likely just the visible tip of the iceberg.

I saw a javascript course the other day that claimed it would teach how to "build a full AirBnB clone in this course". I chuckled.

This is the correct answer. When you search for listings in Airbnb what comes back is heavily personalized.

Of course, that only accounts for one of the various pages you'll see in the checkout flow, and I agree that not everything is as snappy as it could be. But keeping things snappy turns out to be a very hard problem when you're growing as quickly as Airbnb has.

I have the same feeling, it seems overly complicated and I pity the developers that join the project at a later stage.

I don't understand the run for GraphQL everywhere, does everybody query sparse and deep nested data on their website? From my experience, Apollo works well except when it doesn't and then you have a lot of magic going on.

Zeplin works quite well for our team and creates a nice connection to our designers. Storybook on the other hand not so much. At first we developers used it, then we had to update some things for Apollo but Storybook was not ready for that. Now everything runs again but nobody uses Storybook actively anymore...

I have the feeling that the software industry is often driven by personal preference instead of sane decisions. I see projects that use micro services without any reason, using React for static content, dockerizing everything to a ridiculous amount, K8s because why not. All of that because it's interesting for the developer not because it's good for the user.

> I don't understand the run for GraphQL everywhere, does everybody query sparse and deep nested data on their website?

Exactly. Forced to use GraphQL at work for an internal-only API and what a nightmare - what would be a nice, one-line REST API query can take hundreds of lines (not exaggerating).

If you're serving a public-facing API at massive scale, yes, GraphQL will save you bandwidth. If not, what a pain in the *. For most engineers it's a solution in search of a problem.

> I don't understand the run for GraphQL everywhere, does everybody query sparse and deep nested data on their website? From my experience, Apollo works well except when it doesn't and then you have a lot of magic going on.

I work primarily as a FE software engineer who spends a lot of time researching, using the JS ecosystem. I have gone through graphQL/apollo docs multiple times in order to really understand the value add. Fetching/bandwidth/caching/persistence appear to be the biggest value adds for the tech. To me, these are the easiest things to do in a react/redux SPA. Fetching data isn't difficult, it's all the derived state data that is the hard part. Most of the "business" logic for me is formatting the data in a way that makes sense for whatever UI component I'm building, combining multiple streams of data for the UI, when to refresh data, optimistic UI, and offline support. To me the "declarative fetching" is not really that much a sell to me, because that piece of many projects of even intermediate size is relatively small.

I realize that apollo is trying to solve some of the optimistic UI, offline support, but it does not seem to fit super well atm. The other really big issue I have with apollo is like you stated: it's easy until you want to do something that it can't do. This is the worst position to be in because for 80% of the use-cases it works, but that other 20% where it doesn't fit at all can make a team's life a living hell.

Not to mention most of the time, for any large enough SPA, you will still need redux. If I still need redux then apollo solves nothing for me.

Most of the stuff that you need Redux for you should be able to handle with @client [1], and the local "resolvers" approach isn't too different from Redux reducers, to the point that wrapping Redux-style reducers as Apollo resolvers seems like it should be boring/trivial to implement. It would probably be cool to have something of a "standard library" for that which let you easily convert Redux-style reducers directly (ie, a sort of combineReducers that spits out local resolvers). I don't think it should be hard to do, just doesn't look like anyone has done it yet.

Of course the bigger issue, though, is the Redux Dev Tools/Thunks/Sagas/Observables ecosystem where you want a richer experience and/or already have existing code investments. Apollo has some equivalents to those (Apollo Dev Tools; resolvers can return promises, taking care of a lot of basic thunks/sagas), but it probably needs richer options for others. I know redux-observable is currently a big need for several of my applications and I don't currently know any way to approach that in Apollo other than maybe trying my luck with a custom "Link" and that API looks more intimidating than it probably is, enough so that I haven't had the investment need to approach it. (Then again, most of my applications need to be offline-first so GraphQL in general isn't a great fit for them, though Apollo looks like options might be possible eventually, if someone built a little more infrastructure [Links] for them.)

[1] https://www.apollographql.com/docs/tutorial/local-state.html

I can empathize with an organization interested in motivating its employees over the long term. SPAs, GraphQL, and these other non-essentials are intrinsically rewarding. They give the creators a sense of agency. This motivates people to give their work their best effort. From AirBnB perspective, as long as the value created by these projects doesn't exceed their costs (a quasi-NPV), why not continue them?

The next chapter of intrinsically rewarding work will involve simplifying the complex. Trimming the fat. Reinventing the Zen of Python. Most importantly, it will be glorious.

>Do each Airbnb engineer create their own stack for a tiny part of the website ?

I don't work at Airbnb but I am the CEO of another startup. Our main website (https://rainway.com/) used three different technologies to build it. Why? Because it streamlined development. One team could focus on the code powering the blog, while another could write static pages that query an API. The build process brings it all together.

Tool such as Figma (we moved from Zeplin) do an amazing job for designing entire user interfaces and interactions and providing developers with all the needed materials to implement them. If you're building a homepage for a mom and pop shop, download WordPress. If you need to build something across multiple teams, you need tools to make it easier.

> used three different technologies to build it

Would love to know more about that because looking at your website it's just plain HTML with JQuery.

Which ,in my opinion , is how you should be building landing pages.

I agree with this notion. However, it is concerning that jQuery hasn't had a release in 12 months:

https://github.com/jquery/jquery/releases

You failed to notice that they committed less than a month ago to their master branch and approved several PRs.

Their last dotX release was also 9 months after.

You should also always have a look at roadmap (https://github.com/jquery/jquery/wiki/Roadmap) if you are trying to get a read on any project's longevity.

It is in a way a good thing that a mature library like jQuery isn't released too frequently because all the websites that use it works just a little bit snappier because jQuery is usually already available in cache in the browser from some other source and if not, then the nearest CDN probably has it.

On the jQuery website, the latest download version is 3.3.1.

http://jquery.com/

On GitHub, it says that 3.3.1 was released January 20th, 2018:

https://github.com/jquery/jquery/releases

Releases matter, as that is what gets the changes to end-users, and infrequent releases typically indicate a stagnant project.

I am not trying to disparage jQuery, rather the opposite, since it is mature and reliable software. Open-source projects, like houseplants, need stewardship, and jQuery (along with other JS Foundation projects) may be overshadowed by JavaScript ecosystem hype-cycles that are competing for mind-share.

At this point, jQuery is more or less considered 'conpleted' software. It's very mature, and works well.

Why??? jQuery is so old, I expect it to be “done”

As stated above, open-source projects need stewardship. Otherwise they languish. I genuinely hope for jQuery to continue as a project and community endeavor.

So Conway's Law then?

Exactly my thoughts after the design in Zeplin got presented. If your goal is to create this landing page, do you need much more than HTML & CSS and some sort of static site generator / CMS?

As an Airbnb host, I find managing my property with their website to be a nightmare. It takes three times as long to load as it should and three times as long to do find anything or make changes as it should. The sections are not logically arranged for usability and the whole thing would be vastly improved by consulting with the Nielsen Norman group [whom I have no connection with].

> Creating a stack that complex just to render Static Conten

What exactly is Static Content and are you implying AirBnB has it?

Does its mobile app also have Static Content.