I have yet to find a reason to support iOS hot reloading in this context to be perfectly honest. I use the desktop bytecode hot reloading (implemented inside Reprocessing so everyone can benefit from it), and it works wonderfully well. It's faster than anything you've seen before. And given that you probably want to be coding in Reason and not objc, it doesn't really matter what your render target is while you're iterating and being creative.
I'm all ears if you can think of something though.
We are actively working on it. Linux's well on its way and is much easier than windows. We're open to PRs ;)
We consolidated web and native desktop in one repo https://github.com/bsansouci/reasongl. iOS and android are still out because we're still figuring how everything should fit together to be useful.
I saw an issue or thread somewhere about the technical problems of supporting Closure Advanced in Bucklescript. I'm surprised they were solved at one point then regressed. What would be the reason for removing it, unless maybe it was easier to implement new features by no longer supporting it?
Closure Advanced has many benefits so it's really nice to support it, especially if you're writing a whole site app of decent size all in one codebase.
Thanks for taking the time to answer everyone's questions!
Do you simply use Nodejs to do the SSR? I've seen some complaints about the difficulty of scaling node to run well in a cluster, and about security things. Have you had to deal with that?
I'd honestly love to see what you did there. People use Java for the reason that all of those questions have decent answers by now.
Nice work! I really like the idea that the web allows anyone to programmatically dig into the UI and extract data to do things. A friend and I actually made a whole API to interact with FB chat. You should check it out: https://github.com/Schmavery/facebook-chat-api. I'd really love to see what you can come up with, with some of the stuff we support.
I think you forgot something that is very important to React: your component is a pure function that takes props and states and that outputs UI. Being able to make the assumption that given the same props and state, you'll get the exact same UI (to the cursor position), is extremely powerful. As a programmer your brain can focus on other things and forget about side nasty effects.
In React your component is a class. The `render` function is a pure function, but the component itself is a state machine. This is why I prefer Mercury[1]
True. No more spaghetti ball-of-mud. I'm waiting for IntelliJ to release `Extract custom render method` and `Extract React Component` refactors in their IDEs.
It's instant feedback. You should try making an app with animations. You leave the animation looping and you modify your constants and you don't have to reload or do anything, ReactHotLoader will plug in your new code without losing the state of the app.
You get much faster prototyping, collaborative tools out of the box and even a debugger with a timeline out of the box (you just have to save your state at every change and have a little scrollbar to scroll through your states). This is very very powerful.
My opinion on "the web will persist and the web will win" is that it's not a won battle. Native apps have always been smoother, giving users a better experience overall. On the contrary, mobile web apps have been bad, and haven't much evolved since we started having mobile devices (laptops don't count :p). I'm pretty sure that the future resides in mobile devices, and they can't rub the web, we'll have to use the alternative: native. At that point nothing stops Apple or facebook to go entirely native and therefore abandoning the web ideology (and the physical web). So I think that the web is a possible future, but nothing is settled yet, we need more groundbreaking ideas from the web to make it a desirable choice of future.
I think there are too many smart and capable developers in the world to settle on old poorly-upgradable languages for everything. So hopefully there will always be a choice.
