Hacker News Reader

Comment by delambo | Hacker News Reader

I used to think the same thing, but then I ran into the problem where my large app had circular dependencies which require.js/AMD does not support. Naturally, AMD supporters blame you and your project's architecture, but it is not uncommon to have some circular dependencies in a large app.

The work-around is to use require.js in commonjs style or to add hacks into your architecture. Not fun.

View on HN

Circular dependencies ARE a problem with your architecture. You've got two modules that are strongly coupled. They should either be in one module or you should rethink things. It is impossible to need one without the other in that case, so including one without the other makes no sense, so just merge them.

In large projects, and especially legacy ports, you don't have that luxury.

Hence, careful selection of projects to work on is key.

> Circular dependencies ARE a problem with your architecture

This whole thread reminds me of the PHP days before namespaces. If you have circular dependencies within your own codebase, you have an architecture problem. If they are introduced by third-party libraries, maybe the usage of the library should be questioned.

Here's a trivial example:

I have a Modal class which depends on some utilities in a Utility class, but the Utility class depends on the Modal class because there are some utilities that show Modals.

This is not a broken architecture and is handled just fine by other programming languages/dependency handlers.

The concept of a "Utility Class" is normally a sign that there is something else going on!

What are the utilities contained in this module?

You want to use inversion of control in your Utility class. Just pass function, which will operate on Modal class instance (not Modal class instance itself but function) as argument to its utilities that show Modals.

Reply on news.ycombinator.com