Live data from Hacker News

Angular or Backbone: what are startups using?

blog.backlift.com

71–77 of 77 posts

Re: Angular or Backbone: what are startups using?

#71

I've played with both and I honestly still don't feel comfortable with computing the view on the client side instead of in my code on the server. Most of the form factors we use regularly to access HTML5 type applications are in flux. Today we see the latest quad-core Snapdragon that screams across the silicon leaving empty battery cells in its wake. Tomorrow may be a battery friendly OS that sacrifices resources in…

Completely agree. I love these new frontend JS frameworks - particularly Angular, Facebook's React, and the Guardian's Ractive - technically they're fun to learn, mind-expanding, and really impressive work. But using them has the effect of shifting computational work from the server and network to the client - eg, from an environment you control to one you don't. Besides the examples you gave, what if someone loads y…

Couldn't this same argument be made against native apps?

Re: Angular or Backbone: what are startups using?

#72
post #26

I have used both in my startup job and vastly prefer angular to backbone, however I think it's not quite an apples to apples comparison as angular provides a lot more than backbone. That isn't meant as a criticism of backbone per se, rather I think they are actively going for different things - backbone makes it easy to achieve a client-side rendered single page website with MVC separation but lets you control actual…

After spending two or three months with Angular, I’m running away screaming. I really owe people a blog post about it, but basically, it’s hard to debug, weird for weird’s sake, and polluting of the HTML namespace. Death by a thousand cuts — and by disregard for best practice.

Polluting the HTML namespace? Have you looked at the emberjs (actually handlebars) generated html recently? View the generated output for everything that is bound and tell me you don't want to run away screaming.

Re: Angular or Backbone: what are startups using?

#73

Earlier quoted context omitted.

Completely agree. I love these new frontend JS frameworks - particularly Angular, Facebook's React, and the Guardian's Ractive - technically they're fun to learn, mind-expanding, and really impressive work. But using them has the effect of shifting computational work from the server and network to the client - eg, from an environment you control to one you don't. Besides the examples you gave, what if someone loads y…

Couldn't this same argument be made against native apps?

I'm not a native dev so I can only speculate, but based on my personal experience with Android the past few years, I don't think so simply b/c there's no better alternative yet, performance-wise at least.

On mobile, native still offers better performance and integration than html5/javascript apps, the network latency is more variable and less manageable than with wired broadband, and Android and iOS are tuned more to manage resource usage and even hibernate all but the currently active app if necessary.

And I'm not sure how much flexibility native SDK's provide developers to decide where things like rendering get done anyway. There's definitely some subset of stuff that can be done serverside, hence the existence of Parse and Stackmob, but I don't know the details. There may not be much choice in the matter.

Re: Angular or Backbone: what are startups using?

#75
post #26

Earlier quoted context omitted.

After spending two or three months with Angular, I’m running away screaming. I really owe people a blog post about it, but basically, it’s hard to debug, weird for weird’s sake, and polluting of the HTML namespace. Death by a thousand cuts — and by disregard for best practice.

I'd be interested to read about your issues with it. It is definitely weird , but I don't think it's for its own sake, rather it's adding a new layer of abstraction which will always come off as a bit strange until you get used to it, e.g. lisp. I've not had awful problems debugging it, certainly no more than any other js library spitting out "cannot read property 'foo' of null" all over the place with stack traces t…

Batarang[0] is chrome plugin that vastly helps with debugging angular. I also highly recommend approaching it from a TDD standpoint. The seed[1] project comes with a baked-in testrunner. This also helps you move away from direct dom manipulation unless absolutely necessary: treat it like the definition of an html DSL specific to your app.

0. https://chrome.google.com/webstore/detail/angularjs-batarang...

1. https://github.com/angular/angular-seed

Re: Angular or Backbone: what are startups using?

#76
post #28

I've played with both and I honestly still don't feel comfortable with computing the view on the client side instead of in my code on the server. Most of the form factors we use regularly to access HTML5 type applications are in flux. Today we see the latest quad-core Snapdragon that screams across the silicon leaving empty battery cells in its wake. Tomorrow may be a battery friendly OS that sacrifices resources in…

I've been wondering about client side vs server side view rendering as well. I am used to working with server side MVC frameworks so rendering the view client side is a bit odd to me. Is the ability for the end user to see some of the view markup (conditional statements, loops, etc) an issue?

Think of it like this: you still have model+controller at the server side (REST interface), the whole HTML+Javascript thing is the view layer. This view layer happens to be modeled using the MVC pattern, which is a pretty smart move if you are writing complex user interfaces.

For example, if you are mimicking a spreadsheet, it is very handy to have the presentation layer modeled in MVC instead of writing all the old-fashioned-jQuery-spaghetti-code way.

Re: Angular or Backbone: what are startups using?

#77

I've played with both and I honestly still don't feel comfortable with computing the view on the client side instead of in my code on the server. Most of the form factors we use regularly to access HTML5 type applications are in flux. Today we see the latest quad-core Snapdragon that screams across the silicon leaving empty battery cells in its wake. Tomorrow may be a battery friendly OS that sacrifices resources in…

Completely agree. I love these new frontend JS frameworks - particularly Angular, Facebook's React, and the Guardian's Ractive - technically they're fun to learn, mind-expanding, and really impressive work. But using them has the effect of shifting computational work from the server and network to the client - eg, from an environment you control to one you don't. Besides the examples you gave, what if someone loads y…

That's how thus industry had operated throughout its, albeit short, history and will continue to do so. If Twitter/Facebook survive another 10 years, they'll do the server-/client-side tango another two iterations at least.

It's faster, less resource intensive (from a revenue standpoint) and more easily targeted to isolated groups of users to implement innovative solutions on the client-side. Through testing and days analysis, those techniques can be vetted, with clear "winners" moving from industry-accepted best practices to finally becoming true open standards (20 years later).

Shortly after the transition to industry accepted best practice, we see the risk takers (businesses) internalizing those features back to the server-side so that their user base as a whole can reap the benefits. All while freeing up resources within their product (your client) to start the process over again on the "next big thing".

Post reply on HN