Flash RFC

Sean still disconnects on some issues, but at least we do agree on some things....

1. Remoting, Latency & Facades

Why is remoting bad? Because for each property get and set you need to make a call to the remote object. Very bad from a performance standpoint. So, we do something to eliminate the amount of remoting we do, like build a facade and pass entire objects or datasets back and forth. I think we agree here.

The issue is why should the facade be written in ActionScript? Well, for some apps it might not be an issue. But when you have a lot of developers that are going to be interfacing with your application or you spend your time building frameworks (like me), then a simple auto-gen'd class aint going to cut it. To truely reduce the penalty of RPC calls, you need to make as few as possible. When you have a lot of logic going on, you are going to have to cache some things (like security credentials) to eliminate the number of calls you make. This has to be done on the side of the client, since the client is the one that initiates the calls in the first place. If you are going to provide rich functionality some name value pairs or simple structures aint going to cut it (ok, it was the other article that was emphasizing the name value pairs as the value object pattern...I guess you don't agree with Brandon Hall's article that originally pointed me to yours?).

I think the situation is similar to what MS does with the Primary Interop Assemblies and legacy COM components. If I was building a flash based eCommerce framework, I would definately want to include some type of equivalent functionality for the very same reasons you would create a PIA. Let's get this straight though. I would much rather just create a .NET assembly that the people using my framework could use and end it at that. This is possible with ASP.NET or a Windows Forms Rich Client, but with Flash it isn't an option (this is again why I say some type of better integration with .NET inside of Flash would be a lot better than remoting). Right now, I would have to write my PIA in Javascript, which is definately not a fun thing to do.

3. Multiple Languages
"So it appears we agree here that in larger applications, using multiple languages is the way to create the best result"

Only given the precondition that you have developers that are predisposed toward seperate languages. This is something of the past though, the trend is consolidation (like MS SQL allowing C# stored procs). Developers don't have time to master a ton of different languages and Javascript is definately a dying language. A couple years ago, you could throw a stone and hit a Javascipt "guru," now they are already much harder to find. Soon, they will have gone the way of the COBOL guru...especially considering the increase of alternative methods of creating internet based Rich Clients (ie. Java, .NET). 5 years ago, everyone was learning Javascript (heck, I even met a rough looking homeless guy last week who learned javascript in the .COM days and was pretty proud of it), but that isn't the case today. I don't know any developers who could say to me with a straight face that they would rather use JavaScript for their next enterprise level application than a real language like C# or Java. If anything, the perception issues alone are going to be a major hurdle for the take-up of Flash development.

4. IDEs

I assume from your comments you conceed that the VS.NET experience is a lot friendlier :-).

I am well aware of the Macromedia Exchange. Lots of cool toys in there, but flash is still majorly lacking in the Component Based Development arena.

5. Spagetti

Yes, everyone can write bad code in any language, and that is one of the things that VS.NET attempts to limit by defaulting to code behind and including support for enterprise templates. The MX team would do well to take note.

However, you still have the problem that the IDEs aren't integrated enough to provide the level of support that a truely productive IDE would require, but Flash 7 is due out soon and 8 on its heels so we will see (I've heard some cool rumors at least that Macromedia is seriously looking at the development market and there are plenty of smart guys over there, so we will see, I just might be suprised...but VS.NET 2004 is also coming out soon and I have heard about a ton of very cool stuff in that area which Macromedia definately isn't going to be able to match any time soon...so by the time MM Studio 7 comes out there will still be plenty more catch-up to play). But, I digress, this was point 4, not 5 :-).

In any case, this still leaves me at the point where I don't see enough benefits to justify using MX for a rich client as opposed to a fancy WinForms client or a vanilla ASP.NET application...and this, of course, is exactly the point. So, using MX may not be a horrible solution for a rich client, but, IMO, the .NET value proposition is still a heck of a lot better.

16 Comments

  • just for the record, I think both of you guys are stretching/ignoring things in order to "prove" your points, but I think the argument can be boiled down to this:





    Flash allows cross-browser cross-platform rich client/server applications. .NET doesn't.





    .NET does a LOT of things that Flash doesn't do.





    Choose the right tool for the job.





  • The only part of that I disagree with is that .NET can't be used to create cross platform rich client/server apps :-).

  • Would you mind pointing me to the Rich Client .Net component that works with Netscape 4?

  • Is there a way to make a cross-platform rich client in .NET?

  • Brandon's article is very good - I don't know why you think I disagree with it? His article and mine are entirely complimentary - we both agree that design patterns can (and often should) be applied to both client and server (and my recent Under The Hood report comments that we do indeed apply design patterns in our ActionScript development).

  • SirShannon,





    Any .NET app is cross platform and will run with or without Netscape 4. .NET is like Java. It isn't as mature, so there aren't as many other VMs, but the Project Mono (Ximian) implementation is pretty good and supports WinForms, ASP.NET, etc. on Linux, Windows, and OS X.





    Sean,





    So, do you like the name value collection idea or not:





    userData.setInfo({name:name_txt.text, address:address_txt.text, city:city_txt.text, state:state_cb.getSelectedItem().data, zip:zip_txt.text});





    instead of:





    userData.setName(name_txt.text); userData.setAddress(address_txt.text); userData.setCity(city_txt.text); userData.setState(state_cb.getSelectedItem().data); userData.setZip(zip_txt.text);





    I agree that sending all your data in chunks is good, but getting rid of your get and set methods completely is lowsy. A much better solution is to have an Update method with no params or an entity broker with a Commit method (very nice from a performance standpoint because you can send all the changes as one big dataset instead of a ton of seperate RPCs). Of course, this takes a little work (ie. an actionscript facade), but the resulting product is superior.

  • Hi,





    Some interesting points here and its good to see Sean raising some points.





    A gotta agree that Remoting may give you performance issues and a Facade will help however what would the issues be over a passing an object/dataset to an RPC. You would have to serialize and unserialize from IL to AS and back. Would that transformation not cost some performance, prehaps this could be addressed by IL translation within the player.





    The AS/JS issue is an interesting one but I don't think JS is going to die out. AS is based on ECMAScript (as too is JS and JScript.NET) so and I think it will be around for quite some time. Prehaps the real issue is could the AS and .NET bridge be closed and thus bring AS developers and .NET developers a lot closer togther. I see this as being very possible (and should a future version of IE be CLR based it may open up a lot of things for the Flash Player) and should SSAS become a true server side language then surely it should be .NET as much as J2EE.





    Another point on the language issue is should AS be the only language of Flash? One thing that could be done is make scripting files external and make the player behave like a VM with a op code (not Flash op codes) so that you can script Flash with any language you choose (as long as it compiles to that Op Code) you could then have a IL-Script Op Code and thus script Flash with .NET language that you want.





    Just a thought





    Andrew

  • .Net is like Java? True, but not in the context we're speaking of.


    Mono is far from finished and isn't an MS product, 2 strikes against it from the start. It certainly isn't something I would redirect users to and require them to install. The third pitch: Mono runs best on Windows at the moment. Would you use it for your client runtime? I'm guessing that's strike 3. Mono passes for server-side ASP.NET and may one day allow .NET to be a cross-platform RIA tool, but today it just isn't there.


    I've heard that MS is working on an OSX version of the .NET runtime, that would be great, but again, it just isn't there.


    The future is bright for .NET but a wise little green guy once said "uncertain, the future is."

  • You operate under the same falacious worldview that Jeremy Allaire recently got caught up in; before he checked himself and took a step back.





    Microsoft has already publically stated its policy on its .NET patents. Although they would be perfectly justified in charging a RAND licensing fee (like every other commercial technology vendor on the planet), they are granting licenses to the .NET technologies free of charge. The patents are there to protect their IP, not to beat down those who are making third party implementations (they have quite a good relationship with the Mono team and have even written up Mono on MSDN).





    As far is GPL is concerned, it is a horrible license. There are plenty of other OpenSource licenses out there (like the one that zlib, perhaps the most widely used OpenSource lib ever uses, or the SGI STL licenses) and there are also plenty of commercial products that run on Linux and aren't open source. The use of GPL is by no means a requirement for creating software that runs on Linux.

  • "Microsoft has already publically stated its policy on its .NET patents"





    It doesn't matter what Microsoft's policy is. Microsoft has demonstrated in the past that policies can change (ref: the numerous Licensing policy changes). Microsoft owns the Patents and the license agreements to use the patents. Have you ever noticed the caveat that allows Microsoft to revise its license agreement in the future? So, just becase a license agreement states one thing today, doesn't mean it will change in the future if it impacts Microsoft's profits.





    "As far is GPL is concerned, it is a horrible license"





    Your opinion. I personally don't care for it either, but I wouldn't call it horrible. It is just one version of a license for a programmer to consider. It has its benefits, and its obligations. Is it any more horrible than proprietary licenses that limit free speech (i.e., can not publish independent reviews of a product without the vendors consent)?





    Cheers,


    TC

  • I guess I don't know how to read OSS release numbers, thanks for the tip. Of course, the "v0.x" is all that matters to me.


    There are MANY numbers the do make more sense to me on the page I posted the URl from. Numbers like 30% complete for some classes, 60% complete for some classes, 80% complete for some classes. You can post as many "most probably will happen soon" as much as you want but I refuse to accept that as backup for your "is cross-platform" statement. If you meant to say "is almost" or "will soon be", then correct yourself. Otherwise, stop pretending that an incomplete beta is anything more than promising.





    Your words "Any .NET app is cross platform " are wrong. That is, unless you have knowledge that "any .Net app" can not possible include calls to any of the 60+% of System.Drawing that Mono hasn't fully implemented yet (just one of many possible examples).





    Also, what effect does the release of .NET v1.1 have on Mono?

  • I may need to clarify something here and tell you that I can't wait until Mono is finished. ASP.Net on Linux is great, but when I can write a desktop app that my graphic designer can run on OSX, I will be a VERY happy man. I have been checking the Mono progress occassionally since the first time I heard about the project. I don't use it at the moment because I don't really use *nix nor Mac. While I don't suggest that my clients use any pre-final releases (or pre SP1 MS releases), I have a habit of installing every new beta that I find interesting. Mono is one of the projects I've decided to let others beta for me.

  • "you will probably have an easier time coding in C# than making the same cross-platform C++ app"





    that wasn't the topic we were discussing. We were talking about rich client cross-platform, cross-browser apps.





    C# being easier vs. C++ is a given, I think.

  • Ok. lots of wandering. Hopefully my new, more thought out and methodical, series should help keep things more focused and "scientific," since it is a bit more thought out than these random musings.

  • Intesting debate....





    But as to answer the question of how ready Mono is (and what runs on it already) and running .NET apps on OSX....see my previous post.

  • Didn't notice this:





    >What effect does the 1.1 release of the framework have on Mono?





    None really. The 1.1 release was pretty limitted in functionality. The complete change list is over on gotdotnet somehwere. The 2.0 (or 1.2 or 1.5 or whatever they end up calling it) release may be another story though. The next version of .NET includes support for generics (think C++ templates) and a lot of cool stuff for data access and lots of ASP.NET enhancements. Miguel (the Ximian guy) says that the generics support is already written though, so they are at least anticipating some of the changes.


Comments have been disabled for this content.