Simplicity begets Stability
September 25th, 2006I’ve been following advances in the Ajax world so I can keep my Ajax Transport Layer Alternatives presentation up to date for The Ajax Experience in Boston next month.
Harry Fuecks wrote recently about new approaches to Javascript asynchronous calls. It’s really neat stuff and I’m stretching my brain to try to understand it fully. I wonder though to what extent it will actually solve problems that really exist for most people any better than what already exists.
I’ve been making Ajax apps that work well enough for years while many people have been waiting for all the stars to align before they even try it. I’ve had all sorts of flack from pedants for using iframes and img/cookie because they’re hacks, but JSRS and RSLite have worked consistently and predictably across a large number of browsers for 5 years and more without modification. I only changed my Blogchat app to use XMLHttpRequest recently (for no really good reason – it’s been unchanged since 2002) and the first thing that happened was a huge debugging session to figure out a really wonky deep IE7 issue.
The thing about simplicity in the programming world is that it begets stability. The unknowns and dependencies introduced by layers of abstraction and frameworks and preprocessing can in some cases introduce far more potential complexity and maintenance issues than the problem at hand is worth. While there is definitely a class of complex UI problems that are now trivially resolved using the latest and greatest of libraries and frameworks, don’t forget that many simple problems deserve simple solutions.
[…] In a good is good enough type post, Brent Ashley (fellow Ajax Experience speaker) talks about the stability that comes from simple solutions. Applications with more moving parts tend to break – that’s just the law of nature. I know that we geeks *love* to add all sorts of bells and whistles but given the choice, I’ll take a system that stands up to some roughhousing. The next time you start on a new feature, remember these wise words from a sharp dresser “simple problems deserve simple solutions”. […]
Hi Brent,
Gotta thank you for the pages you put up covering JSRS all those years ago! Just a comment on this post – I do think that if you dig a little into what Harry is saying in his article there is a greater pragmatism there than you may have initially realised.
I am working with a team on a project which has required alot of javascript event-driven development. This work made it clear to me that event-driven, whilst initially fun, is extremely hard to debug (and often hard to follow).
I think Harry was looking for ways to ‘change the game’ and make the code more the descriptive of what happens rather than have the logic spread amongst your event handlers.
I certainly am a proponent of ‘simplicity begets stability’. As Harry admitted – the systems he described in his article may not be ready for prime-time – but consider if Javascript had the blocking abilities built into the core. To simplify the permutative nightmare that can be event-driven programming would also satisfy your credo.
I agree that Harry’s quest to express synchronous thoughts in synchronous code is desirable. As you may know from way back, this is the grail I was always looking for too for remote scripting.
I’d just rather not do it through sleight-of-hand that simply masks what ends up being actually async code. I’d rather there were a different threading model or a non-blocking sleep() function in Javascript or a synchronous XHR call with more control over timeout and connection parameters and better error trapping so you can actually make synchronous calls without consigning yourself to lockups.
In the meantime, I’d tend to want to avoid code that pretends to be something it’s not.
I totally agree with you – I think it would be a long time before I am comfortable with anything that involves the sort of preprocessing Narrative JS needs. It reminds me of Simon Willison’s ‘Leaky Abstractions’ comments in one of his posts earlier in the year.
I am not confident that anyone could successfully abstract away all the myriad of differences between the browsers. All it takes is on compatibility issue and you are digging through not only your own code but that of the much more complicated parser/abstraction layer.
This is why I shirked even looking at any of the Java-based JS generators (such as Google’s library and DWR). Narrative JS is fun to read about but wont make it out of my sandbox at this stage.