Had a bit of a discussion on Twitter with Kevin Darty about TypeScript. It started off with this tweet:

Please RT if you actually know JavaScript and don't need a crutch like CoffeeScript, Dart or TypeScript.

— Kevin Darty (@kdarty) October 12, 2012

I'm still a bit puzzled by all the hate for TypeScript. There seem to be a lot of NaySayers, but I've still yet to see a single example of a codebase that couldn't benefit from TypeScript. Since it's a superset of JS, you don't have to do anything to start using it except rename your .js files to .ts, and then you can add TypeScript only where you think it will add value.

It's like having a magic switch that helps you find errors and refactor. How can it possibly be a bad thing?

I don't buy the "it'll stop people learning proper JavaScript" argument. I don't know a huge amount of Assembly or IL. Sure, there might be situations were knowing more of them would be useful, but is it really worth the time investment when I could instead be improving my C#/other skills that I use every single day?

Does it matter if I can't type javascript without looking it up to hook up subclass prototypes in JavaScript if TypeScript can do it for me? No. Does it help if I understand the generated code? Sure. Is it a requirement? No. All that matters is I understand how it behaves and any limitations of it. The same way I don't need to understand 100% of the IL generated when I write C#.

I'd actually argue that TypeScript will actually improve most peoples ability to write this kind of JavaScript. Think of the workflow... Chances are, you'll store both .ts and .js files in source control (that's how I'd probably do it, so code reviews can see the actual code going to the browser, and we don't have to worry about devs seeing different code to what's being deployed by the CI server). That means when you're viewing your diffs prior to committing, you'll review both your changes and the generated changes from TypeScript. I'd say this will teach you how these things work in JS. You'll become more aware of how sub-classes work, the behaviour of "this" in event handlers, etc.

I'm still generally curious; I'd love to see someone present a codebase that can't benefit from TypeScript and prove me wrong. I genuinely can't think of how anyone could write JavaScript to run in the browser that wouldn't benefit from type-checking (whether it by their own objects, or access to the DOM) in any way. If you're a NaySayer, then take this challenge! :-)

There was also some discussion about Dart following on from +Kevin Darty's tweet, like:

@cdhowie what about how MSFT Devs everywhere ripped Google a new one for Dart but are embracing TypeScript with open arms. Hypocritical?

— Kevin Darty (@kdarty) October 13, 2012

I can't speak for all MS devs, but I thought it worth sharing my opinion... I certainly LOL'd at the Hell World JavaScript created from Dart, but that was kinda funny (moreso with recent talk of Tree Shaking being a huge advantage of Dart). In general, however, I think Dart is a good idea, but possibly this effort could be better spent doing things slightly differently (more on that later).

I think Dart is a very ambitious project. I really hope it catches on and we see support in all browsers. However, I just can't see it happening :O( Dart and TypeScript solve some of the same issues but coming from the exact opposite sides.

TypeScript is designed to be compatible with JavaScript so you can use all of the existing JS libraries out there, and slowly/progressively add TypeScript to your code.

Dart goes further, and also provides a runtime, which brings huge performance benefits (where it can be executed natively). It compiles to JavaScript for compatibility (a necessity to ever gain traction). It tries to do so much more than TypeScript, however the trade-off is that it doesn't integrate with existing JS libraries.

In an ideal world, the decision to use something like TypeScript vs Dart should be based on things like:

1. Whether a Dart runtime is available to the majority of your users
2. Whether you need to interact with a lot of existing JS libraries
3. Whether you need to interact with a lot of your own JS (legacy projects)
4. Whether you can invest the time required to learn Dart (there's a lot less to learn with TypeScript)

However, I can't help but think that the decision is actually going to be based on one thing only:

1. Are you using Visual Studio or an Open Source IDE?

I just can't see TypeScript support ever being as good in non-VS IDEs. Nor can I see Dart support in VS ever being as good as it will elsewhere.

I actually think we could do much better than Dart or TypeScript. Scott Hanselman described JavaScript as the "Assembly Language for the Web". I think this is the first problem to address. We need something that runs in all browsers that addresses the issues with JavaScript, but it should be more like an intermediate language that other languages/tools can compile to (like we currently do with JavaScript, but less shit). That way, the choice of language can be decoupled from the browser support. If you want to write C#, VB.NET, Dart, Java, etc., it shouldn't matter. As long as they can all be compiled to a standard "IL", they should be deployable to a browser.

I don't know whether any of the existing technologies are good candidates for this (could we compile C#/Java/etc. into Dart? NaCl?), but I think it would be the best solution for all. People could use the IDE and languages they feel most comfortable/productive with.

In the meantime, compiling to JavaScript is the only thing we can do for compatibility. But in the background, I wish the standards bodies and browser vendors could get their heads together and agree on a new way of executing code in the browser in a way that they can all offer the experiences they wish to their devs. It doesn't matter whether it's based on something existing or new; the important thing is that it's not tied to the web development language and that the browser vendors and the companies with huge influences in development get behind it. If we can develop desktop apps and server-side code in the language of our choice; why can't we do the same for the browser? This would allow huge amounts of code reuse across our applications that we don't currently get.

Chrome already has NaCl, and will presumably have native Dart support soon. I wouldn't be surprised if IE ended up with native TypeScript support. This is going backwards, not forwards.

I'm a huge fan of the Nexus 7, but one of the things that annoyed me from day one was the lack of landscape support on the homescreen. I almost always use the tablet in landscape mode, so when switching to an app I didn't already have in the open/recent apps list, I would have to hit the Home button; which flipped everything around temporarily. There was already a user-set orientation lock, and we knew Android could handle it (from other devices, and those with rooted devices changing build properties), so it always seemed like a really random restriction.

This was announced as fixed in Android 4.1.2, which began rolling out only a few days ago. As of this evening, my device still showed no update, so after finding some instructions, I decided to load the update myself.

These instructions do *not* require you to root your device or unlock the bootloader. If your device is unlocked/rooted, I have no idea what affect that might have on this process. If you're unsure about this, don't do it. I accept no liability if you mess things up. I have only limited knowledge of Android! The steps seemed fairly straight forward, which is the only reason I was attempting them!

My first problem was that I was unable to boot into recovery mode using the instructions. When I selected Recovery Mode from the boot menu, my device just booted normally. I didn't get the Android with the red exclamation mark. This was easily fixed by using adb (installed as part of the Android SDK) and running:

adb reboot recovery

This rebooted the device to the screen showing an Android with a red exclamation mark, and pressing Power + Up allowed me to select the "Update from ADB" option.

The problem was, once in this mode, Windows failed to recognise the decide/load the drivers that were previously loaded (before the reboot), which meant adb would no longer be able to connect the device:

adb: device not found

After a lot of searching online, I figured out that the problem was that the Hardware ID of my Nexus 7 when in recovery mode was not listed in "android_winusb.inf" file from the Google Android Windows USB Drivers. The ID I saw in device manager against the Nexus was USB\VID_18D1&PID_D001, which didn't turn a lot up in Google!

I decided to try adding this to the inf file manually (C:\Program Files (x86)\Android\android-sdk\extras\google\usb_driver\android_winusb.inf). As I'm running on a 64bit machine, I added the following to the [Google.NTamd64] section (note: this applies to Intel 64 bit machines, not just AMDs!). If you're using 32bit, you'd want to add it to the [Google.NTx86] section:

[Google.NTamd64]

; !-- snip other devices... --!

; Google Nexus 7
; !-- snip existing device IDs --!
; This is the HardwareID shown in Device Manager for the "Nexus"
;  device when in Recovery mode
%CompositeAdbInterface%     = USB_Install, USB\VID_18D1&PID_D001

After making this change, I uninstalled the device drivers, then reinstalled them using this inf file. I once again rebooted into Recovery mode, and this time, Windows correctly displayed the device as "Android ADB Interface", and I was then able to sideload the Android 4.1.2 update (downloaded directly from Google) by typing:

adb sideload 03a4eaf95f73.signed-nakasi-JZO54K-from-JRO03D.03a4eaf9.zip

ADB transmitted the file to the Nexus 7, then the Nexus spat out the progress as it verified the image and updated the device. A reboot later, and my Nexus 7 was running Android 4.1.2!