explorers' club

explorations in dev, science, sci-fi, games, and other fun stuff!

Thoughts on JavaScript: A Paradigm Shift

3 Comments

Preface

Over the last 2+ months, I’ve been doing quite a bit of soul searching.  Mostly I have been evaluating my desire to stay in the IT game.  With the demise of Flash I’ve been really struggling to get enthused about learning JavaScript.  This is my semi-educated first and subsequent impressions of JavaScript and really more of a journey to my thought processes and rationalizations on WHY I should just suck it up and learn this quirky, frustrating, kinda-cool language called JavaScript.

At first blush

When I first decided to take the plunge and start learning javascript, I’ll admit I was less than enthused.  Javascript has been around in some form or fashion since the 90s.  It’s not a real object oriented language and achieves pseudo class inheritance via it’s reliance on a prototype chain + plenty of wonkery.  For any seasoned Flash/Flex/Actionscript developer this seems like a step back to AS2 or AS1 even.  It lacks strong typing.  It’s subject to per-browser quirks.  While being “standardized”, it seems Microsoft, Apple and Google all want to seed the path of progress with various APIs and styling idiosyncrasies .  With all these reasons anyone with a similar background could appreciate my reluctance in learning it.

But alas the tides are shifting.  And so are my attitudes.

The good ol’ days

I generally subscribe to the ol’ idiom “If it ain’t broke, don’t fix it”.  Ergo my initial attitudes.

It used to be that any real application had 3 components to it: the client which was user-facing, presenting data and receiving user input; the services that interpreted said user input and forwarded data; and the data which resided in, yep you guessed it, the database.  Pretty basic application programming oh let’s say for the last 10-15 years at least.  Generally these 3 separate components were comprised of 3 separate technology languages.  Whether it be a Flex-Java-Oracle system or an HTML-PHP-MySQL system, it generally required 3 specialists to work on the individual components and to work in concert.  Anyone with experience in an enterprise-development environment knows the plethora of problems that arise from supporting legacy data and legacy services with an ever evolving client.  Looking further into the HTML-PHP-MySQL system, you ofttimes have PHP services serving up client side code.  Basically the rendered client was assembled on the service layer.   In a case like this, you’re blurring the lines of responsibility and are actually committing an OOP no-no!  You’re coupling your design to your service layer.  Thinking back, I can now appreciate why it always seemed that as a client-side developer, we were always waiting on the service guys to catch up.  They had to unravel the mystery of legacy code in order to serve pure data to a Flex client.  Sorry guys if ever I seemed impatient.

Paradigm Shift

But that’s all changing.  Now I may have my facts a little skewed or screwed but I think I have the big picture right and here it goes.  Thanks largely in part to technologies like iOS’s dis on the Flash, Nodejs and a move away from SQL-based databases, we start to see technology stacks in pure javascript (aside from some DB specifics).  Now we can have a client written in javascript that talks to a services layer in javascript that then hits a DB that stores data in big ol’ fat JSON-ish objects.  While I can’t speak to the technological pros/cons of such a technology stack, I will state the obvious – JavaScript is here to stay.

As a Flash/Flex/Actionscript developer, at first that chapped my hide, royally I might add.  But in retrospect, I see the value in it.  I’m pragmatic and from a numbers game, it makes a whole heck of a lot more sense to have a common language serve as the core/majority of your technology stack than it does to have 3 or more distinct languages.  From the human perspective, say I’m an expert javascript client-side developer, the ramp up time to help hop onto the service layer written in js is significantly lower than say me as a Flex developer having to hop in and start learning all the ins and outs of PHP or Rails or Java.

Some advantages

In the previous point, I already listed that you have more reusable skill sets that can be applied.  As a client-side developer, I WANT to be more versatile.  And prior to this opportunity, the opportunity costs for entry into the realm of a server-side developer was very high.  Now I can take what i learn as a client-side JS developer and go hop on the node services.

The next advantage is the cost of entry is low.  I’m sure I won’t win any fans with this statement but JavaScript has a low cost of entry.  I’d probably not call it an elegant language (yet).  There seems to be TOO many ways to do something, most of them very cumbersome.  But any Java, ActionScript, C* developer will probably feel at ease diving into the code.  I can’t speak for Rails, PHP or other folks but from what I have heard, they seem to have an easy time learning JS too.

Next up: Javascript is forgiving.  Or rather the browser is.  Now this can be a huge point of frustration as debugging things that just don’t work because the browser decided to eat the error.  But in most cases, if you’re careful, you can write some pretty gnarly JS code and still have it work.

It’s everywhere.  So if you add up all the iPhones, iPads, iPod Touches, Android phones and tablets, pretty much any computer sold in the last decade, you can make a safe bet that Javascript came with the installed browsers.  So it’s ubiquitous.  I’d be interested to know the penetration states of say EcmaScript 5 compliant browsers vs say Flash Player 9 or 10.  Considering the explosion of iOS and Android in the last 3-5 years, I’d say JS beats Flash Player’s what? 98% penetration stats?  I’m taking a wild guess so if you have actual numbers, fire away.  This is today.

Used to we spoke about refrigerators, microwaves, coffee machines and other non-computer appliances with some sort of embedded Java interface.  I’m sure in the very near future if not already today, there are appliances being made with Linux & apps/interfaces being built with Javascript.  This will be very appealing to non-computer tech companies who want to jazz up their UI without investing too much in proprietary software.  Embedded technology can be cheaper and have a lower point of entry via Javascript.

Lastly, why code to multiple platforms when you can code once.  That’s not to say you won’t have per-platform specifics but if you can code 98% of your application in one source and then have platform specifics left to the last 2%, I’d say that’s a net win.  While I appreciate the advantages that native code for iOS and Android provide, in terms of many of the aforementioned advantages for jS, you really can’t beat it.  Gaming is probably the only example that I can think of where going native is your best bet.  Most users aren’t going to notice the 2-3ms difference because the browser takes a tad bit longer than the native touch interpreters.  We’re talking the 98% here.

The sapling

So you probably think me a JS fan-boy.  Not at all.   I think Javascript has so much room to grow.  With EcmaScript 6 coming hopefully soon, we can see less design-wizardy and more development common sense.  Built in module APIs, interfaces, some sort of more-class-ish APIs, yumyum.   JavaScript also allows you a level of freedom that I never had coding in Actionscript.  All of the sudden I find my right pinky hurts less because I’m typing less colons & semicolons.  OMG!!!!

Really it boils down to this: I’m pragmatic.  Either I can be the tree that bends with the wind or I can be the tree that breaks in the wind.  Whether you like it or not, Javascript is here to stay for a good long while.

Advertisements

3 thoughts on “Thoughts on JavaScript: A Paradigm Shift

  1. > JavaScript also allows you a level of freedom that I never had coding in Actionscript. All of the sudden I find my right pinky hurts less because I’m typing less colons & semicolons.

    Great arguments, especially for developer who’s trying to fix something in the code after you.

  2. Very cool post. I felt the same way when I was transitioning languages. I remember too getting into ruby on rails. But now I am all into SP. Thanks for sharing my friend! Great post…

    John.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s