That's only two lines of code compared to 30 or so. This scales up because with more models, you have less code.
In practice these are easier to debug, because the debugger supports function calls with stack traces, and easier to read, because people understand function calls. They are also faster.
This is why I think that long article is complex. Remember that OO uses messages and objects. Method calls are events. Also remember that there is an M in Document Object Model (DOM). So you see we already have a Model, and events?
Please also consider how much less code there is in the jQuery version of the todomvc app compared to the react one. http://todomvc.com/
The people arguing against you don't know what they're talking about. They're stuck in a paradigm where "de-coupled event-driven architecture" is a holy goal and can't see their feet on the ground anymore.
Hmm, this answer seems to have missed 7-8 years of the web's development, and shows a preference for convoluted, messy codebases with huge conginitive overload...
Smaller: Not really. You just avoid some K of helper code already build (by the React team). Your code will end up being more than the one you'd have written on top of React -- because it will also have to reimplement and handle all common cases (either poorly, or time-consumingly).
Faster: could be, could be not. Without profiling this is an empty statement. Besides, "premature optimization is the root of all evil".
Simpler: Noope. You have to manually track all the interactions, and you strongly couple things together with your "OO and functions" idea. It might be simpler to just churn out code initially (instead of understanding an architecture), but it becomes an ad-hoc mess soon.
Let me put it this way: it's not like you have discovered a novel way of building stuff compared to these coders that overcomplicate things. What you propose is what these engineers have already tried, used for a decade or so, and found unscalable and wanting.
It can work for small and not complicated pages, but it's not a solution to modern single page web apps.
You might think that you are proposing a clear and simple way of coding as opposed to something like overengineered J2EE patterns mess.
But what you describe is more like the "Why use procedural code etc, GOTOs for flow are simpler and faster", or "why use functional programming, imperative is simpler and faster".
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_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.
>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.
Unit testing has been done with jQuery since it came out in 2006. Rather than one giant monolithic app, jQuery promotes putting things into plugins or separate libraries.
What stops you from unit testing function calls? Nothing.
It also promotes procedural code for modifying DOM, not declarative. This makes unit testing much harder imo, since you're into the realm of either working against a real DOM, or mocking everything.
In the example from the article we are talking about, it would be easy to mock out the one function call for modules A, and B. There's no DOM manipulation in the article.
Keeping DOM modifying code separate is good practice in either case. Then you don't need to involve the DOM in much of your code. Doing end to end testing is also completely ok to do.
It's worth repeating, so I'll say it again... It's better to keep DOM manipulation code separate. Then you don't need to mock, or simulate anything. Except where needed. You do need to test DOM manipulating code somehow.
