by ondrejsv
15. September 2011 22:34
With the hype of Windows 8 HTML5/JS apps I’m again and again rediscovering some of the pitfalls of the JavaScript language which bring issues we never have with strongly-typed languages like C#.
The first scenario is going to be quite common not only when using the new promise/then feature. (Snippet is taken from one the tutorials on the MSDN.) Look at the processPosts function that gets called when the xhr promise gets asynchronously fulfilled. There is no way the IDE would know the type (more precisely available methods and fields) of the argument and thus providing IntelliSense because the function could be called from everywhere:
If we write the code to run when the promise is fulfilled as an anonymous function and Visual Studio would be way smarter, it could theoretically provide IntelliSense on the result argument by parsing and processing the xhr promise but it does not so:
The second pitfall comes from the fact that any code could be run in a context of any HTML file. When you reference a .js file from an HTML page, some of the global variables get alive by getting references of the screen elements with variables of the same id. If you make a typo in the name of a variable, you would not find it out until you run the page. Of course, there is no IntelliSense either because the variable could be of any dynamic type at run-time. This pitfall is really a feature of all dynamic languages but for a programmer used to program user interfaces in ASP.NET and Silverlight which have concepts of code-behind coded in strongly-typed C# it represents a loss in efficiency, indeed.
by ondrejsv
15. September 2011 20:20
This is an unstructured list of interesting things I found when playing with the new metro applications.
While HTML5/JS metro applications always run in a host process WWAHost.exe (Windows Web Application Host?), .NET apps does not, they run directly in its own process:
When deployed locally from the Visual Studio, applications (both HTML5/JS and .NET) are stored within the folder AppxLayouts in the user folder. It is interesting that XAML and content files are not embedded as resources in the executable but they are left alone:
As the WinRT is native, every external event such as Click comes from the blackbox:
If we look at modules currently loaded when a managed application is running:
we’ll find some interesting things:
- despite the fact that in a Metro app you may use only a subset of the full .NET, it looks like some of the full .NET modules are loaded (mscorlib.dll, System.Runtime.dll, System.Linq.dll, System.Core.dll, System.dll, System.Xml.dll and others), so a managed application obviously does not only forward calls to the native WinRT,
- of course, a number of WinRT modules are loaded (with .winmd extensions)
.NET 4.5 assembly references are evident if we look at the application from the Reflector:
437efbd2-5097-4e9a-8abd-8dd0c1a5242f|0|.0
Tags: windows8
by ondrejsv
14. September 2011 23:13
3dc82791-a372-4340-86c1-0402e62864bf|0|.0
Tags: windows8