4 ms·

When the author doesn't understand the difference between a module system and a dependency injection system, it's hard to take the rest of what he says seriousl

When the author doesn't understand the difference between a module system and a dependency injection system, it's hard to take the rest of what he says seriously.

troels 11y ago
They kind of solve the same problem, but in different ways. I, for one, think it's debatable if the 800 lb gorilla that is dependency injection has any merit in javascript.
- emsy 11y ago
  DI is not an "800 lb gorilla". If anything, certain implementations of DI frameworks are (I'm looking at you, Spring).
  - troels 11y ago
    I disagree. They were a solution to the inflexibility of rigid languages like Java, but seems entirely alien in the context of Javascript. A DI framework adds a load of indirection.
    - brodo 11y ago
      DI is a design principle, not a class for frameworks. DI just means to "inject" the dependancies of an object through constructor arguments, setters or by simply setting instance (aka member) variables. In other words, DI means that you don't use global variables (aka singletons). DI does not provide any more flexibility itself, but most DI frameworks encourage the usage of interfaces instead of concrete classes (which is a good thing) when it comes to defining dependancies. Sadly however, the fancy pants therm for using interfaces is "dependency inversion", because when using interfaces, the compile time and runtime dependancies of a class point in opposite directions. As you can imagine, this lead to a lot of confusion.
    - radicalbyte 11y ago
      It has nothing to do with the "rigidity" of Java, and everything to do with the complexity of the problems solved in Java land. The value comes as you scale the number of developers, the lifetime of the software and the complexity of the product. This holds just as much for Java as it does for Ruby or Javascript.
- trumbitta2 11y ago
  I like Angular's DI. It makes it easy – to me, but YMMV - to organize my thoughts and my code.
  - troels 11y ago
    Fair enough. It's probably a matter of taste to some extend. I generally don't like too much structure unless there are clear benefits and DI doesn't seem to hold up on that scale. The problem it's solving has traditionally been solved with a dozen global variables. And while the purists may scuff at this, I find that in practise it's never an issue in otherwise well structured code.
    - JustSomeNobody 11y ago
      Too many people reach for DI first where some quiet time with a pencil and paper could produce a much better design that doesn't need a DI framework.
- aikah 11y ago
  > They kind of solve the same problem no they don't. That's a fundamental mistake to say that. DI is about inversion of control , modules don't do that.
  - troels 11y ago
    IoC is the way that DI solves the problem. But the problem is dependency management - and there are other ways around that.
    - stupidcar 11y ago
      The difference is that modules systems specify statically resolved dependencies between code files. DI and IoC specify dynamically resolved dependencies between instances of objects. They are both useful, but they both solve different problems.
- mercurial 11y ago
  Dependency injection has merit in any language. Throw DI out of the window, testability goes with it. Now, on the matter of IOC containers, you can easily roll your own or use a sane one (eg, Guava in Java).
l1ambda 11y ago
The author's point was that with Angular, the Angular module system you must use (you can't opt out), and you are most likely nowadays going to be using commonJS or AMD anyway, so you end up with two module systems. At the time (in 2009) it probably made sense to come up with an Angular module system, but now that most people use require/webpack/browserify, it has become a hinderance. The reason being you can't just require() a module in a unit test, you have to bootstrap the entire Angular system and all angular modules, which is a huge pain for unit testing and causes all sorts of side effects. The other thing the author didn't mention is you can't debug your HTML templates. With Mithril, you can set a regular javascript breakpoint in your views. Directives and code-in-HTML essentially reimplement a half-assed version of JavaScript. (The same criticism applies to JSTL which throws out a perfectly good language, Java, and forces you to use XML and tag libraries.) HTML logic creates complexity because it invents a new programming language in the HTML. The code-as-HTML is the root problem that causes all the scope issues, all the explosion and complexity of directives, filters, and the inability to set breakpoints in views. With Mithril you don't have this whole directive/filters nonsense, you just write functions. I've written more about this subject at: https://medium.com/@l1ambda/mithril-vs-angular-vs-react-d0d659c24bae https://medium.com/@l1ambda/mithril-vs-angular-vs-react-d0d6...

When the author doesn't understand the difference between a module system and a dependency injection system, it's hard to take the rest of what he says seriously.

troels 11y ago

They kind of solve the same problem, but in different ways. I, for one, think it's debatable if the 800 lb gorilla that is dependency injection has any merit in javascript.

emsy 11y ago
DI is not an "800 lb gorilla". If anything, certain implementations of DI frameworks are (I'm looking at you, Spring).
- troels 11y ago
  I disagree. They were a solution to the inflexibility of rigid languages like Java, but seems entirely alien in the context of Javascript. A DI framework adds a load of indirection.
  - brodo 11y ago
    DI is a design principle, not a class for frameworks. DI just means to "inject" the dependancies of an object through constructor arguments, setters or by simply setting instance (aka member) variables. In other words, DI means that you don't use global variables (aka singletons). DI does not provide any more flexibility itself, but most DI frameworks encourage the usage of interfaces instead of concrete classes (which is a good thing) when it comes to defining dependancies. Sadly however, the fancy pants therm for using interfaces is "dependency inversion", because when using interfaces, the compile time and runtime dependancies of a class point in opposite directions. As you can imagine, this lead to a lot of confusion.
  - radicalbyte 11y ago
    It has nothing to do with the "rigidity" of Java, and everything to do with the complexity of the problems solved in Java land. The value comes as you scale the number of developers, the lifetime of the software and the complexity of the product. This holds just as much for Java as it does for Ruby or Javascript.
trumbitta2 11y ago
I like Angular's DI. It makes it easy – to me, but YMMV - to organize my thoughts and my code.
- troels 11y ago
  Fair enough. It's probably a matter of taste to some extend. I generally don't like too much structure unless there are clear benefits and DI doesn't seem to hold up on that scale. The problem it's solving has traditionally been solved with a dozen global variables. And while the purists may scuff at this, I find that in practise it's never an issue in otherwise well structured code.
  - JustSomeNobody 11y ago
    Too many people reach for DI first where some quiet time with a pencil and paper could produce a much better design that doesn't need a DI framework.
aikah 11y ago
> They kind of solve the same problem no they don't. That's a fundamental mistake to say that. DI is about inversion of control , modules don't do that.
- troels 11y ago
  IoC is the way that DI solves the problem. But the problem is dependency management - and there are other ways around that.
  - stupidcar 11y ago
    The difference is that modules systems specify statically resolved dependencies between code files. DI and IoC specify dynamically resolved dependencies between instances of objects. They are both useful, but they both solve different problems.
mercurial 11y ago
Dependency injection has merit in any language. Throw DI out of the window, testability goes with it. Now, on the matter of IOC containers, you can easily roll your own or use a sane one (eg, Guava in Java).

l1ambda 11y ago

The author's point was that with Angular, the Angular module system you must use (you can't opt out), and you are most likely nowadays going to be using commonJS or AMD anyway, so you end up with two module systems. At the time (in 2009) it probably made sense to come up with an Angular module system, but now that most people use require/webpack/browserify, it has become a hinderance. The reason being you can't just require() a module in a unit test, you have to bootstrap the entire Angular system and all angular modules, which is a huge pain for unit testing and causes all sorts of side effects. The other thing the author didn't mention is you can't debug your HTML templates. With Mithril, you can set a regular javascript breakpoint in your views. Directives and code-in-HTML essentially reimplement a half-assed version of JavaScript. (The same criticism applies to JSTL which throws out a perfectly good language, Java, and forces you to use XML and tag libraries.) HTML logic creates complexity because it invents a new programming language in the HTML. The code-as-HTML is the root problem that causes all the scope issues, all the explosion and complexity of directives, filters, and the inability to set breakpoints in views. With Mithril you don't have this whole directive/filters nonsense, you just write functions. I've written more about this subject at: https://medium.com/@l1ambda/mithril-vs-angular-vs-react-d0d659c24bae https://medium.com/@l1ambda/mithril-vs-angular-vs-react-d0d6...