Is Server-Side Javascript the Flavor of the Month?

As many experienced developers would tell you, "choose the right tool for the job". While many may have strong bias towards one programming style over another, it is always good to encounter those who are willing to present an argument objectively.

These days there are a lot of advocates for Node.js, and they all begin their marketing campaigns with the same opening statements, "I know Javascript is crap but..."

And therein lies the dilemma. Its not an easy task having to justify a scripting language as the solution for web application development in an era of staleness within the open-source community. Lets face it, php has one of the largest online communities on the planet, particularly with CMS solutions like WordPress and Drupal, however the language hasn't evolved or adapted to an ever-changing environment. Ruby as a framework doesn't scale well and Python has a very poor reputation for performance.

Node.js seems like a breath of fresh air.

In all honesty, when Node.js came out a few years back with this "new" concept of server-side Javascript, I questioned why we were getting back into the world of Classic ASP which was prevalent in the late 1990s. Back then, we had the power of inline server-side code with your choice of either VBScript or JScript, so the concept wasn't "new" unless you think relatively in terms of the 20 years that this idea has been around.

It was only a little later that I realised it had nothing to do with "Javascript being server-side", but rather that Node.js was able to tame the beast of a scripting language, and create a discipline using successfully proven concepts such as modularisation and encapsulation.

These concepts are very familiar in the object-oriented world and have been around for decades. So why create another server-side framework using Javascript? The easiest answer would most likely be because it is cross-platform and has been jointly adopted and standardized by Microsoft, Sun Microsystems and Mozilla.

Javascript has been superior in web development and, as Scott Hanselman put it, "is the assembly language of the web". It is uncontested as a front-end solution for interactive browser-based development, which is why the adoption of such frameworks like angular.js have been extremely popular, with react.js fiercely becoming a dominant framework too. Bundlers like require.js and webpack are becoming household names, and templating tools such as handlebars.js and jade have shown that Javascript has the power to dominate an ever-growing community. Together with the power of HTML5 and CSS3, it has killed off both Flash and Silverlight in one single stoke.

But lets be clear, we are talking about front-end development here, not server-side development.

While searching the online community to find any significant advantages of using Javascript for back-end development using Node.js, there have only really been two common themes:

• "Front-end developers can work on the full stack of an application using one language"
  This argument is great, as we have seen with the emergence of the MEAN stack. But the separation of front-end and back-end development has never been one of language barriers. Rather the difference is based on a mind-set. Lets face it, you won't see front-end developers picking up tasks related to data-access or API security. The real question is whether or not a functional scripting language is appropriate for server-side application programming.
  
  
• "You can start a web application in literally 5 minutes!"
  While that might be great for those who want a pet project to build "hello world" applications, professional programmers will find obvious challenges once complexity is inevitably added. The headaches around peer dependencies is just one, however the topic of discussion that has been the most entertaining is: to bundle or not to bundle. An issue so primitive it is almost comical to consider that other frameworks solved compilation concerns with output libraries more than 15 years ago. It is a non-issue now and yet somehow it seemed like we have gone back to re-inventing the wheel all over again with Node.js. Those who work on other frameworks with rich environments that provide debugging, diagnostics and compilation already had the wheels they needed to concentrate on real programming to provide the vehicles for those wheels.

Stability in the community is one point Node.js cannot boast about either, especially when recalling how easy it was to fork the code-base and create an entirely new community with io.js simply because they were "dissatisfied" by the Advisory Board. They have recently reunited, but how long will it be before another subgroup becomes fickle and creates another community of their own? Angular.js is already facing the same problems, which is why aurelia.io has come out as a potential competitor. A unified community generally gives confidence in a framework's future.

But lets not get into politics.

Without getting too deep into the "one thread per request" model limitation, or the limitation of only two basic data structures in comparison to other frameworks that provide hash-maps, dictionaries, enumerables, sets, vectors etc, there is one more concerning factor.

If we take a deeper look into programming principals, then we can start comparing Node.js with enterprise frameworks such as Java and .NET and their object-oriented programming edicts.

Software engineering principals like OOP adopt concepts like abstraction and polymorphism, with mathematical concepts like covariance and contravariance.
They define the difference between software engineering and simple web development because it is the philosophy that engineers and science professors like Alan Kay prescribed for application programming in order to help mimic the real world.

The universe is defined with objects that interact with other objects in one way or another by performing a specific function. Each object has its own attributes, and has general similarities with other existing objects which can be abstracted. Since the universe is infinitely scalable, the very concept of OOP over functional and procedural programming can determine the best fit for scalability in complex web applications, particularly in the space that exists for implementing business functions.

One may argue that even between different object-oriented programming languages, the health of the community is equally important. Unfortunately the Java community falls short, and nothing could have been clearer when Java8 came out with the "new" concept of lambda expressions, especially when .NET 3.0 introduced it 5 years prior.

But if "new" is any measure for Node.js being the better option today, is the mere reasoning for a cool new hip way of doing things good enough? What happens when Node.js is 10 years old? Will Node.js outlive its hipster status? And then there are those who are already talking about Golang being the better option for performance and scalability, which definitely raises alarm bells for its longevity.

If the fact that Node.js is lightweight and uses a dynamically typed scripting language has anything to do with it, then a simpler question arises: What would stop us from building a web application using say PowerShell scripts? Why not? Its possible to write primitive code in PowerShell to open an HTTP port with binding through IIS to stream strings of HTML! Given enough time someone might write a wrapper and call it express.ps1 to make it easier!

But that would be silly, wouldn't it...

Going back to the initial statement to "choose the right tool for the job" might help us maintain focus in an ever-changing web space.

Being language or framework agnostic is key to determining the right tools and it could help us realise the natural strengths of the technologies at our disposal. Javascript is excellent for front-end development, PowerShell is suitable for systems programming, and frameworks like .NET are great for scalable server-side application programming.

DateTime.Parse vs DateTime.ParseExact for culture issues

I'm sure most of us savvy .NET developers have come across the dreaded issues that surround the inconsistent standards when working with multilingual / multicultured applications. Namely the sites that provide the opportunity for a user to change their language and/or culture for their convenience.

Dealing with different languages is one thing, but that in itself isn't so bad because it mainly deals with a resource file of some sort that allows mapping of one word (or a sentence) to a different word of a different language. The site can then replace those words where it finds them.

Dealing with data, and specifically dates on the other hand, is a completely different story.

Seriously, why did the Americans have to come up with a date format that doesn't even conform to itself!? Generally speaking, numbering systems work by having the larger metric unit at the front, then the second metric unit succeeding it, and so on (e.g. $15,432,67). Naturally you would expect the date structure to be the same so that the military format (yyyy/MM/dd) would be found wherever we deal with dates.

Even though the Australian format doesn't conform to this, it at least has consistency by having the reverse, whereby the smallest metric is found at the beginning of the sequence (dd/MM/yyyy).

The U.S. format, however, is an influence of their own language. It comes purely from a cultural perspective where they are naturally inclined to say "February the 15th" rather than "the 15th of February". That has lead to the demise of their date format which logically makes no sense (MM/dd/yyyy).

Regardless of the format, we are still faced with the dilemma of having to interpret this in code so that our data isn't corrupted by the front-end client machine's culture, and the server's culture, when the server-side code deals with the data.

You may find that you have a JQuery date picker that can help you "set the culture" as shown below:

$(".datepicker").datepicker({ dateFormat: "dd/mm/yy" });

The problem would arise once the user clicks submit and hits a server with the "en-US" culture.
The moment you write the following code, you will face some issues:

var date = DateTime.Parse(Request.Form["date"]);

One of two problems will arise:

• the date conforms to either en-AU or en-US because the "day" is not greater than 12, and therefore will not complain when translating it into a month part.
• a FormatException will occur because the day is considered month and is invalid if greater than 12.

The way to work around this so as to Parse the date into the current culture of the server, but based on the culture you are expecting the string to be coming in from the client side.

var date = DateTime.ParseExact(Request.Form["date"], "dd/MM/yyyy", CultureInfo.CurrentCulture);

What this does is define the structure of the string that is passed into the first parameter, based on the format of the second parameter. Once it maps the string exactly as defined in the second parameter, it can then convert it successfully to a DateTime type based on the third parameter. The CurrentCulture can define the timezone as well as the format, and any other relevant metadata.

HTML rules for Email clients

The following email clients are generally what need to be supported today:

• Outlook 2003
• Outlook 2007
• Outlook 2010
• Hotmail webmail
• Yahoo webmail
• Gmail webmail
• MacMail
• Lotus Notes
• Eudora 

Since most email clients still use HTML 1.1 in one way or another, there are severe limitations to the look and feel of your email.

Here is a list of general rules you can remember when trying to create an email template:

• Remove <style>.</style>
  • NOTE: This is not always the case and <style> is necessary in some specific cases
• Remove <script>.<script>
• Remove <noscript>.</noscript>
• Remove <link>.</link>
• Change anything with <.*? /> to <.*? > (e.g. <img /> should be <img>)
• Change <td></td> to <td>&nbsp;</td>
  • NOTE: Please test as outlook might create a bigger gap in place of &nbsp;
• There should not be spacing in between the following tags: <img.*? ></td> 
• <img.*? > should have style="display:block"
  • NOTE: Please test as its not always the case
• <img src="" needs to be an absolute path
• <img src="" cannot contain the word "banner"(for spam protection!)
  
  • NOTE: ISP filters and other technology deployed across the internet have complicated rule sets designed to block banners, advertising and all other manner of communication deemed to be unsolicited commercial email. By naming the folder that contains your image "banner" you are increasing the likelihood that your image, if not your entire email will be outright blocked because you've declared it as a banner in so far as a spam filter is concerned.
• Replace style="width:0" with width="0"
• Use embedded style="font-family:." or <font face="."></font>
• Use embedded style="color:." or <font color=".">.</font>
• Use embedded style="font-size:." instead of <font size=".">.</font>
• Replace style="font-style:italic" with <i>.</i>
• Replace style="font-weight:bold" with <strong>.</strong>
• Do not use style="padding:[0]"
• Do not use style="margin:[0]"
• Replace style="float:[0]" with <table align="[0]"><tr><td>[content here]</td></tr></table>
• Replace <style> and <link> and replace all class attributes (class="") with corresponding simple class styles (.className)
• Replace <style> and <link> and add all id attributes with corresponding simple id styles (#id)
• Replace <style> and <link> and add all element attributes with corresponding simple element styles (elementTag) 

 Most of these can be created with an application that stream reads the HTML template and replaces them using Regular Expressions.

Opacity in IE, Firefox and Chrome

pngs and other images require separate styling attributes for IE and Firefox. Below are the two attributes that will allow transparency to be supported for both browsers:

.menu .hover .menuitems
{
 filter: progid:dximagetransform.microsoft.alpha(opacity=80);
 opacity: 0.8;
}

Note: the "filter" attribute is used for IE, and the "opacity" attribute is used for FF.

It must also be noted that this will actually make the entire image transparent so all text found within it will most likely not have the desired effect.

This is different from images that have transparency in it.

Html and Javascript basic practices

Developers get tempted to embed <script> tags within their html or aspx pages as shown below:

<html>
    <head>
        <title>Test Page</title>
    </head>
    <body>
        <script type="text/javascript">

            function testFunction(element)
            {
                alert(element.id);
            }

        </script>
    </body>
</html>

This inevitably creates grief when trying to debug script code, and also makes it harder to find javascript code when a new developer starts working on your application. On top of all that, maintenance starts becoming an issue.
A better example would be to separate javascript code from your web page:

// javascript file testJavascript.js

    function testFunction(element)
    {
        alert(element.id);
    }

<!-- html file testHtml.html -->
<html>
    <head>
        <title>Test Page</title>
    </head>
    <body>
        <script type="text/javascript" src="include/testJavascript.js"></script>
    </body>
</html>