Reapp – hybrid apps, fast
reapp.io
reapp.io
I spent a large part of the development on the animations. Reapp has a custom animation mixin designed for React that works through props. It's really cool and I'll be writing a blog post on it this week. It's what drives all the animations you see including the fully interactive "swipe view from edge to go back", as well as modals and popovers. You can see the animations here:
https://github.com/reapp/reapp-ui/blob/master/themes/ios/ani...
Another thing I've spent a lot of time on was getting the view animations to match iOS. Notice how the TitleBar text animates, while the icons remain in the same position. This took quite a bit of effort and resulted in several refactors of the animation library.
Finally, theming. The theme system is quite robust, though the iOS theme itself needs work. It's fully JS-powered CSS, and we use Flexbox for the default theme. It uses two teirs: Constants and Styles. You can override any of our constants or styles to make your own theme, or load an entire new one. I'll also be writing about this more because it's really a big feature. Here's an example of loading a custom theme:
https://github.com/reapp/hacker-news-app/blob/master/app/the...
That folder also contains more interesting usage.
Feel free to ask me any questions you all have, I'm happy to answer.
Also, it seems to be looking for a "http://kitchen.reapp.io/assets/sunrise.jpg" in the drawers demo, which isn't there.
For now I'm going to start doing consulting using Reapp, starting today. So as I go I'll be pushing stuff back to it.
I'm considering funding, I think it would help to really build it out right. Would open it to cool native features, easier build/deploy tools, and focusing on the tech and featureset.
module.exports = { route, routes };
I got an error when I tried to do this:
var a = {1, 2};
What is it setting in that case, since there is no concept of tuples in javascript? It doesn't seem to be an array, dictionary, or function. Appreciate any advice!
module.exports = { route: route, routes: routes };
Makes me a little concerned about what other "common" hybrid bugs you've missed. Is this your first rodeo with Hybrid apps or have you pushed them to production?
Everything else avoid the 300ms delay. We are using react-tappable[0] as a mixin into many of our components that allows a nice onTap={this.handleTap} usage.
It is alpha. For example, I need to fix behavior that allows you to overflow scroll the entire body, which will require some thought and care in it's implementation, but I've already gotten it most the way there. More optimizations will come.
As far as rodeo's it's not my first with hybrid though, I made a large mobile hybrid site in 2u.fm (now deceased, it avoided the 300ms delay though :)), and with my previous employer's site in production quite a bit.
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.
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.
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.
https://groups.google.com/forum/?fromgroups=#!searchin/react...
edit: another good read if you're interested: http://futurice.com/blog/combining-react-flux-and-web-compon...
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.
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.
The problem with your framework,just like jQuery Mobile,SenchaTouch and the rest is that it doesn't look native by a long shot.
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.
How is this going to play with react-native though? My thoughts are it may be a bit late to the party.
I'm happy to see more options available to developers, Ionic looks like a great framework but I won't use it as its built on Angular.
I was actually at React conf and was initially a little deflated because it was announced with a lot of hype about how "hybrid doesn't cut it". But, after talking with FB folks I came away very happy. I think they will complement and gain from each other immensely.
A few notes on Native vs Hybrid:
1. Facebook is a big company with complex apps. They care very much about speed in their experience and can afford three development teams.
2. You can use Reapp today on all platforms, including web. Native is still unreleased. Outside of Facebook no once can use it, and it hasn't shipped any code for Android.
3. Native will feed back into hybrid well! They told me they wrote a much nicer touch library for it that could be ported back to JS, which I'm excited to do.
4. The dev experience with Reapp is still ahead big time. One codebase, hot reloading of components, and lots more, but you really can go from 0 to app in less time than any other way in my opinion.
In fact I think Reapp is a great way to get into React in general. With the CLI you have all the glue for a great React app in place. You can write your mobile website, and deploy to all platforms. Feel free to ask me any questions!
That being said, I can't help but wonder if a bunch of people who clearly have been working very hard were feeling a bit gutted last week when React Native news hit the street.
Hopefully both offerings will find a following.
You may want to reuse UI between platforms for more simple apps, and Reapp lets you do that. Not all apps are fit to be hybrid but some are.
I really think the landing page could be more clear, perhaps there's more backwards people like me.
I personnaly prefer projects like Titanium(or React native), instead of using a webview and styled webpages(that will never feel native), it just uses javascript to call native phone apis,GUI included, so no HTML or CSS that looks like IOS on Android phones,but only native widgets.
I can wrap a simple HTML page with phonegap. Does this make HTML hybrid, too?
Although at it's current stage I feel it doesn't do nearly a good enough job at "looking native", which is one of the best things about the Ionic Framework.
I do remember hearing that Ionic is looking to eventually move towards a framework agnostic approach with its components. In fact, a lot of the library code is already somewhat separated from Angular itself by layers of abstractions.
I personally can't wait for the day when I can use React + Om + ClojureScript with Ionic components. =D
I'll be putting up a comparison in the next week between Ionic/Reapp, but I think it will fare pretty well! Let me know what you think if you have time / see this.
Any other reason you wouldn't use Reapp?
Is there anyway to see your app on your phone, or emulate it, if you don't have a mac?
I'd love to build something like this though to do it more fully.
I like the guys who made TouchstoneJS but for comparison sake, touchstonejs.io shows a list of features. Here are the "unchecked" ones that Reapp currently has (7 out of 9 of them):
Retain scroll position Dynamic headerbar View nesting Partial view transitions Gesture navigation Cross-platform themes Project generator Landscape mode (just about)
Also, I'd say the Gesture navigation and theming support took up 90% of Reapp's development, they were by far the hardest parts. It's what birthed the React animation mixin we use, which is really cool and powers all our animations.
EDIT: It works fine in Chrome with iPhone emulation. What's up on mobile?