Windows 8 – Desktop vs Metro
I have had a chance to play with the Windows 8 preview and so far I am impressed. The Metro part is really nice for tablets and is well suited to touch. The question arises though, should one write Metro style applications or desktop style applications ?
Metro applications have many advantages, such as always full screen, multiplatform (x86 and ARM) and some of the unique metro features (ie. contracts). Yet there is a downside to only developing for Metro. Metro development tends to lean towards applications similiar to web apps. It is obvious that web style applications have their limitations though and so will Metro applications. Some of the programming languages which will target Metro are not going to have the full speed of a well written native code application. Personally I can’t see how an HTML5 or Javascript app can have the power and speed of a well written native app.
Even using the dot.net framework (ie. C#) for writing Metro apps doesn’t provide the full power and speed of a native app. There have already been concerns of bloat (slow and resource hungry) with dot.net applications written for Windows 7, so I don’t imagine things will change much with Windows 8. There are just some things that are better suited to a desktop style application. Can you imagine something like Adobe Photoshop being written as a Metro app ?
The other thing which concerns me about Metro apps is when you switch apps, Windows will pause the application (it won’t be running) unless you use special asynchronous coding for background tasks that will always run, which is a fancy way of saying using Threads. My experience with Windows programming has shown me that over use of threading is not always good and can lead to programs. First threads actually slow down a PC, not speed it up. A CPU can only do so much and the more you multitask, the more work it creates for the CPU. Context switching between threads has a degree of overhead which makes more work (not less) for a CPU. The operating system is already doing a lot of multitasking, even if you are not running a single application (lots of services running). There are some applications which really need to be running all the time, but IMO it is better to limit that to a single process, rather than to add threads to a Metro application.
I am also not to happy about the idea of all Metro apps only be installable via the Microsoft App Store (or whatever they will call it). Sure I understand the idea of trying to protect the end user from bad software, but it also takes away a great deal of freedom and control we currently have with Windows. Now if computers are only going to become consumer devices like an iPad, sure it may make sense, but I have done most of my programming for businesses and in the business world this sort of control just may be too much.
The desktop has the benefit of keeping the freedom we are currently use to. I would venture to say that a lot of inhouse software will more likely be written as a desktop app rather than a Metro app. At least to me that makes more sense. I am also not sure about this tremendous shift in how Windows will work. I am glad that the desktop is still there in Windows 8, but it concerns me when I see articles written that keep refering to desktop apps as legacy apps. Legacy means obsolete and soon to be replaced. That would be a big mistake if this were true. One of the reasons Windows has been so successful has been its backward compatibility to previous versions. To throw all of that away would be a big mistake.
My last point about Desktop applications is native coding. It took me years to learn a good bit about the Windows API and combining that knowledge with a quality native code compilers like PowerBasic, I can see how native coding can produce very powerful, fast apps with an amazingly small footprint. When you compare a dot.net app to a native code app (or even one created using my own EZGUI runtimes), there is no comparison. I can still write apps which can fit on a floppy disk. Sure that may not mean much anymore, but with tablet PC’s being the next big fad, one can see how being able to write software which uses minimal drive space, minimal ram and which can push a CPU to the max can make a big difference. Just look at the current generation of tablets. SSD (solid state drives) are almost mandatory for such devices, but because of expense you see tablets being shipped with just 16, 32 or 64 gig of drive space. By todays standards that is not a lot, compared to hard drives. So a well written native app which has a small footprint (both disk space and memory) is critical for the current generation of mobile Windows devices. Sure some Metro style apps may also have a small footprint, but it is at the expense of the full speed and power of the CPU like a native app can have.
It will be interesting to see how many software companies make the decision of whether to port their software to Metro or not. Some may do so and later find the desktop was better for their particular app. Only time will tell, but developers now have to make some hard choices about the future of their software. I for one, plan to stick with development for the desktop. Sure I may experiment a little with Metro, but right now I don’t like the idea of being limited to using a Microsoft programming language to do so. Metro is new, so the only real alternative will be to use Microsoft tools. It will take awhile for third parties to offer other choices. I have been turned off to the direction Microsoft languages have gone in recent years. Visual Studio just confuses me, compared to writing native apps using PowerBasic. Now HTML5 though does interest me, particularly because HTML is a well known language (for the web) and HTML5 is just an extension of it. Yet native coding IMO still has many advantages over Metro.
For now, I am just watching the tech world to see what works well and what does not. Metro is too new to make any long term decisions yet. Who knows, maybe I will do more with Metro as time goes on. I just dislike having to keep relearning programming every few years. Moving from DOS to Windows was a challenge. Moving from Visual Basic to PowerBasic and native coding using the Windows API (Win32) was a challenge. And now Metro! Fortunately for me, I think I made one good choice in all of this. I made the decision to stick with a language I know better than any other, BASIC. I moved from QuickBasic (and PDS 7.1) to Visual basic 1.0, because it still had the core features of the language I knew. Later versions of Visual Basic though deviated from the heritage of Basic for new grounds such as OOP and dot.net. Thats when I left Visual Basic behind and moved to PowerBasic. True I did have to take time to learn the Windows API, but once I got the fundimentals of the Windows API down I once again became productive and could take advantage of all my years of experience with the Basic language. I appreciate new technology, but in programming it makes sense to be able to still use what one has learned in the past.