frontendbeauty

> In every software company the people who are the most influential, and the best paid, are in management or sales.

I don't think that's necessarily true in Silicon Valley, where companies like Google, Facebook, Airbnb, Uber, etc. have parallel career tracks for individual contributor vs manager, with equal salary bands. I'm earning way more as a high-level IC than mid-leveled managers.

> Here's the litmus test. Ask the Reactive Native team to port their non-trivial paper app or mission critical messenger app or main app to Reactive Native.

Facebook is rewriting the News Feed in RN. That's not a trivial example.

s/AirBnb/Airbnb/

We've called ourselves "nerds" since the very early days, at least 5 years.

See Brian's post: https://news.ycombinator.com/item?id=7254986

Airbnb does leave an automated review about the cancellation and dings the host's listing in search results.

Why couldn't you use a CDN for the JS files? We most certainly do.

There are already two problems, if you're building a rich client-side web app. Have you done this? If so, you would understand the problem.

I like "multiplatform" -- current winner :)

There are a few options. Easiest is to just render HTML strings on the server, not actual DOM. But, you can also use a DOM implementation if you want to, like jsdom or PhantomJS, and then capture the outerHTML of an element as an HTML string to serve. But, that is slower. React.js has a nice middleground approach; it has a fast pure-JavaScript DOM abstraction that can emit either DOM (browser) or HTML (server).

(author here) Good point. TBH, I have no idea what "isomorphic" means in the mathematical sense.

I was inspired to use "isomorphic" from a 2011 article by Nodejitsu [1]. It seemed like a fine way to describe this approach. I would gladly use a better would if I were to find one.

[1] http://blog.nodejitsu.com/scaling-isomorphic-javascript-code

(author here) We just bootstrap some JSON onto the page to transfer application state to the client. It's the same approach as the `express-state` (mentioned in a below comment). Same as any client-side app.

The approach you mention is much easier. However, it does make for slower perceived page load times, even when serializing JSON on the page, because the browser has to fetch, parse, and evaluate JS files before rendering the HTML into the document. This can take many hundreds of milliseconds, especially on mobile devices.

In my experience, server-side rendering has led to a much better UX.

Correct. If you're already writing a bunch of JavaScript for the client-side, then just think about this approach as migrating some of that client, UI logic to the server.

(author) Cool! What's the JavaScript runtime on the server? Something JVM-based?

(OP here) Probably your best bet is to create a small Node web service that takes a template name and data and returns HTML. Then your (Rails, Python, PHP) app can call out to that in the request cycle.

Instagram.com does something similar; it's a Django app.

That is just amazing. Keep it up.

Yep.

At the time of the previous post, Rendr was not yet open-sourced.

We're using Rendr in a few more apps in production, in progress. It's starting to eat away at our Rails site a bit.

https://www.airbnb.com/jobs :)

The app template is such an example, consuming the public GitHub API: https://github.com/airbnb/rendr-app-template

In the future, we'd like to come up with some more in-depth tutorials.

Yep! Because links use full URLs which get intercepted by JavaScript, if JS is disabled, you can still navigate around the app, getting full HTML from the server. Of course, any client-specific code wouldn't run (slideshows, etc).

SEO was our first concern, but then we realized performance was the big win. Serving the user a full page of HTML rather than waiting for JS to download before rendering HTML makes a big difference, especially on high-latency or low-bandwidth connections (mobile).

EDIT: We decided against using something like PhantomJS or node-chimera because why deal with a DOM if you don't have to? DOM is complicated and slow, compared to string-based templating. Plus, it's another moving part, another process to keep up and running. The Meteor guys aren't too excited about the PhantomJS approach either, and IIRC they'd like to be able to serve HTML without firing up a DOM.

This is exactly right. We still have 5 years worth of business logic in Rails, so we just expose a RESTful API as part of the Rails app. The same API is consumed by our iOS, Android, Mobile Web, and Desktop clients.

Thanks, fixed.

Cool, I like that ViewModel pattern. You could certainly use that with Rendr.

We are absolutely hiring! airbnb.com/jobs

Awesome effort. Be careful, though, when you post screenshots of your Twitter, Facebook, Instagram feeds to the world to see -- don't forget that the people who you follow may see that as a breach of privacy. Very likely the things that we can see in those screenshots were never intended to be public.

I imagine the custom styles would be hard to maintain on more rapidly-evolving products.