So long Actionscript, so long PHP.
January 21st, 2012
To those of you not keeping up with my career as a technologist, I’ve long since abandoned my Actionscript roots (PHP is in serious decline) in favor of Javascript and Java. There are many reasons for this: Industry movement away from Flash, a shift in implementation practices, and a personal desire to keep my own skill set fresh and interesting. Wait a sec… Java? Fresh and interesting? What am I smoking, right? Well, read on:
Speed and Scalability
If you’re working on smaller projects with no notable load, “popular” languages such as Ruby, PHP and Python are great; After all, they are optimized for developer productivity rather than runtime performance, and in 99% of all cases this is fine. This is the main reason they’re so popular in the startup scene, as they enable extremely rapid feature development as a business evolves to find its place in the world.
At some point, however, a designed system must perform at scale, and as most detailed examinations such as this one show, not all languages are created equal. Delivering software at that level in a language that has a poor performance profile changes the discussion entirely: If your system chokes, you lose business transactions, customer confidence, and reporting data, all of which translates into money. In short, the argument stops being about the salary of one or two additional engineers, and more about the reliability and maintainability of your codebase.
Not only have years of optimization made it a very reliable and performant platform, the religious arguments about What Is The Best Tooling™ out there have been had and are mostly over, with configuration winning out over convention every time. The IDE’s support it, Continuous Integration Environments support it, Unit Testing frameworks exist and are very mature, and even though the code itself is extremely verbose, shitty Java will still run faster than shitty Ruby. Mind you, the study in the post linked above was done several years ago, and I’m quite certain that the various languages have improved since, however given the lack of community trumpeting about oh-look-we-finally-beat-Java, I’m going to take that post as mostly-still-accurate.
B2C vs. B2B
The second big shift that happens at scale is a shift from a consumer-based business to a service-based business. Don’t get me wrong: Consumers are important, however onboarding more consumers is a linear function, and usually not a very steep one. Onboarding businesses to your platform, however, is an entirely different beast, as each new partnership could bring orders of magnitude of extra load to your system. Is this a provisioning problem? Yes, yet with it come a whole new set of problems: Will you need to provide authentication integration with their corporate LDAP system? Will you have to Whitelabel your service? Will you need to provide API support? A dedicated and/or isolated data cluster?
To be fair, these are language-agnostic architectural problems, ones which encourage a clear separation of UI and API layer, forcing all business logic into the latter. Websites in this system are simply UI clients and serve no purpose other than making the API human-friendly (not to be discounted- UX is super important).
Now that the UI is simply a facade, does it really make sense to render it on a server before sending it back to a client? Let me illustrate with an example:
Consider a website written in PHP that consumes an API.
- I visit this website
- The Application Server makes an API call
- The API returns the data
- Application Server Renders the data.
- Browser renders the HTML
- I get my html
Now consider a website written mostly in Javascript that consumes an API:
- I visit this website
- Browser calls the API
- The API returns the data
- Browser renders the HTML
See the difference? In the former case, you’ve got two times as many network transactions (added points of failure), and the additional cost of maintaining an application server. In the latter case, you can host the files on a glorified hard drive (S3 for instance) and are talking to the API directly.
But Javascript Sucks!
It really doesn’t: Javascript is an amazing, powerful language that is hamstrung by browsers, an outdated standards body, and a lack of a unified toolset.
Thankfully, browsers are starting to come around (Chrome at the lead) and implementation difference are starting to be eroded. Most of the javascript libraries out there (such as JQuery) don’t seem to have caught up to this fact yet, and are still rooted in the philosophy that they can only work for what works everywhere – no worries, they’ll evolve soon enough if their communities will let them.
The current arguments between the WhatWG and the W3C are obvious to anyone in our industry, and different business philosophies between browser vendors make sites like caniuse.com an unfortunate necessity. Add to that the never-ending political maneuvering in the ECMAScript standardization process, and javascript will forever be a bastard child of 5 different parents each telling it to follow a different career. Having said that, Google has successfully used Chrome as a strategic tool that established a de-facto standard, forcing other vendors to catch up.
Javascript tooling is still in its infancy, and many tools out there have not yet grown beyond themselves. Take, for instance, a unit testing framework like QUnit that is sadly dependent on JQuery, or a functional testing framework like Lebowski which is inexorably tied to Ruby and Sproutcore. Furthermore, many frameworks are differentiated by philosophical differences (take QUnit vs Jasmine for instance) which muddies the water even more. Lastly, even with a plethora of tools, nobody has managed to wrap it all into one single, cohesive whole that combines Formatting, PMD/Linting, Unit Testing, Functional Testing, Documentation and Optimization.
However… the tools are (mostly) all there, individually. JSDoc has become a de-facto standard. Google’s Closure compiler is mostly platform agnostic, drawing most of its cues from JSDoc. Jasmine could be your one-size-fits-all Unit Testing framework (assuming you like behavioral testing), and JSTD is a powerful testing framework that can be used for either unit or functional testing (It’d be even more powerful if the various browser runtime engines could be run headlessly like Mozilla’s Rhino). All it takes is for some enterprising individual to put them all together.
No comments yet.