Live data from Hacker News

Rant: Backbone, Angular, Meteor, Derby

gist.github.com

101–110 of 163 posts

Re: Rant: Backbone, Angular, Meteor, Derby

#101
post #83

[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: aut…

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…

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

Re: Rant: Backbone, Angular, Meteor, Derby

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

We actually think that AMS is significantly better, but I'm glad rabl works well for you. :)

Mostly for the gluing and custom node editing, but also I really like keeping my rabl files (presentation) outside of my models

Re: Rant: Backbone, Angular, Meteor, Derby

#103
post #96
post #14

Try knockout. I wrote a quick intro to it a few days ago: http://returnbooleantrue.blogspot.com/2012/12/architecting-k... I personally don't like backbone that much. I don't know why so many people love the damn thing. It is hard to understand and not even that great.

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

Re: Rant: Backbone, Angular, Meteor, Derby

#104
post #76

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.

Ams is far better than rabl.

Re: Rant: Backbone, Angular, Meteor, Derby

#105
post #96

Earlier quoted context omitted.

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

Re: Rant: Backbone, Angular, Meteor, Derby

#106

[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: aut…

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.

Re: Rant: Backbone, Angular, Meteor, Derby

#107
post #26

Earlier quoted context omitted.

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…

Probably should have said that in your article if thats what you meant. It came off as a pretty insular point of view with 'rant' in the title.

Updated the article, thanks for the advice

Re: Rant: Backbone, Angular, Meteor, Derby

#108
post #102

Earlier quoted context omitted.

We actually think that AMS is significantly better, but I'm glad rabl works well for you. :)

Mostly for the gluing and custom node editing, but also I really like keeping my rabl files (presentation) outside of my models

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

Re: Rant: Backbone, Angular, Meteor, Derby

#109
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"

Download all the examples and reverse engineer. That's what I did and I'm glad I did it because I'm loving Ember.

Re: Rant: Backbone, Angular, Meteor, Derby

#110
post #36

I have a rant coming about these things too. * 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…

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.

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".
Post reply on HN