Will Microsoft devices sit happily on a single platform? The world can be a confusing place. Often a one-size-fits-all solution looks to be just the thing but ultimately it turns out that it fits no one. Microsoft is touting a single development environment for desktops, laptops, tablets, phablets, mobiles and the Xbox. Can this deliver? The platform for PC, phone and tablet comes …
A user interface designed for a 24" monitor with keyboard and mouse will not work on a 4" touchscreen phone. Similarly an interface designed for that phone will look like shite on a 24" monitor. You see that on a tablet when running apps that were only designed for phones.
So one code base fits all will not work. At the very least you need a UI for each device type.
It's really not that hard to build a UI that adapts to different form factors. See Responsive Web Design for details.
We are talking about one development environment with one set of core APIs covering all devices - with the device specific stuff on top of that, for device specific I/O for example.
That means that the core functionality will work across all devices. You can still conditionally compile in different UI elements and I/O devices to different platforms, but it means a majority of your code should work across all platforms with little or no modification.
That means, for example, if you are designing the next Evernote, you write your sync and data format libraries once and just have to look at getting the UI on each platform optimised, without having to re-write the bulk of your code for each platform.
That makes maintenance easier, it makes extending the functionality easier.
Much like apple was able to deliver a singular development environment build around good old Object C for both iOS and Mac OSX, I never really saw why MS couldn't have done the same with C#/.Net, which IMO is a pretty solid stack. Instead, they decided to also push Javascript/HTML5 for mobile development, which just confuses developers. Hell, even Apple was smart enough to abandon the JS/HTML5 app approach early on, and Google, the 800 lb web gorilla, never bordered. Why? I suspect their very smart engineers realized that mobile apps are closer to desktop apps than web-pages-apps. Hence, basing your mobile dev environment/APIs on desktop model will gain you more devs than JS/HTML approach, even though there are a lot more web devs out there in theory. To put it another way, someone who knows HTML/JQuery is going to have a hard time understanding a mobile dev stack. On the other hand, someone who knows Java/Swing or Object-C/Cocoa can get going on mobile app development with relative ease. It's just a matter of seeing what APIs to call and SDK to use. For example, this week I decided to get my feet wet with iOS development, coming from an Java/Swing world, it only took me a few days to understand how things work in iOS. I just need to understand Object-C Syntax and the APIs since the whole concept of client side MVC is known to me already.
There is also the issue that the JSHTML5 approach for mobile has failed to make any real inroads and has left many such mobile platforms (WebOS, Blackberry OS10, FireFox OS) dead, or dying by the wayside. Yet MS feels the solution to their stagnant mobile platform is down this road. The even invented a "new" language (TypeScript) to take this task on. Why they simple didn't do something like GWT, but with C# instead, one wonders? That at least would make more sense.
"apple was able to deliver a singular development environment build around good old Object C for both iOS and Mac OSX,"
ObjectiveC is common language, but the iOS and OSX APIs are not. They're similar in design, but the features are different for each API library. Higher up the stack, CocoaTouch and Cocoa are two related UI frameworks, but they're "compatible" only at the conceptual level.
I think you've misunderstood what Microsoft's HTML+CSS+JavaScript solution actually is. It's not a web browser: it's a way of specifying the application's UI using markup that it is already familiar to designers (with the addition of the full set of CSS object layout properties that application UIs need). The application underneath can be native code (doesn't have to be if the app is "shallow" enough to be realisable in JavaScript, but if access to deeper system functions is required, you can write native components, and expose them to the UI). It's very like QML in Qt, although unlike Qt it uses an existing, widely-known markup language (HTML) to define the UI rather than invent its own. (Personally, I prefer QML, but that's largely my background as a developer, not a web designer)
Previous "web apps" systems did suck, because a. the browser script engines weren't good enough (and even now, Apple still holds back the performance of encapsulated HTML apps on iOS), and b. the browsers didn't (and don't) support the CSS3 and CSS4 object layout properties needed to produce user interfaces (e.g., dividing a div into equal sections, aligning items vertically, anchoring one object to another, etc... all trivial in Swing/QML/XAML/Cocoa but impossible on the current browser population.)
when Ubuntu does.
Once the final nails have fallen in the MS unique offering - namely Exchange & Outlook the fall will be swift.
The other nails rusted away or were sheared off by MS themselves - namely the desktop (Windows 8), Office (Cloud? No thanks), SQL Server (too expensive), File & Print (became irrelevant years ago), Development (An unholy mess).
This is a damned fine idea. It's almost as if it was conceived by actual developers and not business people... No, wait... it makes good business sense too... Wow.
On the other hand, now we can have the same bsod on our laptop, smartphone, watch, microwave, car, TV...
Maybe it is important not to confunkt up too much?
Sure devices might it might not talk together, might or might not do (or appear to do) similar things in similar ways B-U-T what they should do across a myriad of devices with a myriad of operating systems and operating system variants is: respect my data with 100% reliance and similar compatibilities?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
