4 ms·

Now I'm definitely more embedded in the backenders community than the frontenders, but from my perspective Angular.js has been a lot more popular than the autho

by tinco 12y ago

Now I'm definitely more embedded in the backenders community than the frontenders, but from my perspective Angular.js has been a lot more popular than the author suggests. Of course my only metric for this is hearing other people talk about it. When we started selecting technologies for a new frontend for our web application about a year and a half ago, I did a quick evaluation of the big frameworks. Looking at the TODO list implementations and implementing a small side project in Angular and a few others. My conclusion was that the way angular works and how you use it was pretty horrible, and I was quite surprised to see so many so impressed and positive about it. I didn't even think about its performance (as it was promised it was going to improve as it stabilised). The whole idea of the dependency injections and factories, it just doesn't make sense. Within the company my colleagues agreed with my conclusions so we decided to pick something else. My probably not so popular opinion on dependency injection in dynamic languages is that you shouldn't bother with it. Javascript (and Ruby for that matter) allows you to overwrite both properties and prototypes, this means that any dependency injection can be done dynamically at runtime whenever you want as long as your logic and data is nicely captured in properties. (Note that his last clause is something that often does not hold in Javascript projects as most/many authors love wrapping their stuff in functions with very harshly make lots of things private and immutable) So designing a whole framework around enforcing this pattern, with a terrible syntax and un-fathomable semantics, on top of a dynamic language, it doesn't sit well with me.

marknutter 12y ago
Angular's dependency injection is very similar to AMD modules. In fact, the syntax is barely distinguishable. So if you have an issue with Angular's dependency injection, you likely have issues with AMD and perhaps javascript modules in general. I much prefer having my dependencies injected in a modular way than having to pollute the global namespace with every library and component I pull in.
- tinco 12y ago
  Well this is exactly the point that people disagree on with me. I think your application owns the global namespace, as long as your dependencies are neatly defined somewhere there really is no downside to letting pulled in libraries 'pollute' your global namespace.
  - marknutter 12y ago
    When you're working on large teams it's no longer your global namespace alone. I've worked on quite a few projects that abused the global namespace and it's very painful to try and recover from.
kyllo 12y ago
My probably not so popular opinion on dependency injection in dynamic languages is that you shouldn't bother with it. I heartily agree. Imagine trying to do dependency injection in a Lisp or Scheme app. It'd be like putting legs on a snake. Totally unnecessary. Now recall that JavaScript was designed to resemble Scheme with a C-like syntax.
pmontra 12y ago
> so we decided to pick something else I'm sincerely interested. What did you pick and for what reasons? How did it end?
- tinco 12y ago
  Well our pick comes with a big disclaimer, we chose Polymer. I am not sure if it's already a good idea to build a big consumer-facing using this tech as it's very future (modern browser) oriented. That said, Polymer has been absolutely awesome to work with. Even though it's not so much a framework as it is an interface/wrapper around some cool new stuff that's in HTML5 we built a very light weight framework around it and that has been a great experience for us. It's possible we did some more work than we would have to on other frameworks, but we got a lot of control back for it. I think we would've went with something light like backbone.js otherwise. And it's also possible that it would not have been a good choice if we had team members with less experience (i.e. every now again there's some advanced fire extuingishing going on). Anyway, our audience is a low-traffic tech niche and our app is a SPA that's mostly read-only, so that's a very small target that gives us a lot of room for taking chances and picking tech.
crazychrome 12y ago
absolutely agree. when I first saw AngularJS and read about dependency injection, I was turned off immediately, wtf?? Of course, I was not brave enough to call google guys idiots.

by tinco 12y ago

marknutter 12y ago

Angular's dependency injection is very similar to AMD modules. In fact, the syntax is barely distinguishable. So if you have an issue with Angular's dependency injection, you likely have issues with AMD and perhaps javascript modules in general. I much prefer having my dependencies injected in a modular way than having to pollute the global namespace with every library and component I pull in.

tinco 12y ago
Well this is exactly the point that people disagree on with me. I think your application owns the global namespace, as long as your dependencies are neatly defined somewhere there really is no downside to letting pulled in libraries 'pollute' your global namespace.
- marknutter 12y ago
  When you're working on large teams it's no longer your global namespace alone. I've worked on quite a few projects that abused the global namespace and it's very painful to try and recover from.

kyllo 12y ago

My probably not so popular opinion on dependency injection in dynamic languages is that you shouldn't bother with it. I heartily agree. Imagine trying to do dependency injection in a Lisp or Scheme app. It'd be like putting legs on a snake. Totally unnecessary. Now recall that JavaScript was designed to resemble Scheme with a C-like syntax.

pmontra 12y ago

> so we decided to pick something else I'm sincerely interested. What did you pick and for what reasons? How did it end?

tinco 12y ago
Well our pick comes with a big disclaimer, we chose Polymer. I am not sure if it's already a good idea to build a big consumer-facing using this tech as it's very future (modern browser) oriented. That said, Polymer has been absolutely awesome to work with. Even though it's not so much a framework as it is an interface/wrapper around some cool new stuff that's in HTML5 we built a very light weight framework around it and that has been a great experience for us. It's possible we did some more work than we would have to on other frameworks, but we got a lot of control back for it. I think we would've went with something light like backbone.js otherwise. And it's also possible that it would not have been a good choice if we had team members with less experience (i.e. every now again there's some advanced fire extuingishing going on). Anyway, our audience is a low-traffic tech niche and our app is a SPA that's mostly read-only, so that's a very small target that gives us a lot of room for taking chances and picking tech.

crazychrome 12y ago

absolutely agree. when I first saw AngularJS and read about dependency injection, I was turned off immediately, wtf?? Of course, I was not brave enough to call google guys idiots.