Hacker Newsnew | comments | show | ask | jobs | submit | yuchi's commentslogin

Not only I’m discovering a lot of jargon that I should have known before, but also this document is giving me formal knowledge for the project I have currently at hand.

To the op and the author, my most sincere thanks.

-----


I was thinking user zgm's comment [1] in the current Ask HN regarding large code bases and it reminded me of this InfoQ talk by Evans and Foote:

http://www.infoq.com/interviews/eric-evans-brian-foote-desig...

Mud flowing into a project scope is a powerful image.

https://news.ycombinator.com/item?id=9061217

reply


By the way, you’re re-defining Flash but with a canvas and JS :)

-----


Bloated assets? JS runtime?

-----


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.

-----


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.

-----


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.

-----


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.

-----


Looks like it’s for your own repos.

My ruby is rusty, but I’ll look into it, thanks!

-----


Exactly! It’s a mass s///g!

-----


Their promise of being cross-platform probably will move them into a cross-env toolchain, a-la Titanium.

-----


-- Attention -- Cross posting from the other thread --

Seasoned Appcelerator’s Titanium Mobile SDK dev here. Looks like that a lot of people here is comparing this announcement from the react team to the Titanium Mobile SDK. I’d like to give some info to shed some light on the differences, and probably anticipate the challenges they have to (or had to) solve.

## Architecture

Both Titanium SDK and this Native React thing do have a JavaScript runtime behind the curtains.

Both frameworks will run the JS runtime on the background, on a different thread from the UI. This is incredibly important to remind.

Titanium SDK follows an OOP-ish, imperative approach. You create views using factories (`Titanium.UI.createScrollView({ })`) and you add those views to parent views (`parent.add(child)`). This is very similar to a browser DOM, and in fact it’s cumbersome to work with. They built an xml preprocessor called Alloy which does a better job at exposing the view hierarchy right in the source, but it just compiles down to JS, `create()` and `add()`.

This is important for the evaluation at least for the following reason: every time you update a property on a view (actually on a proxy object to the real view) you’re crossing the bridge and you have to pay that penality. The bridge is the void between the JS runtime’s thread and the main, UI’s one. This is incredibly painful when trying to do JS animations, sometimes if you’re not careful you can get hurt very badly. You can still do great things, but it’s way better to use the native `.animate()` methods, which cross the bridge only twice (at start, and at the end as a callback invoking).

On Native React you should not have this kind of problems because changes will be batched and updated on a update loop basis or at least debounced. Or at least optimized in some smart way. I believe.

## Layout

One big problem will be the layout. Given that they don’t want the developers to understand every layout system every platform provides, they have to normalize it somehow. Titanium SDK has it’s own layout system, incredibly easy to understand even from a web-only dev experience:

a) by default everything is absolute positioned,

b) you can get a vertical flow layout by setting the 'layout' property on the parent view or

c) you can get a horizontal flow (inline-block-ish) by setting 'layout' to horizontal.

Native React will probably follow a more intimately web-ish approach, just look at this JS/C/Java implementation of the box-model and flex-box specification by Facebook itself [1]

[1]: https://github.com/facebook/css-layout

## Support and limits

Titanium SDK is always criticized for being to limited in what you can do with it. This actually comes from two different issues:

1) they have to (almost) manually implement every API you might need, by proxying from native-land to JS-land;

2) they have to follow every release of the platform’s SDK;

3) you cannot just put native code along-side your JS code, so you cannot go where they didn’t.

Let’s see how Native React will solve this issue.

Titanium SDK is undergoing an heavy lifting refactoring to solve exactly this issues. The project is code-named Hyperloop and is already working behind the curtains for the Windows 8 version of the SDK.

## Conclusion

Because I shamelessy want to karma-drift this topic, I’ll stop here.

It’s interesting, but until they show us some (native) code... it’s just ideas.

Follow me on twitter (@_pier) and github (@yuchi [2]) for Titanium related stuff.

Also my company, SMC, does a lot of great opensource things for Titanium (on gh we’re @smclab)

[2]: https://github.com/yuchi

-----


Seasoned Appcelerator’s Titanium Mobile SDK dev here. Looks like that a lot of people here is comparing this announcement from the react team to the Titanium Mobile SDK. I’d like to give some info to shed some light on the differences, and probably anticipate the challenges they have to (or had to) solve.

## Architecture

Both Titanium SDK and this Native React thing do have a JavaScript runtime behind the curtains.

Both frameworks will run the JS runtime on the background, on a different thread from the UI. This is incredibly important to remind.

Titanium SDK follows an OOP-ish, imperative approach. You create views using factories (`Titanium.UI.createScrollView({ })`) and you add those views to parent views (`parent.add(child)`). This is very similar to a browser DOM, and in fact it’s cumbersome to work with. They built an xml preprocessor called Alloy which does a better job at exposing the view hierarchy right in the source, but it just compiles down to JS, `create()` and `add()`.

This is important for the evaluation at least for the following reason: every time you update a property on a view (actually on a proxy object to the real view) you’re crossing the bridge and you have to pay that penality. The bridge is the void between the JS runtime’s thread and the main, UI’s one. This is incredibly painful when trying to do JS animations, sometimes if you’re not careful you can get hurt very badly. You can still do great things, but it’s way better to use the native `.animate()` methods, which cross the bridge only twice (at start, and at the end as a callback invoking).

On Native React you should not have this kind of problems because changes will be batched and updated on a update loop basis or at least debounced. Or at least optimized in some smart way. I believe.

## Layout

One big problem will be the layout. Given that they don’t want the developers to understand every layout system every platform provides, they have to normalize it somehow. Titanium SDK has it’s own layout system, incredibly easy to understand even from a web-only dev experience:

a) by default everything is absolute positioned,

b) you can get a vertical flow layout by setting the 'layout' property on the parent view or

c) you can get a horizontal flow (inline-block-ish) by setting 'layout' to horizontal.

Native React will probably follow a more intimately web-ish approach, just look at this JS/C/Java implementation of the box-model and flex-box specification by Facebook itself [1]

[1]: https://github.com/facebook/css-layout

## Support and limits

Titanium SDK is always criticized for being to limited in what you can do with it. This actually comes from two different issues:

1) they have to (almost) manually implement every API you might need, by proxying from native-land to JS-land;

2) they have to follow every release of the platform’s SDK;

3) you cannot just put native code along-side your JS code, so you cannot go where they didn’t.

Let’s see how Native React will solve this issue.

Titanium SDK is undergoing an heavy lifting refactoring to solve exactly this issues. The project is code-named Hyperloop and is already working behind the curtains for the Windows 8 version of the SDK.

## Conclusion

Because I shamelessy want to karma-drift this topic, I’ll stop here.

It’s interesting, but until they show us some (native) code... it’s just ideas.

Follow me on twitter (@_pier) and github (@yuchi) for Titanium related stuff.

Also my company, SMC, does a lot of great opensource things for Titanium (on gh we’re @smclab)

-----


Titanium comparisons are some of my top thoughts too.

1) How do they access the native API?

If there's no abstraction, just a translation, then the apps must be different for each platform. If there is an abstraction, then how much of the native platform do they cover? It can't be 100%, and the native APIs change with every OS version. Basic calls are easy, integrating things like device keychain, intents, and services are not so easy -- we learned this with Titanium.

2) How will React Native do cross-platform local data storage?

Being able to easily import, retain, and sync remote data is an absolute need for today's apps. Titanium uses SQLite on both sides, and has modules for more (like TiTouchDB). Not abstracting data storage would be a major mistake IMHO.

3) Can we use standard npm modules?

JS's killer feature is the module ecosystem, it's no good having a JS engine if we have to reinvent common modules to match a new API. V8 is the gold standard here, fingers crossed.

4) Debugging?

Speaks for itself. Debugging both JS and native code together bridged from a device is hard. Hopefully they are adapting existing tools and IDEs like node-inspector and Sublime Text.

-----


Exactly. As Haynie stated on tw, it’s sad that they didn’t included them in the design process. They already solved a lot of challenges.

BTW, did you have a look at titaniumifier? (https://github.com/smclab/titaniumifier) it’s a tool we built to port node packages to titanium (a declination of browserify, actually).

-----


Hyperloop is being used other internal APIs as well.

-----


Given the presence of https://github.com/facebook/css-layout it will probably flex-based. Not cool as a constraint based layout but good enough for easier portability of knowledge.

-----


Can I create the largest possible square div in a rectangular div with this library? That is my standard test as to whether a layout framework is advanced enough to meet my basic needs. (vanilla CSS fails this test of course, even with the most recent extensions, AFAIK)

-----


With css-flexbox, you probably can. Your DIV should have flex-grow: 1 which will make it take the allowable space along the "main axis" (shared with other flex-growers) and then align-items: stretch, to pick up all available space along the "cross axis". With some nesting, you can do pretty much whatever you want except for the grid layout. Grid layout is another thing coming but barely implemented in the today's browsers.

Anyways, flex-box is not available in IE < 10. IE10 requires ms- prefix. If React makes it available everywhere (IE8+) that will be really great.

-----


Thanks, but last I looked into this it wasn't possible for this to work for a square in a parent rectangle of arbitrary dimensions. Can you find an example that works, using jsfiddle or something similar?

-----


Are you excluding hacks? Because you can do this pretty easily in CSS2 since padding is always relative to width. Make your square div { width: 100%; height: 0; padding-bottom: 100% (or whatever ratio you want, doesn't have to be 1:1); };

-----


That only works for one dimension, can't handle square in landscape rect.

-----


You can do that with some funny inline-block wizardy on Vanilla CSS by the way. I don’t currently know if flex-box helps here. I think not.

-----


Source? AFAIK if you want your border, padding and margin respected, there is no way to do the above in vanilla CSS. Which is why css-flexbox was proposed.

-----


Here it is (it’s border-{top, bottom} based, not inline-block) http://www.mademyday.de/css-height-equals-width-with-pure-cs...

The issue is that it’s only width-constrained.

-----

More

Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: