> 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.
"Individual contributor", as opposed to management. i.e. for a software engineer, someone who ships code for a living rather than shipping Gantt charts/emails.
> 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.
> They are using Reactive Native for a lame duck Groups and some ad manager app.
"Some ad manager app" which happens to be the ad manager for one of the largest advertising platforms on the planet right now. It's also composed of non-trivial UI, you should try it before blindly bashing it. I've used both Cordova, and Titanium, too, by the way - Cordova was relatively painless but lacked the native feel. Titanium sort of had the native feel but it was slow. The Titanium community also felt very hostile towards competition and they didn't promote FOSS. Maybe you're a Titanium developer?
> Unfortunately they are marred by poor API support, performance and customization.
Web apps can hit 60fps these days (again, using React (Canvas)).
> 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.
That's a really lame litmus test considering they've got a massive code base in native languages with no reason to throw them away since they're working perfectly and they have a ton of developers to throw at the problem.
> They are using Reactive Native for a lame duck Groups and some ad manager app.
They appear to be using React Native for most new apps that they develop. I would assume it would be up to the discretion of the team to choose whether or not to use React Native. Most do because React Native is way better than plain old native. Even the author of UIKit thinks so.[0]
I'd be interested if you could provide a common real world example where React Native wouldn't be a good fit.
Furthermore, React Native never claims to be a total replacement for native. We openly acknowledge that some problems are best solved in native code. That's why React Native has excellent support for 3rd party modules.
Okay how about one very, very simple question - Can I replace my all of my Swift and iOS+tvOS+watchOS APIs with React Native? To make it easy for you. Can I do that within next 1 year? What will happen when Apple will introduce a slew of new APIs will be introduced in Sept?
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.
Technically, you're correct, see the biology and chemistry use of the word. But seeing how you're dealing with a mathematically inclined audience, there will be disapproval. I think it's a very useful concept in general, the more it gets out into the world, the better.
What about simply DRY? isn't that what you're aiming for - having code sharable between client and server such that you don't have two pieces of code that do the same thing in two different places?
Shall "multiplateform javascript [code]" be suitable here? Looks like this is all it's about: having a single js code generating the same results, with no dependance on the plateform.
(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.
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.