Some conclusions about webdev
After a complete reconstruction of Herd Hound core, I’ve come to some conclusions I want to note down here, in case I decide to revisit them some time in future.
Event-driven is good
Web apps are mostly asynchronous, and concurrent most of the time. Event-driven design the the best match for this type of app.
Never add event handlers from within event handlers
You may fire events, but never attach new ones. If you’re attaching new event handlers from within event handlers, that’s generally a sign that you’re not doing something right.
Never use event names to identify the caller or callee
If you’re using events to pass messages around (which is the point, really), never encode identification data to event names. Treat even names as channels, and the actual identification data should be in the messages.
For example, if you have an event ‘broadcast.jerry.data.request’, you most likely want Jerry to make data request. This is not a good event name. Instead, you should use ‘broadcast’, and then add a message {caller: 'jerry', request: 'data'}. Something like that.
In my app, I have tons of very long event names. But most of them are fairly generic. I just namespaced them by component for which the events are valid. For example, all events that are related to sandbox plugin are ‘app.sandbox.something.something’.
Never detach event handlers
This is a constraint I’ve imposed on myself. I believe that this constraints makes the event system much better. If you find yourself in a situation where you want to detach a listener, your event system is probably not generic enough. Remember, the more specific you get, the more problems you’ll have, so it’s best to keep things generic. And generic event handlers do not need to be detached. They are always valid throughout the app lifecycle.
Don’t be afraid of prototype
JavaScript exposes the object prototype, and this allows us to monkey patch them as we go. There is a lot to be gained from careful modifications of the base objects’ prototypes.
Don’t add stuff to Object.prototype
Seriously. Although this flies in the face of the previous conclusion, I find that adding things to Object.prototype causes weird behavior in jQuery, which is hard to debug. So it’s best you make an exception for Object object in the previous rule.
Event-handling is hard
Yes, it’s very hard. But it’s worth it. So don’t give up. :) I’ve rewritten my plugin system two times before I got it to work properly and settle dependencies in a timely manner. But it’s well worth the effort.
Simple backends are better than complex backends
Backends that essentially serve as simple web services are better than backends that return whole pages. The more you delegate to the client, the better. Less CPU cycles spent by backends, and more flexibility in the UI.
Don’t set or read cookies in the backend
The backend should be completely oblivious of any cookies you have. And it should set none. The reason is that not every consumer of the web service might be able to set cookies. So use cookieless HTTP requests and use encryption and hashing to deal with security issues.
Stateless backend is great
Since we’re talking AJAX apps, you don’t need to worry about loggin users in each request. Payoff is great if you manage to keep your backend stateless (no sessions). It simplifies things greatly.
String templates and declarative is good
Instead of building HTML elements using jQuery, just append a string. Then use plugins to add interactions and event handlers. Plugins should read the element attributes instead of asking for extra data. I think this is a good pattern. At least it’s faster.
So ok, I’m really tired now, and I bet there are typos and babbling all over the place. But this is more of a note-to-self thing, so please forgive me.
