3 ms·
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 w
by 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 agoFor 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.