undefined | Better HN

0 pointsmike_hearn11y ago0 comments

An alternative direction to head is back to the future: take the web for what it is and try to simplify AJAX interaction, rather than relearn all the hard lessons of client/server programming from the 80's, but in a hobbled browser sandbox.

For an even more retro approach, perhaps some things are just better written as desktop apps. I know they're out of vogue at the moment, but I've been having good experiences with writing a JavaFX app lately. Particular points to note:

* I wrote my own online updates engine, that can be used to implement Chrome/Web style silent background updates, but which can also give control to the user over which version of the app they use. Users can downgrade at any time if a new version is buggy or just not as good as the previous version. It's very small, simple and easily integrated. It supports threshold signed updates so it's also suitable for high security apps where a hacked web server could be critical. It's called UpdateFX, check it out.

* JavaFX has a tool that creates native, bundled installers on each platform (dmg, exe/msi and deb). The user does not have to install JVMs or get any Ask Toolbar crap on their system. You remain in total control over JRE upgrades.

* UI is specified with an XML dialect called FXML, it's quite intuitive and anyone who knows HTML can pick it up quickly. But there's also (unlike with the web) a competent visual designer. You can style UI with a dialect of CSS and it's very easy to match the Twitter bootstrap look, native looks can be done too.

* Data binding is easy, the UI is OpenGL/Direct3D hardware accelerated, you can trivially apply effects like drop shadows or blurs and animate them, the API is clean, the entire framework is open source and the developers are responsive.

* Because it's not a web app, support for offline or flaky internet connections is second nature.

If your users can tolerate the initial download then it's a much more pleasant and robust development experience. If your users are the type who can't wait, you might want to stick with the web.

0 comments

5 comments · 2 top-level

carsongross11y ago· 2 in thread

Totally agree.

I will say, a well done client/server app is much more difficult to implement robustly than a web app. And, horror of horrors, users usually expect you to implement... undo!

mike_hearnOP11y ago

What makes you say it's harder to implement robustly?

Yes people have higher expectations from native apps, it's true.

carsongross11y ago

Higher expectations are the major issue: undo being the canonical example. The general problem of distributed system data synchronization is another: things tend to demo well enough on a local development instances, and then fall to pieces in the unreliable field. Showing synchronization status, merging changes in a semantically correct way, useful UX affordances around all this, etc. is all very difficult work.

Of course it all depends on the domain and architecture of the app in question, so counter-examples and exceptions are easy enough to find.

1 more reply

munificent11y ago· 1 in thread

> For an even more retro approach, perhaps some things are just better written as desktop apps.

This is effectively what the mobile marketplace has decided. Native mobile apps are thriving while mobile web apps struggle to keep up.

jbergens11y ago

I'm not sure that is true, a lot of apps use web technologies on the inside. The more interesting part is that most seem to choose native not because of the development story but because they need to reach some special API or really want to keep the UI very close to examples from the platform manufacturer. It is actually a problem to go native when you have to develop multiple versions of each application which might totally lose any advantages the native coding experience has over html+js.

j / k navigate · click thread line to collapse