Thoughts from the Wet Coast
The musings of an ASP.NET Developer from Canada's We(s)t Coast

Closures are an important concept in JavaScript and give raise to some of the real power of the language. Later in this series I will discuss JavaScript module patterns – all of which rely on closures. In order to understand closures lets look at a specific example function.

In C type languages, such as C, C++, Java and C#, whether the curly brace starts on the same line or on a new line is basically a matter of convention.

However in JavaScript it does make a difference due to a feature of JavaScript called the “implicit semicolon”, If a statement doesn’t end in a semicolon then JavaScript interpreters will add one.

As C# developers we think we know what variable scope is all about.  But if I showed you the JavaScript code below, what number would you think would be shown in the alert dialog.

Its been a while since I blogged in my series on JavaScript for C# developers, but I have got a few topics lined up.

JavaScript is actually quite a simple language.  It is described as a loosely typed language, which means that unlike C# it doesn’t enforce a strict “typing” model. 

In fact, in JavaScript, aside from a few primitive value types, everything is an object.  Ok, some of you C# developers are saying – that’s true of C#, everything in C# is considered an object.  The difference is that whereas in C# everything is an instance of a class which "derives” from the Object class, everything in JavaScript actually is an object.

I am a Web Developer – and so you would think that I use JavaScript as a routine part of my job. 

However, until recently I have been mainly involved writing “server-side” Visual Basic or C# code in the ASP.NET Web Forms model.  In that model, when a user clicks a button (or hyperlink) on a web page or makes a selection in a drop-down control this invariably results in a post back to the server which responds to the client-side action, and then completely refreshes the page.

In the previous paragraph I wrote “until recently”, and that is because for the 2 or 3 years, JavaScript has become a significant part of my job.

One of Reacts strengths is that it is NOT an MVC or MVVM framework.  These frameworks can get quite slow when there are a lot of complex updates being made to the underlying models.  The frameworks are continuously monitoring for changes and one change to one component can lead to hundreds or thousands of changes to other objects, and the frameworks are continuously updating the DOM to visualize the changes.

In my previous blog I introduced React – a new(ish) JavaScript library for building “Web Components”.  In this post I will start to dive deeper by building our first React Web Components.

Browser based JavaScript code is all about manipulating the browser’s DOM. 

Up until a few years ago, at DNN Corp we had primarily been using jQuery to do that manipulation.  Don’t get me wrong jQuery is an awesome framework, but jQuery directly manipulates the DOM  -  there is no concept of working with models/objects in jQuery – i.e. separating your presentation aspects from your other logic.

Its been a while since I posted a blog in my Knockout series.  In the last couple of posts in this series we reviewed how Knockout implements the concept of Observable Arrays.  Observable Arrays support the idea of detecting when objects are added and removed from the array.  For a complete solution though we actually will want the array to contain observable objects so we can also detect when changes are made to each item.