4 ms·

Seriously please stop making assumptions on Titanium without knowing a thing about it. > With the latter, you're also interfacing directly with native objects

by yuchi 12y ago

Seriously please stop making assumptions on Titanium without knowing a thing about it. > With the latter, you're also interfacing directly with native objects all the time, which is doomed to fail performance-wise. React Native actually performs the layout on a separate thread [...] Wrong. With Titanium you work with proxies. And JS is in a separate thread. The only actual difference between ReactNative and Titanium on this side is the functional/fully-declarative/almost-stateless vs imperative DOM-like philosophy. Let me slip this through: «if you don’t know something then don’t make it look like you do». Sorry for the rant. I’m just very upset from yet another post like this.

jlongster 12y ago
I have a friend that uses Titanium a lot, so yes, I only know of it second hand. The lack of a function/reactive componentized UI paradigm forces you to work with native objects (the views) a lot. React can optimize how much it touches the bridge because you don't interface directly with the UI. From what I've seen, Titanium can't do nearly as good of a job as that because it's like the DOM. You touch the UI in several places and it needs to always talk across the bridge. I never said it doesn't run JS on a separate thread. React performs layout on a separate thread, providing the flexbox layout algorithm. EDIT: It's all of these little details that can make or break something like this.
- yuchi 12y ago
  For sure there’s this «don’t cross the bridge» paradigm in the community, yet I’ve never actually experienced this issue. In our biggest app, an SFA that grew other time in a big fat ass app (project that I’m quitely waiting to chop in different pieces/apps) the kind of performance issues we found we’re related to managing tableviews of… 20'000 rows! And then we switched to dynamically loaded listviews and boom. No perf issues at all.
peterhunt 12y ago
The issue with Titanium is the direct manipulation of view objects via the proxies. Much of what makes React Native special is that everything -- from the original React API all the way to the latest and greatest bridge stuff -- has been designed with the assumption that the bridge (DOM) is the bottleneck so everything is batchable and async. The API that Titanium gives you is much more traditional OOP which means that developers can easily create applications that chatter over the bridge.

by yuchi 12y ago

jlongster 12y ago

I have a friend that uses Titanium a lot, so yes, I only know of it second hand. The lack of a function/reactive componentized UI paradigm forces you to work with native objects (the views) a lot. React can optimize how much it touches the bridge because you don't interface directly with the UI. From what I've seen, Titanium can't do nearly as good of a job as that because it's like the DOM. You touch the UI in several places and it needs to always talk across the bridge. I never said it doesn't run JS on a separate thread. React performs layout on a separate thread, providing the flexbox layout algorithm. EDIT: It's all of these little details that can make or break something like this.

yuchi 12y ago
For sure there’s this «don’t cross the bridge» paradigm in the community, yet I’ve never actually experienced this issue. In our biggest app, an SFA that grew other time in a big fat ass app (project that I’m quitely waiting to chop in different pieces/apps) the kind of performance issues we found we’re related to managing tableviews of… 20'000 rows! And then we switched to dynamically loaded listviews and boom. No perf issues at all.

peterhunt 12y ago

The issue with Titanium is the direct manipulation of view objects via the proxies. Much of what makes React Native special is that everything -- from the original React API all the way to the latest and greatest bridge stuff -- has been designed with the assumption that the bridge (DOM) is the bottleneck so everything is batchable and async. The API that Titanium gives you is much more traditional OOP which means that developers can easily create applications that chatter over the bridge.