Sean Fights Back

Sean (the Architecture "guru" from MM) doesn't agree with me about MX, but he doesn't seem to understand what I was saying, so I will try to explain a little better this time :-).

1. Why is Flash remoting bad?

Flash remoting isn't bad. It isn't like Macromedia made a horrible implementation. The problem is that remoting doesn't scale (you yourself point this out in your own article). .NET does not require me to use remoting. ASP.NET lets me keep all my logic on the same machine. But you say, HTML isn't a rich client? So? For most web apps, you don't need a full blown rich client. If you do, use WinForms.

2. Why is the CFC facade a bad thing?

Facades are generally used to accomplish two things:

a) make a system easier to use
b) decouple client implementations from the server

A CFC based facade that requires you to pass around name value pairs throughout your UI layer hardly accomplishes (a) or (b). All you have done is create a thin, non-functional layer over your nice OO system. And why did you do this? It wasn't for (a) or (b), it was for performance. Ok, fine. I can justify that, but what I can't justify is having to write a big facade layer every time I create an application. The very thought reeks of architecture maleficence. Solving all your latency issues on the server side is a pretty lame idea. If the client is doing the talking, the client should solve at least a few of the latency issues (it is a "rich" client...right?).

Why should I use an actionscript based facade? How 'bout so I can implement things like caching? How 'bout so I can use the object oriented priciples I was trained to use? How 'bout so I don't have to spend countless hours remembering what property is associated with what key? How many apps that you've helped design over at Macromedia pass all their data around the UI layer as one big associative array? I hope none. And why not? Because it is a stupid idea and anyone lame enough to design a system like that would be fired on the spot. Why then do you recommend that the clients using your product design their systems in such a fashion?

Additionally, by creating a rich object model on the client side (via actionscript), you can solve both (a) and (b). Let us take this contrived example:

class Person
{
  [property] string PhoneNumber;
}

in your name value pair collection, you would represent this with the key "PhoneNumber" linked to a string.

Now, what happens when you want to support multiple phone numbers? If you have a nice class structure, you just change the class like so:

class Person
{
   [property] PhoneNumberCollection PhoneNumbers;
}

Then, you take your implementation of PhoneNumber, mark as obsolete if you want, and make it point to PhoneNumbers.Primary. Walla! Now, if you were using fields, it becomes a bit more difficult to update your client side code. What choices do you have? Not many. You can add a phone numbers collection linked to a "PhoneNumbers" key. A key linked to a collection is shady business though, and you also have another problem. If someone changes the PhoneNumber value, the primary phone number in the collection is not updated, and vice versa, big sync problems emerge.

Take it a step futher, you need to implement security on top of the properties. Only certain people can set a the phone number property (say, only adminstrators). How do you ensure this if everything in an associative array? Well, you could just check on the submit to the server, but performance blows there and someone debugging their app doesn't find out until after it has been submitted, you should be able to warn them immediately. If you have a class based layer written in Actionscript, you can take appropriate actions to ensure that the call to the server is never made in the first place and that the developer knows exactly what caused the error.

Now, you might say, but that isn't a facade, it is a full object model! Who the hell said that your facade had to be a thin, non-functional, flattened view of your backend systems? How does that accomplish (a) or (b)? If anything, you could save yourself the trouble of having all those extra properties / objects on the server side and pass datasets back and forth to the client, which wraps their data in nice, easy to work with objects for you.

The main objection from most devs is really going to be, but that is going to take way too much actionscript to accomplish! Yes, they are right and that's exactly my point.

3. Isn't the point of .NET that I can use multiple languages in a solution?

No, the point of .NET is productivity. The fact that you can use multiple languages in a solution does not mean you should. In fact, it is a last choice solution, usually reserved for people first transitioning to .NET that don't have time to get there VB UI programmers and C++ guys all working in the same language and meet their deadline. Don't most UI guys know Javascript anyway? No. Web guys, probably (though I've seen a lot of incompetent web guys), but it isn't a requirement. Additionally, understanding javascript and being proficient in it are two completely different things. Can I use client side Javascript with .NET? Yes. Do I have to? No! Can I use client side javascript with Flash? Yes. Do I have to? Yes.

4. Isn't MX Studio just as integrated as VS.NET?

Lol. Give me a break. It is a heck of a lot more like the integration in Visual Studio 6. It is there, but only slightly. In VS.NET I never have to leave the IDE. If I want to add an event handler, just double click and it is added. If I want to do this in MX, I have to do quite a bit more work (click ui component, find event handler property, type in name of event handler, switch to actionscript editor and enter event handler name exactly as I entered it in flash, etc.). Is this difficult? No, but multiply by 100 and you have a time consuming load of repetition.

This isn't even to mention that ActionScript editing support in Flash is very poor, and that is why everyone serious uses .as files and third party editors outside of the IDE anyway. Can you imagine a .NET developer using VS.NET for the UI layer and jumping to sharpdevelop for their coding?

Sharing a .as file is hardly the equivalent of having a solution under source control with the aspx.cs files. I can step through the entire project line by line, in and out of layers, all from VS.NET. An AS file without the associated FLA is pretty useless for debugging.

"Our developers use Dreamweaver MX for pretty much all our code - both client and server - using Flash MX as the visual UI creation IDE and compiler. To me, that doesn't seem like "two entirely different IDEs" (since they share a look and feel and are well-integrated)."

LOL. I don't care what it "seems like," making two applications look the same hardly makes them integrated.

Now, if you want to talk IDE's, what about extensibility in the MX suite? Where is the System.ComponentModel? Where are the VSAs? Where are the UITypeEditors and ControlDesigners? Can't find them in MX? That is because they don't exist. What to extend design time dehavior for a control or add some functionality to the IDE. Good luck. First, you have to sell your sole away to Macromedia and then they will give you a crappy SDK that doesn't even compile and tell you to figure out how to use it (how do I know? because I've seen the SDK and witnessed it not compiling, and then crashing when it finally did compile). What about if you want to extend VS.NET? Just head over to MSDN and you can find a plethora of info without ever signing a licensing agreement or trying to get someone else's shody code to compile.

5. How does Actionscript promote spagetti code?

Well... let us see... why don't VB or C# have include statements? Why does MX? It isn't that you can't create relatively clean code inside of MX, but that it is a lot harder. For one, you have to leave the IDE and put your code in an .as file, this step alone leads to spagetti, because most people aren't going to use it, and those that do will have to hunt down all the include statements to find out where this code is actually getting run from.

6. But code behind requires you to be multi-lingual...

What are you talking about? For someone in charge of architecture at MM, you seem to know very little about your competition. The ASPX file is declarative, it doesn't contain code (and, if you embed code, it can be in C# or VB or whatever language you are using in your code behind file).

"How or why is that better than writing business logic in ColdFusion behind Flash's ActionScript front end?"

Because no one uses ColdFusion for serious development. But the cold fusion argument is a whole different topic now isn't it...

7. What are the limitations of flash?

Well...you asked for it....

a. Lack of true component based programming model (see: System.ComponentModel, System.ComponentModel.Design)
b. Lack of WebService support (see: WS-Extensions for Microsoft.NET)
c. Lack of XML suport (see: XPath, XSTL)
d. No declarative programming support (see: Attributes, ASPX templates, ASCX templates, HTML)
e. JavaScript is the most powerful language you can use in your UI layer
f. Javascript is the only language you can use in your UI layer
g. Lack of framework support (see: CLR, BCL)
h. Lack of standard support at the file format level (see: ISO, ECMA, vs. crappy non. compiling discontinued SWF SDK from Macromedia with very poor documentation)
i. Slow as molasses (see: Macromedia redesigns site with MX and ticks off their customers)
j. ByteCode format significantly lacking (zero support for class definitions, metadata, etc. at the bytecode level, see: SWF File Format Docs vs. CLI docs)
k. Lack of Enterprise level support (see: System.EnterpriseServices)
l. Lack of RAD tools
m. Macromedia doesn't listen to community (see: director of architecture ignores valid points about the limitations of Flash...or this article or this article by some people more involved in the Macromedia community).

Don't get me wrong, I think flash is a very cool tool, and I would love to use it in my projects! However, these are some of the reasons I can't use it as much as I would like to. When John Dowell (from MM support) notes that he can't tell me anything Macromedia is doing to solve these problems and Mr. Corfield ("the director of Architecture at Macromedia") tells me they aren't real problems at all, I get the feeling that I won't ever be using flash for any serious development... very sad feeling, since I would very much like to use it. Oh, well... I guess I will just wait on SVG instead :-).

23 Comments

  • I find it interesting that you don't understand what Sean is asking. Let's look at some of your counterpoints:


    1. Flash Remoting doesn't scale.


    I don't know what your basis is for this statement. You do not provide any backup information for your comment. Flash Remoting scales quite nicely, especially, from the standpoint that less data has to travel across the network.





    On the server end, Flash Remoting is built into CFMX and JRUN, both scale tremendously since the also run on Unix based servers and J2EE servers (both Windows and Unix). Also, J2EE Servers cluster a lot better. So, one can take their pick of high end, multi-processor servers (a whole lot bigger than anything Windows runs on), or high-end clustering solutions from IBM, BEA, and others. I guess the problem is you don't define what scale means.





    2. Facade/CFC's


    CFC's reside on the server, not in the FLASH client. My guess is you do not understand Cold Fusion MX, and therefore, assume this is something to do with Flash. It isn't. A CFC can be a web service, fully compliant with the Web Services spec. A .NET web application could call a CFC, in addition to Flash Client Applications, and Server based web pages (CF Invoke method). Further, since CFMX is servlet based, CFC's are compiled once and reside in memory to be called by whatever page or remote client requests the CFC's methods. They are the object layer between the presentation layer and the database layer.


    3. Multiple Languages


    I don't know what you have been reading, but this is one of the features heavily promoted by Microsoft.





    4. Studio MX as Integrated as VS.NET


    I don't think Sean stated it this way. I would compare Studio MX integration along the lines of MS Office's integration. You can combine objects created in each and they share common interface, but each application has its own purpose (much like Powerpoint's purpose is a lot different that Excel

  • Jesse,


    The system you are using cut off the rest of my previous post. Not sure if this is a bug or intended. I won't bother with the rest of the post. The system should state something about total word count allowed. Other blog systems allow for preview of the post prior to posting. This would be a nice feature.


    Cheers,


    TC

  • Where would be the fun if we agreed on everything?

  • TC,





    1. Ok, maybe I should say remoting is very inefficient to be a little more clear. You can scale just about anything if you add enough hardware :-). The problem is that every time you make a remote call you get a bit performance hit, so the more calls you make, the slower your system. We aren't talking about small in-proc performance hits or even the larger out of proc penalties, these are full blown as bad as you can get remote call performance hits. It doesn't matter whether you are using WebServices, Remoting, etc. the father out of proc you are the bigger the hit. With ASP.NET you aren't required to go out of proc. Admittedly, on a rich client you will have to go out of proc every once and a while, but the key is minimizing this. Sean and I agree on this.





    2. The same goes for the facade, it doesn't matter what technology you are using to make the facade (.NET, J2EE, CFC, etc.), if you are passing name value pairs around in your client you have big problems from a usability and matinence standpoint. You get spagettiti code very quickly. In any case, remember that the key reason to create the facade was performance and the only way you can really get performance gains is to eliminate calls to the server. I don't care if you are using X#, C#, Java, or CFCs. you are going to get hit hard and a facade with proper caching on the client side is the best way to eliminate a lot of these calls.





    3. Yes, Microsoft touts the fact that you can use any language you want. And this is a good thing, but find me one article that says it is preferable to use multiple languages in a single solution apart from the reason I have already mentioned.





    4. I understand completely how the integration works, I am just saying that the VS.NET solution is a better one. Speaking of Office, Visual Studio Tools for Office let you do all your office programming from VS.NET too :-P. Let's try doing cut and paste of OLE data from Office to your Fl

  • (cont.) Flash rich client... it ain't happening.

  • Hmmm, .Net framework 23mb download, Flash plugin less than 400kb.

  • LOL. That is why I like Flash so much (actually, that is why everyone likes flash so much)! Still, bandwidth is less and less of an issue every day. With a decent connection, 23 megs is pretty small.

  • Where do I download .NET Framework for Mac OS X? Or Linux? I tried to download it and was redirected to the windowsupdate website. Flash Player works on those platforms... :)

  • "there is absolutely no reason why you can't build a facade in ActionScript that talks to the facade on the Server."





    I agree wholeheartedly. In fact, I almost posted this to keep from being misunderstood, but then I realized that creating two facades is definately a waste of time :-). If you knew your architecture was always going to involve a facade on the client end, then why worry about having a really rich OO model on the server only to hide in and then re-expose it (even Sean pointed out that it didn't make much sense to do that).





    So, since the main point of creating a facade is generally to make systems easier to use, one on the client side (like a PIA) would make much more sense than one on the server side, because you can give it a lot more useful functionality on the client side than you can on the server side (yes, you always need parallels on the server side, but, again, we are trying to reduce the number of calls we make to the server).





    Since the point of the facade here was actually to improve performance, not make the app easier to use, a client side facade makes a lot more sense because of things like caching that, by their very nature, you can't implement server side.





    Also, I didn't even break open this can, but in a rich client you will most likely need some offline/disconnected functionality. In that case you really need some client side functionality, and if you plan on extending your app to support offline use, remoting ain't going to do jack for you. If you have already started a client side facade with caching, etc. extending this to support occasionally connected computing shouldn't be too difficult.

  • "If you knew your architecture was always going to involve a facade on the client end, then why worry about having a really rich OO model on the server only to hide in and then re-expose it"





    All client server applications suffer from problems of latency sooner or later.





    In general, you don't want to have to worry about the network latency when you are writing the methods for the objects in your model.





    In order to abstract the network latency problem out of these objects you might build an object that takes incoming client requests and passes them on to the relevant parts of the application. This object is designed to minimize the number of calls that must be made between server and client.





    If you take a step back and have a look at this object, it looks remarkably like a facade:


    It provides a unified interface to a set of interfaces in a subsystem.


    It decouples the subsystem from it's clients.


    It provides an interface to a software layer.


    It shields clients from subsystem components, making the subsystem easier to use.


    It promotes weak coupling between the subsystem and it’s clients.





    Additionally, I'm not convinced that creating a facade in ActionScript is the only or best solution to building caching, following object oriented principles, or any of the other justifications that you gave. It may be that it is, but I can still see a lot of good reasons to use one on the server.

  • Spike,





    For a simple project, you are right, you can get away with a thin facade on the server side. However, let us say (for example) that you were building a framework like Central. Regardless of how the server side code is layed out, you are going to have to do quite a bit of Javascript coding if you want your framework to be usable by flash developers and enable maximum productivity. There is no way around it. In any case, the whole facade thing was just a side note, I never intended it to become the focus of the discussion. The discussion was about why a pure .NET solution is superior, not whether a client side facade or server side facade would be a better solution to the latency issue. Like I said, I would rather not create the facade in the first place.





    Matty,





    I never said flash couldn't handle XML. I said it can't handle XPath or XSLT (which it can't). XML support in flash has always been very limitted.





    Additionally, I never said flash could not integrate with WebServices, I said that it can't work with the WS-* stack (which it can't).





    Yes, you can work offline and have information saved with .NET apps very easily. The data access model in .NET is designed to support disconnected architectures. Central will supposedly have some features to address this, but Central is not out yet.

  • 1. "With a decent connection, 23 megs is pretty small. "





    LOL. you've got to be kidding me. 23 mb is not small. period.





    2. "For one, you have to leave the IDE and put your code in an .as file, this step alone leads to spagetti,"





    ummm, what are you talking about? Putting your code in a .as file leads to spaghetti? Thats a reach. In fact, just the opposite is true. Separating functionality increases encapsulation and promotes better oo practices.








    3. "a. Lack of true component based programming model





    false. reusable components are a fundamental building block of flash mx.








    c. Lack of XML suport





    simply an incorrect and uninformed statement. Actionscript XML object is very powerful, as is XMLSocket








    e. JavaScript is the most powerful language you can use in your UI layer





    false. Javascript leads to bloat as multiple solutions are required for different browser implementations.








    h. Lack of standard support at the file format level





    ActionScript is more ECMA compliant than any current implementation of Javascript. Don't even get me started about that sh*t wagon you guys call IE :)








    l. Lack of RAD tools





    ???? Flash Authoring Environment? Ever heard of it?








    3. "you seem to know very little about your competition"





    yeah. right. Fella, look in the mirror :)












  • 1. LOL. you've got to be kidding me. 23 mb is not small. period.





    I guess you don't have a decent connection? :-). Seeing that I download 700 MB ISOs from Microsoft just about every month without blinking twice, 23 MB is pretty small.





    2. ummm, what are you talking about? Putting your code in a .as file leads to spaghetti? Thats a reach. In fact, just the opposite is true. Separating functionality increases encapsulation and promotes better oo practices.





    No, the fact that you have to leave the IDE leads to spagetti.





    3. "a. Lack of true component based programming model





    LOL. Once again, go on MSDN and take a look at the System.ComponentModel namespace. We aren't even in the same league here.





    c. simply an incorrect and uninformed statement. Actionscript XML object is very powerful, as is XMLSocket





    If your idea of powerful XML support doesn't include XPath or XSLT, it is no wonder you disagree here.





    e. false. Javascript leads to bloat as multiple solutions are required for different browser implementations.





    What are you trying to say? ActionScript = JavaScript. They are based off the sames specs (ECMAScript).





    h. ActionScript is more ECMA compliant than any current implementation of Javascript. Don't even get me started about that sh*t wagon you guys call IE :)





    I'm talking about published file format specs here. Download the SWF File Format specs and work with them for a few months (like I did), then you will know what I am talking about.





    l. ???? Flash Authoring Environment? Ever heard of it?





    I don't think anyone at MM would even classify Flash as a RAD tool yet. RAD means rapid application development, think VB (drag and drop and you have an app).

  • Yah, the FireFly stuff is definately cool for toy apps and banner ads. Still quite a ways to go to be anywhere near as flexible as ADO.NET or be useful enough to use in many real world applications. For example, what about transaction support etc.? This is especially important if you are going to be working with next gen webservices supporting WS-Transaction. You will need support for both compensating and non-compensating transactions... either of which are going to be a pain to work with without structured exception handling (add that to the list of missing flash features).





    I do see XPath expressions mentioned in there though... is this new to FireFly? Full XPath, or just a subset?

  • Just as TC, my comment got cut. Fortunately one line got cut only: "XPath or XSLT support should concern server-side languages such as CFM, PHP or .NET".





    It's interesting that you preach "best-practices" and you do not even validate the only form available in your blog.

  • Drag and drog my projects and I'll fire you.

  • Sorry, I didn't write the blog engine :-).





    There are many reasons why Flash should support at least XPath. Xslt would be a bit harder, because there is no equivalent XML for flash (like SVG). But, xslt would still be hella useful. One example is for creating flash based charting tool. XSLT could make creating graphs a snap, no coding, just run an XSLT transform and you have your graphic.





    In any case, I've heard a lot of arguing from the Flash guys about why I am wrong, but no one has really made a good case for why flash is a truely a better tool (again, the size argument and the "everyone has it" argument are not valid discussion points, they have little, if anything, to do with the technology itself).

  • >(again, the size argument and the "everyone has it" argument are not valid discussion points, they have little, if anything, to do with the technology itself).





    Wow, really? Where have I been? From now on all my RIAs are going to be full-immersion 3D worlds designed in and exported from Blender. Sure the downloads will be huge and the plugin penetration is about .05%, but the technology is top-notch. ;)


  • "The discussion was about why a pure .NET solution is superior..."





    You're arguing about whether all houses should be build using a hammer (ASP.NET) or a saw (Flash+Remoting). However, the best Software Engineers recognize that it's not about which tool is "superior", but about which is most appropriate for each individual project or sub-project based on the user problem or problems being solved.

  • That is exactly right. Flash and .NET are not equivalent technologies. None is better than the other as there are things you can do on one that you cannot do on the other and vice versa. Stating that Flash is "inferior" just because "it cannot do XPath" is an uninformed and unscientific statement. There are a few things .NET alone cannot do. Maybe a perfomance comparison would be approriate but that is a completely different issue. Let us not go back to the PetMarket/Shop/Store discussion.

  • "Sorry, I didn't write the blog engine :-). "





    Too bad the "Your-own-dot-Net-blog" button didn't have validation. I bet you had it up in no time. I just wish the "E-commerce-site-in-five-minutes" button does have one.

  • Jesse,





    You should look at an impartial view of RIA from IDC and see its business and technical uses. I don't think you understand the difference between html/js/css/dhtml and the x-internet. Remember .Net, like J2EE builds only html/js/dhtml for the browser. HTML is only good for document displaying, not applications.








    Take a look at MM site (home page - right hand side.)





  • One should ask themselves, is it truly the tool that does not have the functionality or my ability with the tool (platform) that stops me from crafting the solution.

Comments have been disabled for this content.