I don't know. From that demo, I really doubt that the tiled interface will ever provide enough functionality for these apps to be really useful or as full-featured as their real desktop counterparts.
I see this tile-thingy more as an additional overview-shell, but the real work will remain to be done in the classic apps. This is more comparable to the Mac Dashboard widgets than to a complete UI redesign.
As such, I see no problem in doing these widgets in HTML/JS which is what we have used ever since. The "real" applications will still be done in whatever technology is available under windows.
Of course, everything is just speculation. I just know that I'm sure as hell never going to use a touch interface on my desktop PC nor drag around tiles with the mouse trying to fake enough inertia to get the scrolling to go.
I think you are onto something here. I think the tiled interface will be very similar to the Windows Media Center shell. It's a specialized interface for touch, just like WMC is a specialized interface for couch surfing.
In the end it's not going to be very useful for end users unless Microsoft really bites the bullet and forces developers to migrate to the tiled interface, en mass. Apple did that with iOS, basically forcing developers to create entirely new apps, because the input method of touch was so drastically different that apps requiring mouse-level precision would never work. Microsoft will never do that, so instead they need to fragment their OS into two interfaces, touch and classic.
I fear a Windows 8 tablet will be the worst of both worlds. It will need enough horsepower to run "classic mode" with all of the baggage that brings, yet most tablet users are just doing simple media consumption so they can stay in tiled mode most of the time. In the end you bring a product to market that costs $1500, has a quad core CPU and 4GB of RAM, and gets 4 hours of battery life - not to mention it weighs 3 pounds. Basically you end up with the current crop of Windows tablets. A stylus will probably be included just to make classic mode usable.
I'm not saying there isn't a market for a powerful tablet that can run Windows 8 in classic mode, but those tablets have been around for years and they haven't gotten mass market traction for a reason.
Actually MS directly addressed the horsepower aspect. Remember they're going to have this running on ARM. I've used Win7 for consumption scenarios on a $250 netbook - worked like a champ.
> It will need enough horsepower to run "classic mode" with all of the baggage that brings.
Microsoft managed to squeeze Windows 7 (albeit crippled) onto netbooks; I'm hoping they'd see the use case you're describing and make Windows 8 tablet-friendly (which at least now looks touch-friendly).
(Microsoft demoed Windows 7 on ARM, and AFAIK ARM chips aren't that powerful―there's hope yet.)
At least in Windows-land, I really don't see the point in a touch OS. I've played with Lenovo X-series tablets, and I love the older ones (Wacom-based) and can't stand the touch ones.
But I love being able to run Photoshop and draw in my lap, so I'm kinda biased.
The argument that "xyz on the web is a toy and will never be fast enough / xyz in html,css,javascript will never provide enough functionality to be really useful or as full-featured as their 'real' desktop counterparts" is an argument that has been consistently wrong, or at least become wrong over time in every case. Why should the next few years be any different?
Agree 100%, but also would like to add that the only reason we can't develop things faster, better, and more performant is that so many companies have been focused on making their own tools faster and more performant. If Microsoft can design something as cool as F#, they can make a responsive HTML + JS rendering engine. They just haven't put their money there.
^^^ pretty much. Full featured applications are and have been being built with what is basically 10 year old web technology.
Simultaneously, users are coming to the realization that full featured isn't what they need. Thanks to the drastically lower cost of distributing software over the web, instead of monolithic, multi-purpose software from giant companies, small shops are building single-purpose applications that target niche markets. User experience is better, and costs are lower. Consumers and the economy as a whole wins.
If I had built my career on client-based Windows development, I'd be getting out of that burning building as fast as possible.
Java was supposed to take over everything, scripting languages were supposed to take over everything, etc. C/C++ are still the primary languages for native application development.
I think the comparison to the Mac Dashboard is a very good one. With the introduction of SideShow in Vista, Microsoft showed an interest in simple at-a-glance apps, and it seems like they want to push that interaction model for 'tablet mode', while still leaving everything in place for 'desktop mode'.
I agree. For most existing users, especially power users, this will probably be as insignificant on the desktop as Active Desktop and Active Channel were in Windows 98 or maybe desktop gadgets in Windows Vista. I mean, who even remembers that stuff?
For some users like my dad, the tiled interface with a touch screen should make it easier to use the computer. He doesn't use them enough to learn the whole stacks of windows metaphor and all the operations involved with it, but he can pick up an iPad and use it just fine.
The real significance I see here is that Windows mobile developers with just the skills of a web developer can now target desktop and tablet users fairly easily with the same exact code and a similar UI. If Microsoft releases their own App store for Windows 8, then that provides a unified platform for developers to sell the same product to every kind of Windows user from kids with smartphones to grandparents with a desktop PC.
And if the tiled interface takes off with the not so computer-literate, there'll be a great new demand for applications that fit into it's metaphors to prevent the jarring experience of being thrust back into a classic Windows-like environment, kind of like the demand for GUI applications after Windows supplanted MS-DOS.
The tile interface is definitely a shell, right now. It's a stepping stone for Microsoft to step into a post-desktop world.
I've read a lot of commentary that is very impressed with the tiles and just as much commentary writing it off as something that's not enough and not appropriate for Microsoft to make a step and just put a new pretty face on Windows.
To me, I see it as a thought out stepping stone to reaching the post-desktop era that reaches a pretty good compromise. I don't think many people have to be worried about this new transition, but that's my own speculation - you'd have to wait for MS's official word.
Mac Dashboard widgets are the equivalent to Gadgets on Windows. And Windows gadgets are already made with html and js. I don't see why anyone was surprised to see Microsoft continue with this tradition. And I don't know how anyone who has a programming background can think that HTML5 will replace the incredibly large and rich .NET ecosystem. But it makes good sensationalistic news so everyone is freaking out about it.
1. I am not comparing .NET to the web. That comparison is impossible. The web is an abstract entity that .NET is part of and .NET is a software framework.
2. I am comparing .NET to HTML5 and JavaScript.
3. The capabilities of.NET are far greater by an absurd margin than the capabilities of HTML5 and JavaScript for Windows application development.
If IE10 supports hardware acceleration, CSS timelines, and a strong JS engine there is no reason why this couldn't work. JS owes some of its process problems to lower priority in the typical OS. What if JS had higher priority and it's own dedicated thread of CPU?
.NET developers shouldn't fear the future. They should be happy that, for once, their ecosystem may see a growth that actually works for them.
But what would that CSS end up looking like? There will be a lot of proprietary extensions (at least their should be) and a lot of quixotic classes and element id's that you'd probably have to work around. I envision something like Office's awful "open" format - the same people are driving this bus.
I've done the MS HTML/JS client route for a long time - I've set up a lot of gadgets, and InfoPath(!) has an HTML/XML/JS programming model. Truth be told this model is actually really painful to work with if all you have is HTML/JS. Keep in mind that the "web" isn't just HTML. It's Perl, Rails, Json, JS, Google, Wikipedia, RSS, etc.
Now, if these tiles are something akin to mini-web browsers, where you can use the full power of the web & web technologies (is this what they are actually saying?), that is a different story.
The difference though is if the intent is for the markup to be styled, it will be written differently.
For example, take a look at the WPF built-in controls. Those are written in very clean XAML. Easy to read, style, and modify. I'm sure they could have made it difficult, but their intent was that you'd modify the built-in controls.
If they want to do this with the UI, they could do it. The theming you could do with this could be incredible.
I doubt this is something they're going to do for V1 (if ever), but I can dream.
I just know that I'm sure as hell never going to use a touch interface on my desktop PC
Looking into the future, a dual use tablet like the Asus tablet with a keyboard portends a new reality that execs don't like lugging laptops to meetings. Have you tried to balance an open laptop, a mouse, power supply on top of folders? There's no hand left for that cup of coffee.
> I see this tile-thingy more as an additional overview-shell, but the real work will remain to be done in the classic apps. This is more comparable to the Mac Dashboard widgets than to a complete UI redesign.
Microsoft hasn't been portraying the new shell that way. It seems to be where the first-class Windows 8 applications will reside, with the icky old legacy applications relegated to the classic desktop.
Microsoft's biggest problem is how fractured this new consumer-centric approach is inevitably going to feel for everyone, though devs are probably going to be hit the most, and that spells trouble.
The problem is that Windows has a slew of legacy API's, languages, and frameworks that you can't get rid of without undermining the existing application ecosystem that made it popular. And it seems like they're not willing to get rid of any of that for the new world of web/mobile apps, like Apple did with flying colors. Instead they're shoehorning yet another framework onto an already bloated platform.
So in the end they're trying to apply a lesson from Apple (touch, interactivity) with total disregard for why it worked (simplicity, seamlessness, usability). A recipe for failure if I ever saw one. Ballmer still doesn't get why iPhone won the mobile wars.
> "And it seems like they're not willing to get rid of any of that for the new world of web/mobile apps"
They did it pretty handily with WP7 development.
And Win8-on-ARM obviates the legacy issue anyway. There's going to be a clean-slate development approach put forth as the recommended way to develop for 8. There's no way around that.
It'll almost certainly look a lot like current Windows development (likely just a new iteration of Silverlight and .Net). And just as certainly, legacy apps will stick around in a sort of "XP Mode" for x86 Win8, but they're going to be phased out.
If MS isn't talking yet, it's probably just because they have a new slew of buzzwords and marketing to finish drafting before they introduce it.
But, a good part of the point of .Net was that the managed code was in MSIL and being compiled to X86 down the line rather than by the developer, so the argument that ARM support requires a move from .Net really doesn't hold water.
I'm hoping there's more to this than meets the eye, but... Here's a test case for you. VB6 apps are supposed to be going out of support relatively soon, but there's a lot of them still out in the wild. The understanding had been to redevelop them in .Net, but based on this exactly what should the authors commit their investment to? Frankly if this doesn't get cleared up soon, for me the answer would be 'anything but Microsoft's stack' - it's just too unpredictable.
> "the argument that ARM support requires a move from .Net really doesn't hold water."
I would draw a thick, dark line between managed .Net and "legacy". When people talk about legacy Windows code, they're talking about those massive enterprise apps running front ends written in VB6/MFC-era code. Those are the ones that Microsoft has to push to the curb in Win8 [1].
That said, any number of .Net tricks to enable legacy behaviors will likely pose roadblocks for particular apps. So some .Net incompatibility will be at issue as well.
> "but based on this exactly what should the authors commit their investment to"
I'd imagine the question Microsoft is grappling with, is which versions and parts of .Net they can reasonably support. Though I'd be surprised if anything they recommended in the last five or so years that wasn't supported.
That said, anyone designing an enterprise replacement in the last five years, who did so as anything other than a web app is likely out of their gourd [2].
[1] i.e. live on in an XP-mode style ghetto only on Win8x86
[2] Sure, some of have some steep client requirements that rule out web apps. But that's a tiny minority amongst enterprise apps. The overwhelming majority are workflow/database interfaces.
Frankly if this doesn't get cleared up soon, for me the answer would be 'anything but Microsoft's stack' - it's just too unpredictable.
Don't get carried away. MS has been very clear that you can run any Windows app here. If you're porting over old VB6 apps it seems clear that porting to VB.NET makes the most sense. .NET development isn't going away as at the very least MS's web server-side story is still all .NET.
Yeah, that's what is confusing to me about any .NET developer employment angst. ASP.NET and other business infrastructure technology seem unaffected by desktop software innovation. I have to believe that desktop software is a small piece of all .NET development and innovation in this area shouldn't threaten the platform.
The iPhone hardly won the mobile wars with Android gaining that much market share (and even in some measurements, exceeding it) - it is a little like saying that the British have won the war of independence because they have the rebels holed up in a fort.
In my world Apple is the leader because they have the best business. If you only look at market share then nokia should have been the winner for a long time.
*We put up with Windows so we can use C#,
F# and VS2010*
It's not like you won't be able to use .NET - they are just adding IE9 into the equation, so I don't understand what this "fret" is about.
This is what happens when developers believe blindly in promises, instead of focusing on getting the job done with minimal friction.
Of course Microsoft was going to let go of the .NET "vision" at some point, as .NET is not applicable to everything. If you believed that by learning .NET you are going to have a unified platform to be able to use it for everything, that's your problem.
It's like believing .NET's CLR is a general-purpose VM. Well, it ain't. Yes it provides some flexibility, but you'll never have Haskell on it. Or a reasonable LUA implementation for that matter.
And in my view, basing this new UI on IE9 and Javascript/HTML is a move in the right direction for Microsoft, one of the few I've seen in years - I mean, why reinvent the wheel instead of leveraging the knowledge of lots of outside developers? Last time I checked, even Adobe AIR had better penetration than Silverlight (total, not counting the number of out-of-browser Silverlight apps or people that use such apps).
> This is what happens when developers believe blindly in promises,
Actually, this is what happens when you rely on software someone else controls. I once worked in a company that (after I left) made a huge investment in WebClasses, as they "were the future" of web development on Microsoft platforms. "The Future", as often happens, didn't last long.
Microsoft hasn't clearly ditched neither .NET (and .NET permeates most of Microsoft's server business) nor Silverlight and the "classic" view will still be there for when it makes sense (and it really does in a lot of scenarios). I suspect, however, "modern" apps will prefer to use the cleaner tile interface. If things like Gmail and Google Docs taught us something, is that simple interfaces are a good idea. With the onslaught of fresh desktop GUI ideas like Apple's full-screen apps, Gnome's new shell, and Canonical's Unity, Microsoft had to show something.
And that's what damns them. When a competitor, any competitor, shows something, they make themselves show something like it. Frankly, this whole tile thing has "PDC 2003" written all over it.
this is what happens when you rely on software
someone else controls
True, but you invariably depend on somebody else to write the software you want.
For the web, you depend on the industry to evolve towards your specific needs. Client-side, you depend on whichever company controls the operating-system of the devices you're trying to target.
I wanted to mention open-source platforms when writing that comment, but in this specific context it isn't really useful, since that's not what .NET developers seek. They want Windows, Visual Studio, commercial support and a unified platform for the web, client and mobile (the promise of .NET), which is insane as there can be no such thing.
> True, but you invariably depend on somebody else to write the software you want.
Not really. When Zope Corporation ceased to develop Zope 2 in favor of Zope 3, the Plone community and others continued development of the 2 series. It currently has a lot of features migrated from the 3 series, a lot of new features of its own, but remains compatible with the Plone CMS that runs on its top.
If, for whatever implausible reason, Oracle decides to ditch MySQL, its users already have a bunch of forks in place, perfectly functional. If, however, Oracle decides to discontinue their RDBMS, its users are royally screwed.
> and a unified platform for the web, client and mobile (the promise of .NET), which is insane as there can be no such thing.
Despite my dislike for Java (the language), I have to recognize it spans a very vast space, from dumbphones (J2ME) to fairly clever ones (CLDC, CDC) to very smart ones (Android) to desktops (Eclipse, NetBeans, several standalone development tools I use) to large distributed server solutions (Cassandra, Mule, Hadoop). And the JVM is sweet. I'd love to find a decent excuse to do something in Clojure on it.
My perception is that they are worried that their existing knowledge (in .NET or any other MS dev tech) will not allow them to create applications for this new touch interface. Instead, they will be forced to use a new technology if they want to create an app for the new Windows 8 interface.
You're partially right. But I'd draw your attention to this part of the article...
"Underlying the discussion is that developers have clients, and clients want applications that run on a platform with a future. Currently, Microsoft is promoting HTML and JavaScript as the future for Windows applications, putting every client-side .NET developer at a disadvantage in those pitches."
Remember most MS developers work in corporate environments. Either in companies or as consultants. No one wants to spend money to build a "legacy" app. So when Microsoft says HTML5 apps are the future but doesn't lay out how their APIs are going to work it freezes many .NET developers in their tracks. Because now Silverlight and WPF are legacy but you don't know how to pitch these new Windows 8 apps to a client because Microsoft hasn't specified how they'll work.
Most of the time, the criticism comes before the first contact with the technology being criticized. For instance, most of the people who criticize Smalltalk's "alien" syntax never finished a single tutorial.
I think that does often happen the way you described, but not in this case.
First, to be a dev using the MSFT stack, as I'm sure you know, you learn a new technology every week -- so they're not against learning new things :-)
But more importantly, most of them complaining have used HTML/JS, and many use it regularly for the web side of the house. It's not an obscure language/Fx that people haven't touched before. They maybe haven't written Angry Bird with it (which BTW, their JS looks like it was machine generated -- anyone know how it was done?), but most know the technology decent enough to comment about it.
Using HTML/JS in Internet Explorer is very different from developing on a platform where HTML/JS application development is fully supported. I have been playing for some time with WebOS development and I am quite happy with it.
Anyway, I seriously doubt .NET will be deprecated anytime soon.
Using HTML/JS in Internet Explorer is very different from developing on a platform where HTML/JS application development is fully supported. I have been playing for some time with WebOS development and I am quite happy with it.
This is probably true. But the tooling still leaves a bit to be desired.
I was really excited about WebOS when it first came out, but they just took too long to get the SDK out. I eventually just moved on and haven't gone back. Although I do think the new stuff they're doing looks quite nice.
Are you confusing an SDK with an IDE? IIRC, the Palm launched an SDK early on, with a full device emulator. I don't see why an IDE is a basic requirement. I've been on and off IDEs for the past 2000 and, quite frankly, I am perfectly happy with Emacs.
If you were approved you got access, but most didn't. I think jwz ranted about this too. There were all these devs who wanted to write for it, but weren't given access. Eventually I gave the phone back.
General rule, your SDK needs to be done a month before product launch -- unless you're Apple.
otoh, since the new app platform is based on IE10, it will have the new CSS3 grid module which seriously solves about half of the day-to-day problems I have with web front-end development.
It's not like you won't be able to use .NET - they are just adding IE9 into the equation
Exactly. I write a lot of .net code for work and haven't written a UI in anything other than HTML/JS in a long time. Too many people seem to be reading HTML/JS and thinking entire apps will now have to be written in them, and I just don't that's true.
As a .NET developer, I'm not in any way worried that they're going to replace the .NET framework as their primary enterprise platform, with javascript.
For this tile UI, I'm a little surprised - if only because it's quite different from how WinPhone7 works (isn't it?).
I would have preferred if they had somehow integrated/replaced the system tray functionality with that of the tiling interface... as my understanding the tiles can mimic most of this functionality, if not do a little more.
I dare say most the concern I'm seeing about this so far is that they've simply not gone far enough... Unless the tiling interface is the primary mode of use, then most people simply won't use it and it'll be relegated to the list of features the OS has, that simply no one uses. Think "Windows SideShow".
Of course, this all depends on what MS are planning on doing - and I think they've made yet another PR misstep (even if it's only to developers) in that they've simply not released enough information. I can't decide if they're teasing deliberately in an attempt to drum up interest (working, but I would argue that it's more worry than interest to their target demographic) or whether they actually don't have much more than this demo and that they don't know what their long term plans are (even more worrying?)
I dare say most the concern I'm seeing about this so far is that they've simply not gone far enough... Unless the tiling interface is the primary mode of use, then most people simply won't use it and it'll be relegated to the list of features the OS has, that simply no one uses.
I think their intent is that this new UI is the Windows UI. I think they're going to push devs to use this new UI for all apps unless they need to go to the old UI. Recall that native apps will not be cross platform, so there's motivation for devs to target this new UI to run on x86 and all the ARM variants.
I agree. I'd like to know what can't be done in HTML that can be done in WPF. WPF is a lot nicer, but HTML is usable. JS, feels like a huge departure from C#. I think ppl use the .NET stack because they like things like static typing, generics, the BCL, etc... Even something like a halfway decent editor for JS seems to be missing.
A number of things can't be done in HTML that can be done in WPF.
Since WPF has a sane architecture, you have access to a huge set of high quality UI components (grids, editors, etc) that can simply be dropped into your applications. 15 years on and web developers still don't have this. The components that they do have don't follow a common object model or anything like what WPF has, so they're much harder to work with. So that is one very important quality that you simply can't have in HTML.
I'm not HTML expert, but I've seen things like Wijmo and controls from Telerik that allow you to drop in jQuery UI elements just like WPF controls. They have things like grids, charts, calendars, etc...
WPF does have lookless controls and triggers, but I'm not sure I'd make a dev platform choice based on that.
Wijmo/Telerik and others bring the web platform _slightly_ closer to the level of quality and ease of use that can be had in a desktop platform, but let's be honest...browsers really don't know the difference between a bunch of text and a bunch of advanced controls (e.g. Grids, Menus, Dialogs, etc.) and it shows, particularly in the areas of focus and selection.
Also, keyboard acceleration is severely lacking in every HTML advanced component set that I've ever seen. The whole scene is just dismal compared to what can be had with a decent desktop kit IMO. I am thinking it will be another 5 years before the web really catches up, but that doesn't help me much because I'm lazy _right now_ (EDIT: meaning, I don't want to have to work that hard for all those little niceties, but I still want them).
You can't get the raw power that you get from WPF and BAML. You can't tap into the GPU for free and multi-thread client side at ease. I agree web platforms are the future. It's distant though.
It is. While Im not really worried that .NET will be replaced by HTML 5, I really wonder why the windows team wouldnt want to try and merge the development models for WP7 and windows 8. If they really want this platform to run on tablets, why would you not want to leverage WP7 code a'la iOS???? I think that it is great if the HTML/JavaScript model is an additional way to draw in developers to the windows platform, but the fragmentation is not a good plan IMHO.
My guess is they had to release WP7 when they did, and IE9 was not ready to ship on it, so the Silverlight was a stopgap. I think the HTML5 people have won the arguments in much of Microsoft, and Silverlight will be deprecated gradually on WP.
"My (and your) 10k, 100k, 200k line C# applications are not writable in JS."
I don't know that this will be true for very much longer, if it's not already been disproven. Javascript isn't the greatest language out there but it's gain functionality that is removing the limitations that uses to plague it compared to other languages. Slow VM is not longer true, no multithreading is not longer true. Webworkes are a little odd for sure, but they still make it possible to build multithreaded applications. WebGL/Canvas allow for some very advanced graphical applications. You can now access local storage, a database (and in node, other databases), new ArrayBuffers and such. It's a different environment now.
I can't point to any (GMail client side code must be pretty big), but I do have a 5K one that I work on daily and it's not a mess. This project is still very much in development and will grow with time.
It's not 50k and it's for sure not a project with 20 devs but even this size was unthinkable earlier.
I'm working on a backend in node to take advantage of Websockets.
I can't show you one either. But I can tell you that JavaScript, done right (which is a big caveat), is a great language. People think it's a toy because of its history (and a good number of embarrassing mistakes in its design), but it's very expressive. It has borrowed many of its core concepts from Scheme.
I think he's talking about the maintainability of such an app in the hands of your average joe programmer, not the sophistication of the language. Also, static typing does have it's advantages, particularly in that it's easier to write tools for developing and debugging those languages.
It's not just Gmail and Node. It's Live Mail and Yahoo Mail and dozens of other Web mail apps that now dwarf desktop mail systems -- at least with consumers.
It's Microsoft's Office Web. It's Google Docs. It's Zoho Apps. Yeah, there are hundreds of millions of users there already.
It's YouTube and Facebook and Twitter.
These are applications with logic and complicated functionality and they're built with HTML and JS and they have hundreds of millions of users, each one of them.
If you think that the Web is "niche" you're in for a rude awakening over the next few years.
"My (and your) 10k, 100k, 200k line C# applications are not writable in JS."
Actually, they are, and quite well. But not by the developers that Microsoft targets. Those developers need a lot of hand-holding to get used to async programming, prototypal inheritance, closures for encapsulation, etc.
So actually, I'm agreeing with you -- there's no way that's where Microsoft is heading. They'd be more like to drop all their programming languages and tell everyone to switch to Lisp.
As a .NET dev, I'm not worried, MS has invested really heavily into .NET, it's everywhere in their eco-system now. Even if the preferred way to build some desktop apps was HTML/JS, .NET is still going to be in use in many other places.
Even if they did ditch .NET (which I don't think they will), it would take years to do; plenty of time to move to something else ;)
Keep in mind those HTML/JS apps will probably have hooks into .NET libraries installed on the system. And I bet that HTML will still be compatible with ActiveX.
The problem with WPF/Silverlight is that Microsoft never managed to make it feel fast enough to compete with native code. The Windows Phone 7 UI is praised because of its excellent performance. Now imagine that Microsoft would have used WPF instead. Because of the Silverlight requirement it's impossible for third party app developers to reach same level of performance as build-in services.
I would like to see a new UI framework that everyone inside Microsoft feels is good enough to use. And give third parties equal access.
You can AFAIK in WPF (not SL which is a smaller lib subset). You can render it to a GDI Image and then convert that using CreateBitmapSourceFromHBitmap. It sucks though.
It's understandable - I have a similar setup (i7 860, 8GB, Intel SSD) and VS2010 runs like a champ. I haven't installed the service pack, though, because all I hear is horror stories. The only time it bogs down for me is when I have Resharper is in "Analyze Errors in Entire Solution" mode, but that's been an ongoing issue for me since... VS2005.
There is definitely something weird with the performance of VS 2010 - running it side by side on two identical laptops on the same project one was unusable and the other was perfectly OK.
I've had people tell me that they find VS2010 to be a lot faster than 2008 was, along with people who say it's much slower. For me it's about the same (but 2008 was awfully slow to begin with).
I will concur. Aside from a memory hog, VS2010 performance has been ok on my dev box which has an NVidia Quadro card in it. However, there are still some quirks in the environment that I attribute to WPF bugs. I have frequent redraw issues even after applying SP1. I also noticed that my installation has a whole lot of trouble with datasets and pulling up the designer file. TFS 2010 issues have been the most frustrating thus far though. They are better with SP1, but still exist.
I have frequent redraw issues as well with Quadro cards. Particularly when moving VS between screens (we have dual monitor setups). It sometimes whites out portions of it. Occasionally as well it just goes batshit and goes white and flickers as well. Oh and the performance sucks on low end Quadro cards. We upped them to ATI FireGL and they seem ok now. Still not happy about the situation.
Have you tried disabling the use of hardware acceleration? WPF seems to have some issues with some graphics cards, or more accurately some graphics cards have some buggy hardware acceleration. Another thing I have noticed is that use over remote desktop and on VMs (specifically VMWare) can have quirks, then again I thought I read somewhere that WPF has to use bitmap remoting instead of primimtive remoting because Windows doesn't offer them any way to take advantage of primitive remoting because they aren't Win32 based (except their root visual which is an HWND, but everything else uses DirectX surfaces), which is a great example of Microsoft teams having pissing contests that just hurts users.
Yeah tried that. Didn't make much difference. I think the main issue with the Quadro's was the poor quality of drivers more than anything else. Even the WHQL ones are junk.
VMware - forget it - unusable. All our infrastructure is VMware based and we have to do remote debugging on VM's via RDP. Yuck. I think when RDP is used it falls back to a GDI+ backend as HW accelerated primitives cannot be thrown down an RDP link and then uses tiles (as you state).
This is all down to the fact that RDP came before DWM. If it was the other way around we'd be throwing surfaces down the wire which would be nice.
>> This is all down to the fact that RDP came before DWM. If it was the other way around we'd be throwing surfaces down the wire which would be nice.
The joke here is that on Vista to Vista RDP connections (.NET 3.0), WPF was properly remoted over the wire and rendered on the client machine instead of bitmaps being sent. This was removed in .NET 3.5. (http://www.virtualdub.org/blog/pivot/entry.php?id=216)
The hardware on the laptops was identical and they had both recently had Windows 7 re-installed. It wasn't a plug-in because the laptops had just been rebuilt and VS 2010 re-installed.
Same trouble here. My (work) workstation is a Dual Xeon, 12Gb RAM, SAS 15k disks (to replace the crap SSDs Dell shipped with the machines). We have (using CLOC) about 250K lines of C# (!). MVC3/NHibernate etc. Takes FOREVER to compile and run (3-4 minutes per change). Resharper is unusable. Crashes every 30 mins or so. Using SP1.
I get the same with Microsoft Connect as well. It's a disaster zone.
That has been true in most every version of VS I have used...almost like Resharper itself sucks from a software engineering point...hmmmm
>Crashes every 30 mins or so. Using SP1.
Try taking off Resharper. I hate how Visual Studio is so unguarded against poorly written components / extensions, but it is. The single biggest point of slowness / crashes I have ever seen is in third party crap, they just figure you'll blame Visual Studio so they don't care.
Ack I don't use R# any more TBH. Dies every 30 mins rather than ever 15 without it so it's a little better... I use the productivity power tools which is good enough.
You can probably find much ranting about R# on stackoverflow from myself.
I would start with removing Resharper first. While I understand why people like having it around, I've seen it degrading performance of otherwise perfectly capable setup on the same solution which flies on a similar setup without Resharper.
Do you have third party things installed like Resharper? My Visual Studio runs like a champ then again I don't install giant steaming piles of shit like Resharper, which has always struck me as something that was written by idiots or drunken monkeys. The fact that so many people install tons of add ins and extensions and then say 'Visual Studio perf sucks' baffles me. It is like installing a bunch of crap toolbars in IE and then saying 'IE perf sucks'.
I did but I don't now. Your solution probably doesn't have 50 projects and quarter of a million lines of c# code in it (oh and another 1/2 million lines of XML and T-SQL).
Anyone who has worked enterprise in the eastern half of the U.S. knows better than to be worried by this. There are so many mission-critical business applications written in C#, and even VB.net, that the idea of .NET jobs going away in the next 15 years, even if MS were to abandon the product today, is nil.
Where I live I would guess that at least 90% of job postings for programmers are .NET.
How many of these mission critical business systems are written with WPF or Silverlight for the native front-end? I don't know the numbers, but my guess is that the bulk would still be Winforms.
I think a lot of people who develop desktop front ends for .NET (and want to develop on new projects) would have put effort into learning Silverlight and/or WPF and are afraid that the effort is going to be wasted, as they need to learn another technology.
What exactly does learning Silverlight entail that differs from learning any other .NET environment? XAML is just an xml markup. I only used it on a WP7 app and it took me a couple of hours to get the gist of how it works.
Not much really, especially if you limit the XAML to basic layouts. If you do everything in C#, it's not too much different from something like, say, WinForms. Which is why people like it.
But most .NET apps that I see have stuck to the best practice of splitting the presentation layer from your other layers. Re-coding just the UI into HTML5 could very well become a standard, especially if it enables apps to easily move to more phones, tablets, or whatever else gets invented in the coming years.
So it is probably true that .NET jobs will not go away. But that 90% mark on job postings could very well shrink significantly.
Last time Silverlight was in the headlines it was because, surprise, MS was pushing HTML5/JS over it. Same deal here, I can't say I'm too shocked this time.
Although now their API situation is more of a mess, with normal native APIs plus HTML5 for Windows now, then there's Silverlight for Windows Phone 7. Makes you wonder if they didn't have any foresight about this decision when choosing WP7's set of APIs.
The idea that Microsoft is going to go the IOS route is so completely contrary to the interests of their primary customer bases - business and enterprise - that it is only the constant call of the techpress for Microsoft to be more like Google or Apple which gives the idea credence.
Windows has had HTML and script based Apps in the form of HTA's for a long time (i.e. IE5). So in many ways the buzz seems more of a marketing coup than a revolutionary new approach (aimed at getting consumers to enable scripting on desktop installations). I suspect Silverlight to be deprecated as a web technology because it has many of the same issues as Flash (for which it was always intended as an alternative/replacement), but .NET is here to stay. It is .NET that facilitates the expanding ability of Windows to run on diverse architectures - since Windows Vista the Windows OS is essentially .NET for many purposes and Windows 8 and WP7 are extensions of that roadmap. A roadmap which, again, is business focused and tailored to provide stability.
Windows had never made it into "essentially .NET". Longhorn was going to be the first one, but it was scraped and Vista is essentially Win32/Win64 APIs with pre-installed .NET framework. I doubt there's anything in Windows client that is written in .NET - server is a different story though.
I did not say that Windows was written in .NET. The parent comment was "essentially .NET for many purposes." Among those purposes would be development of applications and system automation.
Windows developers have a bad reputation for being fixated on one or two programming languages and tools at the expense of learning other platforms. Can't say I would feel sorry for them if any of this were to be true.
There's something to be said about breadth versus depth.
Windows developers have a bad reputation for being fixated on one or two programming languages and tools at the expense of learning other platforms. Can't say I would feel sorry for them if any of this were to be true.
This is an unfortunate, and valid criticism. I've worked with senior C# and VB developers who hadn't encountered the concept of an (OO) interface, but they got along just fine with their day-to-day jobs, copy-pasting. However, I do feel sympathy for them - they were so insulated from the wider programming and CS communities, that they didn't even realize there were other things happening in the wider dev world. Their fault was one of ignorance, not arrogance (and of believing everything Microsoft told them at the developer events they attended).
I think the bigger issue here is how Microsoft is handling the dissemination of coming changes. Why on earth say nothing except 'please wait until september'. Between now and September I could learn object-c and move to another platform. Just a really unwise approach. At the minimum they should be saying, '...your investment in the Microsoft stack will not be lost, C#, F# and VisualStudio are important technologies that we are committed too...'.
So here we are left to speculate as to what happens next. I can't believe they would simply toss all the technology out - what's the alternative for true native apps, pure C++?
As far as the HTML5/Javascript thing goes - hell yeah, I switched to using html(4/5)/javascript and css(2/3) for my front-end code over a year ago. I think this is actually a pretty shrewd move and likely will be more a focus for the tablet and phone developer side allowing easier porting across all the emerging platforms. The fact that I may be able to use that same tech for Windows desktop apps is nice bonus, but like we all saw on iOS - nothing beats native for the best client experience, at least for now.
What's to stop you from putting a Silverlight APP in the tiled interface? Silverlight runs OK now in HTML pages so in theory it should work in the HTML + JS Win8 box as well :)
I think what is more troubling is that Microsoft has apparently signaled a major shift in the preferred way to develop programs for the Windows platform and simultaneously refused to address the implications for developers, asking them to wait for further announcements in September.
That's a recipe for fear, uncertainty and doubt within the tribe itself.
Put another way: it's hard to reconcile "Developers! Developers! Developers! Developers! Developers!" with "We're changing things radically concerning the way you develop, but we won't tell you how-- hold tight until September, 'mmm-kay?"
At this point Microsoft is just pre-empting Apple announcements at WWDC. It's all hubris until they deliver something more concrete. There will be internal debate about HTML5/JS vs .NET, and their choice of strategic platform has changed enough times in the last few years to make me take this announcement with a pinch of salt.
There's a huge number of business developers this won't affect. .NET and "normal" desktop, web and server apps are still the bread and butter for these folks. Not everyone is on the bleeding edge.
There is a turf war at the moment between MS, Apple and Goog. Developers take time to tool up and skill up, and amidst all the gunsmoke and fog of war, we all have to decide who to pledge our allegiance to. By not mentioning Silverlight or WPF, MS is effectively switching sides from developers who have invested in exclusively MS tech to those who are far less partisan, and it hurts.
MS is effectively switching sides from developers who have invested in exclusively MS tech to those who are far less partisan, and it hurts.
Microsoft does seem to be inching away from its traditional developer base to broaden its appeal.
Lightswitch seems to be another example. I doubt that it will be as empowering for non-developers as the marketing suggests, but it should reduce the effort/expertise required in creating well-architected CRUD apps, making in-house development easier and exerting downward pressure on project costs. This will hurt some consulting shops.
But Microsoft's duty isn't to look after its loyal developers, it is to maximize shareholder value.
Lightswitch is Silverlight wrapped in a good practice framework, just like Wavemaker generates code on Spring.
I had a play with Lightswitch and I liked it. It is like MS Access. I'm surprised they positioned this at the developers rather than power users though. Perhaps there is a wall between the tools division and the Office division.
On the topic of loyalty, platform companies are like the Mafioso. Loyalty or the lack of it cuts both ways. MS tech is not the easiest to learn. The reason MS got away with it for years is because Sun was even worse.
I had a play with Lightswitch and I liked it. It is like MS Access. I'm surprised they positioned this at the developers rather than power users though.
They are positioning at power users, but it does seem like more of a developer tool. I think it will appeal to less-skilled or time constrained developers more than to power users. I've turned down side projects, where Lightswitch would have been extremely helpful because of time constraints.
I have worked in consulting places where income is generated, especially during lulls, with the sort of apps that Lightswitch is supposed to generate. I expect, if Lightswitch works as advertised, to see less of those projects.
MS tech is not the easiest to learn. The reason MS got away with it for years is because Sun was even worse.
My personal hope is that Microsoft feels threatened enough to produce some silver bullets for business application development, or at least to try.
I dunno - .NET has long felt like that silver bullet to me. It's rare for me to enthuse over a programming language, but C# is fantastic and F# great in its own niche, and .NET tends to have all the bells, whistles, and gongs that I feel benefit me as a developer.
That is the problem. The system is very complicated and verbose to use.
Lets say you want to write a program that extracts all links from a web page. How would you go about this? First, you look up in the documentation how to load a web page over http. This requires several lines of code, and it's complicated enough that you don't know it by heart after the first time you've done it. From there on it gets easier: you get a library and read the documentation to parse HTML and use an xpath or css selector to load all the links and then read of the href attribute. All of this probably requires around 15 lines of code, with various method calls that you have to look up.
I know how to do this by heart because there are just a couple of things to remember. Not having to look at any documentation to do simple stuff like this saves a lot of time.
The guy who architected WCF needs to understand that MS developers have to be competitive against other technologies or they would start losing out because of cost. The competition isn't Java. It is Rails, Django and PHP.
To be fair, it should be a lot less expansive to get a complex UI running for 90% of a typical user base with silverlight, provided that your business model allows you to ignore the fsf crowd. In the context of those touchy-feely applications for windows 8, it is a hysterically stupid move to force developers into the web stack, and then tell them to go fuck themselves and port the whole shit to Silverlight for WP7 devices. It is really less "cross platform", considered what platforms those devs care about.
I can think of very few reasons for this idiocy besides relations between OS and devtools devision having quietly deteriorated from post WWII style peace to nuclear war.
The platforms that I, when doing .NET development, care about are:
-Windows
-Windows Phone
-Xbox 360 (for games)
And maybe Linux if I'm feeling really charitable and want to make my stuff Mono-compatible.
JavaScript is not a first-class language on at least two of those platforms. It's not a cross-platform application development language on three of them.
This is a market strategy. Microsoft knows desktop apps, WPF, Silverlight are losing the battle against HTML5/CSS/JS based apps, the most obvious movement Microsoft could have done is create a 2 minute video of their next OS and say "hey Web Developers, you can use your web skills here too".
Also, this video says nothing about the architecture behind this "Launcher"(because that what it looks like), there are a lot of possibilities. May be IE10 has some kind of <protected-frame> element so you can specify certain permissions like network access, file system access and stuff, maybe it requires a manifest in which you can specify what "DOM manipulation technology" do you want to use, the most obvious options are:
- A Javascript (IE9 code-name "Chakra" engine) based file.
- A JScript.NET file.
- Any DLR based language file.
- Any .NET assembly decorated with some fashion attributes like <Windows8Launcher.TileDomBehindAttribute(typeof(MyTileHandler))> or something which you can easily compile with any .NET compiler like C#, VB.NET, C++ CLI, etc.
May be developing in HTML is completely optional and each Tile can be developed using Silverlight or Windows Presentation Foundation technologies... we don't know.
We know that Microsoft is a legacy company, they will not abandon .NET anytime soon.
.NET is not going away anytime soon. If anything I feel this further deprecates silverlight. There is no way that MS expects the majority of apps to be written in HTML+JS, it's just an option to make it easy for those used to HTML+JS to write apps on the platform, in the same vein as writing an HTML+JS app for iPhone. Most serious Windows applications are written in C++ for Win32 anyway, VS which is becoming more and more .NET everyday still has heavy roots in COM/Win32. Office integration is still best done in C++. No these apps aren't whats fueling the consumer web but they make big bucks for the vendors who write them, and ensure platform lockin to Windows as MS tries to transition away from their desktop monopoly.
MS is not stupid enough to pull another Vista and make apps that used to work not work. Even if MS were very serious about transitioning everything to HTML+JS you'd be looking at a 10-15 year timeline. The day you see Office written in HTML+JS is the day to start worrying if you're a Win32 / .NET app developer.
.NET bleh. HTML5 is the future, cross platform. JavaScript will be made into a robust language in the coming years, with classes, etc.
The crappy DOM will probably change for the better, HTML5 apps will run as local apps and tap into the native APIs of the system.
Client = HTML5 + JS , yes we dont need .NET here, where .NET/C/C# and others will be used, will be in the backend, frontend/client can be perfectly made with HTML5 + JS.
The only exception is perhaps games and apps such as Photoshop, but 90% of enterprise stuff that is simply thin clients speaking to a big backend database+etc can be perfectly made with HTML5.
HTML5 is here to stay, .NET will be the exception. (Games/Heavy backend/3D apps/Photoshop) sort of things... nothing more.
Or who knows, maybe in the future with WebGL and what not even some more complicated games can be made just with HTML5.
> HTML5 is the future, cross platform. JavaScript will be made into a robust language in the coming years, with classes, etc.
People have been claiming HTML and Javascript were the future of application development for about 15 years now. They also claimed it about Java and, ironically, .NET.
This does remind me of the "no-native-.NET-support" Windows Sidebar attempt. It failed in the end, but even there one of the first things we did was find a way to host .NET elements in the sidebar (and it was possible, but you had to jump through many hoops).
We will have to wait and see, but I can't imagine there will not be a way to host Silverlight in one of the tiles.
Also this whole "every app is going to be html + javascript" does remind me of the earlies Apple IPhone developer offerings.
I can only imagine the turf wars raging right now about this apparent dichotomy between classic and tiled. I assume my friends there are not having a very happy day.
That's not exactly a fully supported toolset. There is another C# to js compiler http://projects.nikhilk.net/ScriptSharp which is AFAICT another side project.
If one of these were to stick - it would first need to be supported be a somewhat larger organization (ala apache foundation for java components, or google for GWT/Closure).
For the F# developer, WebSharper ( http://websharper.com/ ) seems to offer a great implementation based on the Formlets abstraction.
For some theoretical background, have a look at http://groups.inf.ed.ac.uk/links/formlets/ which has some articles describing the Form abstraction by Philip Wadler, et al.
The fun thing is that there WAS something from Microsoft themselves, called Volta. I've never heard anything about this project for 2-3 years already. RIP, I suppose.
Microsoft seems to have lost all sense of direction. I just see them launching a bunch of superficially considered me-too initiatives instead of anything meaty. They still are the gorilla, but it almost looks like they've given up. Is it just me?
That shows the risks of vendor lock in. Although I don't believe MS will replace .NET with html5/js in any regard it shows pretty good why you shouldn't commit too much to vendor specific/centric technologies.
Based on that logic no one should be building iPhone or iPad apps. You have to commit to something at some point. The odds of a company ditching a product they have invested hugely into is probably the same as the odds of an open technology or framework simply becoming unpopular.
You can commit to something, for a time, without pushing everything else out of your brain. I spent quite some time doing iOS development, and it would certainly not be the end of the world if the entire toolchain changed tomorrow.
I see this tile-thingy more as an additional overview-shell, but the real work will remain to be done in the classic apps. This is more comparable to the Mac Dashboard widgets than to a complete UI redesign.
As such, I see no problem in doing these widgets in HTML/JS which is what we have used ever since. The "real" applications will still be done in whatever technology is available under windows.
Of course, everything is just speculation. I just know that I'm sure as hell never going to use a touch interface on my desktop PC nor drag around tiles with the mouse trying to fake enough inertia to get the scrolling to go.