Comment by dos1 | Hacker News Reader

Comment by dos1 | Hacker News Reader

>When you create a component you don't get a handle to it. Consequently, components cannot be referenced by other components and cannot become properties of the global object tree. This is by design. Components do not engage each other directly; instead, they broadcast their actions as events which are subscribed to by other components.

This is a maintainability nightmare. I've gone down this route on hand rolled JS frameworks before and it leads to untold headaches. Sometimes a little coupling is the right solution. Many times it is better for components to have knowledge of their environment. In most applications (other than iGoogle maybe) one thing on a page depends on another. I feel it's far better to explicitly call out those dependencies by having a reference to the other components and directly invoking methods on them with known arguments of a known type.

Edit: Also, what kind of memory allocation implications are there with event subscriptions and no references to the components themselves?

I understand where you're going here: pubsub communication can be both a blessing and a curse, it can be hard to ensure a consistent usage, hard to debug when there's long chains than one place -> the other.

I think the sandboxing from aura.js is pretty interesting here, since you can always look up which widgets are allowed to talk, it makes it easier to narrow down the problem.

The real nightmare comes from the undiscoverability. The right tools can help you out. Unobtrusive JavaScript used to be a nightmare, for example, until Chrome added its 'Event Listeners' tab in the developer tools. Another being the 'Go To Implementation' instead of 'Go To Definition' when writing C# with code that uses interfaces.

Yes, you need coupling when debugging. But it need not be in the libraries and code you use.

Er...why is this broadcast model a maintainability nightmare compared to coupling components to their environment and to other components? I guess maybe it's too much abstraction for a website in which you know most components won't be reused...but then you wouldn't be Flight's intended audience.

So a component subscribes to some event somewhere. Who's triggering the event? When you're debugging in Firebug or someplace, what does your call stack look like? How hard is it to find the source of the event? All you know is it bubbled up from somewhere.

Say I want to add a component to a page. Which events do I need to trigger to make it do the kind of things I want? What do I need to pass as a payload to those events? How do I know if there's a consumer for my event or not? If there isn't a consumer that's probably an issue.

The eventing bus adds an additional layer of indirection. If your app can be truly decoupled, then this would be great. But I just don't see that use case being very common. I have never worked on an application where the broadcast model was more benefit than pain in the long run.

> So a component subscribes to some event somewhere. Who's triggering the event?

Look at the event source.

> When you're debugging in Firebug or someplace, what does your call stack look like?

Look at the data passed to the event. The callstack starts at the function attached as a listener to the event.

Is the event data incorrect? Then the problem is in the code that triggers the event.

Is the event data correct? Then the problem is in the code listening to the event.

> Say I want to add a component to a page. Which events do I need to trigger > to make it do the kind of things I want? What do I need to pass as a > payload to those events?

Documentation. That is indeed the cost of using an abstraction that decouples code, but it's also a cost that has benefits - good documentation is useful.

> How do I know if there's a consumer for my event or not?

It's not important. That's the point of an event-based system, it's a decoupling. De-coupling is an abstraction. It works on pages that are based on components or modules.

If you don't want that abstraction, then using code based on that abstraction isn't a particularly good idea.

Event-based frameworks do need documentation - but reusable code should be documented anyway. There's just more emphasis on getting the documentation done in event-based systems.

> Look at the data passed to the event. The callstack starts at the function attached as a listener to the event.

> Is the event data incorrect? Then the problem is in the code that triggers the event.

> Is the event data correct? Then the problem is in the code listening to the event.

It's difficult to reason about the event triggering code when it's call stack is not available. For a larger code base where an event is trigger in multiple locations with different logic in each location, it may be difficult to pinpoint the triggering code, let alone reason about that code. Direct function calls are much easier to debug because you can walk up the chain of calls and inspect the variables and state of each frame.

This library uses jQuery events which are synchronous. I.e. the event handler's callstack will include the triggerer a few levels up. Not any harder to debug than a direct call version.

> For a larger code base where an event is trigger in multiple locations with different logic in each location, it may be difficult to pinpoint the triggering code, let alone reason about that code.

Populate the event with the event source.

> Direct function calls are much easier to debug because you can walk up the chain of calls and inspect the variables and state of each frame.

If your listener depends on knowing the state of the triggering code, it is a sign your events are too granular. If you require a complete stack trace to be able to debug a listener to the event, that sounds like you have a bigger architectural problem to deal with.

Events are coarse. The listener should not care about why the event was fired, only that the event has occurred. Events are not a replacement for direct function calls. They are a mechanism for de-coupling pieces of code that can be independent of each other. It doesn't sound like your situation is one where there's that independence.

> If your listener depends on knowing the state of the triggering code, it is a sign your events are too granular.

That isn't practical debugging. If I'm debugging an event that was fired and I don't know why, or the payload doesn't match my expectations, it would be very useful to inspect the state of the triggering function and see where things went wrong.

>That's the point of an event-based system, it's a decoupling. De-coupling is an abstraction. It works on pages that are based on components or modules.

Right, we're on the same page. I agree that in certain scenarios these decoupled event based systems make sense. However, Twitter's example app is an email client. That to me is not a use case I would typically envision as being free of coupling. Thus it's more work to maintain in the long run.

> I have never worked on an application where the broadcast model was more benefit than pain in the long run

Unless you're extremely new to the game I bet you have, if only in the sense that it's a very short hop from classic MVC design to this.

Because you need to know what events you care about.

If instead you declaratively define the state of a component via a shared model then you don't have to care how something was updated, just that it was. Any new way you come up with mutating the object will be reflected in all of the components that watch the object.

i might be misunderstanding what they mean, but one immediate thing i thought about was how this would make composing a component out of "private subcomponents" (i.e. those that only the parent component could see) a lot harder.

Reply on news.ycombinator.com