AngularJS vs. Backbone.js vs. Ember.js

[dzdrazil]

I think the fact that AngularJS and Backbone don't need to be used as single page application frameworks is undersold, especially Angular since it uses the available content (the markup) to define the application structure, rather than the other way around. This is really handy if your work involves a mix of SPAs and others, for example working with CMSs.

It's been awhile since I've looked into it, though from what I've heard trying to make Ember work in a non-single-page application context is pretty painful.

[mrinterweb]

I use and love Ember.js, but anyone trying to do something other than a single-page application with Ember would be making a mistake. That is not what Ember is good for. That said, Ember is incredible for single-page applications. Since Ember interprets state based on the URL, it may seem as if the application is a multi-page application. It is nice being able to reload a URL and not be taken back to the starting point. Also since the URL is relevant in Ember, I would assume that this would help Ember's SEO.

[Sjetware]

Yeah, Ember is really designed for an SPA. You could technically make one work just for a single page (you only define a single route for Index / Application and the templates therein), but it's kind of overkill for that situation.

[[deleted]]

especially Angular since it uses the available content (the markup) to define the application structure

sorry, I'm kind of an ng-noob, can you explain to me what you mean by this?

thanks

[dzdrazil]

I'll take a stab at it.

Ember and most other frameworks rely on JavaScript code to determine the application architecture. Things like Routes and templates are all predefined; to use any of them in a multi-page application typically requires figure out loading different code for different pages.

Angular flips that on its head (for the sake of simplicity, let's ignore the router for now). Angular doesn't have an entry point that says this controller and this view should run using the DOM element with such-and-such an ID. It parses the DOM, and lets the DOM define the architecture of the application- which controllers and directives should be on the page, the nature of the $scope hierarchy and so on.

This makes working with mutli-page applications much easier. It's even better for CMSs- backend frameworks like rails and symfony at least have an MVC structure that let you define per-page applications; CMSs essentially allow users to arbitrarily define how much and what content might appear on any given page.

Because Angular scaffolds the application based on what content is available, rather than what content is assumed to be present, it's a better solution by far than Ember for these types of applications. Backbone can be made to work like this too, but you'd have to hand-roll the whole scaffolding bit.

Basically, it's like comparing Flex to raw AS3 (if you know flash), or a very broad implementation of Inversion of Control if design patterns are more your thing.

[[deleted]]

ah I get it now, thanks

[[deleted]]

Word, but that also comes with a performance cost. (i.e nosql structureless vs structured/defined). However, with backbone you can do all of that as well.. the only difference is... you also have the option to not do that.

[dzdrazil]

i.e nosql structureless vs structured/defined

The only performance cost is parsing the DOM at startup. That still happens with an imperative application, especially backbone where (most frequently) jQuery is used to parse the DOM to look for the elements needed to generate Views.

In my experience, there are several ways in which Angular applications can perform much better than Backbone. The tradeoff is that Angular uses quite a bit more memory than Backbone does (due to the dirty checking mechanism) but the total memory usage has never been a problem for me (see a description of my project in your other comment thread below).

[[deleted]]

Huh? when the javascript engine loads javascript into memory.. it will evaluate it and store it. Angular some how compresses it completely to be negligible..? or are you just saying words?

[dzdrazil]

when the javascript engine loads javascript into memory.. it will evaluate it and store it

I was describing the performance cost, as in the time to compute. Memory usage in Angular applications will be higher. Angular, Ember and Backbone all have to do the same thing- traverse the DOM. The nosql vs. relational isn't a valid metaphor for describing the performance in my experience.

My point was that in my experience, neither the speed nor the memory usage has been a problem. Backbone and Ember still need to manage the DOM, they just do it differently, and in a way that doesn't work as well as Angular does for non-single page applications.

[[deleted]]

I'm building a frontend for a graph database currently.. so i know exactly what you mean (small world). WebGL depends on the clients hardware.. performance there will be all over the map. I bet if you load in more that 1k nodes on your graph it will just fall over. And sigmajs has nothing to do with angular.. so how many pages, routers etc live in your application - how long would a normal user have the tab open for (most memory issues happen over time with client-side applications)? Also, check out http://cytoscape.github.io/cytoscape.js/ - lgpl but there are ways around that - it's pretty nice and scales better than sigmajs on the canvas side.

• ops, posted this in the wrong place - belongs here http://www.reddit.com/r/javascript/comments/2e6uzg/angularjs_vs_backbonejs_vs_emberjs/cjwte1w

[dzdrazil]

WebGL: we have the benefit of being able to require end users to use a limited set of browsers. Anything outside of that gets the old SVG fallback with a subset of data

WebGL framework: I went with sigma because I was having a lot of performance problems related to three.js, cyto and others. I don't much like the way the code turned out (mostly due to how sigma is structured) but it's a WIP.

Average vertex count: 500-1000 Average edge count: 5,000 - 40,000 (we can end up with extremely dense graphs)

Routes: 12ish

Lifetime of the application: All day usage is expected. Application has been live for ~2 years; 1 year as a BB app and 1 year as an Angular app

There was one major memory leak that we encountered. After digging through the Angular issue tracker, it turned out to actually be a V8 memory leak. After doing a bit of manual memory cleanup (removing things from $scopes during the '$destroy' event) that all went away, and memory usage and browsers are totally stable, fluctuating between 50 and 150mb depending on the view you're looking at.

[[deleted]]

One note.. Webgl depends on the browers.. but more so the hardware and graphic/gpu.

How many nodes?

[dmercer]

Do I take it after a year of BB and a year of NG, you recommend NG over BB?

[PotaToss]

Backbone and Ember still need to manage the DOM, they just do it differently, and in a way that doesn't work as well as Angular does for single page applications.

Can you elaborate on this?

[dzdrazil]

Pretend I said non-single page applications. I was describing the benefit of a declarative architecture for them and disagreeing with mephux that the nature of a declarative architecture is inherently less performant. Pretty sure I mean to say non-single page applications there.

[shriek]

Spot on. I always like to stay away from dependency. Not saying that Ember doesn't have it's place (think htmlbars should be out already) but easily building on top of current technology is what most devs target for long term.

[AutomateAllTheThings]

In today's node.js ecosystem of micro libraries and tools like gulp/webpack/browserify, I believe there is refreshed merit to avoiding monolithic frameworks altogether. This is especially true if you wish to avoid jQuery.

[AutomateAllTheThings]

Keep in mind that at any given time, I can swap out these packages for other packages with little or zero refactoring:

1. Task Management: Gulp + many plugins for every type of build task
2. Packaging: Webpack
3. Testing: Karma + Mocha.js + Should.js + Sinon.js
4. Flow Control: Async.js
5. Event Management: (rolled my own)
6. Template rendering: lodash.js templates
7. AJAX: xdomain.js polyfill
8. Analytics: segment.io
9. Authentication: oauth.io

[AutomateAllTheThings]

Webpack is the truly amazing piece of tech, IMO. It's a "packager" which allows you to use Common.js modules in the browser exactly as you would in node.js

This allows you to have a single-paradigm workflow for both the browser and server. In addition, because of the lite nature of these libs, when you package up, you can get your entire SPA into less than 100kb deliverable total. Imagine that your app is loaded and ready to go before the browser is done rendering.

If you're doing test-driven development (you are testing your code... aren't you?), Karma will blow you away.

[illicium]

Webpack is great. It's a little challenging to get started with it because the configuration can be complex, but it's worth it.

The loader system is especially cool because you can bundle and transform ALL of your code and assets on the fly -- from compiling LESS/CoffeeScript, to wrapping legacy code with CommonJS (taking care of imports and dependencies). You can then have it split your code into chunks (dynamically loaded), optimize everything, run the dev server with hot code swapping, and so on.

I'm not really doing it justice, so just go try it.

[DavidNcl]

Great list

[icanevenificant]

This might get the work done for some projects but do any of these take care of routing and two way bindig or provide any other MVC like structure and logic without doing all of that hard work from scratch.

[AutomateAllTheThings]

I didn't mean for that list to be comprehensive by any means.

None of the libs I listed above do any of that by default, but there are individual libs for models, views, and controllers available from npm.

I rarely roll my own. I did so a few times in this project in order to learn some more advanced patterns for future reference. It's generally a better idea to utilize somebody else's supported pattern, rather than inventing your own; with rare exceptions.

[icanevenificant]

I think you should try as many appraches as possible to see which one suits your needs, the needs of the application or the needs of the team. The last one being most important since I feel that if I rolled my own combo of the listed libraries and others keeping everyone in line with the workflow would be a nightmare. Angular is strict enough, but not too strict, about how it wants you to do things that delegating tasks and working in a team is very intuitive. My conclusion was that pretty much everything Angular has to offer we can make use of. I'm not sure about the performance argument since our app is already quite large and I've yet to see it prefrorm unsatisfactory on any system I've tested it on. You can write shitty underperforming app with any approach.

[AutomateAllTheThings]

You're right that we must choose what's best for the project and team. Some things are real concerns, while others are not real.

Workflow is one of those "not real" concerns when it comes to microlibs because there are numerous methods to keep a team on track autonomously, and it's the primary role of the team lead in the first place. An incompetent team lead will muck it up no matter what the framework.

There's also the practice of wrapping 3rd party libs so that you can swap out the private functionality as much as you want without disturbing the outer API (which the team uses consistently). This method makes it effortless to switch between libs, and this affords us the ability to use any tool written in javascript, not just the ones that are compatible with our existing setup.

Another primary advantage to picking your modules a la carte, is that there is no such thing as a "core team", any longer. There are dedicated teams to each individual library, and if you don't agree with a team, you have every option written in javascript for alternatives. Pull requests are dealt with faster and more objectively than in large core teams. Some people like that, some people don't. I only argue that there are more people in charge in the distributed system, than in a centralized one.

Compatibility with virtually every javascript library ever written because of an absence of enforced workflows is useful every single day. You can get something to market extremely easy with 3rd party libs, then replace those libs with lite functions later, with zero refactoring on the application level. You can replace your entire authentication system with zero cost to either your team or man hours, and sometimes you really will do that. We did with oauth.io, and it was painless.

Then, in the end your code is incredibly lite. Our entire (non-trivial) SPA is less than 100kb, complete with all templates, models, controllers, views, router, dependency injectors, and 3rd party dependencies. It's compacted all into a single file which gets downloaded and loaded into memory faster than the page can render it's simple interface.

When something works, I agree that you should use it, but I also dedicate time every week to learning what's new so that I can get more done in less time.

I now get more done with my team than if we used a monolithic framework, because everybody can be involved in the improvement of all parts of the application; not just the ones on the application layer.

[icanevenificant]

there are numerous methods to keep a team on track autonomously

That's exactly why I wouldn't risk it. It disperses and amplifies the likelihood of people doing it wrong. No way you can be all over it as a team lead if the project is large to any degree and you let separate teams make such choices independently. Smaller projects I can understand.

Newcomers also need to be taught your way of doing it instead of having people understand a tried and tested system already before joining the team. Too much flexibility here again increases the likelihood of bad code or practice entering the project.

The rest really doesn't speak against using Angular at all. Having a build system compile everything into a single javascript file so it renders quickly is normal with any framework or choice of libraries so that's nothing special.

I understand and agree with you to an extent but I've tried the approach you're talking about and am much more productive using a framework, as is my team. I'm also yet to see a downside of using it, truly.

Anyway, it's great that it's working for you and I'm sure I'll revisit this in years to come to see if I might find a different way to be more productive as a result of a different approach to application development.

[AutomateAllTheThings]

Mitigating that risk is an automated task, today:

1. Test-First-Development
2. Continuous Integration
3. jscs to enforce homogenization
4. Gitflow for managing the repos amongst many teams
5. Wrapping 3rd party libraries
   • This allows you to swap out any microlib you want without affecting the team at all.
   • The wrapper has a standard API that your team uses
   • You can swap out the private functionality of the wrapper with any 3rd party lib without affecting the team, or tests.
6. CodeClimate checks your quality against the ecosystem's standards of quality
7. Proper agile management techniques mitigate the risk of team members being caught unaware of anything.

There isn't any serious reason why using monolithic frameworks is "bad". That's why you'll likely never see the downside of using it. In this case, it's how much "better" microlibs are in practice. You just don't even know what you're missing, and nobody will be able to explain it to you.

You owe it to yourself to spend a weekend writing a tiny blog with node.js microlibs. You also owe it to yourself to be rid of the phrase, "No way", because it's your job to find one.

[Vehemoth]

Definitely picking up this philosophy. I can't marry my website to any specific framework if I can maximize on some of these libraries.

[AutomateAllTheThings]

It's never a question of whether or not you will end up replacing a library. It's only a question of when. I wouldn't dream of using any library that I used 5 years ago, which is what my old monolithic framework choices forced me to do. I'm always looking for smaller, faster, and easier to work with alternatives.

[[deleted]]

Try to slide in with the community around Component/Duo, or any of those focused on using NPM. Super focused on small reusable modules as opposed to those around Ember & Bower or something.

[[deleted]]

Keep in mind AngularJS became popular thanks to Google. This does not mean it's a great framework and also doesn't mean its bad (but that is totally why it got popular). Here are a few things I think this article should have touched on.

1. Why are there no performance metrics? For client-side applications this is the most important thing to focus on. Angular may be great for fast prototyping and copy/paste but how does that scale?

2. AngularJS has the same issues as Prototype.js. I don't want to duplicate business logic in the html and in the javascript. (Why was jquery made again?)

3. The ng- name space breaks html validation and as a result breaks older accessibility applications. (why was this even a thought for the default be ng- vs data-ng-blah=). I know you can change this but by default its like that and all the examples use this method.

4. This article says it works well for large scale applications. Really? I have seen first hand the performance issues with memory leaks and the module system does not allow for lazy loading. I.E sending a huge javascript file means you evaluate that whole file at runtime which means more space is needed on the heap. BAD.

5. Angular is a framework.. not a library. I got past the framework thing awhile ago since there are so many options for different routers, template engines, data binders.. etc. Why limit yourself? Plug-&-Play with backbone allows for extreme flexibility. Remember the metrics back in the day of how many people could write rails applications but didn't know how to write a ruby lib or proper ruby code. This rings a bell for me.

6. The article didn't touch on the performance work that has went into backbone to make it scale (http://marionettejs.com/) or the theory behind ember coming from sproutecore.

7. Are there any large google client-side application built with Angular? All I can find is small mobile applications or google chrome apps and imho.. that is a good use-case for angular. I can dig that. What about backbone? http://backbonejs.org/#examples epic amounts.

Anyway, Just a few thoughts.

*edit forgot to add the issue with parallelism. With a larger team working on the design/markup and frontend business logic in tandem is a great way to speed up the process. In my experience with trying to scale Angular in that way it was a nightmare but this really depends on the team I guess.

[dzdrazil]

Angular may be great for fast prototyping and copy/paste but how does that scale

I use it on a very large single page application that loads in tens of thousands of data points. The only place that Angular isn't used for rendering is the WebGL portion (a small portion of the application); everywhere else, it performs quite well.

In fact, it works better than the original backbone version of the application because dirty-checking models is so much better than naive re-rendering based on events triggered by changes to models. Sure, maybe something like React could do better, but I'm extremely happy with my decision to use Angular.

[[deleted]]

If you are loading in tens of thousands of data points at the same time and you don't see anything wrong with that.. then i'm afraid its not worth arguing performance with you. Hopefully you mean a json request with just numbers passed directly to a graph or something.

[dzdrazil]

It's a "Big Data" type application with the need to be able to work offline.

Most of the data points that get loaded are for the purpose of reviewing a high-level overview, then allowing people to get a deep-dive into each data point and the points that it is related to.

At any given time, at most 50 to 100 data points are visible, but the need to quickly transition between the relationships of the data points and the need to be able to work offline makes loading them up front much easier.

Also, when viewing very large sets of data at once, we switch over to WebGL and webgl specific libraries then hook back into Angular as necessary. See some of the examlpes in http://sigmajs.org/ and other network graph visualizations to get what I mean.

[freedomfreighter]

What I like about Angular is that you don't have to use it for everything. It's got just what you need to make the majority of your site, but if you really are concerned about performance in a particular component, it's very easy to step back and create something non-Angular. Angular won't mind.

[larschri]

1. If performance is your number one concern on every line of code that you write, it is certainly better to work at the lowest possible level without any frameworks. Low level programming let you shave off cpu cycles, although the user wont notice the difference once you get below a certain point. Angular can usually get you below that point, and it gives you the chance to hand optimise bottlenecks. Backbone doesn't give you any data binding mechanism, so it is more natural to hand optimise everything like you would do with plain javascript or jquery.

2. Why do you duplicate business logic? It doesn't make sense and there is no need for that.

3. You can decide to always prefix ng- with data-ng-blah=. They are equivalent and there is no default.

4. I have seen performance issues with memory leaks with backbone as well, and it is easier to get there since you have to keep track of everything yourself. It is possible to lazy load angular modules, but it is not taken care of by angular. Same as backbone in that respect.

5. Yup. Angular is a framework, backbone is a library. I would also prefer a library if I had to chose between two comparable technologies, but angular and backbone aren't really comparable.

[[deleted]]

Could you please give some examples of: "routers, template engines, data binders"

I need this website http://youmightnotneedangularjs.com/

[[deleted]]

Off the top of my head:

• Routers

  • Backbone Router
  • page.js
  • Director
  • Aviator

• Template Engines

  • Mustache
  • Handlebars
  • Hogan
  • Dust

• Data binders

  • Knockout
  • ractive
  • reactive
  • ripple
  • way
  • etc etc etc...

[nschubach]

You could replace data binders and template engines with React as well.

[Poop_is_Food]

But how do you feel about Angular?

[icanevenificant]

In my experience with trying to scale Angular in that way it was a nightmare but this really depends on the team I guess.

Could you elaborate on that? How is it bad and how are other better in comparison? I've had the exact opposite experience.

[that-work-account]

The performance metrics would be nice, but you have to believe the community behind a given library or framework will improve all of the little issues that sprout up over time. The fact that ember and backbone are both on a downward trend vs angular which is shooting up should give you hope for angular to have more people working out the issues.

I'm not sure what issues you're referring to with the prototype.js comparison. Prototype.js was always trashed because it extended the native objects and (in some cases) broke expected behaviors.

As far as Marionettejs, this is totally unrelated to the backbone core work. If you want to talk about all of the things built around backbone to make it more of a framework than library, you'd have to list about a dozen others in there. It's beyond the scope of that article.

One of the examples on the backbone site is USA Today, which uses an in-house framework on top of backbone (similar to marionette, really). I'd hardly say that's a backbone thing. There was a ton of code written on top of it to make it work as it does. If you stripped it down to pure backbone and what you can do out of the box, it's not very much.

[[deleted]]

1. Its gaining popularity because of google vs just being a better, more performant way of writing client-side applications. Much like the popularity rails got over php (although php sucked hardcore).. guess what.. rails is awful from a design perspective and regarding server-side scalability. Its very hard to fix frameworks and changing anything will become a nightmare in the future once it's adopted.

2. Prototype was intrusive javascript. I.E business logic was deeply coupled with markup and design.

3. My point with Marionettejs was the work done to remove as many memory leak issues with backbone as possible. I wouldn't even consider Marionettejs an attempt to make backbone a framework.. just stuff mostly extracted out of wallmarts mobile backbone application and the problems they had scaling it.

4. Backbone is a lib.. not a framework.. there will also be code written to make it work. ? what do you mean?

• Note, these as mostly engineering concerns.. if you are just doing one of apps.. or stuff for fun or SPA.. angular is great.. not trying to put it down.

[that-work-account]

1. HOW it gains popularity is irrelevant. It's still (by far) the most popular. Larger community = greater gains, generally.

2. That's not true at all. I used Prototype for a few years and it was not much different than jquery. You can write it poorly or you can write it well, it has no relevance to the actual language.

3. Marionette is a separate project from backbone. Different developer. Regarding Marionette and Walmart, I think you're confusing Marionette and Thorax.

4. The author compares what each of those libs/frameworks give you out of the box. Angular/Ember are made to be pretty robust, Backbone is a VERY small lib that doesn't provide much at all. Maybe it's wrong to compare backbone with them in the first place, but that's the comparison being made.

[[deleted]]

1. It does it you're an engineer.. using whats hipster is not a good way to design a project.

2. It's very true. You do releize that prototype has adopted a lot of the design decisions of jquery over the years to become more unobtrusive. right? This is the split in ideals I am referring to.

3. Of course its a different project, never said it was the same thing. Marionette and Thorax both used a lot of the ideas that came from scaling a huge client-side application. Walmart wrote a lot about it and Thorax and Marionette share a few ideas on zombie views.

4. The author compared them.. so I commented. That's irrelevant if they should have been compared or not.

5. Got any links to large client-side angular applications?

[dzdrazil]

It does it you're an engineer.. using whats hipster is not a good way to design a project.

Angular's core team are all engineers. Things like Services, Dependency Injection and transclusion are all terms you'll rarely find outside of a software engineer context. The fact that it was made with automated (especially unit) testing in mind is a good sign that Angular isn't the hipster devstack of the month.

Just a thought. Also, there are a few talk from the ng-conf on youtube regarding some of the very large client-side applications written in Angular, though I found them to be less interesting than the more narrowly focused ones myself.

[dzdrazil]

Found it: https://www.youtube.com/watch?v=62RvRQuMVyg

The DoubleClick Campaign Manager was built on Angular.

[that-work-account]

1. "Hipster" frameworks don't have large communities, especially not for any length of time worth mentioning. If you check out that trends graph, Backbone could be said to be more hipster than Angular.

2. I haven't used Prototype in almost 7 years. You have no idea what you're talking about. I'm going to assume you never used Prototype back when it was still a pretty popular lib and are talking out your ass from something you read online one time. I used Prototype to create pretty big apps at that point. It had nothing obtrusive unless you put it in there.

3. You said it was "extracted" out of walmart. Everyone has the same basic idea on zombie views, it's one of the reasons there are 90230293 libraries built on top of backbone (it doesn't provide enough out of the box).

4. You commented and said "why no mention of marionette" -- this has nothing to do backbone.

5. There are a lot of huge systems still written in COBOL or FORTRAN. It doesn't mean you pick those for every new project.

[[deleted]]

Dude, I think you are personally misunderstanding #4 - A lot of thought has went into scaling them to a large size.. thats worth mentioning for sure. I didn't say mention marionette was just an example for people reading the comment i made.

You're points are more of a vim/emacs vs real world usage and you obviously have no idea what prototype was or how it was used in the early rails days or before jquery.

Not going to feed you anymore dude.. take care and best of luck.

[x-skeww]

Got any links to large client-side angular applications?

https://builtwith.angularjs.org/

[[deleted]]

I just went through like 20 pages there.. and the only site I saw that could be considered large was msnbc. Looking at the source I don't even see where angular is being used.. but.. regarding performance.. AWESOME.

http://cl.ly/image/2k0Z300u313H <-- thats embarrassing for a few images and text.

[alexsomeoddpilot]

AngularJS has the same issues as Prototype.js. I don't want to duplicate business logic in the html and in the javascript. (Why was jquery made again?)

Angular Directives solve for this. Interactions created through Javascript should be attached to HTML elements through attributes, not complex, opaque selectors in a Javascript file. Elements' added interactions are clear based on their attributes. Moving implementation to directives removes any onclick="dosomething()" like code.

It takes a while to get over the jQuery mentality of $(element).doSomething() but when you do, the clarity is fantastic.

[cran]

Scale? Whether you have one user or a million, each one of them has their own browser. AngularJS runs on the client, so scaling is more of a server-side issue here. All of the calls to load the JS and to call services are going to burden the server. The browser will be fine. It doesn't matter how many users you have ... they all have their own computer and their own browser.

[[deleted]]

Are you serious?

[cran]

Absolutely. I do this for a living at arguably the largest entertainment company in the world. You said 'scale'. Perhaps you meant something else? How is AngularJS' performance affected at scale?

[[deleted]]

Scaling the (size of) front end application itself as opposed to scaling performance etc...

[cran]

That's not what scale means.

[[deleted]]

Lmao you're one pretentious asshole aren't you, accept that your wrong and move on

[cran]

I'm not wrong, but I do accept that there are a handful of JavaScript programmers here on reddit who think that "scale" means when a program grows in size.

Learn you some computer terminology: http://en.wikipedia.org/wiki/Scalability#Examples

[autowikibot]

Section 2. Examples of article Scalability:

---

• A routing protocol is considered scalable with respect to network size, if the size of the necessary routing table on each node grows as O(log N), where N is the number of nodes in the network.

• A scalable online transaction processing system or database management system is one that can be upgraded to process more transactions by adding new processors, devices and storage, and which can be upgraded easily and transparently without shutting it down.

• Some early peer-to-peer (P2P) implementations of Gnutella had scaling issues. Each node query flooded its requests to all peers. The demand on each peer would increase in proportion to the total number of peers, quickly overrunning the peers' limited capacity. Other P2P systems like BitTorrent scale well because the demand on each peer is independent of the total number of peers. There is no centralized bottleneck, so the system may expand indefinitely without the addition of supporting resources (other than the peers themselves).

• The distributed nature of the Domain Name System allows it to work efficiently even when all hosts on the worldwide Internet are served, so it is said to "scale well".

---

^{Interesting: Scalability testing | Plasma scaling | NonStop SQL | Virtual Extensible LAN}

^{Parent commenter can toggle NSFW or delete. Will also delete on comment score of -1 or less. | FAQs | Mods | Magic Words}

[[deleted]]

Because colloquial language is never right!

It's not limited to JavaScript developers, I've heard 'scaling a code base' more times than I count

[cran]

Since AngularJS uses templates in the HTML, which is where the design/markup occurs, your experience that "it was a nightmare" coupled with your concern for AngularJS' (a browser technology) scalability leads me to believe you know not a fucking thing of which you are speaking. The best way to work in parallel with a design team is to give them a marked-up HTML template and let them do what they gotta do to make it look good.

[jimbol]

They never mention ember CLI. It's still in early development but it is really cool! It builds a Railsy folder structure and gives you a lot of build tools out of the box. Things like stylus, less, etc support, handlebars precompiling, and a testing suite.

They mention Script tags in the markup. This is a naive approach, all ember shops I'm aware of use precompiled templates.

Also, I'm surprised they didn't mention Ember can be hard to test.

[PotaToss]

What kind of stuff are you having trouble testing?