I also had this exact problem. I posted this question on StackOverflow about it, and the accepted answer led me to the solution I use now, which is identical to the one described in the article:
...I always just do something along the lines of window.MyAppNamespace.EventProxy = _.extend({}, Backbone.Events);
The nice thing about this tactic is that it loosely couples interactions between your views. A coworker who also uses Backbone.js prefers passing references between your views to each other. Although this makes the code easier to read in some cases, since it's more obvious what the flow of control is, it tightly couples the components.
This looks fantastic! It also has the side effect of making me want to get back in to learning Clojure. The idea of the file not being the fundamental unit of code is especially intriguing, but hard to wrap my brain around - that's such a low-level, base assumption that it's difficult to picture truly challenging that.
What are some examples of other paradigm-shifting (argh, buzzword) ideas in the world of software development? Deviations from the norm often become the new norm, and I'm too young and inexperienced (I've only been out of college for 10 months) to remember the "old way" of things.
I seem to remember reading that Facebook was using XHP, which allowed XML literals. That would certainly be an improvement over "warts-and-all PHP", in my opinion.
Of course, I'll trust what an actual engineer from Facebook is saying over some article that I can't even cite. Is this not the case?
Everyone is certainly entitled to their opinions, but I'm puzzled as to whether some of the people claiming that PHP's greatest strength is its deployment model have had significant PHP experience?
As with most things, it's both good and bad. It IS fantastic that you can so easily toss a .php file into a directory, make a few minor Apache config adjustments, and BAM - dynamic website behavior.
...that's also a glaring weakness, though, when a complex application is developed without the structure imposed by other tools. I have to maintain an event registration system written in PHP, and I'm having incredible difficulty with it. The logic to store form data, look for errors, display the current form, and prepare the form for submission are all in a single, 1000+ lines spaghetti-code file.
I think the author's point (and certainly the one I'm making) is not that this is the only possible outcome of writing in PHP, or that other languages do not have this problem. Rather, the point is that the lack of cohesive structure removes barriers to writing bad code; in fact, it makes it (initially) easier than writing good code.
It's all fun and games until you want to find a string in an array.
The entirety of the PHP API should be bundled up in a burlap bag, beaten savagely with a baseball bat, then thrown in a shallow grave to be set on fire before being buried. The "Goodfellas" treatment is way too kind in this case.
Quoted from the documentation: "Every request is wrapped in a Node Fiber".
So...essentially, this behaves like a traditional web server? A process listens for incoming connections, then spins up a new process/thread/fiber to handle the request?
