I refuse to believe that the entire planets best idea of the day is JavaScript.

There isn’t a day that goes by where I stumble into some random blog post, comment, remark, argument that involves JavaScript lately. It’s as if the entire quagmire of its existence is trying to ambush me with wave after wave of interpretation of why it’s important… i’m under JavaScript siege and now it’s time to go all Die Hard on it.

Here’s my notes

* Plugins were evil, JavaScript is the web’s future.
Plugins made a strong point to the interwebs, it said loudly “Hey browser’s stop trying to hijack developers to your greedy needs and if you want to sit around waiting for a committee to make a decision, fine, but me.. i’m going to give that guy over there HD porn…”

Fact is products like Java, Flash and Silverlight (the “evil three”) were the service pack the web needed, it needed to prove the point that developers aren’t getting their fill of API ¬†/ multimedia needs with the slow latency filled migration patterns we (sadly) still have today. It wasn’t until Silverlight and Flash punched each other to death and in turn created this competitive annoyance in the market both externally & internally – that is – internally inside Microsoft it reminded the Windows team that “plugins” could very well hijack the beloved desktop SDK’s if their pace is left unchecked (cannibalizing Windows potential offerings). Externally it also reminded the web that browsers haven’t being doing their jobs, the fact that these two brands duke it out so publicly was the fresh reminder “oh by the way browser, what the hell are you actually doing!”.

Google was the disruptor in that equation as well, Firefox made a good run at trying to keep rising with the demand tide but it wasn’t until Google got its hands in the mix that we started to see a change. Not only did they push the JavaScript angle loudly than any other company but they also baited Microsoft IE Team constantly to meet their needs, it was actually a beautiful thing to see how they worked that team like a puppet via the whole “You need to focus on fixing JavaScript runtime perf levels”.

So plugins are evil? without them you’d probably be still hacking away at some crappy codec or trying to find more hacks to get around memory issues in browser(s) – or worse – writing Java Applets (probably extreme).

* JavaScript is different than it was, its awesome!
Yeah, i’m calling bullshit. Majority of the frameworks today exist to abstract you from focusing on writing actual JavaScript because whatever reason. When you have a JavaScript framework as being the excuse as to why a language should be considered then that’s probably your first clue we’re dealing with a dumb ass response to a problem that needs attention.

Some might argue “well that’s the power of JavaScript, you can write frameworks to solve problems” which to me rides along the same logic as how painters in the old days use to make their own oil paints in order to paint… today you squeeze it out of a tube and you’re now focused on painting less about sourcing various ingredients to make “red”. Abstraction is fine if you are looking to allow a developer to feed instructions into a compiler that then gets distilled into another language (cross compile etc). I simply raise the bullshit flag when that same concept isn’t applied at the compiler but is instead this extra memory footprint at the actual runtime instance itself. As now you’re just putting extra layers of ductape over the corpse that which is JavaScript in order to hide its inherit stink.

* Yeah but JavaScript is what we have today, so we should just deal with it
You can’t really argue this point beyond “yeah but I’m overweight and I can’t stop eating, so just let me die of a horrible death”. I hate mediocrity with a passion and I find anyone who compromises with JavaScript as a solution to a problem they know at the deep core as being a bad idea to be “enablers”. If you are that person and you’re writing JavaScript to pay the bills, cool, but you’re also not helping the industry and if anything you feed the whole ecosystem with more crap to deem “acceptable”.

* Stop using JavaScript isn’t an option, we just have to wait and see what’s next
Which brings me to my next train of thought – what the fuck is taking so long with ECMA6 or whatever its replacement. At what point do we declare fail on these “committees” and rally behind the idea that this shit has to stop taking so stupidly long (are they meeting every 2 years? are they even still alive…are the 90 and need time to watch Matlock before energising the base around their decisions???). ¬†TypeScript for me is “fine, lets just get on with it” or I’m open to anything that hints at being not freaking JavaScript.. i’ll write python in the client if I have to, but get this stuff sorted out and stop wading it down by this agonising death by democracy attitude. Break the web, its broken anyway at least this will be the event that freaks everyone out long enough to come up with a better idea than what we have today.

I refuse to believe that the entire planets best idea of the day is “JavaScript” (aka ECMA3). If that’s the case then the various education systems are teaching the wrong classes.

I have been doing this thing you kids call today “web development” since 1995, I’ve watched the entire internet move at an agnosing slow pace. I got hands on with VRML and watched that crash dive, I got hands on with Adobe Flash which then lead me to Adobe Flex and then later I as most know got hands on in Silverlight/WPF. I keep chasing the idea or potential that we as a human race have, in that we know that multimedia is a medium that can convey so much importance at a pace that’s exciting – when the technology platform allows it.

Today, by keeping JavaScript as being the “best” of the entire plugin wars as a solution, you have to be an absolute idiot if you believe that’s a step forward. It’s steps backwards not just small steps, but large steps.. steps that will take us another 3-5 years to recover from again. Look at the historical patterns around Prescriptive vs Descriptive design languages…

JavaScript is the digital age’s version of herpes, every time you think its gone a new outbreak occurs – DHTML, AJAX, “HTML5”

 

 

 

Related Posts:

Being Playful with Industrial Software

I’ve been sitting in the Enterprise space as a UX mercenary for probably around 5+ years. In every team, sales meeting and brainstorming session I’ve always encountered resistance around “maturity” in terms of design. The more money that is being spent on the software, the more “serious” the design should be. This line of thinking I think typically comes from the concern that if the design is not serious therefore the trust around it’s ability to do the various task(s) will be eroded.

The thing is, the more sales meetings I’ve been in or participated in the preparation for the more I’ve come to the conclusion that “design” isn’t even a bullet point in the overall sales pipeline. Sure the design makes an appearance at the brochure / demo level but overall nobody really sits down and discusses how the software should look or feel during the process. Furthermore the client(s) typically have invited the sales team(s) into the selection panel(s) based off their existing brand, known or rumoured capabilities and/or because they are legally required to.

To my way of thinking, being “playful” with your design is a very unnerving discussion to have in such a scenario. The moment you say the word “playful” most people respond with some word association positive or negative (usually negative) as the word may take you back to your childhood (playing with lego or dolls …I didn’t play with dolls..they were called G.I. JOE’S!). It’s that hint of immaturity with the word that makes it more appealing to me, as it forces you to think about maturity but with the constraints of immaturity (cognitive dissonance).

Playful however doesn’t have to be immature, there are very subtle ways to invoke the feeling of making something playful without actually being obvious about it. For example, Google+ and most of Google’s new branding is what I’d consider “playful” but at the same time the product(s) or body of work that goes into their solutions are quite serious.

Playful Mood Board

Playful Mood Board

Why be playful? My working theory is that the reason why users find software “unusable” has to do with confidence and incentive. If these two entities don’t’ fuel their usage furnace the overall behaviour around their usage decay(s), that is they begin to taper off and reduce it to an absolute “use at minimum” behavioural pattern. This theory is what I would class as being at the heart of invoking “emotion” or “feeling” into how software is made and often why a lot of UX Practitioners will preach as to why these two should be taken quite serious in the design process.

The art of being playful in a way regresses adults back to their childhood where they were encouraged to draw, build and decorate inanimate object(s) without consequences attached. As a early teenage child, you were encouraged to fail, you were given a blank piece of paper and asked to express your ideas without being reprimanded. You in short, “designed” without the fear of getting it wrong or for that matter right (although right was usually rewarded with your art piece being put on the fridge at home or something along those lines). A playful design composition can be both serious but inviting, as a good design will make you feel as if you’re “home” again. A great design will make that temporary break away into using other software and then back again an obvious confidence switch – as if you’re saying out loud “gah! that was a horrible experience, but I’m’m back to this app…man…it feels good to be home and why can’t other software be like this”

 

 

 

Related Posts: