I learned basic HTML tags circa 1995 and my knowledge of web presentation never really advanced beyond that. For the most part, I didn’t really need to care. I had WordPress and MediaWiki to take care of my more sophisticated CMS needs. Then along came FATE. My lack of prowess regarding modern web presentation became quite the liability.

I’ve been resisting updating this skillset for some time since it just seems, well… I’ll just go ahead and say it: Web programming feels beneath me. Come on, I do low-level stuff, performance-minded C and ASM, you know: “real” programming. The QuirksMode blog phrased it best:

They dismiss Web technologies as toys for children. JavaScript is just this little language that cannot possibly compare to real technologies such as the one they’re using. HTML is too simple. Real programmers don’t do that stuff. As to Web developers, they are just glorified pixel-pushers that should in no circumstance be taken seriously.

That pretty much summed up my sentiment (for context, in must be noted that the author of that post was railing against that this mindset). However, my old way wasn’t working and I needed a new way forward. Fortunately, a breakthrough came when I discovered Google’s visualization library. I was able to invoke Google’s widget in my web page which would in turn call a script on my server which would provide some table for charting. What a relief: I wouldn’t have to do a lot of heavy lifting myself. The rework wasn’t perfect but it was a start.

With my offline RSS reader project, I find myself requiring a more sophisticated web presentation again. As you might imagine, this is what the whole thing looks like so far:

That required some tedious intermingling of Python code and HTML markup. If there is one overriding theme I have learned about sane web programming over the past year or 2, it would be that if I’m intermingling code and presentation, I’m doing something very wrong. And comparing what I have accomplished in PHP vs. what I know to be possible in PHP (like WordPress and MediaWiki), I have little reason to doubt that I’m doing something very wrong.

It makes sense: The big reason that FATE frontend development is at such a standstill is that I dread having to implement and test changes in the massive index.php file, even to change just one of those links in the list at the top. The pervasive theme in web programming is that the presentation and code need to be separate. Precisely how these things need to be separated remains a subject of debate.

The prevailing sentiment is that web applications should use a paradigm called Model-View-Controller (MVC). All basic descriptions you can find regarding this topic all sound quite reasonable. But much like object oriented programming or — I suspect — any other programming paradigm — no 2 web frameworks share the same idea about exactly how to implement it.

Look, web frameworks suck. In fact, I have another whole blog post already written discussing that very topic. But I want to remain solution-oriented with this post.

I can totally get behind the idea of calling pre-made widgets which call my custom data sources. To that end, I’m auditioning the Yahoo web UI widgets (YUI) for this little project.

There, much better:

Well, at least a little better. You have to give it that much. One static page can cleanly transition between the feeds index as well as index pages for individual feeds, and back again. Plus, there’s that whole sorting thing built in. And the data is all served up via JSON which is incredibly easy to do on the server side.

My offline RSS reader is almost ready for (my) use. But this basic research portends good things for FATE.