How about Windows tablet support?
Android tablets should work. We don't have native iPad support but we're planning on adding it.
A great option for exponent, once it reaches a certain level of maturity, can be a new type of browser.
I wonder why we don't hear that much about them in HN.
Before choosing React Native, we deeply investigated bridging native and JavaScript on our own and one of the ways was a NativeScript-like approach. When React Native was announced we looked at the beta and saw that it exhibited many characteristics we believe are important in a next-gen app framework.
We saw that React Native was designed for multicore phones by dividing work across multiple threads, namely application logic (JS), view and text layout (this is significant), and rendering. Other work like image decoding also runs on a separate thread. One reason React Native's multithreading is fantastic is because hardware manufacturers are adding more cores faster than they are improving the performance of those cores, partly because power consumption grows superlinearly with respect to frequency. The React team is also in the early stages of exploring incremental rendering, which may allow us to parallelize React rendering in JS as well as native.
So far we're happy we chose React Native for Exponent. There's a lot of interest and activity around it and it's on the right track in several ways.
NativeScript has been around longer than React Native (at least for Android), but going by Github activity (not the greatest metric, but not aware of a better one) React Native[1] is much more active than NativeScript[2].
Some differences between Exponent and NativeScript:
- Exponent supports building iOS and Android apps on macOS, Windows, and Linux. With NativeScript you need a Mac to build iOS apps.
- Exponent also allows you to push updates to published apps, while publishing with NativeScript is identical to publishing regular iOS and Android apps.
[1] https://github.com/facebook/react-native [2] https://github.com/NativeScript/NativeScript
Once you get it running despite their poor support for Android CPUs in their native libraries, half the examples and half the dependencies on the web out there crash immediately because they decided you have to import React and Component from "react" instead of "react-native" now. And there's no stack trace at all when it crashes for that error since it crashes before the normal source map functionality that provides them. My company has hundreds of files being used by React Native on iOS, but they are unusable due to this, even hours of search and replace cannot fix it because it is still crashing out, probably due to one of a dozen dependencies. Similarly if you try to use react redux 4 you are screwed, only 3 is supported. Woe be to anyone who upgrades that dependency.
As a Java programmer who is used to compile time errors when something is wrong, React Native where it crashes constantly at runtime due to poor platform decisions like forcing developers to use a different package from earlier versions is a tough pill to swallow.
Part of the allure of writing React Native apps for me is that knowing React would make me a more valuable developer. I'm curious to see how comfortable I feel saying "I know React" after using these IDEs long-term.
I don't think downloading scripting or native code that changes how an app behaves from outside sources has been allowed on the App Store, so what gives?
- Fork the Exponent client and add your native API.
- Try to get a patch into upstream.
- If it's not urgent, ask us if we plan to implement it and if it seems like a common enough use case we would add it to our roadmap.
- Go into the Exponent source and copy whatever native code you need into a new React Native project.
We're also working on a way to "eject" from Exponent similar to the create-react-app eject command but easier to reverse and to keep receiving updates to Exponent, because it's not an "all-in" kind of eject, you can read more about that here: https://blog.getexponent.com/answered-on-slack-ejecting-from... (caveat: this feature is still in early development)
- Pocketgear - a pokedex app: https://getexponent.com/@rncommunity/pocketgear
- A fun little app I've been working on for a few days for an upcoming talk: https://getexponent.com/@community/growler-prowler
- An IP Subnet Calculator: https://getexponent.com/@levic92/ipcalc
- The navigation/routing library that we recommend to be used with Exponent: https://getexponent.com/@community/ex-navigation-example
- A work-in-progress showcase of animations that you can do with React Native / Exponent: https://getexponent.com/@community/animations-showcase
- Shared element transitions are possible too: https://getexponent.com/@janic/shared-elements
- A showcase of some of the components that you can use with Exponent: https://getexponent.com/@notbrent/native-component-list (tap out the ^ icon in the top right)
- "Floaty Plane" - a simple game: http://getexponent.com/@exponent/floatyplane
- An experiment to re-create basic Wunderlist UI: https://getexponent.com/@mastermo/wunderlist
- A pre-launch version of "React Native Playground" in Exponent: https://getexponent.com/@rnplay/rnplay (just sign in as a guest and go to the Explore tab)
- An image gallery example: https://getexponent.com/@community/image-gallery-example
- A Pomodoro app UI: https://getexponent.com/@exponent/pomodoro
- A tab view component demo: http://exp.host/@rncommunity/react-native-tab-view-demos
The largest app on our platform right now is li.st for Android: https://play.google.com/store/apps/details?id=st.li.listapp&...
Here's a video of a talk explaining how the game works: https://www.youtube.com/watch?v=2_KV7Ha_gRk
The game runs on Exponent and uses React Native for rendering (as all Exponent apps do). It uses individual `Image` components for each sprite. This gets choppy when you have a lot of sprites so we're experimenting with more performant ways of rendering for games.
Give it a try! It's pretty solid.
(I work on Exponent)
Edit - brentvatne just answered this: "we handle builds for you when you want to ship to the app store, before that you can just use the Exponent client".
When you're developing you can use Exponent's apps from the App Store/Play Store, so you can get started immediately and let other people test your app easily. Once you're ready to put your app in the stores you start a build using our CLI and we build it on our servers (see https://docs.getexponent.com/versions/latest/guides/building...). We want to make it easy for people on Windows and Linux to build apps so don't require you to use Xcode or Android Studio. If you don't want the builds to happen on our servers our clients are open source so you can do it yourself if you want (https://github.com/exponentjs/exponent).
> We want to make it easy for people on Windows and Linux to build apps
Is there a Linux version of XDE? I can't seem to find it.
(I saw mentioned on the blog you work on: "making it easier to deploy your app to any server and not depend on ours" as well which will be super cool)
We have some plans to allow custom native modules without forking the client but that's probably a few months out. If you join our slack we'll let you know about any updates: https://slack.exponentjs.com/
If there are any problems, they would probably be easy to fix. The thing I'd be most worried about is just that some things might run very slow on the Pi.
The RPi hardware is pretty slow for a development machine. I have mine minimally overclocked but the CPU temperature was coming close to 85 °C and it took minutes for the starter project to initially load (after that, the build is cached). On the other hand if all you have is a Raspberry Pi, then Exponent is one of the few ways you can make iPhone apps.
Ex. Try opening https://getexponent.com/@exponent/floatyplane from your phone.
If you have the source code for the app, just open the project directory in XDE (our desktop software) and it will give you a development URL that you can open in the Simulator or on your phone.
In general, testing Exponent apps is way easier than testing apps other ways. We put a lot of time into making it simple.
Components aside, you can share your models and data stores, utilities like Immutable.js and lodash, and other environment-agnostic JavaScript. In addition to code, you can share a lot of knowledge like how to write components, structure an app, use npm, and even just write JavaScript.
messutied, you're shadowbanned so I can't reply but thank you for your response!
react-native-vector-icons
react-native-sound
react-native-barcodescanner
react-native-camera(2) Exponent is based on React Native which is newer and people seem to like better (search Google for blog posts about experiences using React Native and then search Google for blog posts about using Titanium), though I can't actually compare them personally since I don't know that much about the inner workings of Titanium.
(3) You can do instant app updates with Exponent since the JS is run on the device rather than being cross compiled to native code. I don't think you can do this with Titanium (though I may be wrong -- they've added a lot of features since I last checked on it)
[1] https://docs.getexponent.com/versions/v10.0.0/introduction/i...
Here are the docs for SDK 10 (based on RN 0.33.0): https://docs.getexponent.com/versions/v10.0.0/index.html
And here are the docs for SDK 9 (based on RN 0.31.0): https://docs.getexponent.com/versions/v9.0.0/index.html
You can use either one.
Also, all our stuff is open source, so just go back and find the old release tags on Github if you want older versions.
Sorry I'm new to mobile development...
> if you have native libraries for x86 or arm 64 in your app it immediately breaks it completely
We handle all the native code for you, so you'll never hit this.
> half the examples and half the dependencies on the web out there crash immediately because they decided you have to import React and Component from "react" instead of "react-native" now
We support multiple React Native versions in our client app, so if you target an old version of React Native it'll keep running on that version even when we upgrade.
The redux 3 vs. 4 part is still an issue, but you should only hit it when you're specifically upgrading your app.
How do you handle that exactly?
> half the dependencies on the web out there crash immediately because they decided you have to import React and Component from "react" instead of "react-native" now.
That resonates for anybody who has done serious work with npm packages over the past few years. It seems like horrific breakage is the norm. Package authors break backwards compatibility for the stupidest "improvements."
If the wheel you reinvented is square, you might run into someone who doesn't quite buy into your pitch of this being the future of technology.
As an Android dev, RN is a real head scratcher for me.
I embraced kotlin but I really struggle to find RN's purpose.
One thing I've learned from working with React Native is that you want to stay fairly up to date with the frequent releases. The Exponent team puts a lot of work into upgrading our own dependencies and maintaining the Exponent API that other developers depend on.
Authors of components and other npm packages will update their code to work with the latest version of React Native. It takes energy to stay up to date since you need to read the release notes and breaking changes and sometimes it's helpful to scan the commit history on the release branch. But this way you can use react-redux v4 and other actively developed dependencies.
On the other hand, though, sometimes component authors don't maintain their projects or support one platform but not the other. When dependencies fall out of date there isn't an easy answer. In the past I've fixed the issues myself and sent pull requests. Showing financial support is also another approach; my teammate Brent wrote a post about this: https://blog.getexponent.com/putting-your-money-where-your-p.... The maintenance of open-source libraries isn't unique to React Native but it's perhaps exacerbated by its cross-platform nature and frequent release cycle.
For the issue about CPU ABIs, I believe React Native supports armeabi-v7a and x86 but not arm64-v8a or x64. It would be great to have native arm64 support but so far no one has needed it enough to implement it instead of using ndk.abiFilters. For what it's worth, this works for Exponent and several other companies with apps that use React Native like Facebook.
With Exponent you generally write your entire app in JavaScript. We've found that you can build quite a large set of comprehensive apps with pure JS and the APIs that Exponent provides (https://docs.getexponent.com/versions/latest/sdk/index.html). We believe that set of apps will quickly grow as Exponent's API grows. Exponent is open-source, though, so if you needed to you could fork it and write your own native code in which case you might need to think about CPU ABIs. But most people developing on Exponent don't need to think about native code or ABIs at all.
We also stay on top of React Native's changelog and make sure our APIs keep working when React Native changes. Some of your other third-party dependencies might fall out-of-date but the Exponent API stays current. Also with Exponent there aren't any Xcode or Android Studio workspaces to keep up-to-date.
Static type systems for JS like Flow are getting better over time and if enough people use it (or contribute type definitions to https://github.com/flowtype/flow-typed) more of these runtime errors will become compile-time ones. Parts of the JS ecosystem do move quickly, though, largely because of the proliferation of npm.
Calling shenanigans given that redux 4 is completely supported and has been supported for a while. Was this many months ago?
I honestly struggle to find the problem addressed by RN, at least if you already know java.
Exponent exposes all of the React Native built-in APIs which encompass a lot of what you're asking about.
For example, here is the Clipboard API: https://facebook.github.io/react-native/docs/clipboard.html
Wifi network configuration is more complicated, but there are some things exposed like "NetInfo" which lets you know the current state of connectivity. https://facebook.github.io/react-native/docs/netinfo.html
The complete React Native docs are here: https://facebook.github.io/react-native/ and Exponent specific docs are here: http://docs.getexponent.com/
For now, Exponent just lets you write things that only use JS, and we make that easy and reliable and straightforward. We actually think this is the best way to write most apps that can be built this way since the code is easier to maintain and works cross platform, and you can do things like instant updates much more reliably when all your code is JS.
We're looking at a way you can write Java/Swift/Obj-C extensions for Exponent, but that will take us some time.
With Exponent you write just JavaScript. In addition to most of the APIs that come with React Native, Exponent provides several APIs (https://docs.getexponent.com/versions/latest/sdk/index.html) and we're steadily adding more. If there's a native API we don't have yet that developers need, they tell us about it and we add it to our roadmap.
Exponent is open-source, too, so if you needed to you could fork it and write your own native code or make a raw React Native app. We recommend writing pure JS apps if you can, though. At Exponent we write native code so other people don't have to.
We intentionally chose to not let users drop down to native -- the idea of having an interpreted language that sits on top of a native runtime on multiple platforms is not a new one, and it allows for so many benefits that you lose out on if developers can add arbitrary compiled code with direct access to system APIs.
Additionally, there is a significant value-add of using Exponent in terms of upgrades. As great as React Native is, it also moves extremely fast and it can be difficult to keep up with new releases -- a change in React Native might cause several of your native dependencies to break, and you'll need to fork those libraries and fix them if the maintainer isn't keeping on the same schedule as you. Updates with Exponent are as simple as updating JavaScript, which has much less churn and breaking changes than the native side (the React API itself is very mature, the APIs for specific native components may change).
Another nice advantage of this is that you can work on an iOS app from Windows and Linux, because you don't need to compile your app with Xcode (we handle builds for you when you want to ship to the app store, before that you can just use the Exponent client).
We ship with a bunch of APIs out of the box and are constantly improving them and adding more. We have analytics tools like Amplitude and Segment built in, Maps, Facebook login (working on Google Login), and more: https://docs.getexponent.com/versions/latest/index.html
React Native is still very early, though, and Exponent is just a small team of seven, so we understand that we can't possibly expose every API that developers working with the platform might want. So, we are working on a way for developers to be able to still take advantage of the Exponent toolchain and layer on native code. I've written up our approach in more detail here: https://blog.getexponent.com/answered-on-slack-ejecting-from...
Sounds like at the end of the day it comes down to Exponent being committed to the user never having to build their own app. I can see that being interesting a to a single dev, or a small app or someone new to mobile development, but to be honest I don't think I could justify using Exponent at a company. On any reasonably experienced team of developers, building an app when native components change or distributing it with something like hockeyapp is not very difficult, so I just wouldn't trade the flexibility of being able to do tricky parts directly in native code for not having to build the app.
Exponent maintains native modules so they continue to work when React Native changes or when Android & iOS change their APIs. In particular, React Native is released every two weeks and we stay on top of the changelog so you don't have to regarding native modules. We also write native code for both platforms in tandem, often by the same engineer, so that we get coherent APIs that cover common features across both platforms and expose platform-specific capabilities neatly. We want Exponent to feel like a coherent project. All of the docs (and code) for Exponent's modules are in one place, and when you download the Exponent app for development you get all of the native modules right off the bat.
As a data point, the Android version of Li.st (https://play.google.com/store/apps/details?id=st.li.listapp) is built on Exponent and was featured by Google in the Play Store. Li.st is currently one of the best examples of how far you can go with Exponent, and React Native for that matter. We're also on Slack (get an invite here: https://slack.getexponent.com) if you want to chat in real time.
From the FAQ (https://docs.getexponent.com/versions/v10.0.0/introduction/f...):
"But no native modules...
The most limiting thing about Exponent is that you can't add in your own native modules. We give you most of the most commonly desired things, but if you need something very custom--like on-the-fly video processing or low level control over the Bluetooth radio to do a firmware update--then Exponent won't work for you and you should just use regular React Native."
It's pretty useful too if you have a drop-in replacement for another library. Heck with JSPM, you can even scope module resolution per module... so you can say module A should resolve to B but only within the context of an import from module C, everything else gets the normal resolution.