Gant Software Systems

Open Source

A Tale Of Two Framework Approaches

I’ve been slowly building a new version of this website, to replace wordpress (and its attendant problems and constant updates) with something a little lighter that I control more tightly (I’m not just rolling my own blog engine, but a platform for several other things I have planned). As I’ve done so, I’ve been rethinking a lot of my approaches to software development for personal projects (corporate projects are a different matter and under different constraints). Given the ever-accelerating rate at which frameworks change, especially client-side javascript frameworks, I’ve had to more carefully assess the risk of major breaking changes and attempt to mitigate those as I switch things over. I’m currently building a fairly lightweight blog editor that allows me to create new blogposts using markdown and publish the rendered HTML in the actual blog itself. None of it is rocket science, but there are a lot of little things to think through. Perhaps one of the biggest things I’ve noticed is how different frameworks deal with extensibility versus ease of initial setup. I’m going to use javascript frameworks as an example of the sort of design decisions I’m dealing with, because it often seems to be the worst offender for me, although it’s likely that much of the difficulty I have on occasion will go away once I’m a little closer to a decade of solid javascript usage (I really only started using javascript heavily in the early days of jquery, although I used it under duress all the way back). While I was originally a fan of larger, more comprehensive systems, such as AngularJS because they handled much of the internals of the front end of the application, I’ve since started to move away from such systems precisely because they attempt to handle the internals of so much of the front end all in one place.

Why I Find The Current Javascript Client-Side Ecosystem Frustrating

’ve been developing in JavaScript for a long time and have seen client side techniques evolve drastically over that time. However, I have to say right now is about the most frustrating (and promising) time to be working with JavaScript in a professional capacity that I’ve seen in many years (and possibly ever). Let’s do a little retrospective of what I recall from back when I started really getting into computers.

The New Microsoft

Having started my training as a programmer in the 90s with 16 bit Visual Basic 4 and having seen them at their worst on several occasions, it’s often easy for me to take the side of people who don’t like the company (except Apple fanboys, because their platform has exhibited a lot of bad, anti-competitive and destructive behavior of late as well and more recently). I’ve seen them destroy competitors, build up a huge userbase on a platform that made building applications easy and then torch it on the altar of progress, and even keep security-hole-riddled crap around for years that caused compromised systems and grief for users for decades. Consequently, I’ve tried on numerous occasions to switch to linux, and ended up coming back to windows (usually after some config file got hosed and cost me a day of work). I’ve lived through ODBC database access, DAO, RDO, ADO, ADO.NET, Linq-to-Sql, and Entity Framework (whose early versions drove me to use NHibernate). I’ve seen ActiveX in the browser, VB webclasses, silverlight, and even FoxPro. I’ve even used Visual Source Safe…. I’ve essentially had a love-hate relationship with Microsoft for a very long time.