Getting Right Back on Track and Fulfilling a Promise

I love coding!

I'm not sure why, but I've had the easiest time to just sit down and crank out some code. And I love it! The tickets are just flying by as I whack them one after another. I've also actually done a commit for the longest time. This reminds me: I should study Git more closely.

The ORM is rewritten from scratch, and I'm back about where I was when I first started, with a much better architecture underneath than the last time around. Boy, the old "hack now, fix later" really bit me in the butt, huh? I'm feeling that each remaining part of LF (namely the 'core' and Response) could do well with a rewrite, or a code review at the least. But they seem to be working, and, as they say; le mieux est l'ennemi du bien (very freely translated: Perfection is the enemy of good enough), so I probably will let those ones rest for now and concentrate on actually getting the product out.

---

To go off in a tangent and filling in an earlier promise, in Restate My Assumptions, I said: "In small-scale web projects, sacrificing some performance to gain convenience for the developer is an acceptable trade-off." I'd like to now clear up what I meant by that:

Call me unambitious, but I'm not targeting the corporate world with LightFrame. The big-bucks corporate world probably uses Java for their web projects anyways. No – I'm after the home users, who have their great projects they want to do for their own, including perhaps a few friends', pleasure. A personal website, blogging engine, photo gallery, calendar software... That's my targeted audience.

With this in mind I'm giving myself a bit less hard of a time when it comes to performance optimizing. When facing a decision between convenient and efficient, I always choose the former. The convenience is for the user, mind you. The user who codes against LightFrame. This very same decision is also a decision between more work and less work, respectively. The fact that I consciously choose more work for me doesn't bother me the least bit, because this leads to less work for the developer. And that's what frameworks should be all about - less work for developers. This would go all to waste, if the configuration would cause a noticeable overhead, even if the coding part of things would be minuscule.

Anyhow. This convenience often requires some computational overhead. To figure out the current Model's SQL table counterpart takes some string manipulation, which inevitably takes some time. Sure, I could force the developer to explicitly tell me what table name she would use for each Model, but that quickly becomes tedious. (NB: You do have the freedom to define a custom table name, but you're not required to.)

But I'm convinced that this overhead makes no practical difference. With modern processing power, running even a complex script takes no time at all. That, added to the limited visitors expected for LightFrame applications, this becomes a non-issue. Think about it: I would consider 1000 daily visitors a successful website. This divided evenly across 8 hours translates to roughly two visitors a minute, or, put in another way, there's a 30 second window to cater the webpage to a visitor. Your visitor probably loses interest if the page doesn't load within five seconds anyhow, so, again, visitor density isn't an issue.

I even did some fancy mathematical calculations for this post, but I then erased them all, because once I noticed that it's probably trivial to achieve 100 000 PHP instructions per second on a modern setup, I stopped. Let me put it this way: once you have a LightFrame site that runs on half-decent hardware and acts slow down due to the framework's overhead, contact me at henrik paul at gmail, and I'll optimize either your project or LightFrame for you.

The fact remains: LightFrame makes the developer experience a higher priority than performance. That's a fact, and it won't change. That isn't to say that performance isn't a priority - it is. It's just not as critical one as ease of use. Besides, let's face it: if PHP is your language of choice, then performance probably isn't your number one priority to start with. LightFrame is, and will be, fast enough.