I was mostly referring to development paradigms and methodology in my original post, but in terms of tooling, I personally haven't see any tooling on the native side even approach the increased productivity provided by the instantaneous feedback loops that countless hot-reload implementations can offer for the web.

https://github.com/gaearon/babel-plugin-react-transform/

http://gaearon.github.io/react-hot-loader/

https://github.com/bhauman/lein-figwheel

Android has JRebel for Android for hot reloads...

https://zeroturnaround.com/software/jrebel-for-android/

I was not aware of this, so thanks for bringing it up.

It's a pretty amazing technical feat that this works at all, but I have a hard time imagining this would work well in practice for changes to anything other than maybe method bodies and templates though. Java's style of object orientation generally means there's plenty of tight-coupling between application state and operations on the application state, which would probably make life very difficult for any hot-reload implementation.

But regardless, it does exist and apparently works well for a lot of people. It looks like I was just ignorant when it comes to native tooling.

Its definitely hard, but JRebel has had 7 years to figure this stuff out and so far seems to work just as well on Android.

Only one way to find out tho :) Trying it out for oneself.

I've done similar with inotify (dnotify before that) and Python now for over a decade, and it is an interface than can automate anything. I use it with doc generators also.

I believe I used something similar called fam in the 90's but that may have only been on SGI.

Filesystem watching is only part of the equation though. Live reload has been available for the web and various other platforms for a long time, but the traditional approach to live reloading does not preserve application state.

These new hot reload implementation allows your app to be reloaded with your new changes without affecting the state of the application, and is not practical unless your application has been developed with a focus on functional techniques and careful management of application state.

This probably doesn't sound like a significant difference, but in practice, it is a huge boost to productivity, especially in a non-trivial app where reloading the entire app and then reproducing the app state manually with every file change can become quite tedious.

That's why Common Lisp / CLOS has functionality like

  * CHANGE-CLASS (change the class of an object to a different class),
  * update-instance-for-different-class (updating the object after a class change, one can provide methods which will be lazily called when needed),
  * update-instance-for-redefined-class (updating the object after redefining a class, one can provide methods which will be lazily called when needed),
  * LOAD (load source or machine code),
  * EVAL (eval expressions)
  * COMPILE (compile code in memory to memory), ...

One then always develops with a live application. Classes and objects can be updated in-place...

Which can be really cool, but has its downsides:

Hey cool, I can change these classes live!

Let's solve this tricky problem by changing the class at runtime. Cool, it works, now on to the next problem.

2 years later...

What's causing this super-weird bug? It's like the code isn't doing what it says at all.

1 week of debugging and head-banging later...

Oooh, something got screwed up in that runtime class change code. Fixed.

2 years later, repeat...

Is that something you've experienced?

Not directly, mostly because I haven't done that much work in any language where you can do that. But I have had that kind of experience when trying to figure out what Ruby code is actually being run somewhere. I may be heading that way with C#, with the occasional overuse of dynamic and reflection.

Sounds neat, I do love a rapid feedback loop, although I may have done similar with a debugger and the reload built-in come to think of it.

In the types of apps I think we're talking about, typically most state is in the database and not much is going on in the client.

You mean like development with Smalltalk and commercial Common Lisp environments?

Or designing GUIs WYSIWYG with Delphi, XAML with Blend, the UNIX 4GL in the 90?

Yes, Smalltalk and Common Lisp environments probably did offer similar experiences.

Tooling for web development has probably been heavily inspired by the tooling available for CL and Smalltalk, but I don't think it's fair to say it's still playing catch up. The tooling ecosystem for the web has long since caught up to the best native ever had to offer, and is now advancing the state of the art faster than any other tooling ecosystem out there today.