5 ms·

I far prefer the hybrid approach to the js-to-native approach Facebook and Appcelerator are taking. If you go fully native, you get the complete benefit of the

I far prefer the hybrid approach to the js-to-native approach Facebook and Appcelerator are taking. If you go fully native, you get the complete benefit of the SDK, Native API's, and performance that comes along with it. If you go hybrid native/html5 you get the flexibility, productivity, and reusability of js/html/css with the option to write custom native components as needed. With React Native (AFAIK) and Appcelerator, you get some of the benefit of both approaches but nowhere near the full potential of either. Everything is hidden behind a thick layer of abstraction and you have to trust that things will be wired up properly on the other side of the fence and continue to be wired up properly as native UI components and APIs evolve. The React team has famously stated that they don't believe in "write once read everywhere" and instead are proponents of a "learn once write everywhere" strategy, which is a clever twist on a controversial topic, but ignores the fact that web developers have been practicing "write once read everywhere" for a very long time now and have gotten pretty good at it (fighting with IE over the years tends to sharpen one's senses). I believe that the negative feedback on their original hybrid mobile app deeply affected Facebook as an organization and as a result they have swung so far in the opposite direction they are in denial about any possibility that the web may be a viable target for mobile experiences. They've gone so far as to abstract away the entire DOM and ignore coming standards like Web Components. To Facebook, the web browser is nothing more than a render target. It's a clever short term hack to get back to the good ol' days of server side templating (like they used to do with PHP) and get around poor browser reflow/repaint performance. But it's a long term bet against the web as an application runtime and it's sad to think what gains we might be seeing toward that dream if Facebook wasn't so opposed to that goal.

danabramov 12y ago
>They've gone so far as to abstract away the entire DOM and ignore coming standards like Web Components. Web Components don't solve the problems React is solving. They are completely different (and sometimes complementary tools). >I believe that the negative feedback on their original hybrid mobile app deeply affected Facebook as an organization and as a result they have swung so far in the opposite direction they are in denial about any possibility that the web may be a viable target for mobile experiences I can't speak for Facebook but I think you're missing the point of React Native. It's not a solution to run webapps on native platforms. React Native is a solution to write native UI code with declarative paradigm. That it runs in JS is an implementation detail. If you look at it from that point of view, hybrid vs native doesn't even come into equation. "Native" is the original requirement here, as far as I understand it. Unless you propose to not write native apps at all.
- marknutter 12y ago
  > Web Components don't solve the problems React is solving. They are completely different (and sometimes complementary tools). No, they don't solve the same problem, but that's not what I was suggesting. What Web Components are trying to solve is the problem of sharing code, and if React doesn't play nicely with Web Components it's going to make it very difficult for React developers to partake in that sharing. Contrast that with the Angular team who are drastically overhauling their entire framework in order to be compatible with Web Components. I prefer that strategy over the long term (Ember is also actively preparing for Web Components). > I can't speak for Facebook but I think you're missing the point of React Native. It's not a solution to run webapps on native platforms. I am not missing the point. I get that it's goal isn't to allow web apps to run inside native wrappers. > React Native is a solution to write native UI code with declarative paradigm. That it runs in JS is an implementation detail. If you look at it from that point of view, hybrid vs native doesn't even come into equation. "Native" is the original requirement here, as far as I understand it. Unless you propose to not write native apps at all. I'm proposing it's better to either choose to write native apps using native languages and SDKs, or write them as web apps and embed them inside native wrappers like Reapp is doing. Hybrid vs. native does come into the equation because it's worth pointing out the pros and cons of every approach to mobile app development. People are frothing at the mouth in response to React Native without fully understanding the tradeoffs inherit with that approach, so it's worth properly setting expectations in response to overwhelming hype. Appcelerator has been around for years and solves the same problem in the same way (minus React's declarative pattern) and it hasn't been a panacea.
  - dustingetz 12y ago
    It appears to me that you are misinformed, React plays just fine with Web Components. https://groups.google.com/forum/?fromgroups=#!searchin/reactjs/web$20components/reactjs/Z4jaRKJK5zU/uf4Ww9GU64AJ https://groups.google.com/forum/?fromgroups=#!searchin/react...
    - marknutter 12y ago
      Exactly which part of that thread leads you to believe that "React plays just fine with Web Components". I suggest you watch https://www.youtube.com/watch?v=g0TD0efcwVg https://www.youtube.com/watch?v=g0TD0efcwVg which gives a very clear picture of the current state of React/Web Component interaction, including the challenges associated with it. edit: another good read if you're interested: http://futurice.com/blog/combining-react-flux-and-web-components http://futurice.com/blog/combining-react-flux-and-web-compon...
nwienert 12y ago
Author here. I agree with a lot of what you say. One thing: "everythings hidden behind a thick layer of abstraction". Native does just that! Abstracts a bunch of stuff away for you. It's just a different abtraction (and one you'll need to write three times for iOS/Android/m.web). I also would like to see Facebook come back to the middle on this, a company that big could put a lot of resources into making those web to native APIs evolve and bridging the performance / feature gap of JS, an effort they are currently putting into bridging JS to C with mass amounts of developers.
- aikah 12y ago
  Well,Facebook is putting resources on React native which is totally sane given the fact that they want their mobile app to use a native GUI. Javascript is just a sugar to make development cycles faster when supporting multiple mobile Os. The problem with your framework,just like jQuery Mobile,SenchaTouch and the rest is that it doesn't look native by a long shot.
  - nwienert 12y ago
    It has a theme running on the demo that isn't the default "native" look. It's also alpha, I'm confident it will look 99% native within a few months. There was a huge amount of time put into making it feel more native than any other hybrid approach so far, and that's what's important. I'm excited to start exploring webworkers and optimizations to really bridge that gap.
aikah 12y ago
> I far prefer the hybrid approach to the js-to-native approach Facebook and Appcelerator are taking. I far prefer native gui backed by javascript. No question that a native gui is faster, more performant and more faithfull to the plateform you're actually developping on. I fail to see how one cannot acheive the full potential of native applications with js backed native gui. There is no translation or compilation whatsoever,the javascript you write with Titanium is the javascript that will be running in the app,so there is no js-to-native, as js isn't compiled to objectiveC or Java. The cleverness of Titanium and co is to expose the native GUI as Phonegap expose native apis of the phone. Nothing prevents you from writing Titanium plugins like one is writing Phonegap plugin when the framework doesn't support this or that feature. On the top of that Titanium exposes webviews if one really needs them. All the app doesn't have to be html and css. Menus,prompts,alerts and navigation can and should be native, something you can't do directly with phonegap and likes. With projects like Titanium,there is very little reason to go back to shells like Phonegap that solve very little. For instance, I want my app to feel native but somehow one screen has to display a 3d model and I know webgl and it runs on my phone? well i'll write most of my app with titanium and i'll just use the web tech I like ONLY when it is necessary. How isn't it using both techs(native and web) to their full potential? Furthermore I get to use all the js libs I like,such as Backbone or Underscore,or Momentjs or Q... So AGAIN,since Titanium exposes a webview anyway,there is no need for things like Phonegap anymore. We need,however,more solutions with Titanium approach.And If you want to use a webview,well,there it is.

danabramov 12y ago

>They've gone so far as to abstract away the entire DOM and ignore coming standards like Web Components. Web Components don't solve the problems React is solving. They are completely different (and sometimes complementary tools). >I believe that the negative feedback on their original hybrid mobile app deeply affected Facebook as an organization and as a result they have swung so far in the opposite direction they are in denial about any possibility that the web may be a viable target for mobile experiences I can't speak for Facebook but I think you're missing the point of React Native. It's not a solution to run webapps on native platforms. React Native is a solution to write native UI code with declarative paradigm. That it runs in JS is an implementation detail. If you look at it from that point of view, hybrid vs native doesn't even come into equation. "Native" is the original requirement here, as far as I understand it. Unless you propose to not write native apps at all.

marknutter 12y ago
> Web Components don't solve the problems React is solving. They are completely different (and sometimes complementary tools). No, they don't solve the same problem, but that's not what I was suggesting. What Web Components are trying to solve is the problem of sharing code, and if React doesn't play nicely with Web Components it's going to make it very difficult for React developers to partake in that sharing. Contrast that with the Angular team who are drastically overhauling their entire framework in order to be compatible with Web Components. I prefer that strategy over the long term (Ember is also actively preparing for Web Components). > I can't speak for Facebook but I think you're missing the point of React Native. It's not a solution to run webapps on native platforms. I am not missing the point. I get that it's goal isn't to allow web apps to run inside native wrappers. > React Native is a solution to write native UI code with declarative paradigm. That it runs in JS is an implementation detail. If you look at it from that point of view, hybrid vs native doesn't even come into equation. "Native" is the original requirement here, as far as I understand it. Unless you propose to not write native apps at all. I'm proposing it's better to either choose to write native apps using native languages and SDKs, or write them as web apps and embed them inside native wrappers like Reapp is doing. Hybrid vs. native does come into the equation because it's worth pointing out the pros and cons of every approach to mobile app development. People are frothing at the mouth in response to React Native without fully understanding the tradeoffs inherit with that approach, so it's worth properly setting expectations in response to overwhelming hype. Appcelerator has been around for years and solves the same problem in the same way (minus React's declarative pattern) and it hasn't been a panacea.
- dustingetz 12y ago
  It appears to me that you are misinformed, React plays just fine with Web Components. https://groups.google.com/forum/?fromgroups=#!searchin/reactjs/web$20components/reactjs/Z4jaRKJK5zU/uf4Ww9GU64AJ https://groups.google.com/forum/?fromgroups=#!searchin/react...
  - marknutter 12y ago
    Exactly which part of that thread leads you to believe that "React plays just fine with Web Components". I suggest you watch https://www.youtube.com/watch?v=g0TD0efcwVg https://www.youtube.com/watch?v=g0TD0efcwVg which gives a very clear picture of the current state of React/Web Component interaction, including the challenges associated with it. edit: another good read if you're interested: http://futurice.com/blog/combining-react-flux-and-web-components http://futurice.com/blog/combining-react-flux-and-web-compon...

nwienert 12y ago

Author here. I agree with a lot of what you say. One thing: "everythings hidden behind a thick layer of abstraction". Native does just that! Abstracts a bunch of stuff away for you. It's just a different abtraction (and one you'll need to write three times for iOS/Android/m.web). I also would like to see Facebook come back to the middle on this, a company that big could put a lot of resources into making those web to native APIs evolve and bridging the performance / feature gap of JS, an effort they are currently putting into bridging JS to C with mass amounts of developers.

aikah 12y ago
Well,Facebook is putting resources on React native which is totally sane given the fact that they want their mobile app to use a native GUI. Javascript is just a sugar to make development cycles faster when supporting multiple mobile Os. The problem with your framework,just like jQuery Mobile,SenchaTouch and the rest is that it doesn't look native by a long shot.
- nwienert 12y ago
  It has a theme running on the demo that isn't the default "native" look. It's also alpha, I'm confident it will look 99% native within a few months. There was a huge amount of time put into making it feel more native than any other hybrid approach so far, and that's what's important. I'm excited to start exploring webworkers and optimizations to really bridge that gap.

aikah 12y ago

> I far prefer the hybrid approach to the js-to-native approach Facebook and Appcelerator are taking. I far prefer native gui backed by javascript. No question that a native gui is faster, more performant and more faithfull to the plateform you're actually developping on. I fail to see how one cannot acheive the full potential of native applications with js backed native gui. There is no translation or compilation whatsoever,the javascript you write with Titanium is the javascript that will be running in the app,so there is no js-to-native, as js isn't compiled to objectiveC or Java. The cleverness of Titanium and co is to expose the native GUI as Phonegap expose native apis of the phone. Nothing prevents you from writing Titanium plugins like one is writing Phonegap plugin when the framework doesn't support this or that feature. On the top of that Titanium exposes webviews if one really needs them. All the app doesn't have to be html and css. Menus,prompts,alerts and navigation can and should be native, something you can't do directly with phonegap and likes. With projects like Titanium,there is very little reason to go back to shells like Phonegap that solve very little. For instance, I want my app to feel native but somehow one screen has to display a 3d model and I know webgl and it runs on my phone? well i'll write most of my app with titanium and i'll just use the web tech I like ONLY when it is necessary. How isn't it using both techs(native and web) to their full potential? Furthermore I get to use all the js libs I like,such as Backbone or Underscore,or Momentjs or Q... So AGAIN,since Titanium exposes a webview anyway,there is no need for things like Phonegap anymore. We need,however,more solutions with Titanium approach.And If you want to use a webview,well,there it is.