robinricard's comments

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.

[0]: https://github.com/tc39/proposal-realms

You can already find a package wrapping the ocaml-language-server. I tried it and it works well with reason: https://atom.io/packages/ide-reason.

You should also install language-reason and reason-refmt alongside it.

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!

[1]: https://github.com/facebookincubator/create-react-app [2]: https://github.com/zeit/next.js/

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).

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 ;-) )!

[0] http://dev.apollodata.com/

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.

[1]: https://github.com/facebookincubator/create-react-app

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.

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.

[1]: http://www.commonjs.org/ [2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Hi! I'm Robin, an engineer at Anyfetch. Ask us anything. We're pre-launching the product and we would like some HN feedback!

Repost https://news.ycombinator.com/item?id=4435547

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.

[1]: https://github.com/clojure-android/neko [2]: https://github.com/omcljs/ambly/wiki/Driving-React-Native-wi... [3]: https://facebook.github.io/react/blog/#when-is-react-native-...

Hi HN !

I wanted to submit that to you because I think it is currently completely useless (It could be more of an API draft in fact).

I just wanted to create a mechanism to enforce immutability in the whole flux architecture. If I manage to get more safety, I'm sure it can get more useful. For now I just want to know if you would use it...

Combining Promises+ES6 Generators seems the next way to go. It is already used successfully in many Firefox tests and the syntax just feels great. For the Node.js ecosystem, you should take a look at IO.js [1], Koa [2] and co [3] that are able to handle nice async syntaxes.

[1]: https://iojs.org/ [2]: http://koajs.com/ [3]: https://github.com/tj/co

- First he makes the point that mobile has taken over desktop very fast.

- Then he explains we are not as experienced in mobile (here for 6 years) than in desktop as we know it (here for 29 years). Worst, the tool we still use mostly is the desktop (as developers/designers/...)

- So we have to learn this "new" mobile thing und UNLEARN what we know about desktop. That's his main point

- Then he explains the different attempts to fit a desktop website inside mobile

  * The "Big List" that you need to scroll endlessly to navigate

  * The "Hamburger" menu that people don't understand (A/B testing showed huge drops in usage with them)

    > Tabs are still better and understandable (facebook came back to it)

    > Don't hide important information and/or actions => you have to understand what's important for your users

    > best pattern: contextual important information for each activity of your app, the rest is hidden behind a menu button emphasized as a button

- After that he gives examples:

  * Reduce the amount of input in forms

  * HotelTonight (just 5 hotels nearby w/ good price) vs Hotels.com (awful search, stars rating ...)

  * Yelp's mobile app that don't support writing reviews vs. HotelTonight that can easily be added by just taking pictures

- Then, he explains how he works better in the startup culture

  * It's not about moving fast, it's about learning fast

  * Don't release and walk away (feedback loop: release, refine, get feedback)

  * Work with APIs and get your logic inside it

First of all they're not the same thing. Coffeescript transpiles to JS (ES3 or 4 if I remember well) and ES6 is a new standard (not finished yet). Maybe one day coffee may compile to ES6 (but that's not likely since that would break support with older browsers). As said before, ES6 may reduce the need of transpiled languages but won't replace them. From my point of view, ES6 will never replace ClojureScript nor TypeScript (ES6 doesn't bring the power of a LISP like clojure or the type system of TS). As for coffee, many people may still prefer its more lightweight syntax that ES6 does not intend to replace either.

Let's say that ES6 will provide a better runtime that may make transpiled languages less useful. Yes, ES6 does arrow functions and classes but it also provides many more cool stuff that the transpiled languages may never support such as generators if they intend to keep backward compat to older browsers. If you are in this case you should bet on ES6. If you don't care and are happy with what's included in coffee, use coffee ! You can always compile it to JS and continue your project with ES6 !

To sum up, transpiled languages are not dead and are still way more flexible than vanilla JS (as they don't depend on a big specification such as the ES specs) but ES6 does improve the runtime, and one day transpiled languages may use this new runtime.

Previous HN thread: https://news.ycombinator.com/item?id=4435547

For all of the issues I have been facing, most of them were actually triggered by virtualbox. Those issues can be quite annoying but can be solved quite easily if you don't have other VB VMs. Usually, resetting the vbox subnets (I had major issues with those) does the job. On the other side, Vagrant has got some minor issues but let's face it: doing what Vagrant does manually is huge and I prefer composing with those issues than being on my own. When VB works well and don't cause any problem, you can do quite complex setups with Vagrant. I already created a swarm of 5 VMs on my machine to test my deployments locally: Vagrant may not be imperatively useful for developers but I think it's essential for everyone working on deployment and having the devs using it too can greatly improve the life of those deploying the apps. One last point: Vagrant is not made for production and I think Hashicorp has been pretty clear on that. I never tested packer/terraform or consul so I won't say anything on the production-side of what they're doing but I won't judge it until I actually used it. Vagrant may have evolved since the last time you used it, you should give it another chance !

I use it to set user access to my company's servers with ansible automatically. I just have to set a list of github usernames and it generates a list of users with their ssh key access setup !

boxen looked nice to me, but I really wanted to avoid puppet (even if I never tried, it's often compared to chef and I have lots of bad experiences with chef !)

I looked into battleschool. The way it overally works seems better (having it's own command and a simple config with just a dotfile) but I really like ansible roles and I really enjoy using brew and brew cask to install everything, it's more neat and more undoable than using a pkg command directly. For now, I don't know which design I'll choose but I still like using the ansible-playbook command. I don't want to hide the internal mechanics of my tool. Ansible is great ! I still want to use it !