WPF/e vs. HTML

It would be ill-advised and brash for Microsoft (or any company) to put forth a new technology and claim that it could replace HTML. As you point out HTML is the backbone of the internet, it's loopholes have been capitalized on and built upon in very creative ways to find solutions to initial limitations (JSON, AJAX, etc). A robust and seamless way to interact with HTML and extend it is necessary for any web technology to succeed.

Given that, the WPF/E team has chosen a set of scenarios that add value to the browser and validate the HTML interaction model as a starting point for our development. We plan to add to the set of scenarios that WPF/E enables in the browser. A technology with all the functionality of HTML cannot be created overnight. Our team uses agile methods for development and we've been iterating very rapidly. Only 4 months ago we did not have the ability to play media and create elements programmatically. We plan to continue iterating rapidly, enabling new scenarios, refining existing features, and hopefully adding customer value, one sprint at a time.

simsod wrote:

Uhm... why don¡¯t you do a little bit more research before you open your mouth

What's worrisome is that people on the WPF/E team like Michael Harsh and Barak Cohen are seemingly unaware of what developers want their product for. Vectorized graphics and media playing Honestly, who cares Vectorized graphics are cute and interesting, but image scaling works pretty well. Media players are nice, and that's why we already have a million of them to choose from. What web developers need is an application framework.

Without C# and the complete 2D WPF control set, WPF/E is just an ad rotator.

Developers need to keep the WPF/E team's feet to the fire. We need to remind them that nothing in the Dec06 CTP is actually new or interesting, and that the useful parts of WPF/E have not yet been written.

I'm a bit disappointed too, but maybe disappointed is not the right word. Lets say "eager". I realize what the team is trying to do in 1.0, actually ship a product and try to match Flash in keypoints. Those of us wanting to do mini apps or "documents" in WPF/E will have to wait for 2.0, or something. Hopefully not too long.

Here is my dilemna and take - corrections to content welcome:
http://www.kudzuworld.com/blogs/tech/20061231.en.aspx

I hope and think that the team does see the bigger picture beyond being a XAML version of flash - and that is just a matter of a phased approach.

Great points. I'm perpetually amazed by the lack of concern many developers have over the current state of affairs in web development. HTML's main utility is one of document flow control. It's good at saving us from having to mess with positioning and sizing elements, and makes drawing a page of content easy. It does this fairly well, though it struggles with animation, video, overlays, and rendering performance in general. It wasn't meant to be a UI. It's also a quasi-standard, with any moderately complex layout guaranteed to look different in different browsers.

As web apps try to do more, the browser is pushed to behave more like an operating system, which is silly. We should just call a spade a spade, and create a new framework that is designed to host applications. An expanded WPF/E could fit this role. The problem is one of adoption and developer culture. Flash might have become the new standard for complete web apps, but most Flash developers don't seem to be strong programmers. Director was actually more powerful, but it suffered the same problem. There are too many designers and not enough coders. With .NET, however, you have a community of programmers. They're already using ASP to make web apps, and would be happy to take advantage of a system that offered better user experience, and a coherent programming model. Sure, there's considerable inertia behind the status quo, but I think that's only an artifact of the lack of options.

I certainly hope that in ten years, I'm not still trying to figure out why a div isn't obeying its z-index in Firefox 5.1, or writing Javascript in notepad.

I totally agree.

I guess I have been going on a bit of a rant on these forums lately but I just feel so passionate about this. I do web development every day and I used to do desktop applications previously. What I saw WPF do for desktop applications is simply awesome. UI designers can now finally do the designs they used to always mock up but developers couldn't code because it was too complicated.

I see WPF/e offering the same similiar qualities. Revolutionize the web. Perhaps tackling the web is a little harder than shifting how desktop applications are presented because its not all neccessarily your OS and your browser and many languages out there.

But possibly the opportunity as I mentioned in another thread is supporting HTML through legacy output. Could a XAML document be indexed by a search engine Could a XAML document be transformed into HTML Lets say you have a form with text input, etc controls in WPF/e (theory here) could you then write an ASP.NET control that if WPF/e is not present, it rendered it as HTML instead

I think so many of us are just begging to get out of this development cycle and lift the web into a much richer model. Right now if you want to do richer features, it really just means making your application extra complicated and laying on a pile of Javascript to do all of the animating etc.

I think its a shame if this technology is only used for menus, banners, ads and video players. It has so much more potential than this. I know it can already do more than this, say listing products in a nice data bound rich graphical listing that comes from a web service that maybe animates. But deep down somewhere your going to want a form with some input of some sort. I want to order this and I want to select 10 as my quantity.

Perhaps I am out of line here I don't know. I just can't help but feel passionate about this, sorry :)

I think the current WPF/e start in the right direction, I just think there should be more ambitious goals for the final product.

As much as they might not want to say publically WPF/e will always be compared to Flash and until you provide above and beyond. Simply for 2 reasons:

1. WPF/e offers very similiar UI aspects as far as Designer Tools (Blend) and rich animating features.
2. Deployment. It took a long time for Flash to be accepted for banners, menus etc because website makers did not want to deploy 2 versions of their site because Flash only had a small installation market. Now I read somewhere 90% or 95% of desktops have Flash so its safe to bet you can use this technology. That being said website makers will take longer to shift to WPF/e until its install base grows to a trustable install base.

That being said, the install base can rise as more applications require WPF/e. If WPF/e offers much benefits over Flash or non-rich UI (straight html and/or ajax) then more web developers will choose it because of its benefits. Thus spreading the technology quicker.

In general developing for the web is all about browser compatibility. If your audience is the public, and you have a choice over a 95% install base or under 50% install base its a pretty simple choice unless the latter gives you a real huge technology advantage.

Currently I hate Flash / Flash IDE / Action Script. But simply liking C#/XAML/WPF/e better as far as coding is not a good enough reason for me to justify dropping a 95% install base for personal grief with Flash.

Also that being said, with the "possibility" of C# coding with WPF/e I could see writting web applications based on ASP.NET server controls that simply output WPF/e and use C# rather than Javascript.

I'm sure many people after that statement are asking why Javascript works great. Yes it does but its so very prone to errors. Visual Studio does not do a good job with Javascript. If I write my own libraries there is no syntax checking, its a very easy to break language. If my ASP.NET control outputs Javascript now things start to really get decoupled and ugly. But does it work Sure it works.

Also on this Javascript note. Who says the C# can't output Javascript so WPF/e can work with the browser For example look at the project Script#: http://www.nikhilk.net/ScriptSharpIntro.aspx

This would be great. Although this project is limited currently, simply the idea behind it has tons of potential. Writting your ASP.NET server controls purely in C# that can also generate javascript in a type safe developer environment. Ontop of that it could have all the WPF/e javascript classes wrapped.

Much like ASP.NET controls, you write ASP.NET markup but what the browser gets is HTML. Why can't I do the same but it outputs us Javascript for scripting code

Anyways I rant again. Sorry ;)

I like the way HTML layout works, but the browser has been going nowhere for years.

I like what I can do with SVG, but it looks like it will never become mainstream.

I even liked HTML+TIME but that seems to be dead.

Above all I want to combine the possibilities of these things with languages that use the CLR. (Ideally languages that include features you have in Ruby and F#.)

If we look at WPF/E here's a couple of observations:

1) We don't really know what it will end up being, but it could take a while. (If it was a genuine subset of WPF it might be easier, I hear VBScript was mostly done in a weekend!!)

2) WPF/E at the moment seems not have much to do with WPF. XAML is common and that's it. Two approaches to learn, bad move.

3) A smooth interop XHTML -> WPF/E -> XBAP ... would be great, even better if the browser got internal compiled support for the things people hack up with JavaScript. (Don't depend on it, or hold your breath. People have lost years of their lives believing that computer technology is designed with developers in mind.)

4) From what I've seen of XAML the work so far is forms oriented. If you want 3D surfaces the representation is rather like shapes in SVG and the tools are not ready. That's disappointing but will eventually be fixed in some way, the question is when.

It's hard to plan, the answers are unlikely to be as good as you hoped for, timings are likely to be slower that you expected, you may have to throw away years of work. That's life, as we know it. It's more restful when you learn to live with it.