8 ms·

React Native: Initial Thoughts

101 points by kaishin 12y ago

agmcleod 12y ago
I think these are fair concerns, but it also sounds like this person comes from a more iOS native development background. Why not stick with that? I like the idea of react native as i use react more and more in the browser, and I enjoy the workflow.
- edgyswingset 12y ago
  > Why not stick with that? Eventually it'll be available for Android, so that's a valid reason.
  - agmcleod 12y ago
    I thought the APIs would still be different though. Maybe not. Either way, I think it's great for people who do use native to try new tools. But yeah I can accept that they will probably miss certain features.
Kesty 12y ago
When "The Bad" list start with the single word Javascript, it loses a lot of credibility for any unbiased judgment.
- thewarrior 12y ago
  Especially when its using ES6.
- nkozyra 12y ago
  I think this is because you're interpreting it as "Javascript is bad" instead of "Javascript is bad for this purpose." I think there are plenty of places where the latter is a totally logical statement that needs no real further explanation.
  - thomasfoster96 12y ago
    The article probably should have removed any ambiguity on the way it could have been interpreted. An explanation as to why javascript isn't a good language choice would have been even better.
- cristianpascu 12y ago
  He's pointing to JavaScript as being "bad" when the very point of ReactNative is to bring web technologies to iOS development. What did he expect?
- fabean 12y ago
  Completely agreed. After reading that I was immediate put off about the rest of the article.
  - fit2rule 12y ago
    Why? Javascript is not without its thorns and glitches. What makes it perfect for this use, in your opinion? Is it just the general "I don't like something you like" reaction - in which case, what is it that he's wrong about here?
    - stupidcar 12y ago
      Who said it was perfect, for this or any other use? You're just constructing a straw man. The actual objection, which was perfectly obvious from the comments you were replying to, is with the use of the word "Javascript" alone without any further explanation, as if it was axiomatic that the use of Javascript is bad. When an article includes such an extreme opinion without explanation, it inevitably puts off anyone who doesn't share it. Moreover, it calls into question the ability of the author to review the technology in a fair way, and the purpose of them reviewing it at all. React Native's entire raison d'etre is to provide a native version of a web development stack. If you are inherently biased against web development technologies, then you're obviously not going to get on with React Native, or any similar technology.
      - fit2rule 12y ago
        I don't think that just because someone doesn't like Javascript it makes their opinion less valid, or that they are a poor developer .. by many professional, highly-productive developers standards, Javascript is a mess and ought to be avoided. For some, the use of Javascript to solve the cross-platform web development problems is a poor decision .. whereas your argument seems to be "everyone else is doing it therefore it must be good and anyone who disagrees with the collective mind is clearly stupid". Sure, I'd like to know why he thought Javascript is a negative. I'd also like to know why some think its a positive. But I fail to see how invalidating his entire argument is going to prompt that discussion. Seems to me like those who disagree with him about Javascript just want to shut down the whole discourse - whereas there could, indeed, be very good reasons why Javascript is a negative.
- dcre 12y ago
  I think you're expecting a little too much out of a one page blog post.
- lucian1900 12y ago
  But JavaScript is a bad language, objectively. There's little debate on that subject. Most of us use it because we have to, even though there are much better languages available.
  - ceejayoz 12y ago
    > Most of us use it because we have to, even though there are much better languages available. Node's popularity is a pretty dramatic counterexample to that assertion.
    - smt88 12y ago
      > Node's popularity is a pretty dramatic counterexample to that assertion. Popularity has nothing to do with quality. Node is popular because so many people knew JavaScript anyway. JavaScript is popular because it was the only widely-supported programming language for the browser (other than ActionScript, which is itself an ECMAScript flavor).
      - ceejayoz 12y ago
        > Popularity has nothing to do with quality And that has nothing to do with the discussion at hand. The statement "Most of us use it because we have to" is pretty clearly refuted by the fact that no one had to use JS on the server-side, yet plenty still pick Node over other alternatives (even ones they know well).
        smt88 12y ago
        No one "has to" use anything, even if they only know that one thing. It doesn't take that long to learn a new language. I wasn't saying that people use it because they have to. There are a lot of reasons to use Node on the server side that are still unrelated to the quality of JavaScript as a language. 1) Easy asynchronous execution (something that is also making Go very popular) 2) Easy to get started 3) Lots of existing libraries 4) Everyone, including frontend devs, knows it already If you're starting a Python project, you're probably going to prefer hiring Python devs. If you're starting a Node project, you can hire anyone who has done full-stack or frontend work, including Ruby and PHP devs. Again, all of those are really compelling reasons to use Node, but they have nothing to do with the way JavaScript is designed. The seminal JavaScript book ("The Good Parts") even alludes to the fact that it's not a thoroughly good language. Further evidence that it's not a good language are the huge number of compile-to-JavaScript projects popping up (TypeScript and Go come to mind). I also went to a JavaScript conference, and not a single company was using Node through their whole stack, even for new projects. They were typically using Ruby, Python, or PHP for the bulk of their backend, and JavaScript was a thin API layer. I know this is also the case at Yahoo and probably some other companies. I could write a lot about why I (and lots of others in the dev community) find JavaScript to be Blub-y and fragile, but this is long enough already. The dynamic typing and many ways it behaves unexpectedly are among the major problems.
- weavie 12y ago
  You aren't limited to Javascript, any compile to JS language can surely be used.
tariqr 12y ago
"StyleSheet is not CSS. You will be quickly disappointed if you adventure outside the few CSS-inspired properties that React Native ships with." < I can see how that can be quite annoying, everytime you want to use a property, you'd have to go back and check if RN supports it. Maybe there will be stronger overlap in the long run.
- colinramsay 12y ago
  The one pain point I can see coming up again and again is that the way of making something full-width isn't to specify "width:100%" but instead to use flexbox. While that makes sense to me, I've already seen quite a few people (on SO for example) tripping up on this. For the rest of the properties I imagine anything that's really needed will be coming - many seem trivial to implement.
badlogic 12y ago
While react-native isn't for me, some of the features are really nice. Hotswap for mobile development is definitely a very nice thing to have. I do wonder how that handles app state. Is only the UI reloaded or all of the code?
- colinramsay 12y ago
  At the moment I believe it's everything JS-side. It's not like webpack hot-swapping where just the component gets replaced. The one caveat is that if you've got a native module written in Obj-C obviously you'll need a full rebuild to see any changes there.
0x0 12y ago
Any further thoughts on the apparently controversial PATENTS file? https://github.com/facebook/react-native/blob/master/PATENTS https://github.com/facebook/react-native/blob/master/PATENTS
- colinramsay 12y ago
  It ruins every single discussion on the topic when armchair lawyers wade in. I have no doubt that we'll see commenters now provide their own opinions on this clause without having the faintest idea of what they're talking about. If nothing else, the list of very large companies making use of React, seemingly without concern, makes me unworried about this.
  - aggronn 12y ago
    I agree that having this issue dominate discussion is incredibly annoying, however I have to say, Facebook needs to make this more clear. There should not be confusion about this.
    - colinramsay 12y ago
      This, I do agree with. Like I say, I'm not bothered about this issue, but I'm sick to death of seeing the endless stream of internet warriors throwing themselves at it. A clarification blog post would help a lot.
  - ahunt09 12y ago
    The fact that large companies are making free use of this surprised me. Is it because they don't think that the seconds clause is actually enforceable? I would love to hear more on this.
- insin 12y ago
  I saw this [1] from one of the (ex-FB) React devs after the last bout of this on HN: > it's "be a patent troll and suffer the consequences" [1] https://twitter.com/floydophone/status/581486099240873985 https://twitter.com/floydophone/status/581486099240873985
jk5_ 12y ago
> Flexbox. The authors missed the opportunity of offering a saner API and favored sticking to the official spec instead. This is located in « The Meh » section. IMHO, it should be in the « The Good ». Using the official spec instead of reinventing the wheel is always a good move.
- pestaa 12y ago
  Agreed, though it must be stated flexbox is not yet a fully implemented and deployed API, and most certainly not the easiest to use (but it is not for a trivial problem anyway.)
- thomasfoster96 12y ago
  Id really like to know what a better flexbox api would be like.
- Cshelton 12y ago
  I think in either the first or second keynote back to when React native was announced they talked about their reasoning behind using flexbox. I think it's also 'the good'. They were able to use a web technology and make it work in react native just as if it's the browser, pretty impressive. If they had to come up with their own 'css' style layout api I would then have put it in 'the bad' myself.
tel 12y ago
Is there an FRP library in iOS? The author states that React "feels superior" than FRP, so I'm curious what the comparison was.
- lazerwalker 12y ago
  ReactiveCocoa is a fairly mature FRP library from GitHub. It strikes me as a funny comparison. I agree that the react approach can feel like a better fit than FRP at the view layer, but it's not like there aren't positive reasons to use FRP/signal-based programming in your model layer or when wiring up your models to React views.
  - wahnfrieden 12y ago
    View as function of model isn't a concept foreign to FRP either - MVVM is a common pattern together with ReactiveCocoa.
UUMMUU 12y ago
He knows they just released it right? A good number of "The Bad" should probably be seen as coming soon. Probably could've named those "will be better when..." Especially Stylesheet and Swift support.
legacy2013 12y ago
Why is Chrome Developer Tools meh? It's something people are familiar with and has a full debugging suite
- rickyc091 12y ago
  "Chrome Dev Tools. Browsers are doing too much already." I think he's trying to convey that the browser is getting too bloated and that there should perhaps be a native app to handle the debugging.
  - colinramsay 12y ago
    Which is daft, because to produce a separate app specifically for debugging React Native would be a huge undertaking with zero extra benefit. Chrome's Dev Tools are best in breed (IMO) and it makes sense to leverage them. If there were things being added to Chrome Dev Tools specifically to support React Native, that'd be different.
    - 15155 12y ago
      Blink Devtools are used widely. node-inspector is another isolated use case, and is quite popular.
  - talmand 12y ago
    So the preference would be to install a separate tool instead of using the one I already have installed to avoid bloat?
bryanlarsen 12y ago
Component-based file structure is firmly in the "good" column for me. It makes small components much more feasible. If you're forced to split out your view, your template, your stylesheet, your controller, your model, your business logic, et cetera into separate files you are forced to keep components large. However, if you have a component-based structure, whenever you notice a very small piece of common functionality it becomes trivial to create a new component for that functionality. You end up with a very large number of very small, very easy to understand components, with clear areas of responsibility.
- marknutter 12y ago
  > If you're forced to split out your view, your template, your stylesheet, your controller, your model, your business logic, et cetera into separate files you are forced to keep components large. Why exactly does this force you to keep your components large?
  - bryanlarsen 12y ago
    A typical component in my React app contains about 3 lines of HTML. Have you ever seen a 3 line HTML template?
    - ben336 12y ago
      I have. Not uncommon in Backbone development for instance to keep templates in separate files from the views. If the templates are short you can inline them, but sometimes its easier to just be consistent and give every template its own file. It definitely does add friction compared to React though.
  - Fishkins 12y ago
    "force" is certainly an overstatement, but it does add friction to creating small components.
dheera 12y ago
Has anyone compared React Native to Appcelerator Titanium?
- ltb 12y ago
  It's a bit like comparing a particle accelerator to a bagel. Easier to explain them each on their own. Try running through some sample code of both to feel out the philosophy.
pjmlp 12y ago
For me QML/C++ (or other C++ UIs) and Xamarin make much more sense for native mobile coders. - Better native integration - Integration with the SDK tooling - Support of all three major mobile platforms - Performance As soon as I saw what React Native offers, it was meh for me.
- zura 12y ago
  I wish Qt Widgets (C++, not QML) was more mobile friendly... Xamarin will be good when it finally becomes free (acquired by MS?), or at least gains more indie-friendly license. API-wise, MoSync really stands out. Unfortunately, it is dead now. Same goes for Adobe Flex/AIR.
  - pjmlp 12y ago
    Xamarin prices are quite good when one takes into account developer salaries and saved time. Personally, I would also like more Qt Widgets love, but only due to binary size.
acdlite 12y ago
> Flexbox. The authors missed the opportunity of offering a saner API and favored sticking to the official spec instead. Flexbox is the saner API we've all be waiting for, in my opinion. I'm curious what the author's objections to it are. That's really my problem with the whole piece — statements like this are thrown out there without much justification or explanation.
- thramp 12y ago
  I'd much rather be writing apps using constraint-based layout, much like AutoLayout. It took me a while to grok it, but it's much simpler once you get it.
  - PSeitz 12y ago
    I agree, imho there isn't any decalarative and powerful way to build UIs as AutoLayout.
  - DennisP 12y ago
    It's even available in javascript: http://gridstylesheets.org/ http://gridstylesheets.org/
    - thramp 12y ago
      I saw that, but using polyfills for layout give me pause.
  - acdlite 12y ago
    I disagree, but I suppose this a matter of preference. For whatever it's worth, the React team did explore using a constraint-solver, but nixed the idea. They explain their reasoning here: https://www.youtube.com/watch?v=7rDsRXj9-cU&t=14m20s https://www.youtube.com/watch?v=7rDsRXj9-cU&t=14m20s
    - thramp 12y ago
      Yeah, it is preference. I found that buying entirely into Autolayout + Storyboards makes for a really nice development experience. And their reasoning makes sense. I totally get why they would avoid constraint-based layout.
bkurtz13 12y ago
OP mentions you can enable auto refresh, instead of having to Command + R every time I assume. I couldn't find that info anywhere, does anyone know how to do that? I'm really used to that workflow now with Figwheel + Om.
- colinramsay 12y ago
  Yes, in the simulator if you go to the "Hardware" menu, then "Shake Gesture" while the RN app is running, it'll pop up a menu that gives you the option. It is very cool.
- bradleyboy 12y ago
  See: https://twitter.com/ryanflorence/status/582016664847290368 https://twitter.com/ryanflorence/status/582016664847290368
  - bkurtz13 12y ago
    Awesome, thanks. That should really be mentioned in the Quick Start and/or Tutorial in the docs. I think a lot of people would really appreciate that feature. :)
    - bradleyboy 12y ago
      Looks like it got added to the Debugging page in the docs yesterday: http://facebook.github.io/react-native/docs/debugging.html#content http://facebook.github.io/react-native/docs/debugging.html#c...
vjeux 12y ago
> Styling nested view controllers is a pain. You are taken back to the root view controller after each refresh. It's so interesting how once you get used to instant feedback loop, anything that's longer is perceived as a pain. We want to find a solution for this though :)
ksherlock 12y ago
I played around with it a bit over the weekend. You can call it native, but at the same time, it's not completely native. For example, there is no UITableView support. That's one of the most common ways to present data. Hell, one of the first things I tried to do. (There is a bug report. They tried to support it but the code was ugly and didn't really play well with react-native so it was dropped). You can create a ListView and the performance (and feel) are great, but it's not a UITableView. You can draw a chevron and make it kind of look like a UITableView but if you have to manually re-create the native UI, it's not really native anymore, is it? It certainly is slick to get instantaneous feedback when you edit your javascript file, though.
- mpweiher 12y ago
  So: would an instant feedback environment that is "more native" be of interest?
- woah 12y ago
  I don't ever find myself using the default uitableview much, usually it will contain completely custom cells. Does their ersatz table view have any issues beyond the lack of a chevron?
aboodman 12y ago
"Component-based file structure. Handling styles, view hierarchy, and business logic all in one file is a step backwards. Poor style reusability is one direct consequence of this approach." If only there was some way to pull out a hunk of code so that it could be reused. Hm. Somebody should invent that.
ExpiredLink 12y ago
> Immutable user interface. You no longer have to track state in both the model and the view; the latter is a function of the former. As soon as the model changes, React Native re-renders a virtual tree of the view hierarchy, then applies the delta to the native views. The meaning of 'immutable' must have changed lately.
- erikpukinskis 12y ago
  Can you help me understand which part of that you think stertches the definition of immutability too far? The developer doesn't change the UI state, it is just a pure function applied to the domain state. Is it the fast path they implemented that does the diffing to speed up the function that bothers you?
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]

101 points by kaishin 12y ago

I think these are fair concerns, but it also sounds like this person comes from a more iOS native development background. Why not stick with that? I like the idea of react native as i use react more and more in the browser, and I enjoy the workflow.

edgyswingset 12y ago
> Why not stick with that? Eventually it'll be available for Android, so that's a valid reason.
- agmcleod 12y ago
  I thought the APIs would still be different though. Maybe not. Either way, I think it's great for people who do use native to try new tools. But yeah I can accept that they will probably miss certain features.

Kesty 12y ago

When "The Bad" list start with the single word Javascript, it loses a lot of credibility for any unbiased judgment.

thewarrior 12y ago
Especially when its using ES6.
nkozyra 12y ago
I think this is because you're interpreting it as "Javascript is bad" instead of "Javascript is bad for this purpose." I think there are plenty of places where the latter is a totally logical statement that needs no real further explanation.
- thomasfoster96 12y ago
  The article probably should have removed any ambiguity on the way it could have been interpreted. An explanation as to why javascript isn't a good language choice would have been even better.
cristianpascu 12y ago
He's pointing to JavaScript as being "bad" when the very point of ReactNative is to bring web technologies to iOS development. What did he expect?
fabean 12y ago
Completely agreed. After reading that I was immediate put off about the rest of the article.
- fit2rule 12y ago
  Why? Javascript is not without its thorns and glitches. What makes it perfect for this use, in your opinion? Is it just the general "I don't like something you like" reaction - in which case, what is it that he's wrong about here?
  - stupidcar 12y ago
    Who said it was perfect, for this or any other use? You're just constructing a straw man. The actual objection, which was perfectly obvious from the comments you were replying to, is with the use of the word "Javascript" alone without any further explanation, as if it was axiomatic that the use of Javascript is bad. When an article includes such an extreme opinion without explanation, it inevitably puts off anyone who doesn't share it. Moreover, it calls into question the ability of the author to review the technology in a fair way, and the purpose of them reviewing it at all. React Native's entire raison d'etre is to provide a native version of a web development stack. If you are inherently biased against web development technologies, then you're obviously not going to get on with React Native, or any similar technology.
    - fit2rule 12y ago
      I don't think that just because someone doesn't like Javascript it makes their opinion less valid, or that they are a poor developer .. by many professional, highly-productive developers standards, Javascript is a mess and ought to be avoided. For some, the use of Javascript to solve the cross-platform web development problems is a poor decision .. whereas your argument seems to be "everyone else is doing it therefore it must be good and anyone who disagrees with the collective mind is clearly stupid". Sure, I'd like to know why he thought Javascript is a negative. I'd also like to know why some think its a positive. But I fail to see how invalidating his entire argument is going to prompt that discussion. Seems to me like those who disagree with him about Javascript just want to shut down the whole discourse - whereas there could, indeed, be very good reasons why Javascript is a negative.
dcre 12y ago
I think you're expecting a little too much out of a one page blog post.
lucian1900 12y ago
But JavaScript is a bad language, objectively. There's little debate on that subject. Most of us use it because we have to, even though there are much better languages available.
- ceejayoz 12y ago
  > Most of us use it because we have to, even though there are much better languages available. Node's popularity is a pretty dramatic counterexample to that assertion.
  - smt88 12y ago
    > Node's popularity is a pretty dramatic counterexample to that assertion. Popularity has nothing to do with quality. Node is popular because so many people knew JavaScript anyway. JavaScript is popular because it was the only widely-supported programming language for the browser (other than ActionScript, which is itself an ECMAScript flavor).
    - ceejayoz 12y ago
      > Popularity has nothing to do with quality And that has nothing to do with the discussion at hand. The statement "Most of us use it because we have to" is pretty clearly refuted by the fact that no one had to use JS on the server-side, yet plenty still pick Node over other alternatives (even ones they know well).
      - smt88 12y ago
        No one "has to" use anything, even if they only know that one thing. It doesn't take that long to learn a new language. I wasn't saying that people use it because they have to. There are a lot of reasons to use Node on the server side that are still unrelated to the quality of JavaScript as a language. 1) Easy asynchronous execution (something that is also making Go very popular) 2) Easy to get started 3) Lots of existing libraries 4) Everyone, including frontend devs, knows it already If you're starting a Python project, you're probably going to prefer hiring Python devs. If you're starting a Node project, you can hire anyone who has done full-stack or frontend work, including Ruby and PHP devs. Again, all of those are really compelling reasons to use Node, but they have nothing to do with the way JavaScript is designed. The seminal JavaScript book ("The Good Parts") even alludes to the fact that it's not a thoroughly good language. Further evidence that it's not a good language are the huge number of compile-to-JavaScript projects popping up (TypeScript and Go come to mind). I also went to a JavaScript conference, and not a single company was using Node through their whole stack, even for new projects. They were typically using Ruby, Python, or PHP for the bulk of their backend, and JavaScript was a thin API layer. I know this is also the case at Yahoo and probably some other companies. I could write a lot about why I (and lots of others in the dev community) find JavaScript to be Blub-y and fragile, but this is long enough already. The dynamic typing and many ways it behaves unexpectedly are among the major problems.
weavie 12y ago
You aren't limited to Javascript, any compile to JS language can surely be used.

tariqr 12y ago

"StyleSheet is not CSS. You will be quickly disappointed if you adventure outside the few CSS-inspired properties that React Native ships with." < I can see how that can be quite annoying, everytime you want to use a property, you'd have to go back and check if RN supports it. Maybe there will be stronger overlap in the long run.

colinramsay 12y ago
The one pain point I can see coming up again and again is that the way of making something full-width isn't to specify "width:100%" but instead to use flexbox. While that makes sense to me, I've already seen quite a few people (on SO for example) tripping up on this. For the rest of the properties I imagine anything that's really needed will be coming - many seem trivial to implement.

badlogic 12y ago

While react-native isn't for me, some of the features are really nice. Hotswap for mobile development is definitely a very nice thing to have. I do wonder how that handles app state. Is only the UI reloaded or all of the code?

colinramsay 12y ago
At the moment I believe it's everything JS-side. It's not like webpack hot-swapping where just the component gets replaced. The one caveat is that if you've got a native module written in Obj-C obviously you'll need a full rebuild to see any changes there.

0x0 12y ago

Any further thoughts on the apparently controversial PATENTS file? https://github.com/facebook/react-native/blob/master/PATENTS https://github.com/facebook/react-native/blob/master/PATENTS

colinramsay 12y ago
It ruins every single discussion on the topic when armchair lawyers wade in. I have no doubt that we'll see commenters now provide their own opinions on this clause without having the faintest idea of what they're talking about. If nothing else, the list of very large companies making use of React, seemingly without concern, makes me unworried about this.
- aggronn 12y ago
  I agree that having this issue dominate discussion is incredibly annoying, however I have to say, Facebook needs to make this more clear. There should not be confusion about this.
  - colinramsay 12y ago
    This, I do agree with. Like I say, I'm not bothered about this issue, but I'm sick to death of seeing the endless stream of internet warriors throwing themselves at it. A clarification blog post would help a lot.
- ahunt09 12y ago
  The fact that large companies are making free use of this surprised me. Is it because they don't think that the seconds clause is actually enforceable? I would love to hear more on this.
insin 12y ago
I saw this [1] from one of the (ex-FB) React devs after the last bout of this on HN: > it's "be a patent troll and suffer the consequences" [1] https://twitter.com/floydophone/status/581486099240873985 https://twitter.com/floydophone/status/581486099240873985

jk5_ 12y ago

> Flexbox. The authors missed the opportunity of offering a saner API and favored sticking to the official spec instead. This is located in « The Meh » section. IMHO, it should be in the « The Good ». Using the official spec instead of reinventing the wheel is always a good move.

pestaa 12y ago
Agreed, though it must be stated flexbox is not yet a fully implemented and deployed API, and most certainly not the easiest to use (but it is not for a trivial problem anyway.)
thomasfoster96 12y ago
Id really like to know what a better flexbox api would be like.
Cshelton 12y ago
I think in either the first or second keynote back to when React native was announced they talked about their reasoning behind using flexbox. I think it's also 'the good'. They were able to use a web technology and make it work in react native just as if it's the browser, pretty impressive. If they had to come up with their own 'css' style layout api I would then have put it in 'the bad' myself.

tel 12y ago

Is there an FRP library in iOS? The author states that React "feels superior" than FRP, so I'm curious what the comparison was.

lazerwalker 12y ago
ReactiveCocoa is a fairly mature FRP library from GitHub. It strikes me as a funny comparison. I agree that the react approach can feel like a better fit than FRP at the view layer, but it's not like there aren't positive reasons to use FRP/signal-based programming in your model layer or when wiring up your models to React views.
- wahnfrieden 12y ago
  View as function of model isn't a concept foreign to FRP either - MVVM is a common pattern together with ReactiveCocoa.

UUMMUU 12y ago

He knows they just released it right? A good number of "The Bad" should probably be seen as coming soon. Probably could've named those "will be better when..." Especially Stylesheet and Swift support.

legacy2013 12y ago

Why is Chrome Developer Tools meh? It's something people are familiar with and has a full debugging suite

rickyc091 12y ago
"Chrome Dev Tools. Browsers are doing too much already." I think he's trying to convey that the browser is getting too bloated and that there should perhaps be a native app to handle the debugging.
- colinramsay 12y ago
  Which is daft, because to produce a separate app specifically for debugging React Native would be a huge undertaking with zero extra benefit. Chrome's Dev Tools are best in breed (IMO) and it makes sense to leverage them. If there were things being added to Chrome Dev Tools specifically to support React Native, that'd be different.
  - 15155 12y ago
    Blink Devtools are used widely. node-inspector is another isolated use case, and is quite popular.
- talmand 12y ago
  So the preference would be to install a separate tool instead of using the one I already have installed to avoid bloat?

bryanlarsen 12y ago

Component-based file structure is firmly in the "good" column for me. It makes small components much more feasible. If you're forced to split out your view, your template, your stylesheet, your controller, your model, your business logic, et cetera into separate files you are forced to keep components large. However, if you have a component-based structure, whenever you notice a very small piece of common functionality it becomes trivial to create a new component for that functionality. You end up with a very large number of very small, very easy to understand components, with clear areas of responsibility.

marknutter 12y ago
> If you're forced to split out your view, your template, your stylesheet, your controller, your model, your business logic, et cetera into separate files you are forced to keep components large. Why exactly does this force you to keep your components large?
- bryanlarsen 12y ago
  A typical component in my React app contains about 3 lines of HTML. Have you ever seen a 3 line HTML template?
  - ben336 12y ago
    I have. Not uncommon in Backbone development for instance to keep templates in separate files from the views. If the templates are short you can inline them, but sometimes its easier to just be consistent and give every template its own file. It definitely does add friction compared to React though.
- Fishkins 12y ago
  "force" is certainly an overstatement, but it does add friction to creating small components.

dheera 12y ago

Has anyone compared React Native to Appcelerator Titanium?

ltb 12y ago
It's a bit like comparing a particle accelerator to a bagel. Easier to explain them each on their own. Try running through some sample code of both to feel out the philosophy.

pjmlp 12y ago

For me QML/C++ (or other C++ UIs) and Xamarin make much more sense for native mobile coders. - Better native integration - Integration with the SDK tooling - Support of all three major mobile platforms - Performance As soon as I saw what React Native offers, it was meh for me.

zura 12y ago
I wish Qt Widgets (C++, not QML) was more mobile friendly... Xamarin will be good when it finally becomes free (acquired by MS?), or at least gains more indie-friendly license. API-wise, MoSync really stands out. Unfortunately, it is dead now. Same goes for Adobe Flex/AIR.
- pjmlp 12y ago
  Xamarin prices are quite good when one takes into account developer salaries and saved time. Personally, I would also like more Qt Widgets love, but only due to binary size.

acdlite 12y ago

> Flexbox. The authors missed the opportunity of offering a saner API and favored sticking to the official spec instead. Flexbox is the saner API we've all be waiting for, in my opinion. I'm curious what the author's objections to it are. That's really my problem with the whole piece — statements like this are thrown out there without much justification or explanation.

thramp 12y ago
I'd much rather be writing apps using constraint-based layout, much like AutoLayout. It took me a while to grok it, but it's much simpler once you get it.
- PSeitz 12y ago
  I agree, imho there isn't any decalarative and powerful way to build UIs as AutoLayout.
- DennisP 12y ago
  It's even available in javascript: http://gridstylesheets.org/ http://gridstylesheets.org/
  - thramp 12y ago
    I saw that, but using polyfills for layout give me pause.
- acdlite 12y ago
  I disagree, but I suppose this a matter of preference. For whatever it's worth, the React team did explore using a constraint-solver, but nixed the idea. They explain their reasoning here: https://www.youtube.com/watch?v=7rDsRXj9-cU&t=14m20s https://www.youtube.com/watch?v=7rDsRXj9-cU&t=14m20s
  - thramp 12y ago
    Yeah, it is preference. I found that buying entirely into Autolayout + Storyboards makes for a really nice development experience. And their reasoning makes sense. I totally get why they would avoid constraint-based layout.

bkurtz13 12y ago

OP mentions you can enable auto refresh, instead of having to Command + R every time I assume. I couldn't find that info anywhere, does anyone know how to do that? I'm really used to that workflow now with Figwheel + Om.

colinramsay 12y ago
Yes, in the simulator if you go to the "Hardware" menu, then "Shake Gesture" while the RN app is running, it'll pop up a menu that gives you the option. It is very cool.
bradleyboy 12y ago
See: https://twitter.com/ryanflorence/status/582016664847290368 https://twitter.com/ryanflorence/status/582016664847290368
- bkurtz13 12y ago
  Awesome, thanks. That should really be mentioned in the Quick Start and/or Tutorial in the docs. I think a lot of people would really appreciate that feature. :)
  - bradleyboy 12y ago
    Looks like it got added to the Debugging page in the docs yesterday: http://facebook.github.io/react-native/docs/debugging.html#content http://facebook.github.io/react-native/docs/debugging.html#c...

vjeux 12y ago

> Styling nested view controllers is a pain. You are taken back to the root view controller after each refresh. It's so interesting how once you get used to instant feedback loop, anything that's longer is perceived as a pain. We want to find a solution for this though :)

ksherlock 12y ago

I played around with it a bit over the weekend. You can call it native, but at the same time, it's not completely native. For example, there is no UITableView support. That's one of the most common ways to present data. Hell, one of the first things I tried to do. (There is a bug report. They tried to support it but the code was ugly and didn't really play well with react-native so it was dropped). You can create a ListView and the performance (and feel) are great, but it's not a UITableView. You can draw a chevron and make it kind of look like a UITableView but if you have to manually re-create the native UI, it's not really native anymore, is it? It certainly is slick to get instantaneous feedback when you edit your javascript file, though.

mpweiher 12y ago
So: would an instant feedback environment that is "more native" be of interest?
woah 12y ago
I don't ever find myself using the default uitableview much, usually it will contain completely custom cells. Does their ersatz table view have any issues beyond the lack of a chevron?

aboodman 12y ago

"Component-based file structure. Handling styles, view hierarchy, and business logic all in one file is a step backwards. Poor style reusability is one direct consequence of this approach." If only there was some way to pull out a hunk of code so that it could be reused. Hm. Somebody should invent that.

ExpiredLink 12y ago

> Immutable user interface. You no longer have to track state in both the model and the view; the latter is a function of the former. As soon as the model changes, React Native re-renders a virtual tree of the view hierarchy, then applies the delta to the native views. The meaning of 'immutable' must have changed lately.

erikpukinskis 12y ago
Can you help me understand which part of that you think stertches the definition of immutability too far? The developer doesn't change the UI state, it is just a pure function applied to the domain state. Is it the fast path they implemented that does the diffing to speed up the function that bothers you?

deleted 12y ago

[deleted]

deleted 12y ago

[deleted]