Also been a happy user since their very early days.
I do have some nits though:
- It's kind of finicky on Android, especially with exit nodes enabled. Sometimes I lose connectivity completely after connecting to an exit node, until I flip my WiFi on and off, then everything starts working.
- Not being able to auto-update the desktop clients, or at least update remotely, is a bit of a pain, and potentially a security risk?
I skipped the last few generations of Nintendo hardware, but there are a few 3DS and Wii U games that I still really want to try. If Switch is backwards compatible with Wii U and 3DS then it's an instant buy for me.
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.
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.
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.
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.
Speaking as a web developer, this is sad, but true.
However, what's even sadder to me is the fact this continues to be true despite the fact that, believe it or not, the web has been the platform where most of the innovation in UI development paradigms has been taking place in the past few years. And I don't just mean in terms of the sheer number of new things coming out.
The web community pioneered UI development paradigms involving functional programming techniques and immutable data, and have brought its benefits to other platforms (through projects like React Native). I personally would never want to go back to the old way of building UIs. And I suspect I'll feel the same way about client-centric data fetching when I get to try out Relay/GraphQL, Falcor, Om Next, etc in production.
I really want Firefox OS to be successful for this exact reason. I don't want to have to make compromises between the best experience for my users and the best experience for myself as a developer. With a platform that makes web the native UI technology, we shouldn't have to make this compromise in theory, but Firefox OS's execution thus far has left much to be desired.
Not sure how common it is, but I've worked on a few Cordova apps and have no native experience whatsoever.
I have ran into some roadblocks that required stepping into native development to fix up issues with Cordova Plugins (specifically for background operation), but I suspect that won't be necessary for a large majority of apps out there.
Personally, I find the Hosted Web App spec a very promising alternative to Cordova for app development with web technologies. You simply use the open web APIs (notifications, geolocation, camera, etc) for features that would normally require messing with plugins in Cordova, and they would just work.
It's such a shame that the biggest players (Android and iOS) probably have no plans to support it natively since it would greatly reduce developer lock-in. In the meantime, the ManifoldJS project can provide Cordova-based polyfills for your Hosted Web App, but then you'd have to resort to messing with plugins all over again for the only two mobile platforms that really matter...
I do have some nits though:
- It's kind of finicky on Android, especially with exit nodes enabled. Sometimes I lose connectivity completely after connecting to an exit node, until I flip my WiFi on and off, then everything starts working.
- Not being able to auto-update the desktop clients, or at least update remotely, is a bit of a pain, and potentially a security risk?