Discussions

News: Why I might not want to use Flex - A second opinion

  1. While waiting for my eclipse to shut down, because the Flex Builder plugin again made it crash, I decided to write a little about my Flex experience. I’m now on the finish straight of a small-to-medium project which uses Flex as a front-end. On first sight Flex is smooth and pleasant to work with. You draw a bunch of beautiful components, write three lines of actionscript, and here’s is our nice “advanced hello”. But whenever one gets more into the details, the immaturity of Flex (and ActionScript) is too visible, alas. See the full article here

    Threaded Messages (56)

  2. Again[ Go to top ]

    see the discussion at http://www.theserverside.com/news/thread.tss?thread_id=51979
  3. To me, there are at least two very good reasons to avoid Flex: 1. Even though it may be OpenSource, Flex is and will probably remain entirelly based on non-standard, proprietary, single-vendor controlled runtimes, APIs, languages and communication protocols. Compare it to GWT, which is all based on open standards from the W3C (HTML, DOM, CSS), ECMA (ECMAScript/JavaScript), and JCP (Java), and whose runtime environment (the web browser) is provided by multiple competing vendors. 2. Developers of Flex applications necessarily will use two major programming languages, ActionScript for the client side and Java/C#/PHP... for the server side, which inherently is less productive and more costly than using a single language for both sides, as GWT allows.
  4. Developers of Flex applications necessarily will use two major programming languages, ActionScript for the client side and Java/C#/PHP... for the server side, which inherently is less productive and more costly than using a single language for both sides, as GWT allows.
    I am not sure it's possible to create a user interface of the quality provided by Flex by means of tools like GWT and other text/jscript crunchers. It's just too clumsy to create nice GUI with HTML. Forms, blogs, web email client - fine for HTML. But what if I need something more complex than that? A nice looking chart for example. Client run time for rendering UI is a good idea and large companies have finally realized that. Also, I am not sure there is one language that fits all tasks. Sure, it would be nice to write everything by means of POJO's. But it's a wishful thinking :)
  5. I am not sure it's possible to create a user interface of the quality provided by Flex by means of tools like GWT and other text/jscript crunchers. It's just too clumsy to create nice GUI with HTML. Forms, blogs, web email client - fine for HTML. But what if I need something more complex than that? A nice looking chart for example. Client run time for rendering UI is a good idea and large companies have finally realized that. Also, I am not sure there is one language that fits all tasks. Sure, it would be nice to write everything by means of POJO's. But it's a wishful thinking :)
    Maybe there are things which Flash+Flex does and browsers+GWT still can't do, but my experience has been that modern browsers are VERY capable, and GWT exposes this power in very convenient ways. Although you can easily access HTML and JavaScript directly in a GWT based app, the fact is that you almost never will have to do so. An interactive chart, for example, can be easily programmed using the GWT Canvas API (vector graphics), which works greatly in the major browsers. I actually am currently developing a personal project which uses it, along with the Google Gears embedded database, and the results have been fantastic 8^)
  6. capable browsers?[ Go to top ]

    I am not sure it's possible to create a user interface of the quality provided by Flex by means of tools like GWT and other text/jscript crunchers. It's just too clumsy to create nice GUI with HTML. Forms, blogs, web email client - fine for HTML. But what if I need something more complex than that? A nice looking chart for example. Client run time for rendering UI is a good idea and large companies have finally realized that. Also, I am not sure there is one language that fits all tasks. Sure, it would be nice to write everything by means of POJO's. But it's a wishful thinking :)

    Maybe there are things which Flash+Flex does and browsers+GWT still can't do, but my experience has been that modern browsers are VERY capable, and GWT exposes this power in very convenient ways. Although you can easily access HTML and JavaScript directly in a GWT based app, the fact is that you almost never will have to do so. An interactive chart, for example, can be easily programmed using the GWT Canvas API (vector graphics), which works greatly in the major browsers. I actually am currently developing a personal project which uses it, along with the Google Gears embedded database, and the results have been fantastic 8^)
    Capable browsers? Hm.. my experience tells me that supporting all these "capable" browsers usually costs rediculous amount of money, effort and patience. Why suffer? I think that creating rich user experience by means of text rendering is silly. Look at these ajax technologies and frameworks flooded the market.. there are billions of them, and what are they all trying to do? A windowing experience in the runtime (browser) which is originally designed for paging through text. It's like riding horse to the moon when you actually need a space ship. Shure, horse riders are having a good time.. But what about the user? Why do I need this complex and clumsy server side view rendering while all we actually need is a runtime to do the proper GUI - platform neutral, fast, simple with proper programming language, IDE and tooling. We have JVM on server side.. Why not having same "GUI VM" on client side as well? Big players realized this already, today there are products from microsoft, sun, adobe and open source as well.. It's just that Flex happened to be ahead of everyone on this new concept..
  7. Flex is not Java[ Go to top ]

    2. Developers of Flex applications necessarily will use two major programming languages, ActionScript for the client side and Java/C#/PHP... for the server side, which inherently is less productive and more costly than using a single language for both sides, as GWT allows.
    First, Flex is *not* Java. I see the same complaints from Java developers getting their feet wet in Javascript. These platforms are, simply put, not the same - you need to learn how things are done, how to let the language/platform do the work for you. Second, Flex developers 'need two languages', but so do Ajax/JSF/JavaFX/whatever developers - heck, even more: You need to learn the CSS, Javascript, HTML languages in addition to the server-side language. In fact, a Java web project already uses multiple languages: Java, Spring XML, JSF, JSTL, Hibernate mapping XML etc. Don't tell me these don't count, because these languages do need to be programmed for your software to work.
  8. Re: Flex is not Java[ Go to top ]

    2. Developers of Flex applications necessarily will use two major programming languages, ActionScript for the client side and Java/C#/PHP... for the server side, which inherently is less productive and more costly than using a single language for both sides, as GWT allows.
    First, Flex is *not* Java. I see the same complaints from Java developers getting their feet wet in Javascript. These platforms are, simply put, not the same - you need to learn how things are done, how to let the language/platform do the work for you.
    Exactly, and that's why as (mainly) a Java developer, I choose the GWT SDK for developing a RIA app. Toolkits for developing RIAs are in fact quite similar, at least based on what I know from GWT and Flex.

    Second, Flex developers 'need two languages', but so do Ajax/JSF/JavaFX/whatever developers - heck, even more: You need to learn the CSS, Javascript, HTML languages in addition to the server-side language. In fact, a Java web project already uses multiple languages: Java, Spring XML, JSF, JSTL, Hibernate mapping XML etc. Don't tell me these don't count, because these languages do need to be programmed for your software to work.
    Sure, for the conventional Java web framework (Struts, JSF, Wicket, Seam, etc), developers need to constantly switch between Java, JavaScript and HTML, at the very least. But not so with GWT: I have been implementing the UI layer for new business use cases in GWT, as well as converting old ones from Struts+JSP to GWT, and from this experience I can assure you, almost all work is performed on plain Java code.
  9. Well, but ...[ Go to top ]

    To me, there are at least two very good reasons to avoid Flex:

    1. Even though it may be OpenSource, Flex is and will probably remain entirelly based on non-standard, proprietary, single-vendor controlled runtimes, APIs, languages and communication protocols. Compare it to GWT, which is all based on open standards from the W3C (HTML, DOM, CSS), ECMA (ECMAScript/JavaScript), and JCP (Java), and whose runtime environment (the web browser) is provided by multiple competing vendors.

    2. Developers of Flex applications necessarily will use two major programming languages, ActionScript for the client side and Java/C#/PHP... for the server side, which inherently is less productive and more costly than using a single language for both sides, as GWT allows.
    Flex is indeed proprietary technology. However, I think that GWT is, after all, called "Google" Web Toolkit for a reason. It seems to me that Google will control what happens to GWT on their schedule and according to their priorities. Also, for a large organization like mine, using proprietary software backed by a large organization is a good thing. So there are pros and cons depending on what you need ... Your point about learning yet another language is well taken, in my view, especially in the context of our existing business. In my experience we do not want to use Flex for all Web applications. That means that we need to retain knowledge of JavaScript/CSS/HTML/Java/C# and add to that ActionScript ... which is a cost. It takes longer to learn the Flex way of doing things than to learn the GWT way of doing things as well. In the end though I guess this boils down to comparing the benefits you receive ... some of our users, and especially our higher-level users, really like the look and feel of the Flex apps we have developed.
  10. GWT[ Go to top ]

    GWT is even less proprietary than Java itself is, so this should not be an issue. Before I started using Flex I had exactly the ideas mentioned above - proprietary, non-standard, using plugin, a different language, etc. But these are things that one can not use as firm cons. I like to use as cons concrete examples of something not working, or working in a bad way. I've used Flex, GWT and Echo2. The latter 2 have much prettier architectural design (not UI design, alas). Flex, on the other hand, has pretty design and, as expressed in my post, some very ugly things to workaround. I've even forgotten to mention drag n' drop there.
  11. 1. Even though it may be OpenSource, Flex is and will probably remain entirelly based on non-standard, proprietary, single-vendor controlled runtimes, APIs, languages and communication protocols. Compare it to GWT, which is all based on open standards from the W3C (HTML, DOM, CSS), ECMA (ECMAScript/JavaScript), and JCP (Java), and whose runtime environment (the web browser) is provided by multiple competing vendors.
    Then use OpenLaszlo so that you can target Flash or DHTML, as you please. Is it perfect? No and neither are any of the other technologies that are currently available. Does it work? Sure it does. I have an app that I can deploy in either runtime and they look incredibly alike. And it's not "Hello World", either. It's a full blown business app that does real work from the typical CRUD to the application targeted functionality using all the niceties of a real, rich UI with AJAX interactions with the server. (yeah, it's buzzword compliant, too). In addition, I can take the SWF, wrap it with an AutoIt3 script, build an installer with the NullSoft Installer, and run it as a standalone desktop app. No code changes. So, using the Flash runtime is a good option especially if you use the right tool to let you target other deployment platforms.
  12. Interested[ Go to top ]

    I was interested in OpenLazslo about a year ago and took a short look ... I thought I saw that they had no IDE for GUI building and moved on. Can you tell us if that community has come up with an IDE comparable to the FlexBuilder (comparable in the sense that they have a WYSIWYG GUI builder) yet? There's no way I can sell OpenLazslo in my (large) shop if without that ...
  13. OpenLaszlo[ Go to top ]

    I was interested in OpenLazslo about a year ago and took a short look ... I thought I saw that they had no IDE for GUI building and moved on. Can you tell us if that community has come up with an IDE comparable to the FlexBuilder (comparable in the sense that they have a WYSIWYG GUI builder) yet? There's no way I can sell OpenLazslo in my (large) shop if without that ...
    I've learned OL about a year ago, when i had to develop a medium project with a rich and appealing interface (it was to be used to collect data for a report about eating habits). At least i've choosed OL for front end (Spring MVC + Hibernate in the back end). In the first time OL were a little bit difficult because it had no ide. But it enabled me to look and learn it in the deep. At least i've loved it, for clean separation about biz logic and presentation layer, for power of the graphic routines, for extendibility and customizability, for to delegate entire UI functionality to browsers and simple xml interaction with back end (Web Service/JSon/Jsp/Servlet/Mvc....etc.) Now it has also a open source ide (u can link it from Ol site). I've not tried it yet. This my 2 cent about OL. Sandro
  14. Re: OpenLaszlo[ Go to top ]

    I was interested in OpenLazslo about a year ago and took a short look ... I thought I saw that they had no IDE for GUI building and moved on. Can you tell us if that community has come up with an IDE comparable to the FlexBuilder (comparable in the sense that they have a WYSIWYG GUI builder) yet? There's no way I can sell OpenLazslo in my (large) shop if without that ...


    I've learned OL about a year ago, when i had to develop a medium project with a rich and appealing interface (it was to be used to collect data for a report about eating habits).
    At least i've choosed OL for front end (Spring MVC + Hibernate in the back end).
    In the first time OL were a little bit difficult because it had no ide. But it enabled me to look and learn it in the deep.
    At least i've loved it, for clean separation about biz logic and presentation layer, for power of the graphic routines, for extendibility and customizability, for to delegate entire UI functionality to browsers and simple xml interaction with back end (Web Service/JSon/Jsp/Servlet/Mvc....etc.)
    Now it has also a open source ide (u can link it from Ol site). I've not tried it yet.

    This my 2 cent about OL.

    Sandro
    Thansk Sandro! I'll revisit the OL site. By the way, for this project where you used OL - how did you choose OpenLazslo over Flex? Or did you have the ability to make a choice?
  15. Large applications? SilverLight?[ Go to top ]

    One thing I don't know much about is how well the Flex way of doing things might apply to a large Web application - a big shopping site, for instance, with the kind of traffic you see around this time of year. Anyone know where information is available about the scalability and architecture of this kind of application using Flex? (Of course I mean real information, not marketing literature.) Secondly ... when Microsoft makes SilverLight ready for professional use, what do you think will happen? My feeling is that SilverLight will displace Flex, very quickly - in 2-3 years. This consideration makes me wonder about choosing Flex in the long term ... but maybe I'm wrong. ( No, I'm not a Microsoft employee :-) )
  16. when Microsoft makes SilverLight ready for professional use, what do you think will happen? My feeling is that SilverLight will displace Flex, very quickly - in 2-3 years. This consideration makes me wonder about choosing Flex in the long term ... but maybe I'm wrong. ( No, I'm not a Microsoft employee :-) )
    Then maybe we will have a ready-to-use JavaFX, which will be an even better choice. But that's not what we're about to see in the very near future.
  17. Java FX - no, we will not see that in the near future - or at any time, in my opinion. However, Java FX, in my view, would not be important - I think SilverLight would easily and quickly displace that as well. Having Sun's marketing people fight with Microsoft's is like sending a three-toed sloth out to fight a wolverine ;-) I expect to see a professional version of SilverLight in 2009.
  18. Re: Large applications? SilverLight?[ Go to top ]

    Java FX - no, we will not see that in the near future - or at any time, in my opinion.
    Yes. Within days.
    However, Java FX, in my view, would not be important -
    For Java developers it is. It means I can use the same code on the server AND the client.
    I think SilverLight would easily and quickly displace that as well.
    I have looked at it already. To talk to server-side java is just as "fun" as a regular .Net client. See the above comment. Flex is much better in this regard. Not as good as pure Java though.
    I expect to see a professional version of SilverLight in 2009.
    What do you consider "professional".
  19. Re: Large applications? SilverLight?[ Go to top ]

    Java FX - no, we will not see that in the near future - or at any time, in my opinion.

    Yes. Within days.
    Well, sure ... but we have heard that before ... and it has to be useful -not simply 'released'.
    However, Java FX, in my view, would not be important -

    For Java developers it is. It means I can use the same code on the server AND the client.


    I think SilverLight would easily and quickly displace that as well.

    I have looked at it already. To talk to server-side java is just as "fun" as a regular .Net client. See the above comment. Flex is much better in this regard. Not as good as pure Java though.

    Beg pardon - my view has nothing to do with the technology - probably I should have made that explicit. I don't think the tech will necessarily be better. I expect SilverLight to dominate because of the domination of the Microsoft browser and superior Microsoft marketing skills. I believe that Microsoft will be able to sell their GUI browser plugin tech better than all competitors combined.
    I expect to see a professional version of SilverLight in 2009.
    What do you consider "professional".
    For me, this means that arbitrary point at which the number of defects in a product is low enough that the majority of the business world begins to use the product in production. I'm never sure how businesses make this decision. It's a famous joke that Microsoft typically gets this done in version 3 of a product ;-)
  20. Re: Large applications? SilverLight?[ Go to top ]

    Well, sure ... but we have heard that before ... and it has to be useful -not simply 'released'.
    True. Guess we will have to see.
    I think SilverLight would easily and quickly displace that as well.
    It can't. While C# is VERY much like Java, it isn't. It can't talk via serialized objects to Java. And no matter what, code will have to be duplicated. I am speaking from experience. I've done Microsoft technologies since VB3.
    I expect SilverLight to dominate because of the domination of the Microsoft browser and superior Microsoft marketing skills.
    If this were true, then .Net would dominate. It doesn't. Silverlight will only affect those who are "Microsoft shops" and currently doing Flex. There will be some others too, but that will be few. I've looked at Silverlight already in this light (Java on the back) and as soon as I saw how I would have to communicate to Java ... it was a non-starter compared to the "ease" of Flex and the ease of JavaFX. If you have used Spring Remoting you will know how ridiculously easy this is with Java on the client and Java on the server.
    For me, this means that arbitrary point at which the number of defects in a product is low enough that the majority of the business world begins to use the product in production.
    That won't make any difference in the numbers. Those moving Silverlight are doing so because it is Microsoft and since they do VB.Net or C# is just fits.
  21. Re: Large applications? SilverLight?[ Go to top ]

    If this were true, then .Net would dominate. It doesn't. Silverlight will only affect those who are "Microsoft shops" and currently doing Flex. There will be some others too, but that will be few.
    Well, .NET only runs on Windows, but Silverlight will run in as many browsers as Flex/Java FX. IMHO, if M$ supports the full .NET (exccpt Winform/WPF, of course) on Unix/Linux, .NET would have dominated a few years ago.
  22. Re: Large applications? SilverLight?[ Go to top ]

    .NET only runs on Windows,
    Actually ...
    IMHO, if M$ supports the full .NET (exccpt Winform/WPF, of course) on Unix/Linux, .NET would have dominated a few years ago.
    We will never know. But IMHO and IMHE, they would not have. Been there, done Microsoft technologies.
  23. Re: Large applications? SilverLight?[ Go to top ]


    IMHO, if M$ supports the full .NET (exccpt Winform/WPF, of course) on Unix/Linux, .NET would have dominated a few years ago.

    We will never know. But IMHO and IMHE, they would not have. Been there, done Microsoft technologies.
    Then you would know VB4/5/6 once dominated on the client. Given that .NET is the best technology from Microsoft so far, if Microsoft supports the full .NET (minus Winform/WPF) on Unix/Linux, .NET might as well have dominated on the server. Yes, we will never know. At the end of the day, supporting .NET on Unix/Linux does not help Microsoft sell Windows.
  24. Re: Large applications? SilverLight?[ Go to top ]

    Then you would know VB4/5/6 once dominated on the client.
    If you discount C/C++. And DBase. And Delphi. And Powerbuilder.
    Given that .NET is the best technology from Microsoft so far,
    Yes. But VS.Net still suffers from the Visual Studio mindset.
    if Microsoft supports the full .NET (minus Winform/WPF) on Unix/Linux, .NET might as well have dominated on the server.
    Possible but highly unlikely. I would rather do Java even if my platform is only Windows.
    At the end of the day, supporting .NET on Unix/Linux does not help Microsoft sell Windows.
    Yup.
  25. Re: Large applications? SilverLight?[ Go to top ]

    Then you would know VB4/5/6 once dominated on the client.

    If you discount C/C++. And DBase. And Delphi. And Powerbuilder.
    Hey, this is the possible scenario we are talking about, i.e. Silverlight achieves a similar market share to what VB4/5/6 used to enjoy, in the post-HTML era.
  26. Re: Large applications? SilverLight?[ Go to top ]

    Then you would know VB4/5/6 once dominated on the client.

    If you discount C/C++. And DBase. And Delphi. And Powerbuilder.


    Hey, this is the possible scenario we are talking about, i.e. Silverlight achieves a similar market share to what VB4/5/6 used to enjoy, in the post-HTML era.
    That is what I said. Microsoft shops running only on Windows using only Microsoft technologies. Heck, if I was a Microsoft only person, I would be moving to Silverlight like yesterday. That way I can have my back-end AND front-end in C#. The only downside is the client/server communication. But having both sides in the same technology makes it pretty easy. And THAT is the reason JavaFX is important to the Java platform.
  27. Re: Large applications? SilverLight?[ Go to top ]

    Then you would know VB4/5/6 once dominated on the client.

    If you discount C/C++. And DBase. And Delphi. And Powerbuilder.


    Hey, this is the possible scenario we are talking about, i.e. Silverlight achieves a similar market share to what VB4/5/6 used to enjoy, in the post-HTML era.
    That is what I said. Microsoft shops running only on Windows using only Microsoft technologies. Heck, if I was a Microsoft only person, I would be moving to Silverlight like yesterday. That way I can have my back-end AND front-end in C#. The only downside is the client/server communication. But having both sides in the same technology makes it pretty easy. And THAT is the reason JavaFX is important to the Java platform.
    The beauty of technologies such as Flex or Silverlight is that they are server neutral. JavaFX? I am not sure.
  28. Re: Large applications? SilverLight?[ Go to top ]

    The beauty of technologies such as Flex or Silverlight is that they are server neutral.

    JavaFX? I am not sure.
    Uh, why not? Java can talk to any server type. JavaFX is Java.
  29. To me Flex should be very lightweight, basically using HTTPService or URLStream to pass off calls to a service which does all of the heavy backend lifting and simply binds controls to the response data. The backend can be written in Java, Ruby, .NET, FDS, whatever. That is where the scaling issues should be dealt with. In fact there are several books, "Flexible Rails", "Flexible Java", etc. that discuss this. There should NEVER be any business logic contained in Flex code. Flex is just another way of rendering data in a browser, and should be looked as an alternative to Javascript-based solutions like Scriptaculous or Dojo.
  30. Of course no business logic on the client. But there is always that "presentation logic", which in my case was quite big. And in RIA's presentation logic tends to be a little more than just binding.
  31. Re: Large applications? SilverLight?[ Go to top ]

    Of course no business logic on the client. But there is always that "presentation logic", which in my case was quite big. And in RIA's presentation logic tends to be a little more than just binding.
    Which is typically "business logic". This is why having the same language on all tiers makes tons of sense. I can share logic without duplication. With Flex, I even have to duplicate object structures.
  32. Flex or GWT[ Go to top ]

    I like to reduce the complexity of the technology stack that I am using. I am not going to debate the tech stack on the server, since we do need something there. I like something like Spring and JPA. This is enough in my view to build a working application without the interface. Then comes the hard part. Choosing the interface. You can go two ways in my opinion. 1. The old style way. Use HTML/CSS/JS/Ajax AND some serverside framework to support this all (JSF, struts etc...). 2. Go Flex/JavaFX/Silverlight. Bear in mind I am developing an APPLICATION. I think option 2 is better just because of the technology reduction it comes with. You could argue that I need CSS, But I do not. I am developing an application, not some flashy site. MS Word is not all about cool widgets and stuff, but provides all you need to do your work as should my application. Furthermore I do not like to epend on a shaky foundation for my application. Since there is no unified browser, but all kinds for which you have to write specific supporting code, no sane developer would in his right mind code for such a unstable platform. Coding the backend in minutes, and coding the frontend in weeks is no exception here because of the low quality of this platform. I use the best of the web, TCPIP/UPD, and ignore the rest. This is truly what is the web, not the browser. The browser is just a very basic application to show content. Kind regards, Marc
  33. I agree that these are good general guidelines and considerations. In the case of Flex and its supporting technologies there are additional specific considerations: the performance of the data exchange with the browser plugin, the efficiency of its data transformation from input stream to UI (whether we're sending in XML or ?), whether AMX offers anything, that sort of thing ... I guess what I'm really wondering is whether anyone has any experience actually building and maintaining large-scale Web applications using Flex. I'm assuming not much changes from any other technology, but real hands-on experience is always necessary to avoid problems.
  34. In the case of Flex and its supporting technologies there are additional specific considerations: the performance of the data exchange with the browser plugin, the efficiency of its data transformation from input stream to UI (whether we're sending in XML or ?), whether AMX offers anything, that sort of thing ...

    I guess what I'm really wondering is whether anyone has any experience actually building and maintaining large-scale Web applications using Flex. I'm assuming not much changes from any other technology, but real hands-on experience is always necessary to avoid problems.
    I have real world experience with Flex and Echo2. Evaluated GWT before choosing Flex. Echo2 is completely server side, Echo3 has a pure js version so things should be better from a scalability perspective. Any JS based solution has some serious performance issues with rendering large tables due to browser DOM performance, not necessarily the framework. Flex or for that matter any RIA technology which leverages client processing power, provides better server scalability as the load is shared between client and server. We do not use pagination, sometimes send as much as 1000 records to the client (using mod-gzip of Apache it comes down to 8K, all XML data) and server response is typically 10-20ms (milliseconds). Client is equally fast as Flex datagrids render only the set of records that are visible, typically 20 or so even though the underlying table has 1000 records. Flex apps are built as an application and not pages so a lot of data once retrieved can be stored on the client, it reduces server calls. All this makes our tomcat server run under 64 MB RAM as it has become a pure business processing server, similar to a web service. You can read more of my take on RIA technologies, especially Flex at http://sunilabinash.vox.com/library/post/is-flex-yet-another-mvc-framework.html Thanks Sunil n Abinash http://sunilabinash.vox.com
  35. The three are suited only for some typical application only. One can't really convert an entire website using any of these. You would still need DHTML stuff. Plus all three are poorly integrated with the browser. Forget about leveraging a search string(ctrl+f) and other browser specific features in any of the three tech apps. use DHTML/AJAX... its superior in this repect.. http://skytorch.blogspot.com/
  36. The three are suited only for some typical application only.
    Depends on how you define "application". To me, a website is not an "application". It might have some application type functionality. It might not.
    One can't really convert an entire website using any of these.
    Depends on what your "website" does. I would agree that typically this is not the case.
    You would still need DHTML stuff.
    Not really. The content part of the "website" could be plain HTML and the rest one of the "three".
    Plus all three are poorly integrated with the browser. Forget about leveraging a search string(ctrl+f) and other browser specific features in any of the three tech apps.
    This is not necessary if one is doing an Application.
  37. The three are suited only for some typical application only.
    I would say this a little different. The browser as application is only suited for some special type of application i.e. display content and simple forms. Any other type (custom applications, office type applications, video editing etc..) is best done with either of three C/S technologies (client/server). My case is that the browser is the special one, not the others. Because if the browser is the regular one then It would have had more support for good application design, not only for the display of content.
    One can't really convert an entire website using any of these. You would still need DHTML stuff.
    A website which displays content is the domain of the browser, not Flex/javaFX or Silverlight, but what can be done with DHTML can absolutely be done in those three types, mearly because of the fact that they are richer in capability.
    Plus all three are poorly integrated with the browser. Forget about leveraging a search string(ctrl+f) and other browser specific features in any of the three tech apps.
    In my opinion you should not integrate with the browser, but use only that which you need. That is tcpip or upd for traffic. Furthermore you can build whatever functions you like including ctrl-f, but when you develop an application the customer probably does not want you to build a browser in Flex, but something he can use in his buisiness process. Furthermore you will reduce potential bugs by removing browser specific stuff. The internet is not the browser you see, but a set of protocols which makes interaction easy. The browser is only 1 of the applications which uses these protocols and is suited and has been developed for 1 purpose, display content and facilitate simple forms. Yes you can do complicated things with it, but so can you with MS word and marco's, but you do not build your core business on the use of MS Word and marco's. You build it with the tools suited for that purpose (c++, Java etc....) Kind regards, Marc
  38. but so can you with MS word and marco's, but you do not build your core business on the use of MS Word and marco's.
    Yeah. You gotta use Excel and macros. :) (you'd be surprised how many actually do this.)
  39. Re: Large applications? Silverlight?[ Go to top ]

    ... All this makes our tomcat server run under 64 MB RAM ...
    Are you using Hibernate/JPA?
  40. Re: Large Applications? 64 MB tomcat[ Go to top ]

    ... All this makes our tomcat server run under 64 MB RAM ...
    Are you using Hibernate/JPA?
    No we don't. Started with iBatis, then threw it out as it was too painful to code in it. Hibernate was too bulky, so we had our own JDBC wrapper (about 6 classes) which converts database records to XML and Flex consumes XML. Interaction between Flex and Java servlet is in XML, use XStream for serialization. Flex has good support for XML handling, so not much required there. Btw we run a benchmark of our 6 class library to iBatis and Hibernate - the results are here - http://onelinejdbc.wiki.sourceforge.net/PerformanceComparison Btw if you need any of this code please let me know, we didn't get time to open source it till now.
  41. Re: Large Applications? 64 MB tomcat[ Go to top ]

    ... All this makes our tomcat server run under 64 MB RAM ...
    Are you using Hibernate/JPA?


    No we don't. Started with iBatis, then threw it out as it was too painful to code in it. Hibernate was too bulky, so we had our own JDBC wrapper (about 6 classes) which converts database records to XML and Flex consumes XML. Interaction between Flex and Java servlet is in XML, use XStream for serialization. Flex has good support for XML handling, so not much required there. Btw we run a benchmark of our 6 class library to iBatis and Hibernate - the results are here - http://onelinejdbc.wiki.sourceforge.net/PerformanceComparison
    Btw if you need any of this code please let me know, we didn't get time to open source it till now.
    I figured you were not. It would be interesting to see what you have done. Most of what I do involves complex models so for those things Hibernate is the better choice. But if i need to stream xml directly from the db ...
  42. Re: Large Applications? 64 MB tomcat[ Go to top ]

    It would be interesting to see what you have done. Most of what I do involves complex models so for those things Hibernate is the better choice. But if i need to stream xml directly from the db ...
    Sure I would like to share this stuff. Send me a private message to - sunil(at)bizosys(dot)com I will package a sample app and send it across.
  43. Re: Large applications? SilverLight?[ Go to top ]

    To me Flex should be very lightweight, basically using HTTPService or URLStream to pass off calls to a service which does all of the heavy backend lifting and simply binds controls to the response data.
    That doesn't seem like it would be very good for "large" and "heavily used" applications. Actually, speaking from experience, it is not. Off-loading work on to the client is one of the benefits of RIAs like Flex/Silverlight/JavaFX.
    The backend can be written in Java, Ruby, .NET, FDS, whatever. That is where the scaling issues should be dealt with.
    Having a chatty client will majorly decrease scalability. And it will have bad side-affects on the client. This is from experience.
    There should NEVER be any business logic contained in Flex code.
    Why? Because of duplication of code? If so, this is one reason I am looking forward to JavaFX.
    Flex is just another way of rendering data in a browser, and should be looked as an alternative to Javascript-based solutions ...
    Maybe it is just my experience in developing "desktop" apps but this seems to be one of those sad results of peoples' only experience being "web apps" before embarking on Flex or the like.
  44. For RIAs Flex is an insane improvement over JavaScript / HTML / CSS in terms of developer productivity. ActionScript is more like Java than JavaScript. It's just not even close. As pointed in last week's "TSS don't use Flex thread of the week"(TM) JavaScript / HTML / CSS are hacks for RIAs, Flex is designed for RIAs. GWT is quite an amazing improvement over raw JavaScript but you still have lots of mucking about to do with browser quirks for HTML and CSS. Unless your site is unstyled, droll and boring and you're only supporting one browser, Flex really gets the job done faster. Do we really need two inexperienced (WTF, Hibernate for Flex?? Really?) developer blogs to be posted within a week? These are some more common problems associated with Flex: *Lack of modern IDE features: no code formatting, no auto-generation of plumbing code like getters / setters (workarounds available) *Lack of / hard to find utility classes (date formatting comes to mind) and collections. *No generics *Business / management have inexplicable fear of plug-ins.
  45. Yes, Flex has support for JPA (Hibernate) via BlazeDS. And the inexperienced developer has enough experience with GWT, Echo2, Swing, and a pile of server-side technologies, and is somehow capable of making the difference between well-written software and not-well-written software. I just thought of something, maybe not much relevant, but still - the only design pattern I've seen in Flex classes is Singleton. (Maybe I haven't seen enought classes to discover the factories, for example). In the post I've mentioned about Observer. What I don't understand, is why only one guy tried to make remarks on my points. Is the event-handling ok for you? Or the need to cast to Object? Or the sometimes wrong event dispatching? I haven't mentioned what happenned the other day when I typed var int:id; instead of var id:int; - The compiler complained about undefined 'int' type in all my code. This is what I mean by immaturity - not many good developers have worked with it, and hence it hasn't yet become a good piece of software. Some people see nothing wrong in the event-handling, but maybe they have never seen a properly implemented observer? As long as people are happy with crappy implementations, the implementations are not likely to change.
  46. Alright, here is a point by point: exception handling: Not a problem during development, the debug Flash player gives stack traces. I agree it is a problem for hard to track down bugs, would be nice to capture stack traces on the client and send them to the backend. event handling: Use anonymous functions as a delegate or create custom events. multithreading: J2EE went to great lengths to isolate developers from writing raw threading code. Most developers will generally do bad things with multithreading. Events & messaging keep things easy to use. dynamically typed AS3: This is all over the Flex documentation:
    ActionScript 3.0 has two types of inheritance: class inheritance and prototype inheritance: * Class inheritance - is the primary inheritance mechanism and supports inheritance of fixed properties. A fixed property is a variable, constant or method declared as part of a class definition. Every class definition is now represented by a special class object that stores information about the class. * Prototype inheritance - is the only inheritance mechanism in previous versions of ActionScript and serves as an alternate form of inheritance in ActionScript 3.0. Each class has an associated prototype object, and the properties of the prototype object are shared by all instances of the class. When a class instance is created, it has a reference to its class's prototype object, which serves as a link between the instance and its associated class prototype object. At run time, when a property is not found on a class instance, the delegate, which is the class prototype object, is checked for that property. If the prototype object does not contain the property, the process continues with the prototype object's delegate checking in consecutively higher levels in the hierarchy until Flash Player finds the property.
    Object.toString is well documented as using prototype inheritance. Casting isn't a big deal and you could also slap toString in the interface. event dispatching: Both examples work fine for me. fonts cannot be loading dynamically: 5 seconds of googling: http://undefined-type.com/index.php/2008/01/26/title hibernate support: Flex / BlazeDS do not support Hibernate. They support remoting. If the methods you expose for remoting happen to use Hibernate somewhere down the line, it has nothing to do with Flex / BlazeDS. You probably looked at an LiveCycle Data Services ES example. If you don't need the extra functionality in LiveCycle, you don't need any extra configuration beyond exposing your services for remoting.
    I just thought of something, maybe not much relevant, but still - the only design pattern I've seen in Flex classes is Singleton. (Maybe I haven't seen enought classes to discover the factories, for example). In the post I've mentioned about Observer.
    Developers aren't provided with patterns by a language, they use patterns to solve problems. You are free to apply any pattens you like with Flex. (there are also MVC and dependency injection frameworks available)
    I haven't mentioned what happenned the other day when I typed var int:id; instead of var id:int; - The compiler complained about undefined 'int' type in all my code.
    Garbage in, garbage out. Don't blame the compiler. It's not going to become self aware and detect contextual typos.
  47. Hi. Thanks for the detailed explanations. Below are my little responses to each: exception handling: yup, there is a problem. event handling: actually non but one of the solutions actually solve the issue. I want to pass the parameter with MouseMove, for example which is despatched not by me. The anonymous function will work, I think. But it is too much of a workaround. multithreading: wrong assumption - even though developers happen to make buggy software, this is not a valid reason to cut some 'risky' features off. Because there are developers who can do good things with threads, if they had them. casting: It is not a big issue, of course. But it shows some not good OOP. When something is referred by its interface, then it is not considered an object by the compiler (but actually is). (And, agree with me - adding toString to an interface is something I'd bang my head against a wall for) event despatching: it is Flex 3.1. Check the code of Image, where the Complete event is despatched. It is despatched before the method, which actually does to completion. dynamic font loading: this is not what I sought, but of course it is impossible to do what I want only with flex. Maybe flex+some (LS/Blaze)DS. That is - load fonts which the client don't have, by ttf. I put it at the bottom of the list, because it is no major drama at all. hibernate: ok, I forgot which DS it was. I'm inclined to count bad things in these 'frameworks' as 'bad things in flex', and the way LCDS supports hibernate remoting is bad. patterns: Of course developers aren't provided with patterns by a language, that would be stupid of anyone to think. (Especially when one is aware that the book by GoF is not for Java at all) But I dare to judge some framework for maturity by the patterns it uses, because patterns are best practices, and the more best practices, the better. I'm generally complaining of the large amount of bad practices, which should be worked around. And workarounds are often hard to maintain and understand later. compiler message: the compiler should disable declaring 'int' as a name. I was lucky to find out what happenned, but the compiler didn't help at all. Next time I will put an extra comma somewhere in the code, and if it issues 100 errors that brackets are not closed, it will deffinitely need improvement.
  48. I'd like to chime in on some of these issues:
    Object.toString is well documented as using prototype inheritance. Casting isn't a big deal and you could also slap toString in the interface.
    For me it does not matter that much if it is documented or not. From the developer perspective the distinction between class methods and prototype-attached methods seems arbitrary. There may be a pattern, but I can't see it. And the problem is not only casting. When overriding a method, you have to use the override keyword for class methods, but you get errors if you use it with prototype methods. That's just annoying. And the worst issue: The only way to reflect on AS3 classes is the XML output generated by describeType. And that method does not include the prototype methods which makes it pretty much completely useless for the core types! There are some other issues where AS3 still feels a bit immature: 1) No protected or private constructors. Weird limitation. I remember a blog post by some Adobe engineer that is was due to the pending ECMA standardization effort, so there is hope it gets added for AS4. 2) No abstract methods or classes. The inclusion should be a matter of course for an OO language. And don't show me those workarounds, these are just hacks. 3) No enumerations. What I find puzzling is that fakes for 2) and 3) are constantly used by Adobe in their own APIs, so I'd think that this should be an incentive for them to improve the language with these features. 4) No generics. A first teaser with the new Vector class introduced for Flash Player 10, so let's hope that at some point we will be able to create our own generic classes. 5) No proxies that can dynamically implement an interface like JDK Dynamic Proxies. Makes it hard to create Mock-/AOP-/RemoteStub- frameworks. Might be added in a future release though as there is a ticket in the Adobe bugbase: https://bugs.adobe.com/jira/browse/ASC-3136. So vote for it if you like to see that one added to the Player. There are also some issues with the current version of the Flex SDK, but hopefully these will get resolved with Flex 4 / Gumbo. The components were somewhat hard to extend and any kind of sophisticated skinning was cumbersome (usually involved programmatic skinning). I do a lot of contract work for companies that create RIAs with highly individual UIs and they still shy away from Flex for a lot of projects and build their apps as "pure" AS3 applications, even the large and complex ones. So let's hope that Flash Catalyst will be a good product and improve the developer/designer workflow. But... even with the long list of shortcomings I wouldn't want to miss the Flash/Flex platform for certain types of RIAs. And also, even though I primarily listed features we are accustomed to as Java developers, I don't think that AS3 necessarily has to become a Java clone. In fact I liked a lot of the Python-like proposals for the now-shelved ECMA-4 standard, so hopefully some of them make it into AS4.
    hibernate: ok, I forgot which DS it was. I'm inclined to count bad things in these 'frameworks' as 'bad things in flex', and the way LCDS supports hibernate remoting is bad.
    For data management again I'd like to shamelessly plug our own Pimento Data Services (http://www.spicefactory.org/pimento/) to be released tomorrow, especially if you are using JPA with Spring. Pimento automatically imports the JPA configuration (using Hibernates Metadata API) and let's you start using its AS3 EntityManager remote service without much additonal configuration. And Pimento isn't the only Open Source alternative for data management. Although it might be somewhat natural to look at Adobes own offerings first, if you are not satisfied with them you should look elsewhere. This is also true for other types of their frameworks, like Cairngorm or Flexunit, where (IMHO much better) Open Source alternatives are available, too. Jens Halm Spicefactoy
  49. I'd like to chime in on some of these issues:

    Object.toString is well documented as using prototype inheritance. Casting isn't a big deal and you could also slap toString in the interface.

    For me it does not matter that much if it is documented or not. From the developer perspective the distinction between class methods and prototype-attached methods seems arbitrary. There may be a pattern, but I can't see it. And the problem is not only casting. When overriding a method, you have to use the override keyword for class methods, but you get errors if you use it with prototype methods. That's just annoying. And the worst issue: The only way to reflect on AS3 classes is the XML output generated by describeType. And that method does not include the prototype methods which makes it pretty much completely useless for the core types!

    There are some other issues where AS3 still feels a bit immature:

    1) No protected or private constructors. Weird limitation. I remember a blog post by some Adobe engineer that is was due to the pending ECMA standardization effort, so there is hope it gets added for AS4.

    2) No abstract methods or classes. The inclusion should be a matter of course for an OO language. And don't show me those workarounds, these are just hacks.

    3) No enumerations. What I find puzzling is that fakes for 2) and 3) are constantly used by Adobe in their own APIs, so I'd think that this should be an incentive for them to improve the language with these features.

    4) No generics. A first teaser with the new Vector class introduced for Flash Player 10, so let's hope that at some point we will be able to create our own generic classes.

    5) No proxies that can dynamically implement an interface like JDK Dynamic Proxies. Makes it hard to create Mock-/AOP-/RemoteStub- frameworks. Might be added in a future release though as there is a ticket in the Adobe bugbase: https://bugs.adobe.com/jira/browse/ASC-3136. So vote for it if you like to see that one added to the Player.

    There are also some issues with the current version of the Flex SDK, but hopefully these will get resolved with Flex 4 / Gumbo. The components were somewhat hard to extend and any kind of sophisticated skinning was cumbersome (usually involved programmatic skinning). I do a lot of contract work for companies that create RIAs with highly individual UIs and they still shy away from Flex for a lot of projects and build their apps as "pure" AS3 applications, even the large and complex ones. So let's hope that Flash Catalyst will be a good product and improve the developer/designer workflow.

    But... even with the long list of shortcomings I wouldn't want to miss the Flash/Flex platform for certain types of RIAs. And also, even though I primarily listed features we are accustomed to as Java developers, I don't think that AS3 necessarily has to become a Java clone. In fact I liked a lot of the Python-like proposals for the now-shelved ECMA-4 standard, so hopefully some of them make it into AS4.

    hibernate: ok, I forgot which DS it was. I'm inclined to count bad things in these 'frameworks' as 'bad things in flex', and the way LCDS supports hibernate remoting is bad.

    For data management again I'd like to shamelessly plug our own Pimento Data Services (http://www.spicefactory.org/pimento/) to be released tomorrow, especially if you are using JPA with Spring. Pimento automatically imports the JPA configuration (using Hibernates Metadata API) and let's you start using its AS3 EntityManager remote service without much additonal configuration.

    And Pimento isn't the only Open Source alternative for data management. Although it might be somewhat natural to look at Adobes own offerings first, if you are not satisfied with them you should look elsewhere. This is also true for other types of their frameworks, like Cairngorm or Flexunit, where (IMHO much better) Open Source alternatives are available, too.

    Jens Halm
    Spicefactoy
    Nice see actual vs invented Flex issues and those are all excellent points. The prototype inheritance is annoying, but there is an equally annoying reason. Quoth http://livedocs.adobe.com/flex/3/html/help.html?content=04_OO_Programming_12.html
    Compatibility with the ECMAScript, Edition 4 draft language specification requires the use of prototype inheritance, which means that the properties and methods of a core class are defined on the prototype object of that class.
  50. exception handling: yup, there is a problem.
    Try tracking down an figuring out an exception in production with obfuscated optimized GWT generated JavaScript.
    event handling: actually non but one of the solutions actually solve the issue. I want to pass the parameter with MouseMove, for example which is despatched not by me. The anonymous function will work, I think. But it is too much of a workaround.
    Good luck with GWT. You can't pass args directly to your handler there either. Guess you can't use GWT. And by your argument Java must have jacked up the Observer pattern too...oh no, run away from GWT / JAVA!
    event despatching: it is Flex 3.1. Check the code of Image, where the Complete event is despatched. It is despatched before the method, which actually does to completion.
    Event.COMPLETE is documented as a network data load complete event. And it wouldn't matter if the event was triggered on the last line. The component isn't redrawn in that method, it is just invalidated. Event.COMPLETE isn't the event you're looking for.
  51. multithreading: wrong assumption - even though developers happen to make buggy software, this is not a valid reason to cut some 'risky' features off. Because there are developers who can do good things with threads, if they had them.
    And your recommended framework, GWT, does not support multithreading. How is everyone getting along without multithreading except you?
  52. RSF solves HTML CSS pain[ Go to top ]

    GWT is quite an amazing improvement over raw JavaScript but you still have lots of mucking about to do with browser quirks for HTML and CSS
    We used RSF ( Reasonable server faces) and integrated them with AJAX tollkist ( Smartclient) - the styling is in HTML templates and RSF renderer uses template based rendering with minimal invasiveness of the framework ID(s) into the html template. So all CSS is handled by dreamweaver or other tools.
  53. I agree with you at this point. GWT makes more sense and is the way to go for building RIA.
  54. Flex & POJO with BlazeDS[ Go to top ]

    Just of all don't compare anything but Java & Flex because one is used for front end and other is language. You can compare Swing with Flex or GWT. Flex with BlazeDS to access Java using RemoteObject is piece of cake. I mean you can have your POJO classes with Hibernate Annotation and transfer them as DTO to Flex (map your AS class with Java POJO using one line definition) Anyways every framework has pro and cons and Flex is no difference but one developer shouldn't declare as if Flex is crap and others are great because something work out well for him on particular project. (I see one liner statement or blog more often...)
  55. Re: Flex & POJO with BlazeDS[ Go to top ]

    I would agree with your comment on comparing different technologies. After being in the Web Application development arena for quiet some time, one gets to know the quirks, pros and cons of different languages and frameworks. So, any solution that works best for you should be the choice.
  56. Re: Flex & POJO with BlazeDS[ Go to top ]

    For those working with Flex and Java on the server side, you guys might look at Flamingo: http://exadel.com/web/portal/flamingo I provide an explanation of Flamingo direct support for Hibernate Validations here: http://www.adobe.com/devnet/flex/articles/flex_seam.html. Flamingo uses fast binary protocols for data exchange and does not rely on XML. Basically, it takes care of all communications between server and client. Additionally, it supports dynamic finders: http://www.exadel.com/flamingo/docs/guide/en/html/DynamicPersistentMethods.html This functionality dramatically will reduce amount of code if you use a database on the back end. Flamingo supports Seam/JPA and Spring/Hibernate and will generate entire working project form scratch just like a Rails or Grails application complete with database connection and tests. I'm quite surprised that Flamingo is not even mentioned in comments, and hope people will find it useful. Good luck
  57. exception handling. For a Java-guy like me, the exception handling ‘not perfect’. When an Error is caught, all you can know about it is .. the error code. Isn’t this too 1990? Stacktraces you can somehow acquire by calling “trace”, but it requires some configurations.
    Stacktraces are currently available for the debug player, but i agree that it is a *big* problem that no stacktrace is available to log unexpected exceptions in a production environment. Please vote to have this fixed. https://bugs.adobe.com/jira/browse/FP-644