Hacker News Reader

Comment by sahrizv | Hacker News Reader

I am just starting up web development and have decided to use Django for backend. However, this Angular vs Ember comparisons have lowered my confidence as I think whatever choice "I" make, will turn out wrong in the long run. Can the experienced people here tell me what I should choose? I am fine with either style of approach to HTML(template vs declarative) and I just want a batteries included framework, which I can use in production, with no severe limitations which may haunt me later.

P.S I am very new to HN and I cant do Ask HN posts :(

View on HN

whatever choice "I" make, will turn out wrong in the long run

Get used to that feeling if you want to be a web developer. You are in one of the most "churning" areas of software technology. None of today's popular JS frameworks were around even a few years ago, and in a few years time I expect we'll see an entirely new set of popular frameworks.

Forget about the "long run." Pick something with a decently-sized community of users and support. Learn it well enough to do what you want to do. Expect to throw that away and learn something else next year. The era of actually achieving "mastery" of any development tools is long gone, at least in the world of web front-end development.

" None of today's popular JS frameworks were around even a few years ago, and in a few years time I expect we'll see an entirely new set of popular frameworks."

You're right, but what needs also to happen is for many others to lose the attitude that others are "doing it wrong" if they don't immediately intuit every nuance of some new library that's 3 months old and was only written for one use case, but touted as the latest hotness which suddenly you're forced to use at work (for example).

I'm fine with understanding the churn and rapid pace - what I don't appreciate is the attitude that just because everything's not 100% obvious to me that somehow it's my fault, when there's little to no docs, no test cases, and a README file that shows a trivial hello world.

By "in the long run" I meant the course of my web app development and enhancement. But I feel happy that there is a consensus on transient utility of these technologies. Community size is a strong factor for me but (un)fortunately both ember and angular have large communities. Thanks a lot for your guidance, esp. the last sentence.

So true. So frustrating.

I would recommend you to take a deeper look at Ember.js.

The article above by Jesus Rodriguez is a good article. It shows how Angular is easy to create _very_ small widgets with. But it doesn't tell you much about how to write a big application.

My experience with Ember (we're creating a very large app with around 100 different routes) is extremely good. More functionality != more bulk. All new features we add to the app fit nicely with the existing code. We never have to go back and refactor large parts of the app. It's the same simple pattern you apply over and over again. I seem to get the opposite impression from Angular apps, where as soon as your app grows more complex you need to take a lot of things in a different direction.

Take a look for yourself at some big and serious companies who are building large open source Ember apps:

Discourse: https://github.com/discourse/discourse/tree/master/app/asset...

Travis CI: https://github.com/travis-ci/travis-web/tree/master/assets/s...

Balanced Payments Dashboard: https://github.com/balanced/balanced-dashboard/tree/master/a...

And check out the new getting started guides: http://emberjs.com/guides/ (especially the screencast by Tom Dale)

I am actually inclined towards Ember.js since the time I was faced with this choice. I just wanted to take the opinion of all the experienced developers here, to back my choice or change it. Thanks for easing the choice. I'll go through the Ember docs. :-)

Thanks for sharing, it's always useful to hear about real-life usage. One thing I didn't hear much regarding Angular/Ember is testing, can you tell us how you approached it?

I can't speak for OP but if you look through the Balanced Dashboard repo there are some good examples:

    https://github.com/balanced/balanced-dashboard/blob/master/test/integration/guest_user_flow.js

For the most part we use integration testing e.g. We simulate mouse clicks and key presses via jQuery and then assert changes in the page behaviour and calls made to the API (see line #85 in above link).

If you approach it like that, and I assume this would be the same for Angular, there's very little testing that's specific to the framework you're building on top of.

At Balanced, even when running unit tests on models to test features in isolation we're still not touching anything inside Ember, occasionally we may jump into the internals to short cut getting the app to a particular state but 99.9% of the time you don't need to.

I'm currently contemplating if I should use AngularJS or Ember.js for my upcoming project. Although I have experience using Ember, I was kind of put off by it because of a) the fundamental changes they made to the routing system in a very late stadium of the platform’s development (AFAIK it was officially introduced in Ember 1.0 prerelease) and b) Ember can be a mind-bender sometimes when you’re working on a large application (having many views and sub-views).

So, I was looking at AngularJS as a potential alternative. At first glance it seems quite straightforward. Until I saw this:

Cage Match – Ember.js vs. AngularJS : http://vimeo.com/68215606

I know that Tome Dale (Ember.js) and Rob Conery (AngularJS) only demo the respective platforms superficially in this video, but it got me leaning towards Ember again.

To comment on your wish to have “a batteries included framework, which I can use in production”: Ember certainly has a lot of batteries included: it’s a framework that makes opinionated choices how you should build a web app.

-To comment on your wish to have “a batteries included framework, which I can use in production”: Ember certainly has a lot of batteries included Thanks for considering those factors. Your reply was very helpful.

Don't worry so much about picking the right tools. Just pick something that is popular and start using it. You want something that is popular to start with because a) there will be a large support community and b) there will be more jobs available for someone who knows a popular framework. That second point is most important, because until you start building/working on an in-production project, most of your efforts will be purely academic. Once you have some years of experience under your belt, you can reflect on the technologies you know and figure out where you would like to grow into next.

Ultimately, the goal is to be in a position where you can confidently examine new and old frameworks and techniques, and make confident, informed decisions about what to use. But at the beginning of your career, you won't have the experience and perspective to make those decisions, so just start working on something and don't worry about making sure it's the 100% right thing for all time.

Good luck!

Thanks for reminding me of the employment aspect! For the popularity, I believe both ember and angular have large communities. I checked the jobs and angular although leading here, is comparable to ember in terms of job opportunities.

If you look at Google trends there is a massive spike in Angular interest: http://www.google.com/trends/explore#q=angularjs%2C%20emberj...

I'm not saying this should play the biggest part in your descision, but it's worth noting. I implemented 2 small apps in both frameworks, giving me a small fixed amount of time for each. I liked both, Angular gave me less head-scratching and out-of-the-box Twitter Bootstrap integration.

Another consideration is the projects that have been built with each framework. That can help you gauge popularity, where the jobs are, where you could get a job (or potentially poach someone from), and the capabilities of each library/framework:

http://backbonejs.org/#examples

http://emberjs.com/ember-users/

http://builtwith.angularjs.org/

What kind of "batteries" are you looking to be included? Knockoutjs doesn't automate saving to the server (though it can do everything up to the Ajax call), and IMO it has a pretty intuitive model and near-perfect docs. As a recent convert, I would recommend that you consider it. Unless you've already rejected it for your own reasons, in which case I'm curious what those are.

PS: the tutorial does have a little opaque magic. IMO the biggest need in the docs is some overarching theory. The trick is that applyBindings applies to the whole document by default, but can be restricted to another DOM node.

Knockout only really works if you totally intermix your model code with it. You have to annotate every darn thing until it's impossible to see what the underlying logic was.

Angular's docs suck, but my own code is safely isolated and can be easily developed and tested in isolation.

Hm. In my case, I would have had to invent something like ko.observable anyway, so I guess it works for me. Maybe I'll learn better when things get more complicated.

I'm not saying that it's wrong. KO's approach is a defensible architectural alternative. I guess I took an unnecessarily snotty tone in my previous comment.

However, KO's design it didn't sit well with how I wanted things to work. Basically I want plain javascript for my own core logic and then to have round-trip binding to the user interface with a minimum of fuss.

For simple cases, Angular does that reasonably well. More complicated cases require a much more intimate engagement with Angular's design and architecture, which is where my gripe about the docs becomes relevant.

No offense taken. I did find that my "model" code was basically the same as the viewmodel. I'm not sure how much that matters or how hard it will be to change, hence "maybe I'll learn better".

I was looking for a framework which can handle as much as possible of the configuration, plumbing and any other processes which are involved in web development. I know that is not exciting and causes limitations, but being a novice in this field, I do not want to be messing around with the basics. I rather want to focus on the core business aspects of my venture. :-)

Django for a backend will work good with any frontend framework (ember.js, angular.js, backbone.js, etc).

I think that none of the actual frontend frameworks will disappoint you. I just showed my opinion in one of them :)

I'm a django expert and I've built dozen of projects with it. So it would be hypocrite of me to tell you not to learn it. On the other hand, when I first started learning it, it was a young framework not well known (PHP was still hot.. Rails and Django developers were the hipsters of the web on the edge of technology ;-)

I'm pretty happy about my choice to be on the edge as when it got mainstream, I was already very proficient with it. So, in that sense, I think I'd still suggest you to pick a more edgy framework.. say Node with Angular (or ember).

I understand the point you are making. The only problem with picking up a relatively less mature/complete framework is that I intend to use it in production. Since I am starting up as a novice, I cannot afford to sacrifice maturity for the high of being on the edge. I realize there's benefit for me in being on the edge as you mentioned( and I would love to play with the newest toy), but in my case, I unfortunately can't do that. Thanks for stopping by! :-)

Btw, node.js / angular is production ready. There are others edgy framework or languages that I wouldn't recommend for the exact reasons you are saying.

Choose Backbone.js - the one true choice.

If I were starting again, I'd start with something like the mean.io. It's a stack that's javascript from database to front end. You'll be starting with the latest and in only one language, which could lower your learning curve a bit.

Mean.io is especially appealing to newcomers like me because it hides significant complexity in linking up stuff on the node.js platform. However, the only thing which puts me off is the instability/novelty of node and consequent unsuitability for production environments. Django OTOH has been battle hardened, and there is help available if I hit a wall. Not at all to say that the node community is not helpful. It's vibrant and helpful but there are simply too many gotchas yet to be resolved, and more importantly, discovered and I do not want to be the one doing this discovery, midway through my startup. :-)

Are you sure you want to use Django?

Actually I did give a thought to Node.js/express and more pleasantly, the recent one called Mean.io. Mean.io is especially appealing to newcomers like me because it hides significant complexity in linking up stuff on the node.js platform. However, the only thing which puts me off is the instability/novelty of node and consequent unsuitability for production environments. Django OTOH has been battle hardened, and there is help available if I hit a wall. Not at all to say that the node community is not helpful. It's vibrant and helpful but there are simply too many gotchas yet to be resolved, and more importantly, discovered and I do not want to be the one doing these discoveries, midway through my startup. :-)

Regarding ROR, I'd say I have never even seen the language or the framework. Since I have done previous work in NLP/ML I was inclined to learn python so that I can utilize the huge spectrum of Python based ML/NLP libraries, which I believe Ruby lacks.

As someone who made that choice a while back, I can understand your reasons. I was also familiar with Python from my projects at college and so Django was a natural choice for building a web app. But, I struggled with a lot of basics in Django and then switched to Rails. I can speak with confidence that Rails ecosystem is amazing and the learning curve is easier thanks to the bunch of tutorials and screencasts available.

Though, I hear that the beginner resources in Django have improved a lot lately. If that is the case, it should be an equally good choice.

That was just a little joke that went over a few heads. At least you have one framework choice nailed down.

Reply on news.ycombinator.com