Unhappy about SPA frameworks

I’ve been looking at single-page-app frameworks and not keen on any of them. The list at http://todomvc.com/ has a bunch, and I think I’ve rejected them all — I concede that some of these reasons are just flat-out prejudice or reasonably baseless bad feelings or seem pretty trivial to whoever’s reading, so this is your chance to talk me into something you think is good and show me why my bad feelings are unjustified or wrong.

What I’d like is two-way data binding, routing, and some notion of making separate isolated components. I don’t have a pure REST put/delete/get API to back end onto, and I do not want a “framework” which has as a selling point that you can switch different routing or template components in and out; if I’m assembling my own preferences out of bits, then I won’t use a framework at all; I’ll stitch them together myself. The point of using a framework is exactly that it does everything, and I’m OK with using the framework’s methods to do X, Y, and Z, rather than cursing because I want to use a different routing library. I am a large believer in identifying the approach that a particular tool takes, and not using the tool if what you want to do doesn’t match that approach, even if it’s possible to use the tool in ways other than its expected that you will. Every time I’ve done this in the past I’ve ended up being burned by it. The thing I want is to identify something which wants to do the things I plan, and then use it; not to find something which doesn’t want to work that way and then make it work that way instead.

So, convince me I’m wrong on your preferred choice from this list, or mention something I don’t know about. And yes, I could write my own, but I’m massively resistant to that because that just makes the another-day-another-framework problem even worse.

There is one non-negotiable rule: JavaScript. No other languages which compile to JavaScript. I don’t mind things like React’s JSX, because that’s being used to write HTML (although I’m not sure about it), but no Coffeescript libraries, please.

  • Backbone.js - also requires underscore and jquery. Some ideal thing for this really ought to be self-contained. Concerned about “is pre-configured to sync with a RESTful API” too, and I have to plug in my own choice of templating library.
  • AngularJS - used it in the past for things. It makes me sad. There’s too much magic; it’s fine until something doesn’t work, and then you have to reverse-engineer all the magic.
  • Ember.js - is massive and confuses the hell out of me. I did a bit of hacking on Discourse, which is Ember, and it took me about a day just to work out how to change the simplest thing.
  • KnockoutJS - seems way, way verbose. function AppViewModel() { this.firstName = ko.observable("Bert"); this.fullName = ko.computed(function() { ... }, this); } ko.applyBindings(new AppViewModel());, seriously? Gnah. I hate that.
  • Dojo - old. I never liked it the first time around, really, and I have the feeling that the zeitgeist has not gone with it.
  • YUI - old, and pretty much abandoned upstream afaik. Used it at Canonical; “aspect-oriented programming” is basically computed COME FROM from Intercal, which puts invisible trapdoors in your code so following the thread of control is hell on legs.
  • Knockback.js - builds on Knockout, so see knockout.
  • CanJS - models stuff seems specifically designed to back end to a put/get/delete rest API, which I don’t have.
  • Polymer - seems like it may be ropy on iOS. Also, it has a nice big library of pre-built components, which is great, but they’re all Material Design components, which is not great at all; I’m not putting an Android-themed app on other platforms, for the same reason I wouldn’t put an app which looks like iOS on Android.
  • React - I fear React. It seems to be the popular thing, but it’s very much a thing where one steps out of the world and into the React World instead. Have spoken to a number of people using it for real projects and I don’t like the idea of it.
  • Mithril - I utterly utterly do not understand the m.prop stuff. I don’t know whether the docs explain it badly or I’m just not getting it, but I completely cannot grasp the Zen of Mithril. Shame, because it looks cool, if I could get it, which I can’t.
  • Ampersand - I’m in two minds about the “it’s a zillion small libraries” thing. More to the point, I have no sense of how to structure the overall application; individual bits I can see how to do, but I don’t have a good sense of how to put it together
  • Flight - I’m not sure this is the right thing for new apps. For restructuring an existing thing, I think it’d be good, but I’m building from scratch.
  • Vue.js - doesn’t do routing or provide large-scale structure; they have some notes saying “hey, that means you can do it your way” which I don’t want to do
  • MarionetteJS - depends on Backbone, so see Backbone.
  • TroopJS + RequireJS - lots of dependencies. I do not get how to actually structure an application with it, and the docs are not helpful at this.

I wish I were happy about any of these. To be honest, my secret worry is that all frameworks are either incomplete, so I don’t want them, or do do everything I want but are consequentially too magical and so I don’t like them. I hope I’m wrong and there’s either something I’ve missed or a framework I don’t know about. Speak on, readers: leave comments on Google Plus or on your own site by webmention.

More in the discussion (powered by webmentions)

  • Magnús Örn Gylfason responded at twitter.com @sil don’t fear React. Embrace the Immediate Mode GUI mollyrocket.com/861
  • Stuart Langridge responded at twitter.com @mg0rn I'll take a look. But I'm pretty unlikely to be convinced. My problem with React is not the tech, it's the people.
  • Magnús Örn Gylfason responded at twitter.com @sil I for one find them to be a lovable bunch!
  • Stuart Langridge responded at twitter.com @mg0rn ah, not in interaction. It's that I have to basically step into the React works entirely. It's not possible to be a little bit React.