Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rant: Backbone, Angular, Meteor, Derby

gist.github.com

Post reply on HN
Print view View original

111–120 of 163 posts

Re: Rant: Backbone, Angular, Meteor, Derby

#111

Post by jaequery »

salmanapk wrote: post #92
jaequery wrote: post #63

Earlier quoted context omitted.

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 le…

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? 1: https://www.youtube.com/watch?v=oJoAnVRIVQo

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.

Re: Rant: Backbone, Angular, Meteor, Derby

#112

Post by ganarajpr »

sunwukung wrote: post #88

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.

Re: Rant: Backbone, Angular, Meteor, Derby

#113

Post by nesquena »

krebby wrote: post #76
steveklabnik wrote: post #57

Earlier quoted context omitted.

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...

Huge +1 on rails-api. When used in combination with rabl, it's the most formidable Backend solution there is.

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.

Re: Rant: Backbone, Angular, Meteor, Derby

#114

Post by ryan_f »

davidw wrote: post #94
danso wrote: post #93

Earlier quoted context omitted.

I was just going to post this...Seems like 99% of the anti-backbone posts is that there isn't enough magic in it.

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-…

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.

Re: Rant: Backbone, Angular, Meteor, Derby

#115

Post by steveklabnik »

nesquena wrote: post #113
krebby wrote: post #76

Earlier quoted context omitted.

Huge +1 on rails-api. When used in combination with rabl, it's the most formidable Backend solution there is.

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.

As I said below, if it doesn't, please let us know: I'd consider that a bug.

Re: Rant: Backbone, Angular, Meteor, Derby

#116

Post by ganarajpr »

krebby wrote: post #105
lucisferre wrote: post #103

Earlier quoted context omitted.

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 und…

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!).

Re: Rant: Backbone, Angular, Meteor, Derby

#117

Post by jaequery »

davidw wrote: post #94
danso wrote: post #93

Earlier quoted context omitted.

I was just going to post this...Seems like 99% of the anti-backbone posts is that there isn't enough magic in it.

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-…

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.

Re: Rant: Backbone, Angular, Meteor, Derby

#118

Post by steveklabnik »

marekmroz wrote: post #78
catch23 wrote: post #69

Earlier quoted context omitted.

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 interconne…

> but once you get up and going (...) 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.

Re: Rant: Backbone, Angular, Meteor, Derby

#119

Post by steveklabnik »

heyitsnick wrote: post #79
samratjp wrote: post #70

Earlier quoted context omitted.

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/guide…

> 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 applicati…

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.

Re: Rant: Backbone, Angular, Meteor, Derby

#120

Post by ganarajpr »

joshontheweb wrote: post #99
eterpstra wrote: post #38

Earlier quoted context omitted.

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.

Post reply on HN