In the 1990s I was totally committed (not by choice) to C++ for software development, which is truly an amazing object-oriented language – I remember a company architect in the early 80s that object-oriented programming was going to be the 'next big thing'. And he was correct. And C++ was the pinnacle of OO type languages.
But after so many years with C++, I was getting tired of so many core dumps due to array out-of-bounds errors, et. al. That's why I got excited about James Gosling's Java programming language, the 'next big thing'. So I began attending multiple Java One conventions at the Moscone Convention Center in San Francisco.
In one of the breakout sessions, I learned about this new scripting language called Javascript, and it set me on fire. I proceeded to buy a bunch of fat-book tutorials on Javascript to learn everything I could about the language. One of the first things I learned was that, while it was heralded at a Java Conference, it had nothing to do with Java, save the name and that they both have C-like syntax.
I was pretty excited about this new language, easily integrated into UI code, easy syntax, and most of all you DON'T HAVE TO COMPILE / LINK IT! If you make a change, just reload and re-run – which was perfect for the burgeoning new paradigm of browser based web applications. This was a great new tool to promote rapid application development. And given that web apps no longer provided client based logic per se, in contrast to heavyweight client apps, JavaScript provided the means for UI logic and filled in that hole quite nicely. And of course, like HTML, Javascript interpretation was handled by the browser, making it cross-platform agnostic (except for Internet Explorer 6, the biggest piece of sh*t software written in the history of software, But I digress).
This means that developers could still write code that kept the server from having to do a lot of frivolous logic, such as UI form validation for example, determining if two password input boxes had the same exact strings or not (or am I a robot?), among other more proprietary requirements. And in the 90s, there was a huge surge of processing power capability in laptops and desktops, which provided ample juice to allow more complicated logic to execute on front-end device browsers.
A simple google search of "Javascript Benefits" would list many of the niceties that I described above, but it is always better to experience them directly.
Javascript in the 21 Century
Here's where things got really interesting.
Around 2005, my team was purposed to create several small web based applications displaying read-only data sets based upon proprietary data. We already had a client based version of the applications, which looked like this:
--------------------------------------------------------------------------------------
| | |
| | |
| Section A rows | Section B rows |
| | |
| | |
At initialization, all three sections were DIVs that were fully populated and scrollable. Section A and B had selectable rows and any new selection row in A or B would select a new row in the Results C section, or just several cells in a resultant row.
This was such a simple interface that we thought we could find a simple elegant solution. We already had a data layer interface on the server that could supply any data need on a selection change.
Our solution? Using AJAX via XmlHttpRequest.
Javascript networking capabilities was brand new, being released in 2002, but already there were numerous developers and groups creating JS framework and object packages. With our first application, we employed the low level XmlHttpRequest function utilizing only GET functions, since nothing could be changed by the user, as per requirement. We developed a non-RESTful set of calls, which returned in the newly developed session API methods instructions to "change to Row X" or update "Cell X, Y, Z in Row X", for example.
When we had our development completed, I began cursory testing on the new app, selecting random rows from Sections A or B. I could not believe how blinding fast the updates in Section C were! I had to do double-takes when only specific cells were changed to see if they really were updated. This new paradigm of calls through the JS code, I knew right then, was going to be big. Real big.
I began surfing the web to see if other developers were as happy as I with this new paradigm of programming. There wasn't much, but I did find a group out there that was trying to promote JS network programming, call SOFEA, which stood for "Service Oriented Front End Architecture". It is also called SOUI or "Service Oriented UI"
Dojo Toolkit
Our second application was implemented using one of the new frameworks out there, which could cleanly wrap the XmlHttpRequest() function and handle error cases more cleanly. Dojo is an Open Source toolkit built by a host of dedicated developers which still exists today, version 1.17 (I was likely on v1.4 back then). Additionally Dojo allowed users to simulate object-oriented and behavioral methods for the various UI widgets on the screen. While not as fast as going pure XmlHttpRequest, it was still amazing.
What I didn't know was this: We stumbled upon the Single Page Application (SPA) paradigm in 2005
Being Held Back by the President of my New Company
In 2008, our little startup where all of the above occurred was acquired by Medidata Solutions. One day a group of strange people came into our conference room to announce that we were being bought, and as part of the due diligence process, I demoed these new JS based products to Glenn DeVries, the president of the company (and de-facto CTO and head architect).
I'm not totally sure if he liked what he saw or not, but he did encourage me to discuss my use of the Dojo framework with the tech leaders in the near future.
After our purchase / merger, we began a process of re-tooling and redesigning all of the original products into the new company design and philosophy. The current architect in our startup, Peter Abramowitsch and I had some deep dive technical brainstorming sessions with Glenn. Guess who won those arguments?
Glenn insisted that all new UI development would have to be done using Ruby on Rails (remember, this was 2009), and nixed the idea of a SPA / JS design for the UI. In fairness to him, as a leader, he knew the costs that higher maintenance of products would affect the company bottom line, and Ruby on Rails, at the time, was the leader in Test Driven Development, with their rollout of rspec and Gherkin based cucumber test frameworks. In a summary lengthy email to me, Glenn said basically it's my way or the highway, but I did respond with," ok, it's your company, but there's a future here with AJAX and JS frameworks on the client side". Little did I know...
Another time, during a reveal, I remember Glenn and one member of our team discussing how much they didn't like Javascript, citing its loose type-ness and weakness in error handling. I was a bit perturbed by their comments, but I kept my mouth shut. Arguing with the big boss(es) too much doesn't lead to very useful results.
Of course, UI development in the new applications still incorporated a good bit of Javascript for user validation and complex interactions. Early Rails used the prototype JS framework, which was such a dog that we ended going with jquery, speeding the product up considerably.
Vindicated in the 2010s
Years went by, and I eventually moved onto the server side, hung up my coding hat, as being an engineering director for distributed services for multiple products took all my time. And really, I was happy about that – over time, I noticed the endless niggles and bugs on the UI side were always the last obstacle to products releases time and time again, and I was glad to not have to deal with those headaches!
Then around 2012, I heard rumors about a new product being built in the NYC office using a whole new, huge Javascript framework called Angular, developed by Google. Not only that, the company was moving to Single Page Application paradigm whenever possible. I was so pleasantly surprised – Javascript as a core level framework for application development had finally arrived!
I told the UI teams over in California about this new change and it appeared that they already had begun thinking about the next product coming out using Angular. In managing that product's development on the server side, I did hear complaints about the ramp-up time that Angular had, but the team persisted and the new SPA product was finally released a couple of years later.
By then, the difficulties surrounding Angular became quite known in the UI world, and any cursor internet search would reveal numerous Javascript frameworks vying for the hearts and minds of web developers. Around 2015, the wave of acceptance of React.js became a major shift in the world of UI development, and the company adopted this as the chosen framework for all current and future development.
Summary
I've since retired from the work world, but I felt like I grew up with Javascript, evolving over time, from an HTML add-on for user validation to becoming the most popular language used in the world of software development.
I am happy for it!
You are reading the story above: TeenFic.Net