Bind everything to window is the same as "put everything in global".

It simply is not a long term viable strategy, we've been there, we've done that, it does not work. Perhaps that's not what you mean.

Also plain javascript doesn't have observables in most browsers, and any SPA without an observable system can only reach a certain level of complexity.

TBH, what you write is still so far from reality, that plain javascript is enough, that I am a little hesitant to take your comment seriously.

To be fair, I live a bit in the future. I build apps for tech people who are running up to date browsers, and that don't face the consuming billions. On top of that, Polymer polyfills webcomponents and two-way databinding of templates.

Perhaps my apps haven't gotten big enough to see this binding in global thing fail, but I'm not sure how it would ever. You properly namespace everything right?

I recently came to a similar opinion[1] of Angular like both of you though I was evaluating AgnularDart.

I decided to stick with plain Dart mostly of the reasons you mentioned (JavaScript ecosystem feeling like a mess). Polymer does look great but feels a bit unstable (at least for Dart).

What I would really love to see is a simple front-end framework handling:

- routing

- view encapsulation

- basic animations (when views are altered/loaded)

- back-end requests - preferably swap-in-out (http, websockets)

I ended up basically doing the above by hand in plain Dart. The only part that I found ready made and working nicely so far is the routing part[2] from Angular.

[1] - http://homing-on-code.blogspot.com/2014/11/dart-one-year-lat...

[2] - https://pub.dartlang.org/packages/route_hierarchical

What about Backbone[1] and Marionette[2] for SPA? Do you have an opinion on those tools?

[1]http://backbonejs.org/

[2]http://marionettejs.com/

This is what we use extensively at my work place to build cross platform mobile apps. It's very well suited for mobile apps since it's so lightweight.

We use it in combination with Cordova and some other stuff like Haml Coffee Assets and Fastclick.js.

Is this stack something you'd consider documenting? Coming from Rails, but increasingly moving towards SPAs with Rails as the API (hard to give up all the OOTB niceties), this sounds intriguing.

I definitely am going to do that as soon as we're going to start marketing the app. But at the moment the way we built it is not very repeatable, I'd love to see a project that builds out grape to be more like a standalone framework like rails is, maybe if we get time we could do that.

> I'd love to see a project that builds out grape to be more like a standalone framework like rails is

You should check out Napa by Bellycard. It takes Grape and brings it together with things we all love from Rails like ActiveRecord, Rake and generators that make for a productive framework.

https://github.com/bellycard/napa

I still have a lot to learn, but been off rails a few months and miss nothing -- http://www.ajostrow.me/articles/getting-over-rails

Sorry I missed your comment at the time you posted, and given the structure of HN, no sure you will see this reply, but thanks for posting that. Looks sure to make the transition smoother.

When you say "Ember seems to do too much", can you give me an example? I'm interested in understanding why it has this reputation of being bloated.

Ember, more strongly than any of the other solutions mentioned, pushes you to a browser application (or SPA) architecture. Usually developers who complain about bloat aren't thinking of web development in that context.

The number of challenges a framework should help a developer manage for a long-lived client-side JavaScript application is not trivial. It is absolutely true that Ember is heavier than other frameworks, but it has a specific style of development in mind. If someone chooses to build their app with an alternative, they often end up with a similar amount of code in other dependencies and application code.

And though we aren't there yet, we're working on ideas for modular loading of application code (via the pods patterns) and of Ember itself via tree shaking. This latter strategy leverages the fact that Ember's code and much app code is written in ES6, and thus we can identify and drop un-referenced code.

If you ever inspect ember objects, they're huge, the properties/functions they have...

http://emberjs.com/api/classes/Ember.EachProxy.html

See the EachProxy class? Click on the class it extends.

http://emberjs.com/api/classes/Ember.Object.html

Oh look that object extends another class... apparently it uses Mixin to extend these classes maybe the apply function? If it's using prototype inheritance than looking up the prototype chain would be a performance hit IIRC.

I was doing Ember while during beta though. But during that time they were marketing Ember as smaller library and more performance than Angular.

The last bench mark I've seen, Ember library is much bigger and the performance was not that great compare to Angular...

I'm not certain if it's bloated, and if I was building a regular CRUD app I would probably have selected it over Angular. It just implemented some things I had the feeling I would do differently, i.e. I didn't want to pick a framework I would have to fight to get to work the way I wanted it to. Ember is being developed by some very smart guys so I would never dismiss it out of hand.