The Funny Side of Web Development and Multiple Languages

I was adding a few features to a product the other week when I contemplated that often times the simplest change takes forever and adding major features can be a snap.  The inconsistency comes from the complexities of Web development.  To illustrate the point, I am going to borrow material from one of my favorite comedians Robin Williams.

Robin did a routine a few years back about the invention of golf by the Scottish using a conversation between the drunk Scotsman who invented golf and an interested player:

Drunk: We’re going to make a game.  We’re going to make you put a ball in a gopher hole.  It will be really fun. (hiccup, burp)

Player: Sort of like bowling?  We roll the ball into the hole?

Drunk: Heck no.  We’re going to make you hit a tiny ball with a stick.

Player:  I guess if we are not that far away from the hole-

Drunk: Heck no, we’re going to put you a couple of hundred yards away.

Player: Hopefully, you’ll at least make the thing straight so we just-

Drunk:  Heck no, we’re going to curve holes left and right.

Player: Just don’t put anything in our way.

Drunk: Heck no, we’re going to put water and trees in the way and even sand.

Player: We can try it once to see-

Drunk: Heck no, you’re gonna do it 18 times…

I think you get the point.  Different holes and sand traps certainly make the game fun, but these obstacles also make golf challenging to learn and harder to master.  Web programming feels the same way to me.  There are many reasons why it has become so complicated from humble beginnings.

Just for your edification, the essence of any Web site is a URL which looks like this http://www.openmountain.com/hello.html.  Somewhere on a server, there sits a file named hello.html.  All the other stuff on the URL before this file name helps the Web browser on your laptop locate this file on a central server and download it to your laptop for display.  I know, I know, this is so 1997.

The file hello.html contains HTML which is a simple display language.  The browser understands this language and can turn HTML code:

<html><head></head><body>

Hello <b>Robin</b>! How <i>are</i> you?

</body></html>

into this:

Hello Robin! How are you?

If only Web programming was that simple.  Here now a conversation between our fictitious Web creator Lee and our programmer Marc:

Lee: I have created the Web for you so you can put all your information and data on a central server and everyone can share it.  To display your information, you just need to create HTML files for people to download.

Marc: That’s fabulous!  I love it.  Can’t wait to start.  Can I add If statements and For loops so I can do real programming?

Lee: Good point.  OK, I will add Javascript in the file.  You can code loops and stuff using <script> tags and do display with HTML.

Marc: That works.  But wait, if all my data is on the server, do I have to download all of it all the time?  How do I get only the data user’s want?  Use Javascript on the server?

Lee:  Heck no.  We need a completely different language for that.  It will execute on the server where your shared data is.

Marc: OK, we’ll execute all the code on the server.  We don’t need HTML and Javascript anymore.

Lee: Heck no.  The output of the code on the server will be HTML and Javascript.

Marc.  So our code will output code?  Seems complicated.  Well at least the server side language can collect data and do processing all in one language.

Lee: Heck no, you have to use SQL language to extract all the data and then another language to process it and create the HTML and Javascript.

Marc: Wow, that’s a pain.  I guess so long as there is only one server side language in addition to SQL that’s not too bad.

Lee: Heck no, there’s Java or PHP or Ruby on Rails or Python or-

Marc: I get the point.  So let me get this straight.  I have to learn 4 languages 2 of which execute on the server and produce output that is comprised of the two other languages that run on the client.  Is that right?

Lee: So far so good.

Marc: I was expecting another response.

Lee: Which was?

Marc: Never mind.  OK, so now my users want more interactivity and less download times.  If I pull down all the data they want at one shot, then every time they request something else I have to go collect a bunch more stuff, right?

Lee: Heck no, but this “heck no” is one you’ll like.  You can use something called AJAX to go back to the server and just pull a little bit of information.  Users love it and it uses Javascript and the server side code you already have.

Marc: Finally!  OK, that’s cool.  So I just have Javascript, my server language and SQL and I am set.

Lee: Well…

Marc.  Don’t say it!

Lee.  Um, well, hmm, heck, um, no.  See the X in AJAX stands for XML.  Now XML is a lot like HTML so it’s not exactly a new language.

Marc: Lee, did you ever think about what would happen if I had a bug in my code?  Like a user clicks a link that does an AJAX call and it does something wonky?

Lee: That could be a problem.

Marc: Yes it could.  The bug could be in the server side code in the SQL or the server side language that is executed when I first download the page.  Or it could be in the client side code in the HTML or Javascript that is generated.  Or it could be in the server side code that gets executed when AJAX is called which also has the server language and SQL.  Or it could be in the result that comes back from the AJAX call which has HTML and Javascript and XML.

Lee: Did I show you how easy it was to create a page to say hello to Robin Williams?

In case you were wondering, the feature that inspired this post was your standard geo map integration.  Creating a map on a basic HTML page should take you no more than an hour at most.  Our product uses toolkits with the Rails framework and the nuances from using both combined caused the delay.  In the same amount of time later that week, I created user profiles with custom fields and modified the product to show the thumbnail of the user’s photo with comments.  I guess some holes you par and some holes you double bogey.

Web development truly is comprised of server side code operating on shared data and client side code running on your local computer.  The client code is primary about presentation and analysis.  Server side code manages shared resources and data.  If you think about it, optimizing languages and development processes for each scenario seems like the correct approach for creating a well-functioning solution.  The complexities of engineering are a necessary outcome of distributed systems and data.

Although, we think it is entirely possible to create a single integrated development environment that separates organically upon deployment.  You should then be able to standardize languages and processes.  We’ll add that to the list of other ideas we may never get to.  Would it be cheating if your golf club used a robotic arm with laser sighting?

You can find Robin’s original routine at the link below.  I am warning you that it is filled with tons of profanity.  This should be no surprise to Robin Williams fans.

http://www.funnyordie.com/videos/8e441c0a24/robin-williams-drunk-scotsman-invents-golf-from-dirttron

One Response to “The Funny Side of Web Development and Multiple Languages”

  1. Computer Offers Says:

    My brother in law would love this post. We were just speaking about this. lol

Leave a Reply