* I started out with Backbone. It seems ok as far as it goes, but a bit annoying in that there's enough "magic" and stuff going on that I don't quite understand it completely, but without enough magic to really make things simple and easy.
* Angular.js. Now this is more like it in terms of magic. Then, the other day, I decided to add a date picker to one of my forms. Uh oh: http://www.grobmeier.de/angular-js-binding-to-jquery-ui-date... - how many lines of code just to make it a date picker? I couldn't have written that code myself without several more days of banging my head. Wonder what'd happen if I really try and do something it doesn't agree with... So out the window with that for the time being.
Also: a lot of these tools have tutorials that don't really walk me through all of what I want to do, which initially involves a fairly straightforward "CRUD" type of application. I want to see how the framework deals with both 'make me a new one' and 'edit an existing one' forms, for instance. I found that very irritating about the Angular tutorial, which is otherwise very nicely put together.
Now I'm testing out jquery-pjax, and... so far I'm happier. It behaves more like a web application that I'm used to, sending around HTML, and staying out of my way. And, seeing as how all of these things require that the server do its job in any case, it has more of a "don't repeat yourself" feel to it: click on the button, and the server gives us some new data, without repeating the whole MVC cycle on both the client and server. I got the idea from this post: http://37signals.com/svn/posts/3112-how-basecamp-next-got-to...
> a lot of these tools have tutorials that don't really walk me through all of what I want to do, which initially involves a fairly straightforward "CRUD" type of application
The backend in the tutorial is in C#/WebAPI, but it's very easy to apply the concepts to any server - the server is tiny and very simple. I'll be doing a Python tutorial with Flask-Restless very soon.
I'd be interested to hear any feedback. I'll be adding video wall-throughs in the next week or so too.
i've went the backbone/knockout/angular route and i think all of them works great for simple things. but if your project gets a bit more complex (or where your code-base changes frequently), you'll start running into all kinds of problems. yes, you can usually hack around them after several exchanges on the mailinglists/irc, but very time-consuming nevertheless.
now, i'm back to plain javascript/jquery. i run into less headaches and more control, therefore more productive. my gripe is the same as op, the "magic" is what throws me off. angular is a bit too buggy, last i used was 6 months ago, and still lot of things they didn't support like proper callbacks upon rendering, etc ...
basically something really easy to do in plain js, becomes like a rubik's cube with all the magic going on. just be prepared to write a lot of extra code/hacks/patches for certain things to just "work" if you decide to go the i.e; angular route. but don't say i didn't warn you :)
Angular is used internally by Google for bit-more-than-complex projects so its possible my friend. It was also used for the Double Click for Advertisers rewrite.[1]
>and still lot of things they didn't support like proper callbacks upon rendering, etc
Heh render callbacks in Angular? That's so Backbone. Did you read the hello world tutorial?
well, if you got the authors of angular on the team, anything is possible, no complaint there. magic is only 'magic' if you aren't the one who created it.
also i don't know why not too many people bring up such issues as the 'if/else/switch' flagging nightmare that comes with maintaining an angular code-base. it makes your code a very verbose in that regards.
backbone? magic? backbone is 1534 lines of straightforward, well written, well documented javascript. backbone is about as simple and un-magic as MVC gets, by design.
I feel stuff like this takes a lot of mental power to understand the context that it is being executed in and what exactly it is doing. It feels like I am knee deep in some obfuscated C code.
It's not that hard when you know the idioms. && is a guard and || is a default. With a little bit more context and experience in writing concise javascript, it's actually pretty clean.
I wouldn't go so far as to say this is horrible code, I also wouldn't say this is good refactored code.
It definitely gets the job done; however, I would imagine someone figures they'll come back and refactor at some point. Code is never finished, it is merely shipped. This is shipping code, but it certainly can be refactored into a more intention revealing function.
It's a trade-off. If you pull it into a new function, it adds LOC. It also is another layer of abstraction. Is it worth it? Perhaps...but maybe not. Just looking at this one line of code in isolation without context is a bit unfair though.
I understood what pjax was doing in about 5 minutes. Backbone.js is more complicated than that, and while I'm certain it's not that hard to figure out, I felt a bit like "ok, it's doing stuff I don't immediately understand, but it's also not doing any deep magic that makes difficult things super-easy, either". Very subjective, but it just didn't feel like a sweet spot. Angular.js actually seemed like more of an "all-in" play with the fancy stuff, but that datepicker issue was a wake up call about getting to a point where even doing something simple might be quite difficult.
Backbone and pjax are not similar so maybe the issue is picking the right tool for the right project. PJax is great if you are looking to help navigate. Backbone is useful with managing objects and collections while keeping them separate from the DOM. It also provides its router to coexist with its views.
you aren't the only one. i too went through troubles and concerns when i started venturing out to use some of the plugins out there, notably datepicker, select2, jqmodal, actually just about any other "cool" plugins out there. creating your own directives to get something to work is something i'd just rather stay away from.
Exactly. If you run into something beyond the docs in Backbone you can just step through the code and see what's happening. It seems to do just enough without drowning you in "other people's code".
I had a similar experience. I use backbone for interactive parts of the app and ended up going with jquery-pjax for almost everything else. Another option is to create handlebars templates that are compiled with the asset package. But that introduces some other problems that need to be solved.
I'm ready to get on board with something cohesive that's Ember-ish whenever it matures.
I've been using PJAX as well. Basically, when you click a link, jquery/pjax intercept the click action, make the request to the server, and on the server-side you look at the request to see if it came as a PJAX request. If-so, you just send back the "partial" section of the page that's being loaded/updated. At the same time, you use push-state to update the URL in the address-bar to conform to the page you've loaded. If the server doesn't detect that the page was a PJAX request, it should respond with the entire page contents - header, contents, footer, etc.. If somebody copies and pastes the URL into a new tab, your site will behave the same was as-if no PJAX header were passed - loading the entire page. This is the same way a search-engine spider will behave. They should "see" the same experience content-wise as a user navigating the site using PJAX.
This particular project runs in kiosk mode, more or less, so I don't care about it at all. Also, if it's just pages, rather than an application, you probably don't need this whole extra layer of junk.
>Angular.js. Now this is more like it in terms of magic. Then, the other day, I decided to add a date picker to one of my forms. Uh oh: http://www.grobmeier.de/angular-js-binding-to-jquery-ui-date.... - how many lines of code just to make it a date picker? I couldn't have written that code myself without several more days of banging my head. Wonder what'd happen if I really try and do something it doesn't agree with... So out the window with that for the time being.
To be fair, you can just use Angular UI as that article says:
<input ng-model="date" ui-date> for a date picker and the ui-jq directive for any other jQuery plugin.
"Also: a lot of these tools have tutorials that don't really walk me through all of what I want to do, which initially involves a fairly straightforward "CRUD" type of application. I want to see how the framework deals with both 'make me a new one' and 'edit an existing one' forms, for instance."
Couldn't have said it better myself. I can't count the number of times I had been excited about learning some new framework, only to discover that their documentation is non-existent, poor, or written for rocket scientists.
Recently decided to use Backbone as a JSMVC Framework on my team. Although I looked at Ember and Angular, which obviously both have many more features than backbone out of the box, We chose to use Backbone because it seems to have such a large and vibrant community behind it - seems like angular and ember are both lacking in this respect.
However, as our Backbone application grew in complexity, we noticed that Backbone is so bare in terms of functionalities that we had to build our own half-baked framework on top of
it to make up for the gaps.
I think the Backbone project needs to make Backbone's intentional feature sparseness clear. I've come to realize that backbone is more of a library which provides a basis to make a client-side framework rather than a something that can be used standalone by app developers.
If I could go back and change our original choice, I definitely would have gone with one of the Backbone-derived frameworks (chaplin, marionette) or just gone with something more fully-featured like angular. While backbone is beautiful and elegant for small projects, it just doesn't provide much convenience as a stand-alone library for larger applications.
I have found the Angularjs community to be thriving and most helpful. Check out their google group (1), g+ page (2), g+ community (3), irc room (4) and youtube channel (5) for an excellent place to get help. I usually get help as soon as I need it, amazing.
Also I have been impressed with the active community projects AngularStrap (6) and AngularUI (7)
We recently faced a similar decision, and ultimately went with angular - the two-way binding sold it for me, plus the concept of pushing all DOM manipulation into directives (declared in the HTML), to get that out of the controllers. We've spent ~8 weeks using it: our codebase is smaller, easier to mantain/adapt, and better modularized -- we love angular. The docs are great, and the IRC community is there when you hit something quirky.
I always said it, Backbone is not a JSMVC Framework; It's a JSMVC Framework Framework (How to go meta!) Basically, it's a solid foundation to create a JSMVC Framework.
[meteor dev] Please come help us with this! We have six engineers at Meteor and dozens more contributors in the community working on the platform every day. The plan to 1.0, including REST, is at http://roadmap.meteor.com/.
Here's the guiding principle behind Meteor. There should be a dramatically faster, more accessible way to write applications. Improving that developer experience means rethinking some things: autopublish and minimongo, so you can jump right into a new app's UX in the first five minutes; one-line authentication (http://meteor.com/authcast); synchronous APIs that are more comfortable for a lot of developers; dirt-simple reactive templates; hot code push.
Focusing on that kernel of development experience means some other things -- REST, routing, form building -- need more time to fully bake, with hacks like __meteor_bootstrap__ and phantom for apps that need them now. We think that's a good tradeoff pre 1.0.
I was excited using meteor but was sadly disappointing after a couple days of "banging my head on every simple things I tried". As far as I'm concerned, Meteor is a big "Screw everything that exist, it sucks. We're better and we've got the time and money to re-build all the life from scratch".
So, in a way, that's great! An mental orgasm for any nerds out there. But in the real life when shit needs to get done, I'm still using everything else that sucks.
Now, before people start saying I don't know what I'm talking about, here are a few examples:
- It does NOT use npm (!) -> Basically, you can't use anything without first converting it to Meteor.
- It does NOT use Express (Or connect) as its base -> Basically, the standard in the Node community. That means I can't just plug-in the 20 or so awesome plugins built explicitly to be used by any kinds of node application that support connect.js
- The current Asynchronous (following node's philosophy) wasn't good enough for them; so the re-created a whole new Mongo version acting synchronously.
But most importantly, it's just extremely annoying to hack with it. It's like a big black box.. you're not very sure what it does and you hope it works. But when it's not working, you can't just hack it your way or read the source. It's a little bit like Django or Rails (but in worst) as you can use SQLAlchemy in Django, or you can use different template engines, but then no project from the django community will work with your app.
The good news is, the meteor team is working hard. Maybe in a couple years it will be stable enough and iterated fast enough to provide a platform where it will be fun hacking and building web apps. But for now, I sadly prefer to stay in the "Everything else sucks" world and hack my way in the node jungle.
(For those interested, I have also tried Derby. As said in the article, it's not yet fully stable and the documentation is really Meh. But I think it's going to be big really soon and I'll be more than happy to give it another fair try. So far, I'm sticking to a basic express (Or locomotive.js which is nice.) I'm also using Angular.js on the front-end. It's something amazing as I feel very productive and it saves a tremendous amount of time.. but at other moment, I just bang my head against the table as I want to do something simple and it's just impossible so I need to use all kind of hacks to do what I'd have done in a couple lines in Vanilla Javascript. Oh well. Hard to be a hipster web developer trying all new technologies :-))
What blocks you from digging into the source? I want to make that easier for you.
Nearly all of the Meteor code is broken out into various packages. They implement components like publish/subscribe, client-side data caching and snapshotting, reliable remote method invocation, live page updates, and hot code push. They're the building blocks for a rich client application.
Now, we have some work to do on better separating those components so that you can pick and choose the parts you want, like using livedata (publish/subscribe) with Angular, or using Spark (our reactive page update engine) with a legacy REST endpoint instead of livedata. Those combinations are technically possible today, but not particularly accessible. They should be.
(That is one of the two front-burner project we have going today. The other is scaling.)
What blocks me from digging into the source is mostly that even if there are separated components, I still need to understand all the aspects of Meteor. I can't just open the file and change it. Will it screw up the deploy system? Will all the data-binding continue to work as expected? Maybe yes, maybe no. Unless I totally understand the system, I can't really know.
You say "like using livedata (publish/subscribe) with Angular", but that's the problem I'm talking about. You need to tweak the system to make it work with Angular. But what about the hundreds of other smaller angular-like libraries? Or tomorrow's most popular one? I can't just <script src="it">, I'll need to create a meteor package and make sure it works good with all the rest of the system (Which unless I'm a Meteor expert, I have no way of knowing).
That could actually be a good blog article, "How to use MooTools, django template system and MySQL with Meteor". I.e. Going through what's needed to be tweaked to make it work. Compared to say, express, I could tell you use the mysql node library, normally include mootools in your html files and use mustache (Or whatever library already exist to mimic Django's libraries).
There should be a dramatically faster, more accessible way to write applications.
You do realize this is the holy grail of software development? The thing we've been seeking since, oh, at least the mid 1950s.[1] Pretty ambitious to think you'll crack the nut, at least more than momentarily.
Is it not a rule that a novel application will break the paradigm that other applications follow and hence leak out of the abstractions that allow the traditional application to be written quickly?
Copying is dramatically faster than doing something new.
I'm keeping my eye on Meteor. As it stands I don't feel that anything in the Node ecosystem compares to the daily ease-of-use I find in my Rails environment (and I know Rails isn't exactly a peach). I like that you guys seem to be trying to do some things different, the fact that you're not using NPM could also be considered a boon rather than a defect. I'm not sure I how much I like NPM, but I'm arguably not a Node expect.
Meteor is one of the most exciting things I've seen recently. Will gladly help, what things you need most and how one get started? and do you accept people that like TypeScript, Java, Scala and come from the enterprise world? :)
"It seems that most people today, when thinking about their next JS project, will use Backbone because it's the most popularl framework when it shouldn't be." (sic)
Here's a long list of examples why maybe it should be:
What you want to look for in a library goes beyond feature checklists and magic datepickers. Lots of client side developers have been burned in the past by JavaScript frameworks that promise the world and end up getting in the way more than they help.
Backbone tries to provide the barest useful essentials -- the main business of building your app is up to you.
Backbone tries to provide the barest useful essentials -- the main business of building your app is up to you.
I personally prefer minimal frameworks because they don't assume what your finished product will look like. You can grow the application organically rather than trying to fit it into some prototypical mold. Full-fledged frameworks have their uses - they are perfect for getting up and running on known problems. But if you are trying to bake things into an already mature code base or trying a totally different style of architecture, they are not worth the work.
"... use Backbone because it's the most popularl framework when it shouldn't be."
You bring up a good point...to add to it, many people also choose to go with YUI, Dojo, EXT when Backbone or a list of small well curated libraries would have been a better fit.
Essentially, the problem isn't Backbone or any of the other libraries/frameworks...it's that there are a LOT of developers that can't seem to evaluate the available options effectively.
You use this argument a lot, but the ranter suggests that the reason many turn to Backbone is because of a self-selecting bias of it being the most popular.
It's certainly my favorite argument. Folks sometimes forget that pre-Backbone, there was a cornucopia of rich JavaScript framework options: YUI, SproutCore, Dojo, EXTjs, UkiJS, JavaScriptMVC, Cappuccino, and so on. If Backbone has become a bit popular over the last couple years, perhaps it's because it tries to do less than the excellent pre-existing alternatives.
there is something to be said about flocking to a framework purely based on popularity, Rails is a great example of that too, you sure as hell don't need it for most projects but there are a lot of developers familiar with it, whether it's good or not is another thing
I have the same question as @hnwh: I'm using Knockout and really, really like it (more suited to my way of working than say Backbone), but considered that Angular could be a more advanced/featureful Knockout.
If you use Knockout please consider being more vocal about it. It is a fantastic mini-framework/library but doesn't have the crazy PR behind it like backbone.
Angular is great but the problem is you really need to use client side templating for it to be useful. It also has the same syntax as django's template language by default. All this is workable but Angular is great for projects that you are starting. Knockout is better to integrate with existing projects.
Thanks to all in this part of the thread for talking so pretty about Knockout - it got me to try incorporating it tonight on a simple interactive page I started recently, and it's a pleasure to use so far. Works nicely in combination with coffeekup, which I also enjoy a lot.
I just finished evaluating frameworks for a project and chose Knockout over angular for a couple of reasons:
Extensibility & hooks: Extending built in behavior in Knockout was much easier than in Angular. Without getting into too much detail, one of the things I tried to do was create a list of items on the page with a simple animation for item removal. In Knockout, it was trivial. In angular it would have required a copy-pasta style rewrite of the repeat directive.
Some weird missing features: Angular has no conditional add/remove element directive (that I could find). This just seems like a weird oversight. There's a show/hide element directive, but trying to substitute that for add/remove will break CSS first/last/nth child selectors.
Angular has a lot of potential, but it felt to me like it needs a few more iterations before I'd want to try to build a rich UI on top of it.
You are right about the first situation. Currently doing animations with Angular is not a trivial task. This is mostly because of its "No DOM manipulation in Controllers clause". If you break that clause, having a repeat with animations is possible ( not trivial - but possible! ).
Angular does have a conditional add/remove element. You can use ng-switch for that.
If you are using CSS selectors in an angular app I sense a smell. Something is not right.
Yeah, I came up with a number of potential workarounds to the animation issue, all of which involved doing "non-angular" things. That wasn't ideal, but what really turned me off was how difficult it seemed to be to extend, compose, wrap, or otherwise re-use directives.
You're right - you could use ng-switch for add/remove. It's a bit awkward though. I'm curious as to why you'd consider "CSS selectors" a smell in an angular app. I'm assuming you mean some subset of CSS selectors (possibly just the first/last/nth-child selectors I mentioned?), as without selectors you can't really have CSS.
Oh sorry, I was under the assumption that you were using CSS selectors in JS not in CSS.. If its in CSS, then it should be fine. If you are using CSS selectors in JS in an angular app.. then that seems like a smell.
What does Knockout, Angular, et al give you that Backbone doesn't? It seems like most of the anti-Backbone comments are about it being unable to "scale", which is funny considering Hulu, Trello, SoundCloud and about a hundred other very large apps use it just fine. I have yet to see any of the other frameworks deployed to the that scale at all (where are the examples?)
What they give you actual two-way binding for DOM manipulation and rendering between client and model. They also, generally speaking, place very few requirements on your model which is a very good thing.
Angular is exceptionally flexible and one of the first tools for building client-side JS that really impressed me. That said it is fairly complex (and not that well documented) when compared to Backbone, so I can understand why not everyone would be impressed. Cavet emptor. As an alternative Knockout is pretty simple, it's just not my thing.
Backbone is a neat tool and what it provides most people is a somewhat predefined structure to work in. Coloring between the lines is really useful. However (as the parent said) it really does very little other than that in the end really. There is almost nothing that Backbone does that a sensible use of jQuery binding and data attributes can't do as well or better. It's just that most people will find it easier to learn Backbone, which is great don't get me wrong, but don't be surprised to find people (like myself) who have moved on.
(Also the way model are done is terrible, I've never liked it it always got in the way of whatever I was trying to do.)
There are plenty of two-way DOM binding add-ons for backbone.
OutbackJS makes it work like Knockout, but maps onto backbone models (disclosure: I wrote this one). Most of my models in production apps have zero complexity - a url property is usually all that distinguishes them, and outback bindings means that I a) don't have to litter my code with jQuery nonsense, and b) don't really have to muck with models beyond fetching and saving them.
Two-way binding is a neat trick, but I hate that it clutters my markup, and almost always I need to augment it in some way. Backbone's declarative events hash is universally a better way to go for that.
Can you please make any other sane argument other than "it clutters my markup"? You are holding the markup to a standard which seems like there is someone out there handing out "The best clean and clutter free markup" award.
End of the day you need to somehow hook up js and html. There is no second question to that. If you shovel out all the shit from html guess where it will land? In your js ( all the dom manipulation code!).
Backbone is pretty much a classic MVC, You define your data-model, your views(HTML) and than connecting all together in the controller.
It's an old and trusty way of doing GUI, but it require you to define your UI(views) in two places - HTML and js code. You must have hardcoded HTML references in your JS code(via CSS selectors & etc), and for every change you do in your view you have to check(and probably change) your js code as well - and vice versa.
Where in MVVM based frameworks(e.g. knockout) you define your view only once - in your HTML file. Your view contains everything that is needed to render the data in your View Model, and can initiate changes to the view model(and render any change that is being made to the date in the view model). There is never a need to use hardcoded references to the HTML in your js code.
Get jashkenas or the people behind Backbone to write a data-binding plugin.. I guess, I will consider BB for data-binding then.
I have tried most of the data-binding plugins in backbone.. They all fall short one way or the other. Stickit does not deal with collections, model-binder does but is a pain in the ass to use properly. Rivetjs seems better than the other two - but the scariest part of backbone plugins is that the community behind each is extremely small -hence its scary to consider them.
I wanted to use Ember, and I started going down that road, but I just didn't click with it. I didn't progress past the tutorial! I can't remember what exactly I didn't get working, but I just felt very lost and overwhelmed, and that was spending a couple of days reading around online, looking at the code and examples.*
I switched to Backbone and got going right away, in half a day of reading the docs and watching a couple of peepcode videos and I was off and didn't look back.
Maybe the Ember docs have improved in the last couple of months but at the time it was just a non-starter for me.
edit: I believe the issue was around Ember Data/REST. Out of the box it didn't support polling data on a REST interface, which seemed absolutely critical/fundamental to a JS framework. I found a plugin I believe called Ember Data, but documentation was very sparse and I couldn't even get a simple example going. This is going on memory so this could be slightly wrong or different today.
They just recently updated the guide. I haven't read through the whole thing, but it looks much more organized. Also there is a new Router API which is apparently significantly more intuitive.
Ember data docs are pretty sparse, but once you get up and going, the learning curve is pretty flat. Backbone is pretty easy to get going, but the code complexity gets exponential when you have lots of collections and references that need to be updated.
It's easy to get frustrated with ember & ember-data and just jump ship to backbone, but you'll be paying for it later when your data model expands beyond 5 interconnected models.
The best advice is to tough it out with ember even if the docs are weak and tutorials are sparse.
> <snip> but once you get up and going (...) </snip>
See, that's the problem. How do you get to "up and going" if the docs are sparse?
Just to be clear, this is not meant as a criticism of Ember, just a general observation that I have made time and time again when looking at new projects and reading comments saying things like "yes, X is not documented and hard to get into but once you get up and going it's all roses"
I can tell you that Tomhuda have been working really hard on docs for the last week or so. Ember's getting close to an actual 1.0 release, and docs are a big deal. For instance, they entirely re-wrote the router recently, so if docs had been written before, they'd be out of date anyway.
Not saying it hasn't been bad historically, just that it's getting better and will be good in the future.
I actually just had this same experience this past weekend. Hours spent banging my head against the wall trying to figure out why Ember-Data wasn't working. I don't know what wasn't clicking but I decided to switch to backbone for this project. Literally minutes of work to get backbone going and have my data appear properly.
Ember Data is a heavy hard-hat area and no wonder you were frustrated. Really, just start with your own data layer and get used to Ember first. Ember has a very Rails-ish philosophy and just like in the Rails world - magic happens (but ya should know how it happens anyways). This blog post is a good intro to how Ember works - http://trek.github.com/ (though routing has come a long way since - http://emberjs.com/guides/routing/defining-your-routes/
> Ember Data is a heavy hard-hat area and no wonder you were frustrated. Really, just start with your own data layer and get used to Ember first
So why is that? This was my big head-scratcher with Ember; surely the access to a data layer is the whole point of these javascript frameworks? I mean all backbone is really is a layer between REST and client-side javascript. I guess i'm missing a whole class of JS applications that don't need access to a server-side data layer, but for me that's the fundamental reason to be looking for a JS framework in the first place. So to come across one so highly regarded which doesn't have it baked in was very jarring.
The idea with Ember-Data and Ember in general is the same as Rails: Conventions give you power. Conventions and a happy path are good. That said, until you _learn_ the happy path, it's harder going.
It's not 'baked in' because Ember is modular: Ember-data has all of that layer in it, so the rest of Ember doesn't have to care. That said, I disagree with your parent: you shouldn't be writing your own data layer.
Thanks for the direction, I'll definitely check that out. Hopefully they have some of these baked soon, I did like a lot of the other features as advertised.
we use ember at the day job, and historically i've been primarily the backend guy slowly getting familiar with what the front end guys are doing. I agree that the ember-data stuff is pretty thin on docs at the moment. IIRC, it wasn't part of the original stack, but obviously everyone wants a mvc with that persistence layer. So a -1 for that, not sure if it will be a part of ember by the time it reaches 1.0 or not. (oh yeah, it's still technically beta)
But ember shines in other areas that people wont care about until they have to write single page web apps with a high enough complexity that warrants it. The reason we ditched gwt for ember was the 2 way bindings. Not having to write all that stuff(and test it(in every browser))has been a productivity boost, even though we had to plugin our own persistence layer.
Ember-Data isn't easy, and I'm sure when your frustration is running high it's easy to just say screw it and jump to backbone, but you'll be paying for it later if your frontend has more than 5 deeply connected models.
+1 - I've been following the Ember progress and have been blown away with the progress made last year. It's the most mature UI friendly framework for frontend out there. Fwiw, this (slightly outdated router code but a good philosophical intro) post is super useful for diving into Ember - http://trek.github.com/
We use Ember + Rails at work and if we didn't start with an Ember expert contractor we'd have been sunk. Ember is definitely a winding maze of stuff and until there's a "Agile Web Development with Ember 1.0" book, it's still very difficult to just jump in from scratch.
Still, once we've learned Ember we're very happy with it. Backbone is just too small to start any medium/large app, and Ember has a decent community behind it and lots of integrations with Rails.
We're working on https://github.com/rails-api to make Rails a great backend for APIs, and specifically Ember. Team is mostly Rails Core members and Ember team members.
The hope is to make it awesome for other JS frameworks too, but we mostly build Ember apps ourself, so you start with what you know...
Glad to hear rabl is working well in conjunction with rails-api. Haven't had a chance to try that combination yet, mostly been using rabl alongside Sinatra, Grape and Padrino.
Totally. And there's a reason AMS isn't part of rails-api proper: we want you to pick the tools you want to use. If rails-api (the gem) doesn't work with RABL in some way, please let me know, that's a bug.
You haven't seen the full power of AMS yet, but I have some exciting things planned. :)
You can do both, for example, you can use rails for authentication with traditional views and then use ember for the main single page app. I think this is how square does it.
Also you should look into active model serializers for integrating rails with ember. I think it's yehuda Katz' preferred method for Jason serialization from rails to ember.
"I can't remember what exactly I didn't get working, but I just felt very lost and overwhelmed, and that was spending a couple of days reading around online, looking at the code and examples."
Exactly.
I don't want to feel "lost and overwhelmed" when trying to learn some new product, or having to Google every single thing. It is a wonder anything ever gets done. Seems these things are written by someone in their ivory tower without any forethought to documentation. "Someone else wants to learn it? Not my problem! I developed it, so there! No good documentation for you." That is just lame.
As someone who has sacrificed his last few weekends and holidays writing documentation for my open source projects, I can assure you that that is not my attitude, and the fact you think so is very disappointing.
Ok, you like angular. I don't. It has too much magic and forces you to pollute your html with ng attributes. Blanket statements about frameworks like this grow old. So much of the decision comes down to individual preference and the needs of the project. No need to rant about it. I can't really speak on derby vs meteor but I imagine it's the same.
It's not like that. I'm saying use Angular, Ember, Knockout, whatever - just not Backbone. Unless you know Backbone is what's needed for your project, or you yourself really love Backbone. What I'm discouraging here is its popularity as the de-facto client MV*. I'm under the impression that most people today, when thinking about their next JS project, will use Backbone because it's the most popularly-touted framework where It shouldn't be. It's a great framework, and die-hards & specific projects should indeed use it. But the majority should use one of the other frameworks.
Ember, Knockout, Angular, Batman, all have data-binding in their core. Backbone doesn't. If you like writing client code where you have control over rendering and DOM manipulation, Backbone is the best choice short of building your own framework.
Agreed. Also backbone gives you the flexibility to use it on the backend or as the data models behind a canvas app or other kinds of non-html rendering.
I don't quite understand the 'polluting the html' argument. How is this worse than using a templating package like Moustache? Plus, it's Angular's mission to extend html with the framework. Says so right on the homepage.
Im sure that is inline with their mission. I just don't happen to like their mission. IMO the html gets pretty messy with a bunch of non-standard attributes that could easily be handled just using class/id names. Once again, my point is that is why 'I' don't like it. I don't have anything against angular or you using it.
Could you perhaps answer the first part of his question as well? That was probably the main part that you missed out. Isnt mustache doing the same? Why do you really care about the rendered HTML ( after mustache's spits out html ) being clean and pure? Dont we all know that "no one" sees it?
The only time angular / knockout's html seems to be less "pure" is when the browser has already rendered the content. At which point pretty much no one cares about it. When you are debugging you have your source.. Its either mustache ( or similiar templating solutions! ) which are not even close to HTML or HTML with additional attributes.. I dont see how that makes a difference.
polluting HTML with.. HTML attributes? Angular lets you stay very much in line with the spirit of HTML, which is a declarative language. To me, when done right, an angular infused HTML page reads very nicely. It's clear to the designer what elements do what. All that logic isn't hidden away in some javascript file.
The fact that you do very little DOM manipulation with angular.js is one of its biggest advantages, IMO. Makes it easier to write maintainable and testable code.
Angular lets you use attributes like: data-ng-*. You can also put directives in css if are that concerned about validating markup - class="data-ng-click: foo"
> It’s like Gentoo users proselytizing Gentoo to the masses, perpetuating it as most common Distro; where all this time, Ubuntu would have saved everyone countless hours.
I find this a pretty good metaphor for the backbone/angular/ember distinction, highlights that this complaint is the old "I can't imagine anyone needing more flexibility than I do, so those other people are obviously wasting their time". Nice parallels to PG's famous blub paradox essay as well.
I'll chime in with the requisite "90% of the time, don't use an mvc framework in the browser." Don't build up a mountain of state for no reason. Use functions and composable, lightweight, short-lived classes.
If I had to choose the 'best' javascript development framework, I'd choose clojurescript, not because it's such a great tool in itself (it is a great tool, though still a bit immature), but because it forces the developer to write javascript in the best possible way: functionally, only holding onto state when it's absolutely necessary.
It's good that there are solid mvc frameworks out there for when they are truly needed, but when the average developer picks one up for a routine web app just because it's the hot new thing, he/she's walking into a minefield for no good reason. Javascript is at its best when it's just a dumb, fast bridge between your server and your ui.
actually, Meteor is not like Derby. For one, you don't need to deal with callbacks when data is changed. Meteor can automatically figure out what data sources are bound to certain containers in the template being rendered and when you make a change in the database, the data is pushed to all the clients. Here are some good details on the differences: http://news.ycombinator.com/item?id=3842525. Also, Meteor now has a REST package built-in https://github.com/crazytoad/meteor-collectionapi and additional modules that you can install, like https://github.com/tmeasday/meteor-router
!! Those REST packes enable server-side routes? I remember the last time I checked, when Meteor had it's new "server pages" it was Phantom generated snapshots of client renders, which blew my mind. I'll explore those packages, that was my biggest gripe and may motivate me to take down my post.
[meteor dev] The `spiderable` package is just our hack to let search engines index our own website. It works surprisingly well for that, but it's certainly not the long-term solution.
I'm working on an app which uses Ember 1.0.0pre-2. Over the past few weeks I've been lazy / busy doing other things so the project was set aside for a bit. I came back to it yesterday, opened the guide page (http://emberjs.com/guides/) and noticed it had been updated. I was excited and immediately checked the Router section. The guide reflects a brand new router API, which from what I've read makes it much easier to control the state of your application.
The problem with Ember right now is the documentation doesn't align with the most recent public version, which will confuse the heck out of newcomers and frustrate people who are still learning Ember. You can however, check out master to get the new router implementation.
I'm personally making the jump to the bleeding edge for two reasons:
1. The old router API is very hard to grasp. A lot of unknowns as far as where domain code fits when building your application using the router.
2. I don't want to be stuck struggling to find documentation for an already difficult API to work with.
With all that said, Ember is worth taking a look at as far as an 'improved' MV* experience, but you have to be careful as it is in a state of flux.
I can only speak for myself, but the reason I use Meteor (http://telesc.pe) is because I believe that while it's not perfect right now, it has a bright future ahead of it.
The Meteor devs themselves will acknowledge that some features are lacking (I imagine that's why it's not 1.0 yet), but the roadmap looks very promising and I believe Meteor also has the right team to make all this come true.
Agreed on Backbone. It's awesome, but have had transition to Ember as I take on more complex UI frontend work. Trek summed it the best I could hope for: http://trek.github.com/
Straight from the backbone faq: "Backbone.js aims to provide the common foundation that data-rich web applications with ambitious interfaces require — while very deliberately avoiding painting you into a corner by making any decisions that you're better equipped to make yourself."
I think the problem is people come into Backbone.js thinking it's a full fledged MVC framework for in-browser apps, instead you should think of it as a minimalistic set of tools with which to create your own framework (and in fact, a few actual frameworks have been released that are built on top of backbone.js).
One way to taxonomize frameworks is on how opinionated it is - Backbone.js is on the far end of the unopinionated side. If that's what you like, then Backbone.js is for you. If you want something more out-of-the-box, you should be considering the other options.
Marionette (a framework built on backbone) offers a nice solution. It still keeps things pretty light but does a lot of the groundwork you would normally have to do with backbone for you. Eg cleaning up event bindings, provides a region/view manager and an application wide event bus.
I'd also recommend looking into Chaplin for stronger routing / app design. It's got a great CollectionView, which is one of the most common use cases for Backbone (also seems to solve a lot of the gripes with plain Backbone
Chaplin is a mess. I need node, npm, build a bunch of stuff from scratch? I've already lost interest (I looked at Chaplin a few months ago and honest to God couldn't even figure out what the hell it did besides download various crap to a /lib/ dir. Aren't there six dozen tools that do that?)
I've been using angular.js for a while now and there are a few reasons why I've really liked it:
- dependency injection: because everything is injected, it makes writing isolated unit tests very easy. It also makes it very easy to swap functionality in and out without affecting other parts of the app.
- two-way data-binding: most of the pain of being a javascript developer comes from managing and manipulating the DOM. After using angular, there is no way I will ever use a framework that doesn't automate this tedium by providing two-way live data-binding (knockout, meteor, and ember all do this). The best part about having less DOM manipulation code is that it makes writing automated tests easier and makes those test much less brittle.
- extending HTML: this is often a main complaint of angular. People say that directives "pollute the DOM" which I find to be a strange complaint, given that HTML is a declarative (sometimes) semantic language to begin with. HTML5 added a ton of new attributes and features yet nobody complained that these new tags were "polluting HTML". Angular simply allows you to extend HTML's functionality even further, and in doing so it makes it very easy to understand what an HTML template is trying to do without having to dig through any JS code.
- testing: the angular team made testability a priority, which I was something I always really appreciated about the Rails team. If you're not writing tests for your javascript code, you need to start. Having full test coverage in both end-to-end tests and unit tests has been a major source of stability for me and my team.
How did this get so many upvotes? It's a short rant that basically boils down to "Fuck Backbone, use Angular instead"
In fact, here is a verbatim quote:
"Angular is awesome. That is all."
And here's the technical basis of why Angular is better than Backbone:
"Now, I'm not suggestion people don't use Backbone. Use it if it's what's needed for your project, or you yourself are a Backbone ninja. What I'm discouraging here is its popularity as the de-facto client MV*"
I've played around with Backbone and appreciate its structure. I've never used Angular but have seen many compelling posts on HN arguing why it is a better choice in certain use cases. This rant offers no evidence or elaboration. Is it now cool just to hate the popular thing just because it's popular? Even rants against Facebook and Apple have more substance than the OP.
It got upvotes (1) because nobody's talking about Meteor v Derby, (2) because people agree. I'm not the only one wondering why Backbone is de-facto - look at all these responses, 80% of them are agreement. That surprised me, I thought this thread would be buried. Many (like you) think this as insular and inane. I left out detailed explanations of Backbone cons and Angular pros just to get the conversation rolling, and indeed the comments took care of that entirely.
As a mediocre Javascript dev, AngularJS was the first library that clicked for me and helped me avoid the jQuery soup code I was doing more and more as a result of less code on the server and more on the client.
It can be a bit daunting when you are not a JS rockstar : directives and services code architecture, designing views without straight conditional logic, understanding the full power of filters and expressions (I still don't), using jQuery plugins with it etc.
I don't even use routes or forms yet but I had no problem integrating it into a "classic" web app.
The docs need some work though, maybe with more example on certain part. But you can find great code snippet and videos elsewhere.
please provide more context about what type of app you're building. searching for "ember sucks site:news.ycombinator.com" and "backbone sucks site:news.ycombinator.com" is evidence enough that this isn't a simple comparison.
I think it often is a simple comparison. Meteor & Derby, for example, are the exact same use-case - and I think in the end, one will survive the battle and the other lose steam.
People say Backbone & Angular are different use-cases, but I find so many people "graduating" Backbone and wishing they'd chosen a more robust framework. They say they want to start minimal, so they pick Backbone. You can be minimal with Angular. It's like saying "ms paint or photoshop? Well what are you trying to do?" There's only 1 or 2 people really trying to draw something in Paint, the rest "think" they want minimal, non-bloated software. The answer to the question is Photoshop.
Now, Rails v Node v Java, something like that - there are tons of questions to ask before making such a decision, there's no one-size-fits all. But I think there is a one-size in this particular case.
let me put it this way - right now, this month, im evaluating stacks for an enterprise-y amazon-y feeling thing. Say $XX million dollar budget, ~100k LOC with ~10 engineers (mostly cranky and old) for 7 months.
i'm not sure if you're freelancing an app as a sole developer, or if you're an early stage startup, or if you work on amazon.com store. and where your project is, in this spectrum, is incredibly relevant context when you're dissing a framework.
I switched from backbone to angular about half a year ago. It was the best thing that ever happened to the project I was working on. I've rebuilt the complete interface using angular in 2 days. The original backbone version took me weeks (I learned both frameworks from the ground up while writing the interface) It was just a joy to see how databinding and promises where working hand in hand to make my life as a developer so much easier.
I can't explain in terms of Backbone but I'll do my best to clear things up for you anyway. In Angular, you have a magic $scope variable that is available both in your controller function, and in the section of HTML that the controller is bound to. Now I can set any attributes I want to the $scope variable and they will act like models for that controller.
For example. Within my controller, I set $scope.username to "alex" and this will update any HTML bound to the value "username", within the scope, to "alex". Similarly, I can set, say, $scope.settings = {user: {username: "alex"}} and this will update any HTML elements (within the scope) bound to settings.user.username to "alex".
These are very simple examples, but they show the beauty of having plain JS objects as your "models".
We use Backbone at my place of work but Angular.js looks sooooo clean, it makes me wish it would have come out sooner so I could have pushed for Angular.js.
Derby looks interesting, but their sample apps (chat and todo) crash and hang safari on my iPhone. Are folks sure its acceptable for mobile focused web apps? Is this a known problem or something unique to me?
That's that public-face failure bit I pointed out in my post. My own Derby app https://habitrpg.com is smooth-sailing, but people's first impression Derby's home-page examples. For a lot of people, the buck stops there - unbeknownst to them, it's quite stable at HEAD
similar growing disenchantment with Backbone. Minor gripe re: Angular - if you're working with a server side templating language (i.e. Flask/Jinja) you have to configure it to use alternative tags, which could cause problems if working with any 3rd party libs.
Regarding Angular : You can use the data-ng-* way of adding the ng- attributes. Since data-ng- is HTML5 compliant most major server side templating systems should let it pass through.
If you are using custom elements, then you have to figure out a way for your templating system to let it through. In grails for example, you can override it in the taglib's to do that.
I'm just reading HN and in discussions between one of news about ES.next, the conclusion was that it will happen... complete rewrite of everything and it's not like it will happen immediately, we need some time to discover best practices with new language features
* I started out with Backbone. It seems ok as far as it goes, but a bit annoying in that there's enough "magic" and stuff going on that I don't quite understand it completely, but without enough magic to really make things simple and easy.
* Angular.js. Now this is more like it in terms of magic. Then, the other day, I decided to add a date picker to one of my forms. Uh oh: http://www.grobmeier.de/angular-js-binding-to-jquery-ui-date... - how many lines of code just to make it a date picker? I couldn't have written that code myself without several more days of banging my head. Wonder what'd happen if I really try and do something it doesn't agree with... So out the window with that for the time being.
Also: a lot of these tools have tutorials that don't really walk me through all of what I want to do, which initially involves a fairly straightforward "CRUD" type of application. I want to see how the framework deals with both 'make me a new one' and 'edit an existing one' forms, for instance. I found that very irritating about the Angular tutorial, which is otherwise very nicely put together.
Now I'm testing out jquery-pjax, and... so far I'm happier. It behaves more like a web application that I'm used to, sending around HTML, and staying out of my way. And, seeing as how all of these things require that the server do its job in any case, it has more of a "don't repeat yourself" feel to it: click on the button, and the server gives us some new data, without repeating the whole MVC cycle on both the client and server. I got the idea from this post: http://37signals.com/svn/posts/3112-how-basecamp-next-got-to...