Hacker News Reader

Comment by intoverflow2 | Hacker News Reader

This is a bad sign to me, talks about how to optimise start up performance and optimise list views when the processors in our pockets are the fastest they've ever been.

Do we really have to switch to developer centric development where devs have an easier life using JS at the expense of performance?

Think the millions of users would prefer their devices to have better battery life, load faster and have less cruft just to draw a few text boxes of a profile edit screen or a grid of photos (something I would have thought would be effortless to mobile devs in 2017). Rather than the handful of devs having a slightly easier day at the start of the process.

This whole move seems especially strange to me coming from a Facebook company, have we forgotten the move from native > webtech > native already?

View on HN

> devs have an easier life using JS

I think that is willfully missing the point. Creative work, especially UI-centric product development, requires significant iteration. Layouts change frequently, entire view hierarchies can be re-worked, sizes are tweaked obsessively.

This isn't just about decreasing the burden of engineering (as if Obj-C/Swift/Java/etc. were so hard to master). This is about decreasing the time from concept (e.g. Photoshop mock) to implementation (interactive working app) so that iteration can happen quickly.

As much as I love the performance possible when coding directly against Native APIs, I also have direct experience using web views in native apps. The improvement in the design process around web views is worth investing in getting the performance as close as possible to native. This is multiplied when you consider the cross-platform benefits. However, the performance and UI experience of web views is not good enough.

I can't vouch for React Native giving the iterative benefits of pure web view development nor the performance benefits of pure native development. However, if it does strike a reasonable balance between them I can totally understand why people invest in it.

So why not have a virtual DOM-based data-driven layout engine that _isn't_ an HTML/JS stack. Something in a language that is more optimisable and works everywhere, like Lua with C extensions, or OCaml, or Java. JavaScript is hard to get predictable performance from and HTML is extremely complex, we can do better if we're writing native apps (hell, we should have had a better online solution years ago too, but we don't have control there).

React Native does not generate any HTML. It generates native controls.

> why not have a virtual DOM-based data-driven layout engine that _isn't_ an HTML/JS stack

I'm not advocating RN, I just understand the motivations behind frameworks like it. I think "to make devs lives easier" is not a fair assessment. Also, to be fair, JS performance is generally adequate. My own experience with performance on mobile devices often fell back to rendering (e.g. managing textures, making animations smooth, infinite tiled scrolling). Very rarely was raw CPU processing a major concern. My experience may not be typical.

As for other cross platform native development libraries/platforms/etc. - I've had some experience with a few of them (e.g. marmalade[0] which was in C++) and generally they do not work for me. I even attempted to write my own and it was its own monster.

In general, I am personally biased towards Native. I would definitely take RN on a test spin if I was in the prototype phase of a new app. I would use that time to determine if I wanted to bring RN into production or re-write as Native.

[0] https://en.wikipedia.org/wiki/Marmalade_(software)

What is "adequate"? Any long term task still hangs the business logic thread - the only thread - unless you fallback to native. At what point does constant fallback to native for implementing what is not possible in JS a detriment to development? You may say, multithreading is an edge-case, but is it? I have not been involved in a single project where actual multithreading was not needed. Also, the way RN is implemented internally, such as async bridge and layout (CSSLayout / "yoga"), it is quite impossible to use native optimized views, such UITableView with reusable views, because this API is designed for synchronous API calls.

Google might have the thing for you...

https://flutter.io/

Too bad Dart has fallen so far out of fashion.

The core Facebook iOS team built the news feed in ComponentKit. ComponentKit (Objective C++) was inspired by React:

http://componentkit.org/

" Something in a language that is more optimisable and works everywhere, like Lua with C extensions, or OCaml, or Java. JavaScript is hard to get predictable performance from and HTML is extremely complex,"

React Native is not based on WebViews/HTML. It uses a virtual DOM on top of native views:

https://facebook.github.io/react/docs/optimizing-performance...

"React builds and maintains an internal representation of the rendered UI. It includes the React elements you return from your components. This representation lets React avoid creating DOM nodes and accessing existing ones beyond necessity, as that can be slower than operations on JavaScript objects. Sometimes it is referred to as a "virtual DOM", but it works the same way on React Native."

This is quite different from similar Javascript based efforts such as Cordova.

Just in case some folks read this comment the wrong way, React Native is not based on webviews like say Cordova:

http://stackoverflow.com/questions/33479180/what-does-react-...

"React Native uses a JavaScript runtime, but the UI is not HTML and it doesn't use a WebView. You use JSX and React Native specific components to define the UI."

Some notes on React's virtual DOM concept:

https://facebook.github.io/react/docs/optimizing-performance...

This is an important point to note as a lot of the problems associated with hybrid apps in the past come down to them being based on WebViews.

> > devs have an easier life using JS

> I think that is willfully missing the point.

How is GP missing the point, when you go on to illustrate the point? Or, is your counter-point to GP that "design is special, so cut us some slack"?

The GP implies that the only reason a company would go with React Native is to make life easier for it's dev's at the expense of performance. That's clearly not true and I believe the GP knows it.

If performance was the only thing that mattered to consumers then performance and optimization would be the only thing Instagram's developers would focus on. Facebook is a public company, it publishes Instagram's engagement, growth and advertisement numbers every quarter. Choosing a technology that hurts those numbers would be a poor decision.

Performance doesn't come for free it often comes at the cost of stability and slower time to market. In the case of React Native versus having separate Native teams it also comes at the cost of synchronizing different product teams and dealing with the bugs that come out of that.

To sum up, if React Native was a poor choice it would reflect in the user engagement/growth numbers and wouldn't last long within a metrics driven public company like Facebook.

So you say that React Native is not just to make life easier for developers, but then go on a rant ... that proves how React Native makes life easier for developers? Otherwise, it is a very big compromise, in regards to UX and performance. UX is not native - it reimplements basic concepts from each OS on its own in JS, which is neither good for UX (it doesn't look or feel right), and performance suffers due to bridge shenanigans, JS VM and shadow view hierarchy (aka shadow DOM).

"So you say that React Native is not just to make life easier for developers, but then go on a rant ... that proves how React Native makes life easier for developers?"

I'm very sorry if my comment came across as a rant, that was not my intent. I actually never made the claim that React Native makes developers lives easier in that comment.

My main point was that raw performance is not the only thing that matters to users. App stability and the time that it takes to get new features to market are also things that users care about, sometimes at the expense of performance.

Facebook/Instagram make product and technology decisions based on metrics. Making life easier for their developers is a secondary concern. If a feature is not moving the engagement numbers in the right direction, it gets cut.

The proof of this is Paper, a beautiful fast native app that was originally meant to the replacement for the main Facebook app. It's numbers sucked, so Facebook cut it.

Paper was never designed to be a Facebook replacement, but a PoC in engagement through UI using Facebook. The released a lot their findings and tools to the OS community as well (Tinder took their animation mechanics). Btw 1 billion DAU would have never agreed to that level of rethinking for the app.

The only thing I can say for both of you are that you're both right. We need to optimize for the user and optimize for the people getting the improvements to the user as fast as possible. Anything else is just technical debt :)

> Think the millions of users would prefer their devices to have better battery life, load faster

I'd love to see some testing here. Are we talking fractions of a percent or something like 20% more battery drain? If its fractions I am willing to bet most people would pick an easier life (assuming JS is their definition of easier).

> have we forgotten the move from native > webtech > native

I doubt many have, especially Facebook themselves. What a large cost that must have been for them. To have failed that and be willing to risk doing it all over again with native > "webtech2.0" must say something.

OTOH, this kind of tech is a godsend for smaller shops and solo developers, where having two completely separate codbases (or three if you also do a web version) can be impossible.

Or smaller startups who need to support both platforms at launch. We're going through that right now and we definitely can't afford to pay for a java dev and a swift dev and a js engineer (me). We also can't afford the Dev Shop costs of both iOS and Android. and our customer base is split 65-35. React-Native is literally a gift sent from God to save us

Do you mind sharing what your application does, and possibly a link to the app store of it?

I think almost always, if there was a choice between making thing easier for the developer and squeezing more performance with more difficult practices, majority chose better developer experience.

Especially as chips get faster, teams can afford opting towards a better developer experience to move faster and retain happier engineers. It isn't only developer experience, also developer velocity. That was the whole motivation behind React Native in the first place.

From my experience, any native developers that work with React Native have a mental toll from having to adapt to what seems like unnatural technologies from the native side. Add on top of that the terrible web ecosystem, terrible JS base library (and, perhaps, the language itself), the lack of IDE (not code editors), the debugging experience, the packager performance, and it's just not a good experience for people who have worked in better developer environments, such as Android Studio, Visual Studio and Xcode. The only people really happy, from my experience, are web developers who are already familiar with this technology and ecosystem.

Having done years of iOS and web development, React Native is a far better developer experience than Xcode.

Take it from a former UIKit author: https://twitter.com/andy_matuschak/status/560511204867575808

> devs having a slightly easier day

I think the goal here is to target both iOS and Android with just one codebase.

But I also happen to hate this trend, and I see it on Windows too. It seems like companies stopped creating native, good-looking and performant GUI applications built on .NET (or on Win32 which I still would find acceptable), and instead opted for uglier and less performant applications running on some javascript or node.js framework, because those will also run elsewhere.

Could you give an example or two of a beautiful 3rd part .NET or Win32 app on windows? In my mind many of the standard win-forms-esque looking apps are really ugly or have issues scaling on hi-dpi screens.

BeyondCompare springs to mind. Holy crap, I love that tool.

Welcome to programming with web technologies!

Unless you are making a video game, or doing high throughput data processing, the JavaScript language is probably not your performance bottleneck.

For the most part performance problems in consumer apps are things like pagination, poor re-use of data structures, over pre-caching, etc.

Instagram never has more than what... 10, 20 elements on the screen? And it's all pretty much text or at most a 10 second video clip. There's no reason even a crappy mobile processor can't handle those elements. It's all a matter of being intelligent about what you put on the screen and when.

There's no need for high performance rich data structures. There's no big data.

Reply on news.ycombinator.com