/blag

Welcome to my blag!

I was frustrated by the bulk of a lot of the web frameworks out there, so I decided to write my own.

<img style="margin:0px 8% 0px 8%;"src="/assets/completelyWrong.jpg" alt="programming: you're doing it completely wrong"/>

The norm with any framework is to store information in a database, and retrieve that information as necessary.

While this is a well established practice, it makes it difficult to interact with your content in any other way. For simple applications like my website, I would rather just work with the filesystem. There are a number of benefits to this:

  1. I can edit my blag posts in vim (or any other text editor) like I edit anything else, no web interface necessary. Though, I have wee editor I've been playing with, which will soon work as a publishing platform.
  2. I can version my files with git, like I version anything else, no web interface necessary.
  3. Migration does not require sql voodoo or additional passwords. Use rsync, sftp, w/e, you could put the whole thing in a Dropbox folder, if you didn't care about it going through teh cloud.
  4. Like practically everything else having to do with web programming, it's just a tree. I see no reason to use an extra language to interface with my datastore, which realistically is just a different kind of I/O.

My design specs are fairly simple...

Parsimony

My goal in writing this is not just to have a good option for myself. I plan to release it as an example of how much functionality can be packed into a tiny amount of code. Most of the code is my own, but I've included a select few libraries which I felt were sufficiently minimal, namely:

  • marked.js, a serverside AND clientside markdown parser/rendering engine. The extra code I have to include is dwarfed by the amount of html it replaces.
  • ki.js, a tiny jquery-like selector syntax.

Other than that, I'm trying to stick to vanilla js as much as possible. I mean for it to be an example of what well written js looks like.

Efficiency

Not only is it meant to do a lot of things, it is meant to minimize the amount of traffic sent over a network. It does so by (as mentioned above) serving markdown via ajax calls, only reloading the page if absolutely necessary. Fetching and rendering is achieved lazily.

Whenever possible, I code within the bounds of both clientside and serverside js, maximizing code reuse.

Autonomy

That's right, no outsourcing. I'm not building in google analytics, offloading onto CDNs, or anything like that. Scripts are local. Assets are local. Logs are local. Your clients browse to your ip, they get content from your ip. No browser info leak, no tracking cookies, no social media app integration.

If an asset is so large that you cannot host it yourself, you should start looking for other options:

  1. Share it via torrent, if that makes sense.
  2. Compress it somehow, scripts and css can be minified. Fonts can be cached, etc.
  3. Consider whether it needs to be included at all. Obviously a photoblog needs photos. If your focus is information, style your website with gradients or other css features. Fight bloat however yo ucan!

Transparency

I've enabled CORS. You could already download all my source, but this means you can serve HTML that calls my API, if you want. I'd rather you just hosted it yourself (see above), but if I decide to host anything dynamic, you can reskin it for your project however you want.

Minimal specifications && clear documentation

My goal is to create a focused core. I will not develop plugins if they overreach beyond the core functionality intended in the base. Software updates are best when they result in a negative net size requirement.

My specs are as follows:

  • optional serverside rendering for people without javascript. I love js, but I see where you're coming from.
  • an optional microblogging interface
  • feed generation
  • a general sticky interface sandboxed from the feed
  • static content hosting
  • "plugins" via the html template. "APIs" via static JSON
  • Logging, and local log parsing for admins
  • optional proxy (pre|post) routing
  • clear filesystem layout
  • integrated documentation
  • short, descriptive urls
  • formatting via file extension
  • Rendered Markdown served in a template
  • Rendered Markdown served plain
  • Plain Markdown
  • Markdown encapsulated in JSON
  • XML describing changes to the Markdown (an rss feed)
  • Support for activity streams as you might find on socialno.de.

Blagging

The great sin of the web is that there are so many projects vying for your attention, with the natural trend that the important issues have been abstracted away.

Rather than trying to capture users, I would like to see users learn enough to become developers in their own right. An informed populace is the basis of a better future.

Every time I use some fancy Javascript technique that I think is likely to be misunderstood, I blag about it.

Any time I make some unconventional decision, I blag about why I think it is justified.

Anyone who wants to adapt my framework to their needs should be able to do so.