Javascript

by

Cypht 1.0.0 Released

After more than 3 years of work, over 3,300 commits, 8 release candidates, 126 resolved issues, and 35,000+ lines of code, I’m pleased to announce the first official stable release of the Cypht webmail program is now available! As anyone who has worked in creating releases for software knows, it’s hard to draw a line in the sand. There is nothing worse than creating a release only to find out the next day you forgot something critical or missed an important bug fix. At the same time, creating releases is a crucial part of getting your software into the hands of users.

I created the release branch 2 months ago with the hope that it would only take a week or two to work out the kinks. After eight release candidates, we finally hit the “it’s good enough, let’s do this thing” point. The way I’m structuring releases in git is to create a release branch from the master branch, then porting applicable bug fixes from the master branch to the release branch while putting out pre-release candidates. Point releases will come from the same branch, but primary development continues on the master, until the next major release, which starts the process over again. I first learned this style of releasing from the Squirrelmail project lo these many years ago. In those days we used diff and patch to port fixes from trunk. With “git cherry-pick” this process is a LOT easier.

The downside to this approach is that over time the master branch diverges from the release branch, and it can get harder and harder to port fixes. The solution is to release often, effectively “dead-ending” the prior release branches as new ones are created. This is a good thing since it encourages frequent releasing. Enough has changed in the master branch in the last 2 months, I’m already eyeballing a 1.1 feature release.

I want to thank everyone who contributed code, filled out a bug report, sent me an E-mail inquiry, requested a feature, donated a translation, or told me they love/hate it. The primary force behind Cypht development is what I want a webmail client to do, but feedback is super important to broaden our user base. I greatly appreciate everyone’s feedback and support for the project.

If you are looking for a secure, lightweight self-hosted webmail that provides access to all your E-mail accounts from one place, give Cypht a try and let me know what you think!

https://github.com/jasonmunro/cypht/releases/tag/v1.0.0

by

You Got Your Javascript In My Peanut Butter

I have always tried to embrace a minimalist approach to software design. Even early on in my career when I had no idea what I was doing. In those days I rode a horse-drawn carriage to work and used a pointed stick to scratch PHP3 code directly onto the server’s hard-drive platter. Good times. Back then JavaScript was like window dressing – a bit of flair for the UI – definitely not something you relied on for the web application to function.

It was possible some of your users might not have JavaScript support, and at the time we actually cared about those users. The first two major Open Source web applications I built both worked without JavaScript. I’m pretty sure that increased our user-base over the period of a decade by at least 1. Totally worth it.

These days it seems nobody cares about users without JavaScript. Even me. I care only enough to display a noscript tag with a message stating it’s required, but only when I’m feeling particularly ambitious. In my head I picture users with JavaScript disabled as middle-aged versions of Kip from Napoleon Dynamite, all of whom used punch cards in college, started in IT as a data processor in the late 80’s, and are still running Windows NT (or wish they were). Now that I think of it, if they are running NT they probably should have JavaScript disabled.

As much as I dislike the language – and I do – it makes sense to offload parts of an application to the client. Let’s face it, you can’t be all super-web 3.0.1 if you don’t make constant AJAX requests in the background the moment a page loads. I may be a neck-bearded curmudgeon, but I have begrudgingly come to accept that JavaScript is the best way available at this point in time to improve web applications past what HTML5 brings to the table. To a point.

As an industry we seem to be lurching towards JavaScripting all the things. JavaScript only interfaces! JavaScript on the server! JavaScript interpreters written in JavaScript! The older I get the more I try to balance my skepticism of new ideas with a willingness to keep an open mind, but I am having a hard time catching a ride on the all-JavaScript-all-the-time bandwagon. Maybe I am biased by the five years I was forced to use a bloated unintuitive framework for a former employer, of which the only thing I remember (aside from being gigantic) was how effin horrible it was to work with. But probably not. Additionally, I seem to have missed the memo to web developers that everyone in the world now has high speed internet so we can push gobs of scripts client-side even to perform the most simplistic task. I’m slightly offended nobody told me. Have I also been walking around with a booger hanging out of my nose? Come on people, throw me a bone here.

Running JavaScript on the server is interesting, but for me it’s interesting in the same way that a squirrel water-skiing behind a toy boat in a backyard pool is interesting. I realize event-driven non-blocking I/O is the new Holy Grail of server-side processing, and buzzword-laden start-ups are required to use it in their stack in order to get funding, but I just can’t seem to let go of a well tuned web-server with a fast scripting language and moderate use of JavaScript in the client as an effective foundation for building web applications. Then again I don’t have good reading comprehension because my eyes are worn out from years of articles about the latest technology fad revolutionizing web development, so maybe I am just missing the toy boat.

I didn’t start this post with the intent of bashing JavaScript, and the fact that I now rank it slightly above “necessary evil” (but still below “creepy cousin”) is as close to an endorsement of the language as I have ever come. One could even conceivably describe it as being “handy” for limited purposes *grinds teeth*. Maybe someday I will be telling my great grand-kids about the crazy old days when there were other programming languages, way back before every conceivable app was ported to JavaScript and all knowledge of anything else was lost to generations past. Somehow I doubt it.