4 ms·
The code I mentioned is definitely smaller than in the article. It is faster, because it is just a function call. It doesn't create any event objects, or have
by illumen 12y ago
The code I mentioned is definitely smaller than in the article.
It is faster, because it is just a function call. It doesn't create any event objects, or have to go through six layers of other function calls.
It's simpler because there is less code, and there are less concepts.
No, it's not novel or new. Messages as function calls, and MVC comes from 70s smalltalk.
It's not strongly coupled because of a few reasons. Firstly because in JavaScript it is simple to dynamically reassign objects and functions. The receiving object does not care where it got the function called from. Only the sending object knows where it is sending to. However, from Coupling theory in Software Engineering, we know that if there are a small amount of outputs then the strength of the coupling is still low. Luckily in many apps there are often only a few places where you want to send a message. http://en.wikipedia.org/wiki/Coupling_%28computer_programming%29#Module_coupling http://en.wikipedia.org/wiki/Coupling_%28computer_programmin...
Yes, if there are lots of outputs it may be useful to reduce the coupling. In my experience, even with large apps (100 person teams), this is often not the case.
It is often useful to know what your app is doing by looking at where the events are going. Just using function calls makes this very easy, both in source code and in the debugger. So this also needs to also be weighed up in the decision of how you are passing events around.
- coldtea 12y ago>The code I mentioned is definitely smaller than in the article. Yeah, so this is a first sign of misreading the dangers. Of course the code you mentioned is "smaller than in the article". The code in the article is a toy example to illustrate a specific point. It's when you start to build a full app, with all the (necessary for the requirements) complexity that it's gonna get much more and more unyieldy that the code one would write on top of React. >It is faster, because it is just a function call. It doesn't create any event objects, or have to go through six layers of other function calls. Again: premature optimization. After you build your colossal temple of function calls in a NON TOY example, it will either be slow (because you'll have re-introduced abstractions and layers by yourself) or it would a complex spaghetti of cross-calls. >It's simpler because there is less code, and there are less concepts. Less concepts != simpler. Assembly has less concepts too. And it's only "less code" because you're comparing a "toy example + framework" with a "toy example without framework". It's after that level that it gets hairy. >No, it's not novel or new. Messages as function calls, and MVC comes from 70s smalltalk. Yeah, and it's what all these coders going to React etc have tried already for a decade and found out that it doesn't cut it with modern apps, because the environment they run in is nothing like a Smalltalk MVC application.