

If you learned C/C++, then went on another C-style language (i.e. Java or C#), then you are very much like me. Scope in those languages is created by { }. In JS, relying on { } to define your scope is just pointless. Functions create scope. Only functions can create scope and anything outside of a function exists as a part of the global object. Most of the frustration towards JS is probably due to developers misunderstanding it. Sure, the language does have some design flaws, but what language doesn’t? Read More…
Members of this group believe JS is the rightful king of the web (and possibly server). They believe JS is easy and fun to develop with and mature enough to handle anything you throw at it. They praise the language for its impressive developer community and rich ecosystem of libraries.
Members of this group believe JS is a twisted and deceitful language. They are obstinate that JS is a broken language flawed from its conception and mired by designers and the 90s. They see the language and its associated tooling as too “immature” for any real work. Of course, all JS libraries are just the hyena minions sent upon the web (and now server) to ravage and uglify the beautiful landscape that computer scientists have diligently built over the past six decades.
I believe both groups have valid points. JS can be a bit idiosyncratic at times. I have been burned a few times by many of the questionable “features” of the language. For example, double-equals is not equivalent to ==
present in many C-style languages:
if ("" == 0) //this statement is true... console.log("Seriously?!")
If you are like me, you probably learned C or some language based/inspired by it. The reason behind the behavior above is that ==
actually is an equality operand that performs type-coercion first. But there are also some very neat things going on in JS, and perhaps the best attribute is function-passing. There is great power in the ability to pass functions as arguments — just ask any Scala programmer! While functions are fundamental to JS, they are a topic that confuses a lot of developers, so let’s get started. Read More…
For last several years I have focused on the web technologies, starting with server-side technologies but lately client-side single-page style apps. So the h5c3js model is more suitable based my skillset. (Additionally, my knowledge of XAML is limited to WF serialization format.)
This model, which allows HTML-based native Windows 8 apps, is innovative in my opinion and I applaud the folks responsible for the language projection in Windows RT.
Here at AIS, we’ve found Windows Azure Blob Storage to be an inexpensive, fast hosting solution for non-text or server-side loaded resources. But what if we want to use client-side JavaScript to load HTML fragments or JSON data directly from blobs? Under normal circumstances this is prevented by JavaScript’s Same Origin Policy; that is, you can’t load HTML fragments or JSON from another domain, subdomain, port or protocol.
One commonly used solution to this restriction is JSONP, but this is not available with Azure Blob Storage. Another modern option is Cross-Origin Resource Sharing (CORS), but it is also unavailable on Azure Blob Storage and not supported in some legacy browsers.
We could consider a server-side solution, such as employing an Azure Web Role to read text-based content from blob storage and serve it up from the original server. But this approach can be both wasteful and performance inhibiting.
I have been studying and trying to transition to Model-View-Controller (MVC) for about six months and I have come across some fundamental thinking that must be changed and new things that must be learned in order to make the switch. I worked with Web Forms extensively in my previous position, and since joining AIS have made a commitment to myself to embrace the switch. I am still learning, but this is what I have found so far (your results may vary).