Dave van Bale

After reading Mike Harsh's blog post What WPF/e Really is.

I'm kind of disappointed with the approach that the Architects are taking with WPF/e, as in that it augments HTML instead of replacing it.

Why not

Personaly I find that HTML slows me down in producing rich content for my users (something that WPF promises).

Sure its easy, its fast, and we should keep it (not every website needs rotating letters).

However, as I see .NET being used -alot- for mission critical application, I would only EXPECT WPF/e to take the fore front and upgrading the way we provide commericial services on the Internet in a fast, uniform way.

Flash is doing this, Flex is not 'augmenting' the Web, its rewriting it.

Share your thoughts.




Re: Silverlight (formerly WPF/E) General Discussion WPF/e vs. HTML

Barak Cohen

What we hear from our customers is that there are many things in the web architecture that work very well: scalability, relaiability, security, deployment, search and more. These are the things that you do not want to replace, you want them to just work and work well. "WPF/E" role is to get the web experience a step further while maintaining the benefits of the web architecture. We want to let the customers decide about the dose of "WPF/E" they want to use for their experience without breaking their infrastructure.

If you want to deliver full fleged .NET applicaitons, you can do that in Windows throught .NET Framework 3.0 and WPF.

Barak






Re: Silverlight (formerly WPF/E) General Discussion WPF/e vs. HTML

Dave van Bale

Barak Cohen wrote:

What we hear from our customers is that there are many things in the web architecture that work very well: scalability, relaiability, security, deployment, search and more. These are the things that you do not want to replace, you want them to just work and work well. "WPF/E" role is to get the web experience a step further while maintaining the benefits of the web architecture. We want to let the customers decide about the dose of "WPF/E" they want to use for their experience without breaking their infrastructure.

If you want to deliver full fleged .NET applicaitons, you can do that in Windows throught .NET Framework 3.0 and WPF.

Barak

I understand that the current HTTP protocol is very succesfull as a way of transfering information and being all the things you mention above, HTML however, is the one thing that many vendors/users are not always uniformly agreed upon.

It is the sore spot of the Internet, the multiple interpretations of HTML are slowing down development, and I understand in order to create a wider spectrum for WPF/e to be used, that it can be used with HTML/Javascript, but isn't it good to look towards the future we can't improve the web standards if we keep clinging to them.

HTML will always be the backbone of the internet, but should it not be possible to fully focus on one technology and fully exploit all the advantages it offers us






Re: Silverlight (formerly WPF/E) General Discussion WPF/e vs. HTML

Mike Harsh

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.






Re: Silverlight (formerly WPF/E) General Discussion WPF/e vs. HTML

Daryl

 Mike Harsh wrote:
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.

HTML has needed replacing since the dawn of the internet.  Go look at Google Spreadsheet if you'd like to see what's wrong with HTML and Javascript.  Google has (by far) the best AJAX coders on the planet, using the best AJAX tools available.  Look at the result: Google Spreadsheet is still thin, slow, and unimpresive.

 

Be honest, Mike.  Do you think Excel 2007 could be written using Javascript and DHTML   What about Photoshop   Could Photoshop be written in AJAX   Of course not.

 

Could they be written using WPF and C#   Definitely.  So why is Microsoft playing "ME TOO, ME TOO!" with broken technologies like Javascript and HTML

 Mike Harsh wrote:
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).

"Creative solutions to initial limitations" is a polite way of saying "If you want something as simple as a slider or a tree-view control, be prepared to write 1,000 lines of Javascript and DHTML".

 Mike Harsh wrote:
Given that, the WPF/E team has chosen a set of scenarios that add value to the browser

What value, exactly   What value does WPF/E offer to the browser in its current form   None.

 

Playing media and doing animations in an object embedded in a web page   There are already about 2,000 solutions to that problem.  At the moment, WPF/E is number 2,001.  Big deal.

 Mike Harsh wrote:
validate the HTML interaction model as a starting point for our development.

Please don't validate the HTML model of building applications.  It's like telling a drunkard that he's doing fine: it makes him feel better, but it won't help anyone in the long run.

 

Mike Harsh and Barak Cohen: If Microsoft isn't going to bring a full-featured application development environment to the internet, Adobe will certainly be happy that you're ceding the market to Flex.  Personally I prefer C# to ActionScript, but WPF/E has neither one.





Re: Silverlight (formerly WPF/E) General Discussion WPF/e vs. HTML

simsod

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

The CLR with C#.net support will arrive in future CTPs. This CTP release is a BETA, or perhaps not even that.

Very important things like text input, layout, resources, data binding and of course, CLR integration are all WPF features that our team is scoping for integration with WFP/E.
http://blogs.msdn.com/mharsh/archive/2006/12/06/what-is-wpf-e-really.aspx

Did you have the illusions that we all were supposed to use XBAPS, or any other binary format for our every need. Naah, part of the success with HTML is that ití»s open and that everybody can learn from each other. The goal with HTML probably never were to be what it is today, so in a way, you are right, it is an old, probably a little bit outdated technology. This however only makes it more important to fill in the features that HTML lacks.

My view of what WPF/E is, and can accomplish is simply put:

An open indexable alternative to Flash(Flex) that provides better integration with existing Microsoft web technologies.




Re: Silverlight (formerly WPF/E) General Discussion WPF/e vs. HTML

Daryl

simsod wrote:
Uhm... why doní»t you do a little bit more research before you open your mouth
If you had bothered to read the post you linked to, you would have noticed that I've already posted there as well.

Here's what Michael Harsh had to say about CLR integration on his blog:
Michael Harsh wrote:
Very important things like text input, layout, resources, data binding and of course, CLR integration are all WPF features that our team is scoping for integration with WFP/E.
In case you're not familiar with project-manager-speak, "we're currently scoping this for integration" means "maybe we'll do it, maybe not".

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.





Re: Silverlight (formerly WPF/E) General Discussion WPF/e vs. HTML

simsod

Ah, yes, I think this got of on the wrong foot :)

By the number of posts regarding the need for Controls and C# integration, I doní»t think that ití»s going to be left out in the v1 release. Then WPF/E would be exactly what you say, an ad rotator.

But seriously, do you think Microsoft is that stupid Of course they know that they have to add something new to make this an attractive solution. And if you look at Microsofts other productlines in the web category, do you really think that WPF/E is going to be all about the media and cool animations Are these the things that make the big-business-giants want to use this product Naah... are these the clients that microsoft primarily focus on Yeees...

A good way to integrate this technology with existing MS web technologies, thatí»s the way I think(hope) this is heading.

But I agree, this release of WPF/E really did not contribute with very much . Except for that you can do cool things in a text-only-format.
Either this release was premature, or another CTP needs to be realeased in a relatively near future... or at least some DEFINITE answers to the questions regarding where this is going, and what features are going to be included, before developers loose interest.
When I read the posts made by the WPF/E guys, I really get a sense that they are sitting on alot of information that they are not allowed to share with the public. Why probably some marketing/economic scheme :)

Simply put, we didní»t get very much to play with...and they know it.

Keep up the good work wpf/e people, and weí»ll continue to supply our opinions..
/Simon




Re: Silverlight (formerly WPF/E) General Discussion WPF/e vs. HTML

Kudzu22

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.





Re: Silverlight (formerly WPF/E) General Discussion WPF/e vs. HTML

Joseph Bergevin

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.





Re: Silverlight (formerly WPF/E) General Discussion WPF/e vs. HTML

Synced23

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 :)





Re: Silverlight (formerly WPF/E) General Discussion WPF/e vs. HTML

Joseph Bergevin

It's nice to see that I'm not alone in my bewilderment over the enthusiasm web devs have about AJAX/DHTML. It's the best thing going, but that's not saying much.

If the web is the future of applications, now is the time to make a change for the better. I don't want "Web 3.0" to be another hack that tries to ape a real application paradigm, sapping my productivity. I would venture to say that a WPF/E with the layout and control features of WPF would be the most important thing Microsoft could do in regard to client software.






Re: Silverlight (formerly WPF/E) General Discussion WPF/e vs. HTML

Synced23

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 ;)





Re: Silverlight (formerly WPF/E) General Discussion WPF/e vs. HTML

Greg Brown

>> I'm kind of disappointed with the approach that the Architects are taking with WPF/e, as in that it augments HTML instead of replacing it.

Agreed.

> What we hear from our customers is that there are many things in the web architecture that work very well: scalability, relaiability, security, deployment, search and more.

These are good points. However, HTML isn't integral to any of those. Like Flex, WPF/e should allow developers to continue to take advantage of these aspects of the web while providing a better platform for user interface development than HTML. However, also like Flex, it should be capable of co-existing and interacting with HTML when necessary, since HTML is currently the primary means of developing web-based UIs and probably isn't going to go away any time soon.

> If you want to deliver full fleged .NET applicaitons, you can do that in Windows throught .NET Framework 3.0 and WPF.

...except that .NET 3.0 is not cross-platform, while almost all web apps currently are.

I'm personally very excited about the possibility of developing rich web applications using XAML and C# rather than AJAX or Flex. However, WPF/e needs to, at a minimum, offer feature parity with these toolkits: it needs to be cross-platform, and it needs to offer a widget set that is rich enough to build "real" applications. I'm still hoping that, by the time it is released, it will.






Re: Silverlight (formerly WPF/E) General Discussion WPF/e vs. HTML

MikeGale

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.