echoless

While JavaFx and QML offer a better development environment(good IDEs with refactoring support, drag-and-drop designers etc), they cannot compete with the thousands of UI (and increasingly non-UI/utility) libraries that are out there for Javascript.

For DOM performance, they are pretty much identical. Both use Chrome(each uses a different version though, usually atom-shell uses more recent versions).

For performance of node.js calls, I haven't run any benchmarks, so I cannot help you there. However subjectively, both felt about the same to me(except in the node-sqlite-purejs case).

I've played around with both node-webkit and atom-shell, and I prefer atom-shell over node-webkit, due to some minor inconveniences with node-webkit.

* When an error occurs in node-webkit, it loads an error page instead of simply logging it to the console like normal web pages. Even after fixing the error and hitting reload or navigating back, the page doesn't go away. You need to manually enter the url(copy/paste doesn't work).

* I don't know if this is something that was my fault or the app's, but when I made a call to a sqlite3 database using the node-pure-sqlite3 gem, it would take around 3 seconds to execute. With atom-shell it would take less than a second.

* The developer console is a separate window from the application in node-webkit. I prefer having a single window hold both the app and dev console during development(which atom shell-allows).

Turbolinks wipes off the entire DOM and replaces it with the new request's html on link navigation. So no, it is not an adequate replacement for SPAs.

> It's isnt perhaps,99% of websites outthere arent SPAs.I'm pretty sure a majority of website you visit arent either.

Currently 99% of websites are not SPAs, but I think a lot of sites will switch to SPAs in the future, since they offer a better UX(no full reloads, more interactivity etc) in most cases. I'm sure customers will demand these sort of sites once they start using more SPAs.

> Why would you need a different framework for a "rest-backend" and a website that displays html?

A full-stack framework is overkill as a backend for SPAs.

I'm curious about the fate of Rails(and other frameworks like Django) in a few years, seeing that many web applications are moving to the Single-Page-Application model and the server simply acts as a rest backend.

Perhaps there will still be a large demand for sites that aren't SPA applications. Interesting times.