▲ 139 points
back
46 comments
Hey hackers, Nate with Reapp here. I'll add some technical background. This has been a solo project of mine for the last five months. I actually was relatively green to npm and React in general at the beginning, but I've been working on this full-time since. I think it's a great testament to React's power and ease of understanding.
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.
Although everyone is going to jump on the React Native bandwagon, there's good reasons not to. It's not like every write-once framework is going to go away. How far do you think you are from a components library that can compete in breadth and maturity with Ionic and do you think you'll go down the path of what Supersonic is doing with Ionic, but with React (the semi-native components/transitions/views aspect)? The answer probably lies in whether you're starting with an incubator like Drifty did or going to rely on community support. I think there's enough people out there that don't like Angular, but aren't ready for the commitment of a React Native project.
Also, it seems to be looking for a "http://kitchen.reapp.io/assets/sunrise.jpg" in the drawers demo, which isn't there.
![http://kitchen.reapp.io/assets/sunrise.jpg"](http://kitchen.reapp.io/assets/sunrise.jpg"){kind=link}
Thanks. As per ionic: give it a few months, but I think it's already gotten pretty far. I tried to throw as much in as I could while still launching within a reasonable time. I've had a ton on my plate between the launch site, docs, apps, platform, cli, etc.
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.
Fantastic work! It is exciting to see a project like this take off. I'm trying to dive in right now, and I noticed something interesting. Pardon my ignorance, but can you explain what this is?
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!
It's ES6 shorthand literal syntax [1], equivalent to:
module.exports = { route: route, routes: routes };
That explains a lot. Thank you!
It feels like you are using click for touch events. Which causes a ~300ms delay only on mobile phones.
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?
There's a bug on the hamburger menu that's actually not the 300ms delay but seems like it.
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.
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.
>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.
> 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.
It appears to me that you are misinformed, React plays just fine with Web Components.
https://groups.google.com/forum/?fromgroups=#!searchin/react...
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 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-compon...
> 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.
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.
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.
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.
At first glance it looks nice. I played around with Ionic Framework and if Reapp is going in a similar direction and gets enough traction I can imagine using it in the future. Let's see what React Native brings to the table.
I'm really interested in this and am keen to try it out at the weekend!
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.
Hey guys, developer of Reapp here. Excited to see this on here this morning!
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!
Indeed - right now I'm super excited at how much activity there is in JS-land. It's a lovely time to be a JS hacker. :-)
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.
It's a slightly different niche than React Native.
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 feel so totally out of the loop when I don't even understand what it is a hybrid of?!
I really think the landing page could be more clear, perhaps there's more backwards people like me.
Hybrid in this instance means HTML wrapped in an iOS wrapper ala Phonegap.
So why doesn't the website say anything about the part of wrapping it for Android/iOS? I'm just as confused as unwind.
I guess they expect you to know what it means. Granted the site isn't very good at explaining clearly what the product is. Just a lot of buzzwords here and there.
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.
To run a webapp inside a native app, wrap it in a web view. What gets you confused?
It's supposed to help me build hybrid apps. But from what I can see, it only helps me build web apps. So I still don't see what is hybrid about this.
I can wrap a simple HTML page with phonegap. Does this make HTML hybrid, too?
No but it makes phonegap 'hybrid'. I think that's the point.
Looks interesting.
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
By the way, I've updated the main site with the non-themed iOS style. Also added a Mailbox demo.
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.
I think the themed title bar throws people off. The default iOS theme is much closer to looking like Native, and the rest of the components are very close. I'll be moving to push it as close to native as possible?
Any other reason you wouldn't use Reapp?
I just started playing with Steroids.js from Appgyver. Their Scanner app lets you demo your app on your phone as you go, which is a big plus. However, it uses Angular all over the place, which I'm not a huge fan of.
Is there anyway to see your app on your phone, or emulate it, if you don't have a mac?
You can use Frameless for UI: http://stakes.github.io/Frameless/, or pin it to your homescreen.
I'd love to build something like this though to do it more fully.
The only problem with these is that they never have good support for device features (GPS, NFC, Bluetooth, MMS, etc.). If you just need to build a static app that doesn't need any kind of mobile device feature, just build a web app.
I agree. But thats a good thing if it's the only problem, in my eyes. I'd love to get funding to help further bridge the gap. Unfortunately, the browser creators on mobile all have incentive to keep their browsers limited compared to apps.
It has nothing to do with them having an incentive and everything to do with security.
The iOS WKWebView situation (delayed, bugged, delayed again, de-perfed) shows theres definitely not a strong incentive to even match performance.
Your HN app is nice but: when I tick the current top link it opens the app again, in a new tab (mobile ff). Also there is no favicon which does not help recognition in a long list of favorites in a desktop folder on Android.
Just want to mention a similar project http://touchstonejs.io/ haven't tried it yet
I've checked out quickly both Reapp and Touchstone. At the moment Reapp seems more mature: has better tooling (e.g. the command line tool to generate projects), uses Webpack, has quite big UI kit, etc...
When you say Reapp seems more mature, what do you mean? It seems like Touchstone has been around longer. (Touchstone's Github repo has 1,469 followers and first commit was October 14th, 2014 vs. 200 followers and December 19th, 2014 for Reapp.)
Maturity !== Github stars
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.
I can't view this website on my phone. I can only surmise that I am not worthy.
It's a very early alpha version. It's not a commercial product. I think the makers were too busy preparing the software that we can excuse non-mobile-readiness of the landing page.
EDIT: It works fine in Chrome with iPhone emulation. What's up on mobile?
I checked on mobile with Safari/Chrome. Send me more info if you can! natewienert@gmail