The Realms polyfill is a polyfill for an actual TC39 JS proposal [0]. It's currently at stage 2. If the proposal gets accepted, you will not need the polyfill. This would also work with any JS embedding (browsers, node, etc...) as it would be baked in the language.
Honestly you should not use a React boilerplate of any kind as of today. We got pretty decent alternatives today in order to avoid using that kind of stuff:
- You're just getting started with React? Use CRA[1], it is enough for most of the use cases people will ever need use React with. You may also want to consider Next.js[2] if you are looking to do a more website-like app using React components but that's all...
- You know how to setup js tooling (webpack, babel, react-router, redux, ...)? You may still want to use CRA because it is way easier to use anyway. But this time you know you can either eject to more fine-grained tooling tuning or do your thing independently if you want.
If you use a boilerplate at that point, that's because you understand the tooling behind it and CRA won't answer to the precise need covered in this boilerplate. Also you should be able to maintain it and make it evolve later (the more dependencies, the harder it will be...). So in that case, if you master all of those tools (can't say I do) and integrate them often with django, then maybe, this boilerplate could be for you...
In conclusion, this covers a very special need and I don't understand how this got on top of HN... It actually makes the React community look kind of bad (assuming some people upvote when they see React stuff, which I don't think is the case) because this does not seem to solve any of the problems people outside of the community are complaining about. So, if you are looking for an easy way to use React (that won't prevent you from plugging it to your django backend btw), just use CRA!
Disclaimer: I'm a contributor to Apollo [0], an alternative client to Relay.
This is a great initiative! I remember struggling to learn Relay, I love it though, used it in some toy apps and will use it in some upcoming projects that I have. However I have a few issues with Relay: the main one is that it overall discourages people from starting with GraphQL. From creating a Relay-compliant GraphQL server to adding it to your app, Relay forces you to good conventions that, unfortunately, requires you to learn about its concepts and makes it super difficult to ramp up fast.
For anyone interested in working with Relay and GraphQL in general, I would advise you to start first with just learning GraphQL, without Relay and its constraints. You'll see that much of the issues you may have with GraphQL may come from actually trying to comply to Relay. Once you are okay with GraphQL, then, you can move to learning Relay.
Finally, I want to insist on the fact that GraphQL is just a specified language that can be consumed by any client you need/want. Relay is made by Facebook, for Facebook, which is a cool thing but may be a bit too much for your simple app or may not be adapted if you are migrating a legacy app to GraphQL (which was my case). That's why you should take a look to alternative clients as well (Apollo [0] for instance ;-) )!
Thanks Robin! I've love what you guys are doing at Apollo! I've just answered a similar question below, so I'll just copy the most important bits here as well:
One important thing to note here, is that Relay and Apollo are taking different approaches. Relay provides a great framework which works excellent for a lot of use cases and provides the most convenient and robust solution for that. In some cases you want to "break out" of that framework and be more in control how data is fetched or mutated. In that case Apollo is a fantastic choice as well. Especially in combination with Redux.
Fun fact: We're actually using both - Relay AND Apollo - in our dashboard at Graphcool. Feel free to take a look at the source here: https://github.com/graphcool/dashboard
On a side note: We're already working on a similar project but focussed on Apollo. If you're interested in getting involved, we're still looking for collaborators: https://github.com/learnapollo
Your dashboard seems like an interesting approach for taking the best of both worlds!
learnapollo seems awesome too! I think that Apollo would benefit from this kind of documentation. You should definitely come and send a link on the Apollo's slack!
In general Graphcool is a great idea if you want to start fast with GraphQL (with any client).
You should start with React, honestly. Learning React is a bit about learning the framework but in order to be a good react dev, you mainly need to know how to write some good JS. React views are not templates, they are just javascript function calls (JSX is just some sugar on top of some JS function calls).
After that you can basically try anything, but at least you will know pretty much everything about what modern JS has to offer!
I would recommend starting with create react app [1]. I think it can be used with other libs than react as well, the thing is just a strong webpack + eslint preconfiguration so you don't have to worry about it.
I second it. If you are starting out, React is the way to go. Of all the frameworks I have tried, React is the one that seems most "sane" to me. Either React or Elm.
Both systems are really great, however, when adding typechecking into an existing codebase, flow does offer more flexibility thanks to weak checking and annotation comments. You can really progressively add typechecking by just dropping the tool in the codebase. Also, if you subscribe to Facebook's tooling (Nuclide especially), you will end up with great tools (jump to def, integrated checking, ...). However if you just start the project and you use VSCode, TS seems to be a strongest choice. Depends on what you do, but both tools are great, whatever you choose, typechecking is worth in javascript if you need more reliability and maintainability.
I actually found the opposite was true in our project - TypeScript was easier to add into the code than Flow. The biggest reason for this was that Flow demands null/undefined checking and null was used extensively throughout this code base. With TypeScript, on the other hand, the changes to make it work initially amounted to sprinkling a few "any" notations and making some explicit object interfaces at various points.
The first snippet uses the CommonJS [1] standard (a way to import packages into a JS file that is used by Node, webpack or browserify for example).
The second snippet uses ES6 modules [2]. Babel actually transpiles those ES6 modules into CommonJS modules when used in a Node.js environment (which is the case with a build tool).
Since even IO.js doesn't support ES6 modules for now and you're likely to use a build tool in order to use babel, you shouldn't use ES6 modules in a build file.
This is a nice, complete and well-documented review of why Clojure is not made for Android.
I disagree with the conclusion though: yeah, the classic JVM-clojure seems doomed on Android. Why ? It's not made for that, it's made for servers, it's not even used for desktop GUI programming that much. Even if we beat the startup time, it's not likely that we'll get nice UI-bindings for Android before a long time (I like the Java-interop but writing serious Android apps with the interop alone seems awful to me) and yes, there are some libraries abstracting this a little bit such as neko [1] but it's still too close to the Java-development paradigms (it's not as clojure-ish as I wish, but that's my opinon!).
So, the conclusion: no we don't need a swift for Android, and clojure is not swift anyway.
iOS already has clojure support, it's not really stable but it has decent startup times and a nice API. It's not the JVM-clojure, it's clojurescript. The UI is managed by React Native and om. It works and you get a nice REPL running too. [2] No it's not finished and has lots of bugs and it's not even publishable on the AppStore for now but it's just a matter of weeks here before addressing those problems (you can follow the work of David Nolen & Mark Fikes on this particularly, they often communicate on what they're doing but there are other awesome people working on this too!)
So for Android ? ReactNative is coming too [3]. When it's there, the community will try the same thing as what they did on iOS, and it's likely to succeed too. The community behind cljs is growing and it's becoming the main clojure implementation for ui-related stuff. You can thank React and om for that but I think that core.async has a lot to do with it too.
Anyway, I don't want to stop believing in Clojure for mobile development.
Kotlin also looks like the most serious contender to me.
Sure, something like Rust might be more interesting for various reasons, but the engineering effort needed to port the Android framework to another language would be huge (and the official word from the Android framework team is that it is not worth the effort). Not to mention that third party developers would have to relearn the framework from scratch and that we either have a windows mobile 6 / WP7 rift or the framework team has another nightmarish problem to solve.
Kotlin looks like it could both guarantee retro-compatibility with Dalvik and brings a better language to the platform.
Totally agree with you! Kotlin is great replacement for Java on Android. I like to see that more and more interesting libraries appear for Kotlin, like Anko. I recently made Anvil compatible with Kotlin (http://zserge.com/blog/anvil-kotlin.html), which makes UI development a pleasure
1. Clojure is a general purpose programming language. Just because it isn't used much for desktop GUIs doesn't mean it's not usable for that. What percentage of Java/Scala development is used for GUIs?
2. Clojure in iOS isn't just available via ClojureScript. There is also RoboVM, though it doesn't support REPL-driven development, if I understand it correctly.
3. I am very interested in what React Native can do. For me, the key questions about using it are: Can you create applications that fit will into the UX idioms of the host platform? What happens when something goes wrong? Do the various levels of indirection make debugging much more difficult? Do you still have access to the full platform? If not, then only certain classes of applications can be implemented using React Native.
Very highly unlikely. With the NDK, you lose 99.9% of the framework. Any replacement language for Android needs to interface with Android's java framework or it will be completely useless.
Last time I checked, pure NDK apps are best for games that use OpenGL as their primary interface. If you want native controls, you can't really do that entirely from the NDK side.
So far I have endured the NDK because I cared more about playing around with graphics between Android and WP on my hobby coding.
Something like Qt allows for native like controls, but one is loosing the functionality the platforms offer for free, as well as, increasing the APK size considerably. And JNI wrappers are still required for interacting with the OS for intents and such.
From the JVM languages Clojure would be a good candidate for staying in Android user space and also allow targeting iOS (RoboVM) and WP (Clojure-CLR), specially with the help of the upcoming reader conditionals.
But with this performance, Xtend, Kotlin and Scala appear to be better candidates if one is just focusing on Android.
It is certainly doable. I haven't done it myself, but I know of people who have done it successfully on Android.
Unfortunately, I don't think Phonegap is a very good solution. Depending on your application, it may be good enough, but it's overall not as good as true native development.
It is not. Not as a general purpose solution anyway.
Phonegap can be useful in order to quickly publish a very simple application on both platforms.
Outside of that, its disadvantages pile up VERY quickly.
[0]: https://github.com/tc39/proposal-realms