At first blush
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.
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.
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.