Comment by ebiester | Hacker News Reader

Comment by ebiester | Hacker News Reader

Parent Full thread

Looking at todoMVC, YUI takes ~400 lines of code to do what Angular does in 135, ember does in ~160, jQuery does in ~160, and even Backbone does in ~350 (and is anyone starting a project with backbone today?). Backbone unpacked, however, is only about 900 lines without spaces and comments. How big is YUI?

To be fair, the YUI version has more comments, but it's fundamentally harder to follow too, IMHO.

Further, YUI did a poor job of getting tutorials out at the quality of those available today for backbone, ember, and angular. As such, I at least found no approachable way to really get a mental model without working on an existing YUI project with a mentor or reading through a lot of documentation.

I had done a simple YUI proof of concept with YUI 2, and went, "this is more work than jQuery" and never went back.

So people reinvented the wheel, but they made it better. I'm glad that Yahoo blazed the path, but I'm not convinced it's the better option today.

I'll never understand the web world. A couple of months Backbone was all the rage and now no one is using it?

I believe they still are. Backbone is a library. Angular and Ember are frameworks based off that library if I understand correctly.

No. The projects are completely separate.

I'm not sure about Angular, but ember is definitely not based off of backbone (and probably not Angular either)

I should restate: if someone started with backbone on a project, there's no reason to pull it out and restart with ember. It has its advantages for a certain type of project and a certain type of developer today.

If you like minimal frameworks, like to make your own design decisions and want to build your own framework on top of a library, backbone is great.

If you are just looking for a minimal subset of MVC because you're doing some high-concept app that doesn't fit into the standard web application paradigm, it's worth looking at backbone.

Most importantly, if you're retrofitting an existing application, backbone will be invaluable for years.

The ideas behind it are solid and relevant today and it's not a bad idea to use it. I just believe that if you are starting a web application today, for 95% of the use cases, you are better off sticking with jQuery or moving to Ember, Knockout or Angular.

That isn't to disparage any of the other libraries and frameworks, though.

> for 95% of the use cases, you are better off sticking with jQuery or ...

This is terrible advice. If you can't tell the difference between a procedural app full of jQuery callbacks and a an app modularized with Backbone objects, then I don't think you have had real experience writing apps with either of these libraries.

It depends. Are you doing single page apps? jQuery is awful advice. Are you doing internal 2007-style internal apps with only a small amount of interaction? I'd argue jQuery is a cost-effective way to get a project out.

I haven't figured out how to get a team who is "barely" conversant in javascript productive in an MVC framework just yet, myself.

It's not true. A lot of people are perfectly happy with Backbone.

This "X is old hat, use Y" phenomenon of "hype recycling" is part of a cultural problem that seems particularly endemic to the startup world. There is a lifecycle of "bleeding edge" to "mature" to "abandoned" that never lets up. There is always a newly-hyped library or framework or methodology that's trying to shift people's attention; and rather than refining and evolving the existing stuff into stability and maturity, many devs start new, wobbly, immature projects. But the bleeding edge is fickle, and when the dust settles there are some remaining competitors, but then suddenly the dust rises again and you're urged to abandon everything because the new stuff is in a separate programming language, so everything else is now incompatible; so the cycle goes. It results in a lot of work, and I like the competition and sheer energy of a developer community fired up about something, but I believe there is also a lot of work wasted.

Sometimes I wish software developers were more like engineers, and that people slowed down a bit. As one gets older, one gets to value maturity over novelty, and to see the importance of backwards compatibility, transition paths and careful releasing.

It all depends on what kind of app you're writing. If you're happy with whatever solution you're using then it's foolish to change just for the sake of change. However, I've known multiple developers who started with Backbone and then found that it wasn't able to meet their needs and then switched to Ember. Zendesk is one such example. The goals of Ember are actually very different from Backbone. Furthermore, living on the bleeding edge with others is better than living on your own bleeding edge by yourself with a ton of code that you rolled on your own.

Oh, sure. Changing libraries/frameworks in order to satisfy one's requirements -- or for quality reasons, or for any other good reasn -- is completely justified. It's the habit of chasing whatever is today's new hot thing that I dislike, and similarly, the habit of dismissing yesterday's favourite as being old hat.

As for Ember, I'm sure Ember is wonderful. I still haven't figured out what design decisions in Backbone drove develpers to create Ember, but I'm not qualified to question it. Either way, Ember and Backbone are both trying to solve the same basic thing: Providing an MVC framework for JavaScript, mostly focused on the browser. As I understand it, Ember wants to be a more complete toolkit than Backbone, which is very simple and minimalistic and leaves things like templating to other libs.

What is interesting is that Yehuda Katz was also behind Merb, which in my mind is a good example of a gratuitous project; Merb was someone reinventing Rails with the goal of being perhaps 10% better than Rails in the areas of performance and modalarity, while at the same time completely incompatible, and a lot of people jumped on the bandwagon. As it turned out, the developers decided to reimplement Merb's conceptual improvements back into Rails and shut the project down.

Again, I'm not qualified to critique Ember, but the Ember/Backbone competition certainly looks, on the surface, a lot like the Merb/Rails situation back in the day. I would love to hear more about why the devs decided to create Ember and not evolve Backbone. If the Backbone devs did not want to go in Ember's direction, that is of course a perfectly acceptable (if unfortunate) reason to start over.

This talk I gave last year describes some of the problems that Ember attempts to address that libraries like Backbone don't: http://vimeo.com/49434697

Thanks. I don't have time to watch the talk right now, but skimming through it, it sounds like a view layer like you describe could perceivably be bolted on top of Backbone, at least if one added support for attribute-level bindings?

LOCs aren't a great metric. I'm far more productive with Backbone than with JQuery alone and Angular offers a fundamentally different approach (stuff auto-magically just works) which is brilliant but isn't always easy to customize.

I agree about YUI though ;-)

I get your point about angular -- I tend to think it has a particular use case in mind and does really well for that one. However, my point was that backbone doesn't give you much more than plain javascript itself -- let's not expect to abstract everything away compared to one of the full service frameworks. YUI, however, is aiming to be a full service framework. What is the additional benefit?

Now, it's possible that YUI would show itself closer in terms of LOC/complexity to the other frameworks in a larger application. But looking piece by piece, ember and angular just seem to do things more efficiently, more clearly than YUI. And that was my point when discussing LOC.

How do you check the loc on todoMVC (without you know, going into the half dozen different files and adding them all up)?

There's a nifty tool called 'cloc' that makes it really easy.

Coincidentally, I wrote about earlier this week: http://blog.jerodsanto.net/2013/02/cloc-counts-lines-of-code...

Reply on news.ycombinator.com