[reordered]
>I would love to see something new come along that replaces at least the nasty JavaScript stack. I guess for now we need to settle with the welcome improvements in ES 6 and 7 which are a big step in the right direction. As I said at the start of this discussion I think we are in the midst of a huge changeover in client side technologies and I think in a year from now we're going to be looking at a very different landscape of frameworks and tools that take advantage of all of this new stuff in a much more streamlined development environment scenario.
>
I second Thierrys wish on some insight on your thoughts about JS fwks you tested or worked on. You already answered him, but IMO such an answer here is not the best way to spread your POV, esp when you encounter new fwks. If you had a [regurlarly updated] comment site on west wind along the lines of "Ricks very personal take on web fwks / JS stacks" such info would be easier to find if one is not following this thread.

>I used to actually be a big proponent of building desktop apps that use services from the Web to pull their data, rather than local data. However, recently with the advent of decent frameworks in JavaScript that allow you build abstractions and use proper code separation more easily, I think we can build effective front ends in the Web that are just as nice as native UI. In fact in a lot of ways I think it's much easier to build nice looking UIs using HTML/CSS. Heck there are now many desktop frameworks that use browser containers to essentially let you wrap a Web UI into desktop apps using the PhoneGap/Cordova model. (Atom UI, Chrome Apps are a couple of examples).

Personally I hope abstraction [goes more to / includes] the other side, allowing you to build / generate JS UIs closer to the "OS-metal" like the ideas in React.Js / React Native or Nativescript.

As I do not have the extensive web expirience to draw upon, I tend to go for the ideas behind the fwks, but lack the gut knowledge on how brittle the implementation is or if using this fwk ties you too closely to the use cases in operation when the fwk was conceived.

Meteor was already on my radar before you mentioned it (Node.Js kicked me off couple of years ago to switch some reading from Python): some ideas written down there click instantly

move only data,
database everywhere,
having a local database with the same way to query in miniMongo

while the first seen coupling to Mongo backend scared me off. [mini-]Mongo sharding JSON structures might be beneficial for performance and dev mind ease on a JS front end and has grown into the backend standard DB of MEAN.io, but the typical use cases arguing for Mongo when put against relational db do not matter on the local client installation.

I am thoroughly uncertain whether my preference for a more traditional local DB caching/storage client based on SQLite/AlaSQL is based on measurable benefits from coding or stems from personal inertia aka lazyness ;-))

And while I recognize there are some scenarios where a reactive mind set used throughout Meteor is necessary, it is not typical for the apps I used to create.
I hope I find some time to check the budding SQL / relational support there for Postgres and MySQL, but still fear that going with them will put me too deep into technical debt of the assumptions and structures of their fwk.

To mention an offer at the not-so-famous end: very circumstantial own expirience supports the Mithril claims that building the container structure of a GUI in pure [JS] language [or at least in JSON] as mentioned in
http://lhorie.github.io/mithril/benchmarks.html
do not shift me from thinking a declarative/structured representation of a GUI is best for [cross] development, but make me think about adding a XML to JS compiler as part of a delivery process (the ultimate premature optimization, worrying before code is created...)

and sections like:
"One of the things I'm trying to do with Mithril is encourage people to go back to the basics and realize that a lot of the assumptions and cloudiness surrounding MVC is actually wrong: the view layer isn't HTML-only, the model layer isn't supposed to be solely about ORM classes, controllers aren't supposed to be a pool where we dump things that we don't know how to fit into the rest of the framework."

made me grin very wide ;-)))

>It's not like a don't understand the limitations and tribulations of using JavaScript and it's funky language heuristics, or the difficulty in building Forms based UIs with HTML/CSS, but I've come to realize that this is simply not going to change anytime soon. This is the most ubiquous platform and the Web is the best way to deliver applications.

Full ACK on "deliver" in embolded part above. What I aim for is to be able to sometimes use the smarts of endpoint devices, from caching some result sets drawn {Pox on Oracle for killing SQLite-based WebSQL in HTML5 draft}, using the procesing power of endpoint devices or enable partly disconnected operation. The security benefit of the browser has to be balanced with possible UX benefits from both more direct access to the device GUI layer than through DOM and usage of storage/processing ability utilizing more than that cripple left after murdering WebSQL.

And we will go through the same growing pains when IoD will reach critical mass ;-)

regards

thomas