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

151–160 of 163 posts

Re: Rant: Backbone, Angular, Meteor, Derby

#151

Post by samratjp »

steveklabnik wrote: post #119
heyitsnick wrote: post #79

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

ah yes, you're right - meant to say that handle the serialize/de-serialize yourself at first to get your feet wet.

Re: Rant: Backbone, Angular, Meteor, Derby

#152

Post by charlesjshort »

ams6110 wrote: post #135
debergalis wrote: post #24

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

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. [1] http://en.wikipedia.org/wiki/FLOW-MATIC

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.

Re: Rant: Backbone, Angular, Meteor, Derby

#153

Post by joshontheweb »

OriginalSyn wrote: post #130
joshontheweb wrote: post #95

Earlier quoted context omitted.

ng attributes are invalid html attributes. Any non-standard attr should be prefaced by 'data-' according to the spec. edit: Also to you point about dom manipulation. The same amount of dom manipulation is happening. You just aren't in control of it.

BTW Angular supports prefixing your 'ng-' attributes with 'data-' if you want valid HTML.

Didn't know that. Makes it a little better ;)

Re: Rant: Backbone, Angular, Meteor, Derby

#154

Post by ganarajpr »

CapnCrooked wrote: post #128
ganarajpr wrote: post #72

Earlier quoted context omitted.

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

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

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.

Re: Rant: Backbone, Angular, Meteor, Derby

#155

Post by ganarajpr »

politician wrote: post #145
SoapSeller wrote: post #141

Earlier quoted context omitted.

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

There is a multitude of two-way DOM data binding add-ons for Backbone.

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.

Re: Rant: Backbone, Angular, Meteor, Derby

#156

Post by nailer »

ams6110 wrote: post #134
jtchang wrote: post #127

Earlier quoted context omitted.

I hardly feel that backbone is well written and straightforward. This is one of the lines in backbone.js: if ((callback && callback !== (ev.callback._callback || ev.callback)) || (context && context !== ev.context)) 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.

callback._callback seems a little obscure to me.

Re: Rant: Backbone, Angular, Meteor, Derby

#157

Post by nailer »

krebby wrote: post #77
jtchang wrote: 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 don't you like about Backbone? I never hear anything constructive or even a solidly coherent argument from its detractors

Official docs are terrible. Other sources are better but not maintained with the current release.

Re: Rant: Backbone, Angular, Meteor, Derby

#158

Post by securingsincity »

samratjp wrote: post #70
securingsincity wrote: post #53

Earlier quoted context omitted.

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

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.

Re: Rant: Backbone, Angular, Meteor, Derby

#159

Post by uptown »

robomartin wrote: post #139
uptown wrote: post #74

Earlier quoted context omitted.

"For browsers that don't support pushState pjax fully degrades." Source: https://github.com/defunkt/jquery-pjax Wouldn't that suggest that any search-engines wouldn't have an issue indexing your site if you implement things correctly?

Not sure. I'd have to run a test to really know what "degrades" means in real life. I was hoping someone would know.

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.

Re: Rant: Backbone, Angular, Meteor, Derby

#160

Post by wilmoore »

jtchang wrote: post #127
dustingetz wrote: post #89

Earlier quoted context omitted.

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 hardly feel that backbone is well written and straightforward. This is one of the lines in backbone.js: if ((callback && callback !== (ev.callback._callback || ev.callback)) || (context && context !== ev.context)) 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.

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.

Post reply on HN