Airbnb’s Server-Driven UI System | Hacker News Reader

Airbnb’s Server-Driven UI System

medium.com

113 pointssrichert75 comments

At what point does it make sense to simply use the web for this? This is what the web was meant for, to enable standardized, dumb clients to consume content from any provider. What we have today is a wonderful architecture and a solid set of standards that is the result of over 20 years of evolution. As a user, there is not much I haven't been able to do on the web, that I do on mobile apps. Why do companies insist on the apps model, even when it causes them so much pain as to reinvent the web? Is the performance or user experience over web really that bad, even in this day and age to warrant shipping a 100MB package to the user? Or are there some nefarious gains or access to privileged information to be had by having your app installed on the user's device that the browser sandbox typically safe guards against?

XKCD has an appropriate comic for this: https://xkcd.com/1367/

I too am a big promoter of that a lot of "apps" can be done with web technologies.

Early on I was interested in PhoneGap/cordova ecosystem and one interesting quote that floated around was that users don't care what the technology is, as long as it is fast.

My gut feeling is performance on native applications is "easier" whereas us web developers are butchering a glorified document to behave like an interactive application.

Regardless, I still find the web a lot of fun. Which is why I build simple apps: https://morsecode.tools/

Interesting tool but audio seems to be broken on the iPhone. Says transmitting with no audio (full volume)

Hrm, had an issue with when iPhone's were on silent mode, but that is resolved now.

Is your silent switch on?

Unfortunately, at the moment, I can only test on the iOS Simulator.

Web apps on mobile are ugly, slow, and glitchy with few exceptions unless they simply display a document in which case there is no need to build an app.

The amount of silliness that companies go through to avoid writing native, well-performing apps on basically 3 platforms for relatively simple applications is quite impressive.

I have used airbnb, I would never install an airbnb app.

airbnb is really the stereotypical example of an application that most people will not download a native version of because nobody likes downloading a native version of an application that they only need to run right now for a couple minutes.

I could see an app being useful for notifications when a often booked, popular location comes available during a timeframe that the user selected. Or providing an immersive experience for viewing the layout of the rental and areas outside the rental, for example.

Unfortunately, Airbnb would rather geek out on a silly framework that accomplishes little more than avoiding the implementation of 2 relatively simple native apps and making it harder for new developers to come online.

For airbnb hosts, the app solution makes sense.

I agree - for hosts I would make an app. for clients website. However I might think I could reuse code between client and host and then still make just a website thinking "the hosts need us so they will just have to lump it."

Are you extrapolating your own opinions to that of the masses? Many non technical people I know won’t use anything that isn’t an app on their phones.

You’d think Airbnb folks would be in a better position than either of us to know about those usage patterns.

Man, it's almost like you're saying progressive web apps need to be taken more seriously.

Sarcasm aside, I have used the Starbucks PWA and it's counterparty mobile app. PWA felt snappier and had better load times.

So I don't buy the thought that the web is somehow inferior. It just has Apple working against it because it threatens the app store model.

That aside, I'm excited for Capicitor 3 and what it will mean at the native runtime level for creating web native experiences.

Yes, the sad part is the nice mobile web experiences are often exceptions.

That's only for lack of good tech — everyone doing it before was going against the grain.

That day is over.

Having a great PWA is now the default behavior for any half-technical company.

They don’t have to be. It’s entirely a function of your discipline and care in maintaining and building out your web client.

Have worked on several reasonably complex sites that maintained 60fps on mobile web.

> Web apps on mobile are ugly, slow, and glitchy with few exceptions unless they simply display a document in which case there is no need to build an app.

So basically exactly the same as the average app then? There's more than one way to make an ugly, slow, and glitchy experience.

>XKCD has an appropriate comic for this

hasn't really invented webpages because the apps could still be vetted through an app store.

The description of Airbnb's system feels a bit like compiled HTML with some logic glued on top to make things act like JS.

Web still isn’t optimal for mobile interactions: layout, fonts, scrolling, performance, etc…

Their solution seems somewhat specific to their needs. Sections and screens aren’t the right abstractions for many other kinds of apps.

May still be right for them since for big companies percentage improvements are worthwhile doing and maintaining.

How could web made to be more optimal?

Optimal is a superlative, not a comparative, so "more optimal" is a non sequitir.

My opinion is that the web will never be the optimal user experience, although it offers enormous benefits in ubiquity and ease of access. That doesn't mean we shouldn't try to improve the ux of the web up the limits of security, but native solutions will always have a UX edge.

The web is optimal for things that native apps can never match, but ux is not one of those things.

> Is the performance or user experience over web really that bad, even in this day and age to warrant shipping a 100MB package to the user?

On slow networks (mobile) it is really frequently bad due to the large number of URL's (mostly trackers) that must be loaded. Some web pages require many MB's just to display a simple page. In theory this approach could be faster because you could multiplex data over a limited number of TCP connections, so you can avoid the latency that is caused by setting up a lot of new connections. But they don't seem to use this approach.

> At what point does it make sense to simply use the web for this?

You would basically end up implementing the exact same thing anyway - after all, Airbnb's implementation also targets web.

Airbnb wants, and has, a fairly interaction-rich interface, especially with Search/Filters, and then the rest of the booking flow, which means there's a lot you need to render on the frontend in Javascript.

An app with it's own icon and login is a much more "sticky" presence than a web page that the user must navigate to. It can add notices and alerts to the phone.

1) easier to maintain state 2) store arbitrary amounts of data 3) static assets are served just on download/updates 4) loads a lot faster 5) smoother UI (this requires effort I admit) 6) background network usage (browser will put a tab to sleep when you navigate away)

So, this is going back from SPA ("ship the code to display and interest with data once, and ship only data multiple times") to server side rendering ("ship both the data and the code") ; except that, instead of sending html and JavaScript, they invented an abstraction over layout and interaction.

That makes sense if:

- you have many clients

- that change very often

- but with a kind of change that is fairly consistent

- and you have the engineering horsepower to maintain your own in-house abstraction layer

I wonder if someone suggested jumping the shark altogether, and shipping the whole app as a single s-exp, and make you client a lisp interpreter with a custom logo... (But maybe app stores thrown on that ?)

Yeah app stores generally don’t allow for downloading code like that.

True, but app stores also don’t generally allow for what is described here either, as it would allow airBnB to change their app retrospectively to something that breaks the rules.

(I appreciate that they did actually allow it this time, but it does seem against their own rules)

Not sure, React native and code push definitely allow this - I think as long as you don’t change what the app does you’re fine.

Companies of AirBnb's size have a backchannel with Apple and don't necessarily have to play by the rules of the proletariat.

Source? Have you participated in such discussions?

Amazon Audible doesn't pay anything. So clearly, special treatment does exist.

Exactly my thoughts, why not generate HTML in the server dynamically and send it across? I’m pretty sure such similar things are being done since the 90s.

Exactly my thought. My theory is that dev nowadays grow up in SPA/mobile client era and they are rediscovering what html was meant to be 20 years ago.

I once wanted my SPA to render html directly by fetching the html from my trusted backend and shoving its response directly into a react component using dangerouslySetInnerHTML. One dev told me, "wait, you are opening door for XSS!"

An intermediate UI abstraction may hold some appeal if you maintain apps delivering equivalent function across a diversity of device types and capabilities.

The best example I can think of would be a streaming media service that ships an app for hundreds of different TVs, STBs, dongles, NASes, mobile devices etc etc that all front basically the same service.

> shipping the whole app as a single s-exp

Be careful what you wish for. You may reinvent Lotus Notes by mistake.

I'd blanked lotus notes from my mind. As an ex Notes developer, you're bringing back horrible memories.

I'm not a fan of this type of architecture for many reasons. One of the reasons is the difficuly of organizational coordination, which is funny because a few years ago Airbnb had a blog post about how they gave up on React Native and one of the reasons they gave was the difficulty of organizing changes across teams, but with SDUI that problem is worse, you need tight coordination across many teams to push features. One way to think about it as engineers is how we prefer decoupled systems with clear interfaces and boundaries. SDUI is the opposite of that, it's tight coupling between all the clients and the backend, changes to your UI are split across a bunch of teams and systems.

There are also a bunch of other problems, off the top of my head:

  - difficulty caching resulting in bad performance

  - bad performance because you end up unnecesarily reloading entire screens just in case one small piece of UI changed

  - difficulty taking advantage of unique platform features

  - difficulty handling animations or smooth transitions

  - client engineers lose understanding of the business data model, and motivation since all the action is in the backend.
 
  - hard tracing bugs across frontend to backend
  
  - doing UI in gql schemas is awful. sdui+gql are opposite goals, sdui wants dumber clients gql wants smarter clients. When would a client ever decide not to request a gql schema field? Which is another thing, you have to request these giant schema represantation of the UI which is bad for performance, youre basically sending your entire UI layout and receiving it back filled with data.

  - complexity, difficulty hiring, not being able to use the latest best practices and architectures

  - consistency across platforms is bad as a fundemental goal, users don't care since they typically use one platform. Consistency across mobile and web is actually bad UX in many cases.

But we do have a use case for this where the UI has to be scaled up by a total different group of people who are domain experts. Without such abstraction to generate the UI, the velocity will be terrible with a small UI front-end team. I think this makes sense when you have a need to allow pluggable UI components for something that is domain specific, with rather stable interface and has to be scaled up by non-Frontend folks

It's weird that clients have no idea what a page is supposed to look like until the server tells them. I mean, they could guess or cache the last layout they got, but it makes stuff like partial loading states a lot harder.

This kinda defeats the purpose of a SPA - a SPA lets you have instant page transitions through client-side rendering, but now you can't do that without a bunch of complicated prefetching because you need the server to tell you what the next page is.

> When would a client ever decide not to request a gql schema field? Which is another thing, you have to request these giant schema represantation of the UI which is bad for performance

I think the first part of your sentence solves the second - if the client is always requesting the same set of fields, you can probably give the query a name and pass that to the API instead of the actual giant schema.

Overall I think this sort of pattern is still valuable because shipping around fragments of HTML to update an existing document sucks, especially if multiple branches of the DOM are changing. And it won't work on mobile.

Also at the end of the day, this "server driven" UI is still a lifeless JSON blob that needs to be converted into HTML through giant JS blobs on the client. It seems really convoluted to download a description of the UI, convert it to React components, and then let React convert that to HTML. The new React Server Components project is intriguing, since it lets server-side React code render updates directly to the React runtime running in the client.

This comment on SDUI is the most insightful one I've read yet, and I'm surprised it isn't at the top of the page.

"Can we render some rental listings?" "No, we need to first design a completely new programming language, a new compiler to compile the new language into universal low-level byte code that can be translated by LLVM to run on 3 different platforms."

"Can we use MySQL for the rental listings? I mean there are only so many apartments in the world" "Nooooooo.....We need to design our own storage system that can run on all Cloud vendors and then design our own database on top of it, and a new generic caching system that beats Redis by 1% on this particular job"

Exactly the result of overpaying overqualified people to do something basic and they end up over-engineering everything to make themselves look good.

Spoken like someone who has absolutely no idea what he's talking about.

Spoken like someone who was personally offended by satire.

that wasn't satire, it was just an ignorant criticism along the same lines as "it's a crud app, there is no complexity"

I think this is an interesting approach, and I think many people in this thread are missing the point.

When you are a company that needs to maintain multiple clients across platforms (web, android, ios, and so on) it is very hard to be good at 3 things at the same time: application performance, development velocity and cross-platform consistency. Every solution that currently exists sacrifices some of the points to improve others. For example: If you make a web app across platforms, then you sacrifice performance on mobile; If you use native apps everywhere, you sacrifice development velocity and cross-platform consistency.

You might be wondering: isn't something like React Native or Flutter solve all those issues? Yes, on the surface it's a great fit. For only slight sacrifice in performance you get everything. That is why Airbnb have tried React Native initially, but decided to abandon it in the end due to technical and organizational issues (read mote here [1]).

This is their new attempt at getting good trade-offs here. You get full performance because you are doing everything natively. You get solid cross-platform consistency and high development velocity, because you are making changes in one place. Bravo Airbnb!

[1] https://medium.com/airbnb-engineering/sunsetting-react-nativ...

You don’t need to sacrifice performance on mobile if you make a web app. People choose to sacrifice it because optimizing it well requires care.

IIRC they gave up on RN because they were trying to use it inside existing native apps, and having that boundary introduces an ungodly amount of complexity. Going all-in on RN would have avoided that and result in performance just as good as native, or better, as shown by Shopify most recently.

Why all of this complexity to simply show a list of locations that can be rented? Maybe they can implement the simple ability to sort by price before tackling yet another new way to render a user interface to get around building native apps on basically 2 platforms ios and Android. Seems like Airbnb developers are overstaffed and need toy projects to flex.

My thoughts exactly. While we are not aware of all the possible complexities Airbnb's domain have the lengths their engineering team go to reinvent the wheels makes me wonder if they are in desperate needs to justify their salaries.

I don't know the answer, but I can most definitely say that the experience I have on their platform has always been solid.

But it is not radically different than using booking.com ten years ago as a user.

Maybe faster, maybe better looking, but the experience of renting a hotel/apartment hasn't really changed much.

I used to work on a similar system 20 years ago that leveraged xml to define forms, then generic transformation system written in PHP generated pages from it. Here it's json to define view and some internal schema.

It's good when your requirements are fairly stable, each view falls into a well known category. Meaning - it's great for an app that's basically a catalogue, but less so for apps with more complex user interactions.

you know what they say... "All problems in computer science can be solved by another level of indirection" , in reality those levels can be leaky and cause debugging problems.

Plus one. I think it’s almost JSON schema react forms. There are quite a few use cases for such catalogue like UI, but customization would be challenging

Same here. I used XML + XML Schema as input and transformed with XSLT + XML configs (UI layout metadata, validation rules) to HTML output. Even though the XSLT was huge in the end it remained rather well performant.

If you wanna a taste of how this look like? Pair tailwinds + htmx.

I do this and suddenly I cut a TON of issues, performance problems and make all the logic on Rust. Now I also contemplating doing similar for my mobile targets.

Is using web ok? Totally, absolutely, false.

Specially in android. WebView in android is SLOOOOOOOOOWWWWWW (not you $1000 android, the androids people actually use). All my users hate this when we move to web view replacing a native app. (same thing on iOS fly even low-end/older version).

To me this is just bored developers working on their own interests and their CV.

Crazy.

I used to work on similar project around 4 years ago, It was a Java Swing application that received all the data about the layout from the backend. The system was around 14 years or so, they implemented themselves most of the things like IoC container, custom XML markup for constructing UI, custom Swing elements.

It worked surprisingly well. The thing that impressed me the most was the amount of documentation which even included tutorials on how to make new UI elements, Screens, etc.

Wow that is a lot of "engineering and man-power" to generate UI's

Can I be 'that' d*k on the internet and asked.

-Why not use Svelte + Bootstrap (with a nice Pink Theme ?) and work via CSS to get the "similar (not identical) experience across most used devices ?

Move on to other problems ?

I feel if we were all blacksmiths in 15th century and were asked to shoe a horse. Using today's "UI-mania" (a divine mania maybe ?) would be akin to:

0) Yes sir I can shoe your horse. Will take some time because:

1) I'm first going to make my own metal. Right ? Cause it will be the "best-metal" ever !

2) but you know getting those iron-ore sand is tedious, I'm going to spend a 'little bit' of time to just optimise the mining-process of the sand.

3) Hmm this basic steel (or iron) is no good. To really get that horse going I'm quickly going to come up with a better alloy one that is dynamic, self-healing and glows green when orcs are near.

4) Finally got all the pieces... Bring that horse he is about to get NikeAirpumps for horses.

5) Damnn these nails are not perfect or optimal.. I really should spend some time and come up with a better nail... hmm maybe I can investigate geological-processes and grow my own mountain so the shape of the ore is already nail-like... Yup that sounds good.

6) 1000000 Sun cycles later: Sir please bring the horse around back, we are ready to shoe the horse now.

7) Sir ? You there ?

I should just ad it's mostly tongue-in-cheak.

But I'm pretty sure "there was a time" when AirBnb was "just a website" and somehow still manages to grow to the behemoth it is today.

Aka server-side rendering

A.k.a. 3270?

credit where its due: http://seaside.st/ was first to do this kind of server driven ui.

nowadays if you want a high performance html pushed to the frontend for an MVP, I'd recommend phoenix's liveview. its easy to use and works out of the box really well. You'll get a lot of users before you need to think about scale.

Does anyone know what thinking led to AirBnb blocking website access on Apple phones and iOS Safari devices in general?

What do you mean? Airbnb website works fine. I'm on iPhone 12, and even have the app installed, but the website works just fine.

Are you talking about Reddit because reddit is annoying af to use on the web.

There’s also a funny tactical situation where this makes sense: for whatever reason your front end deployment is really hard and taking much longer than your backend system. It happens when you can deploy backend independently but have to go together with others for front end

At first I was like everyone else, scratching my head but then I decided that this is absolutely fascinating to me, it seems to be more like a CMS with a view layer that can be replaced more than an API. Kinda likeone of those WordPress page builder/Wix/SquareSpace type systems but it doesn't generate a HTML page, instead all the clients bring their own view layers on board. I can kinda see a few somewhat edge use cases for this -- like generating apps for your clients that they can put together like Lego, or something.

Doing something like generating an HTML body and pushing it out to clients, parsing them on mobile and using web components in the browser and then doing the same could also be interesting.

I came across this article from Airbnb's engineering team. It's an interesting take on attempting to maintain engineering velocity while supporting multiple platforms with evergrowing requirements. Down the line, I am not convinced it will not create more problems than it tries to solve. Interested in hearing viewpoints from HN community on such an approach.

I think I've seen other custom systems like this before.

I believe eventually there will be popular open source solutions for this kind of thing that handle a wider variety of use cases. I haven't done a ton of looking into it, but this kind of use case might be possible with React Native and React's Server Components (https://reactjs.org/blog/2020/12/21/data-fetching-with-react...) in the future.

Reminds me of WAP phones.

Back in the 1999-2000 I developed a multi-channel portal system, where each portlet[1] was emitting an XML with a custom schema, and the backend was transforming it using XSLT to HTML, WAP/WML and VoiceXML. I think I even had an experimental 3D VR version using Flatland markup language or something like this.

Also, at one of the messaging companies we developed an XML-based DSL for messenger-embedded 3rd party app development. It was inspired by Mozilla XUL, and was similar to modern chatbots with UI and WeChat's mini-apps.

[1] an individual applet-like component in a portal UI

How often is the UI spec modified in practice compared to the frequency of UI changes? I wonder if this scheme actually reduces app update frequencies much. I can imagine that UI improvements often would require spec changes. Imagine adding colors to the map POI's, etc.

A/B Testing.

It’s fascinating to see Airbnb drop React Native and now watch them attempt to build their own in-house universal UI system from scratch.

There are very few organizations that can spend the kind of resources necessary to try this kind of thing. However it turns out, it will be interesting.

tldr They created a DSL (domain specific language) that specifies their UI layouts and the actions that can be triggered. Each platform has a little DSL interpreter.

This is a good idea since it raises the abstraction from ui frameworks that work differently on each platform, to a common DSL everyone now uses.

The absence of any mention of UI tooling to make it easy to view, edit, diff and do all the project management stuff with these DSL files makes me very nervous, since that's the problem they had in the first place - keeping track of whodunnit, wheretheydunnit, whentheydunnit and whytheydunnit :)

It seems like they did a cool programmer thing, while not addressing the management problem that started this whole thing in the first place.

---

As a larger point, these rich VC backed companies seem to hire people who are capable, but then they get tasked with 'create some CRUD for us' which is boring, so they end up over-engineering and trying to use 'crypto', or 'blockchain', or 'functional programming', or 'new language', or 'create new framework'.

I know the type because I did it when I worked for big money douchebags and uh, you just need to be working somewhere else, on something else instead :)

AirBnB is practically unusable so I'm not sure that's a great indictment of an over complicated technology to solve a non problem.

Microsoft's Adaptive Cards

weird line to try to strddle from an app approval standpoint. you're on the threshold of becoming an interpreted system. your template system has to be ultimately technically unintersting just enough so as to never offend the big No Interpretted Languages / Thou Shalt Only Write In Static Native Code edicts of the various app stores.

it'd be interesting to see if this would fly if you wanted to embed it into a Chrome v3 Extension: the anti- data-driven/dynamical forces there are very very strong these days!

Reply on news.ycombinator.com