Speculation: Microsoft looking to Acquire Macromedia?

Discussions

News: Speculation: Microsoft looking to Acquire Macromedia?

  1. A computerwire article reports that "Microsoft Corp is believed to have trained its acquisition crosshairs on Macromedia Inc, lining up a deal that would throw enterprise Java into a spin". Macromedia has built its Flash and Coldufusion server platforms on top of J2EE which provides an entry point into the J2EE world for flash/coldfusion programmers.

    A Microsoft acquisition of Macromedia would inevitably see Flash, and Macromedia's other cross-platform tools, tailored purely for Windows and .NET.

    Read Microsoft plots Macromedia coup against Java.

    Threaded Messages (81)

  2. Macromedia, ha! What if MS buys Sun Microsystems? :)
  3. Maybe IBM should buy McNealy's wheezing donkey of a company.
  4. McNealy and other share holders may not be wiiling to sell it to IBM :)
  5. Slava: "Macromedia, ha! What if MS buys Sun Microsystems? :)"

    McNealy would probably be asked to tone down his public anti-Microsoft comments. That would lead to a permanent content deficit in the industry, and CNET would go out of business.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  6. McNealy would probably be asked to tone down his public >>anti-Microsoft comments. That would lead to a permanent >>content deficit in the industry, and CNET would go out >>of business.


    To give Scott some credit, he had a rather soft tone towards MS at his comdex speach - and his speech was a lot better than the boring stuff Bill was telling the day before.
  7. So what they are going to do with JRUN and other J2EE stuff?
  8. This again proves that MS always steals other people's technology.

    Java is a serious threat to M$. So the only way to curb it is to buy it out..

    But the days of windoze is over I see linux being the primary desktop OS... I use to.

    M$ never had a grip on the server market and they never will but if they loose desktop M$ is doomed and they will be soon like it or not.

    Java and Linux will kill MS and they know it.
  9. "This again proves that MS always steals other people's technology."

    The post says they are going to buy Macromedia. Since when is paying money for something stealing?
  10. The post says they are going to buy Macromedia.

    >> Since when is paying money for something stealing?

    Oh sure, like we can expect anything else (good?) from M$!!! I just hope those guys are not in a "buying" spree. Guess MSFT's mission statement reads:
    "Be the Sole owner of the world's software"
  11. I would be interested to see how this would play against the anti-trust allegations within the US and EU. Specifically, buying the predominant but cross-platform media format and presumably tailoring it to your own technologies away from competitors would have some relation to those trials. Now, the US has already shown itself rather weak in cases against Microsoft, but it could impact these legal proceedings in other parts of the world.

    It seems like a situation where they wouldn't actually purchase Macromedia, but would rather become more of a controlling interest. Therefore, they could influence a shift to .NET without being the documented owner of the company. Sounds more devious, but they do it all the time with their "investments" in other companies.
  12. It would be nice if Sun, Oracle, IBM, Novell, BEA.. or one of the other J2EE supporters would beat M$ to the punch.
  13. Afterall J# is not bad you know, not bad at all. I have been a J2EE programmer for 3 years, stayed away from Java desktop apps, but this J# thing rocks, same old Java just brand new libraries. So basically soon(i am still with J2EE for now) I wont mind if MS buys Macromedia and then goes on to knife Sun's Java, cause I know Java lives on in J# :)
  14. It seems all the VB programmers have 3 years experience in Java, since the economy went sour.

    "...same old Java just brand new libraries.." - you

    Don't you realize learning a framework is far more time consuming than learning a language? And what for?
  15. Flash[ Go to top ]

    The point here is Rich Client side GUI - Flash Dominance.

    If MS owns the browsser market share and Flash is a good GUI.... no need for Client Side Java or JSF, or anything much more. This is monopolistic and hard to answer with anything with an open standard.

    Best practice becomse Client Side Flash and Server side ADO.

    They can always make Flash not support Java Beans later.

    .V
  16. Re: Flash[ Go to top ]

    If true, this could be the best thing to happen to spur SVG usage and development for creating rich-client applications.

    J
  17. Flash[ Go to top ]

    And who uses flash right now?

    Everyone predicts doom for Java but the day never comes.
  18. Flash[ Go to top ]

    Considering the awful crap that came out when Siemens made Flash their Web Site GUI - please don't. I have yet not come across a single good piece of Flash GUI on the internet. That said, I have come across only very few good Applet GUIs as well.
  19. Flash[ Go to top ]

    For morons like you here are some flash sites. Flash and Java Applets makes one the best web sites. ActiveX is a virus whore and piece of crap


    http://www.vw.com
    http://www.cartoonnetwork.com/
    http://www.toyota.com/index3.html

    There are couple of thousand great Flash and applet websites out there. Now days for any good website containts flash or applet.
  20. Flash[ Go to top ]

    For morons like you


    Is this really necessary?!?

    -Nick
  21. Flash[ Go to top ]

    It is necessary if dont know what your are talking about since MS trolls like you ...is hang around in the ServerSide go back to you .Not website and say hail to you master Bill Gates
  22. Flash[ Go to top ]

    Jamie: "It is necessary if dont know what your are talking about since MS trolls like you ...is hang around in the ServerSide go back to you .Not website and say hail to you master Bill Gates"

    Nick isn't exactly an "MS troll". He has been around for quite a while and seems to have a relatively balanced and positive view of the Java/J2EE space.

    There are plenty of "MS trolls" around of course, just be careful who you point that thing at.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  23. Flash[ Go to top ]

    It is necessary if dont know what your are talking about since MS trolls like you...


    Ah, speaking of peple not knowing what they are talking about...

    (how poetic)

    BTW: By what reasoning do you arrive at "Microsoft troll" from my comment on your choice of language??

    I would suggest you limit your posts to some intelligent commentary on the topic at hand...

    -Nick
  24. Flash[ Go to top ]

    I do not believe Nick is a "Microsoft troll"

    And while being on TSS I learnt that it is not such a bad thing to have Microsoft people with their opinions. Hanging out with people of the same opinion is not really what evolution is about. Also, I observed, that Microsoft people sometimes showed good knowledge (e.g. the Doug Purdy interview). Some other times I believe they just come here to throw in some stupid comments to watch the rage, the reactions and the decreased productivity of some java guys who go off on this. And the best of this they publish on http://sundown, their internal funsite dedicated to fun around java and sun.
  25. Flash[ Go to top ]

    For demo of power / fun of Flash (compared to Java plug in)
    see:

    campchaos.com
        (I like "This thing of Ours")
    icebox.com
        (I like Mr Wong)
    atomfilms.com/flash
       (I like some of the dating flixs)


    .V
  26. Is this a storm in a teacup?

    How many people actually use Flash for their J2EE Web UI?

    I will admit we were starting to look at it - but this was purely due to uncertaininty of availability of a client-side JVM. The recent ruling changes that.

    The report seems rather light on any actual content:

    "Microsoft Corp is believed to have trained its acquisition
    crosshairs on Macromedia Inc, lining up a deal that would
    throw enterprise Java into a spin, Gavin Clarke writes"

    Throw enterprise java into a spin??
    Lets see...

    DreamWeaver:
    Its a dev tool. Its only available on Windows and Mac. We largely wouldnt care.

    Flash:
    Who is actually ising it as their Web UI for their J2EE application? I suspect that most wouldnt care.

    ColdFusion:
    Who is actually using it?

    Fireworks:
    Its a dev tool. Its only available on Windows and Mac. We largely wouldnt care.

    JRun:
    The beauty of J2EE is that we largely dont care - we can move to another servlet engine / appserver.

    I dont see anything that would throw j2EE into a spin there... certainly nothing that would be "deliberately designed to thwart J2EE uptake".

    "Macromedia, meanwhile, said it was bringing its estimated 300,000-strong community of developers to J2EE"
    Really? I dont see a flash developer becoming a J2EE developer.

    Is this article largely a source of global warming or have I missed something?

    Regards,
    Nick
  27. Why do these threads get started in the first place? A few weeks ago it was Microsoft buying Rational, now Macromedia. I mean who cares until it happens. Microsoft has enough money to go buy nearly every software company out their today. Microsoft is 18+ months into .net and past history dictates they overhaul their architectures every five years. Major pieces of .net still need to appear (eg. .net server) before anybody can guage any success for this platform. J2EE is not going away anytime soon, hopefully just the complexity.

    In general I find it offering very little for Microsoft to buy Macromedia primarly for Flash. Flash has it's purposes but it's not going to overtake the presentation layer anytime soon. Coldfusion, Director, Dreamweaver, good tools but difficult to grow the audience. If Microsoft wanted to start supporting j2ee I'm sure they could find a better alternative to jrun, Oracle learned that lesson..
  28. The one obvious omission from my post:

    "DreamWeaver: Its a dev tool. Its only available on Windows and Mac. We largely wouldnt care"

    Obviously, it also supports JSP development - does anyone actually use DreamWeaver for JSP development?

    -Nick
  29. You are right. Macromedia is a minor player in J2EE. Not dangerous at all.
  30. If MS can deliver rich UI via their browser using Flash or some other technology the impact could be more on the client computer. That is, it could help sell more operating systems. J2EE is not really relevant at all in that scenario.
  31. If that rich UI will only work with .net then it will be relevant to J2EE.
  32. My favorite feature of any Flash homepage is the link that says "SKIP INTRO".
  33. Maybe Microsoft should throw the Xbox api's into .net as an alternative to Flash. Make everything animated and flashy and continue hiding the complexity, doesn't that fit their strategy for demos? hehe.. :)

    Flash is a designer tool for artists, I highly doubt developers will take on the task for creating complex Flash components. That program is a career by itself.
  34. Macromedia have made a lot of effort repositioning Flash MX as a rich-client that is appserver agnostic. Flash Remoting is a fantastic proposition, for allowing a flash client to invoke business logic on a server-side application, be it running on J2EE, .NET or Coldfusion MX.

    Flash was picked up by the design community, and we are *all* tired of the <
    The internet is being used in ways that weren't perceived when HTML arrived on the scene...we've hacked our way through CGI-BIN and macro languages, until JSP (and competing technologies) came along and brought some order to using HTML technology as a dynamic client. However, those of us that build enterprise applications have *all* fought with the limitations of browser based technologies at some point or other, and had to resort to workarounds. We all have.

    Now, another important point - for an enterprise software application, where the big money is spent, the J2EE developer is *not* the guy that develops the front-end. The graphic design and creative design team design the front-end, and the server-side developers expose the business functionality in an appropriate way, that integration between the client and server is as decoupled as possible. Separate content from code. Separate content from layout. View Helper patterns. Composite View patterns. Front controller patterns. As a community, we've purposefully made sure that the J2EE developers doesn't have to become a web designer, and vice versa. If our architecture is correct, and our design is good, then it shouldn't matter to us whether the front-end guys are using HTML, Applets, Swing, Flash or Etch-a-Sketch. The easier the integration of our work, the more likely the solution is to be chosen, and that's why we've all worked with JSP so much...the integration between client and server is pretty much a no-brainer for us, and allows us to deliver our business logic to an HTML based front-end.

    Flash MX is a bit of a paradigm shift for sure, but designers are comfortable with it. When it's not being used to load 16-bit oversampled MP3 soundtracks and 100,000 polygons on a portfolio website, or it's not being used to shoot fireballs at reindeers in a christmas viral marketing campaign, but it's instead being used to deliver a richly-interactive user interface, with all the look and feel of a slickly designed website, but with the speed, responsiveness and nice-touches that we'd expect from a desktop application, then people sit up and take notice. When an online bank behaves like Microsoft Money or Intuit Quicken, or an online store behaves like the old CDs that we used to get with product catalogues, and when applications over the internet start to behave like the slicker desktop applications, and this works in a platform independant, low-footprint manner, then people are going to sit up and take notice. Customers and clients are going to sit up and take notice. They'll point and say, "I want one of those".

    Corporate clients *want* the functionality that Flash MX offers. Often we'll find ourselves in meetings explaining to clients why they can't have drag and drop on their internet stock purchasing programme. For too long, we've imposed the limitations of HTML onto our clients. Flash MX (and other rich client technologies) break free of these limitations. I keep harping on about drag and drop -- that is *not* the crux of my argument. The rich-client internet is not about dragging and dropping, it's a more general ambition of breaking free of the rigours imposed by HTML request/response applications.

    With this repositioning of Flash MX, and with Flash MX Remoting offering a clean cut in the role of the designer and the developer, Flash MX becomes an enabling technology for rich-client Internet. What is more, Flash Remoting provides us as Java Developers with a way of exposing our business-side functionality to Flash designers, without ever having to touch a Windows Box and boot up a copy of the Flash IDE ;) We talk to our designers the same way we talked to them before, they just have better tools for a better job...

    We're not going to be happy with the HTML interface forever...someone is going to come along with a technology that gains significant adoption. Let's come up with a list of what features such a technology would require, and let's look at Flash MX objectively, with Flash MX Remoting thrown in the mix, and see how it weighs up.

    There are other rich-client technologies out there as well, and if any of them are easy for the designers to pick up, and easy for the developers to develop against, then I'm sure they'll be candidates for the 7th wave as well.

    I don't work for Macromedia, I'm just a J2EE developer that has explained for too long to clients why "you can't do that online with HTML". Very soon, someone will be able to however, then I have a problem...drowned in the 7th wave ;)

    So Microsoft ? I'm sure this is just churning of the rumour mill, and I'm sure this is as likely to happen as Windows being open-sourced. *However*, if Flash was to become the technology of choice on the client, and if a merger had meant that integration with .NET was significantly easier than J2EE, then it *would* cause the natural migration of projects from J2EE towards .NET. It may not be our server-side technology of choice, but when our client wants a rich-client interface on palmtops, wireless phones, iDTV and rich-client browsers, and they have settled on Flash MX, then other technology decisions just *may* centre around the client technology, all other things being equal.

    Something is going to take the place of HTML, some time. I'd suggest folks take a look at Flash MX Remoting, get a feel for how easy it can be to integrate a Flash MX client designed by a creative developer, with a J2EE application designed by folks like us, before just dismissing Flash as a skip intro technology.

    Stick with some established J2EE design patterns, keep the architecture of your server-side code in good check, and suddenly your front-controller becomes the point of contant, thanks to Flash Remoting, with a richer-client technology than HTML will offer us.

    These decisions will be customer-driven, not technology-driven.

    So to minimise the risk of being flamed for the number of occurences of "MX" in this post ;), how many developers here *have* been working with richer-client technologies, what have those technologies been, and good have they been at keeping the designers and developers in different offices ?

    Steven
  35. This is a very perceptive and intelligent post.

    I'm an information architect, I work in the space between the interface designers and the Java developers. And since 1998, I've been hearing the groans of pain from both teams about making HTML/JSP/x-technology jump through hoops to give users what they need.

    Right now, I don't see companies jumping on rich-client user interfaces in the B2B arena, or for internal applications with Web interfaces. Maybe it's happening more in the B2C arena, I've been away from that for a while. Most of the focus I see in B2B right now is in integration, not in the human interface itself. Seems like the GUI is an afterthought.

    Will it happen? I hope so. But I think the dot.com meltdown had a serious affect on a company's "need" to adopt these kinds of technologies.

    Elaine
  36. Yes, very intelligent. The author used the term "paradigm shift".
  37. Paradigm shifting without a clutch? :)
  38. Flash:

    >Who is actually ising it as their Web UI for their J2EE application? I suspect that >most wouldnt care.

    This is real arrogance.

    I use flash for the ui of my web apps. It allows me to provide a rich user interface for my clients that are using windows and older macs. I can’t do that with java.

    No I am not a big time j2ee app developer. I am an in-house developer for a small government agency. I am the kind of developer that Microsoft is targeting with .net. I’m the kind of developer you want staying with java and open source.

    Remember there are more of us ants in the world then you elephants.
  39. Calm down[ Go to top ]

    This is real arrogance.


    <steam letting="off">
    Its just a f*@cking question. Intended to stimulate some sensible discussion rather than attract insults. First I am a MS troll (as if) - now I'm arrogant - wtf next?
    Is it too much to expect some sensible debate on this thread?
    </steam>

    The main thrust of the article was the effect that a potential Macromedia purchase by Microsoft would have on J2EE (the quote was "throw Enterprise Java into a spin").
    My proposition was that this wont have a big impact on J2EE at all... I am quite happy for someone to change my opinion on that with some reasoned argument.

    >> I&#8217;m the kind of developer you want staying with java and open source.
    But you just said that you dont use Java...
    What do you mean? Can you elaborate?

    -Nick
  40. Calm down[ Go to top ]

    I’m quite calm, thank you. I could offer you the same advance.

    I do use java extensively, but on the server side only. The client side is html, pdf and flash.

    Remember, Microsoft is in a battle to win the hearts & minds of developers. The front line of that war is not the high end developers. It’s with the small in-house people. Remember where VB was used first.
  41. I could offer you the same advance.

    And I have taken it - thanks.
    It has just been getting on my tits for some time now that many of the posts on TSS are often devoid of any technical content and generally open with some kind of insult (like (sorry): "This is real arrogance" ).
    Its known as TheServerFight.com in some circles...

    Anyway,

    1) Are you actually leveraging the J2EE integration aspects of Flash 6 (MX Remoting)? Or are you just using http/xml?
    2) What aspects of the UI are you actually using Flash for? (Are you able to point me to your sites or are they internal only?).

    >> The front line of that war is not the high end developers.
    >> It&#8217;s with the small in-house people

    Most comments I have heard about Flash is that it requires dedicated flash programmers (the learning curve for Action Script and the Flash API's is steep - and its not like any other GUI technology (layers, clips, etc)) - not the sort of thing that every small in-house shop has, I would have thought.

    -Nick
  42. OK, so “arrogance” is over the top. Sorry.
    I am using Flash MX. I’m even using Jrun. So I could use Flash remoting, but I’m not. It’s just to proprietary for me (I use Tomcat a lot too).
    I’m using xml-rpc to get data exchanged. I have a few xslt scripts that I use to generate the actionscript and java code for marshaling and un- marshaling the data.
    All my work is internal. I have no way to show it to you.
    I’m it as far as java development goes here in our shop. I also do the flash development. If I can do it then I’m sure all the sharp people I read at this site can.
    By the way, there are some interesting things for flash coming from the open source community: http://javaswf.sourceforge.net
  43. Calm down[ Go to top ]

    Plz could you elaborate i.e As I once a College Student got taught VB.4/5 in a Wintel environ until I grew up and found Oops I mean got a job with a Government/Local Authority doing Database Driven Sites using Java/JS/JavaBeans in a Linux environ - Thus the Authority is moving onto J2EE can't wait and I'm sorry but I use both Wintel/Linux & Unix OS and our Graphics Guy OS/10 (Mac) .I am anti- M$ as it wasn't till this job that I finally found my vacation and learn't all about synergy tools and great apps.

    rgds Interesting thread but plz confirm you mean't me or whom!!
  44. All I can say nicely put I'm led to believe I fall as one them ant's well that makes two ( ant's that is ).
  45. Sorry folks I obviously missed the train.
  46. Oh boy! Another thread where Microsoft becomes M$ and Java becomes the saviour of the world!
  47. Oh boy! Another thread where Microsoft becomes M$ and Java >becomes the saviour of the world!


    Someone has to save the world from M$ threat.
  48. What are we really talking about, those small applications that here and there use Flash !!! Do real Enterprise Applications, not some local petstore, needs flash? Do we actually need the browser to make J2EE applications? Now with the latest ruling about M$, that java should be delivered with Windows -> that would finally make Java Webstart a great product. Finally stapping down from the hype about using browsers, to the real thing, use a REAL frontend for REAL apps. And we don't need flash for that.

    So let them buy it, so they gain some market in the small local petstore division. J2EE is a serious enterprise framework, that eventually should be combined (once again), with (swing based ... or other) client and non browser front ends. Because the only reason we are using the browser to build apps is because M$ made a hype for it....
  49. In the first place, most stories of the form "X might buy Y" are put out by stock analysts--or, as they used to be called in a slightly more candid era, stock touts.

    But assume it is true: it's worth thinking about. It's not immediately obvious whether Microsoft *might* buy Macromedia in order to 1) put Flash to bed or 2) integrate it into .NET as a new rich-client framework. If the former, it would just be one more example--too small and too late to count--of Microsoft pushing the ethical envelope; but if the latter, it could have very far-reaching consequences indeed, as in: say goodbye to plain-old standard HTML.
  50. I disagree. The latest version of Mozilla kciks serious butt. It is by far a better browser than IE now. If you are not using it (or Netscape), you need to look seriously at it. Anyway, it is very good now and only getting better. AOL will undoubtably switch to it at some time in the future. When that happens, MS will lose browser dominance and standards will rule again. Also, the judge may end up ordering them to distribute Netscape along with Java.
  51. Its an interesting news. we might soon see new versions of Macromedia products with names like DreamWeaver.net ,Flash.net,ColdFusion.net,JRun.net ........
    And finally some day J2EE.net !
  52. Isn't it time for the real desktop apps to take over again. I don't mean for those small local petstores, but serious applications just don't belong on the browser!

    The browser has initially been designed to lookup and read text-based data. Now over the years, with M$ leading the hype, the browser has, let us say, been virtually raped to something that doesn't come even close to a real desktop app.

    You don't hear me say that the browser should be banned out of this world, but is just be used for that was it was intented to be. A good and fast world-wide library.

    Now when making a serious J2EE app (client side), you have to do a lot of magic with servlet filters, struts, jsp, ... for something that could be done easily with a desktop app. Especially now when Sun has won the fight against M$ for delivering the JVM (the version can even be choosen by Sun), the Java Webstart technology can finally make an end at the put-it-all-on-the-browser-HYPE. Clients can go back using a fast desktop app (in awt, swing, jface, or whatever ...) that can offer a higher level of complex aspects, whereas with browser these things are impossible or TOO time consuming to make.

    I think webstart could launch a platform independent, browser independent technology for clients, who are in need of serious apps. An opensource technology whereas Flash really isn't.

    It would be nice to hear some opinions about leaving the browser and start using back real desktop apps (Or am i just dreaming out loud???). Perhaps there are some people out there who have tried it and could share some idea's with the rest of us.
  53. It would be nice to hear some opinions about leaving the

    >> browser and start using back real desktop apps (Or am i
    >> just dreaming out loud???). Perhaps there are some people
    >> out there who have tried it and could share some idea's
    >> with the rest of us.

    We have been using JavaWebstart for intranet (and, recently, internet) applications for almost 2 years now. Its a great tool. All the benefits of applets with none of the limitations.

    >> but serious applications just don't belong on the browser!

    I too agree that it is kinda fundamentally flawed to try re-create the desktop environmnent within the browser - it doesnt make sense.
    Heavy DHTML & JavaScript usage is generally complex, brittle across browsers/versions and a pain to maintain.
    Flash was something we were looking into - just for some dynamic web page components (charts and the like) - but this was primarily because of the Microsoft-not-shipping-a-JVM issue...

    All people want is a rich UI thats easy to develop, with no deployment hassle. Java Webstart, to a large degree, gives you that.

    The only criticism I would have of Webstart is that Sun dont give it the attention it deserves. There are sites devoted to workarounds to niggly problems and buggettes that should just be fixed/removed. Perhaps open-sourcing it might give it the momentum it needs in terms of refinement.

    -Nick
  54. Hi Nick, thx for the reply.

    We are for the moment making all our front-ends in the time consuming js, dhtml, struts, ... . But convincing our boss to use webstart (or at least look into it) is another problem :)

    Perhaps you could pass me your email so that I can gather some information about how you've integrated it, the pro and the cons, kind of apps, ...

    You can reach me at: maarten dot volders at cronos dot be

    Perhaps if people would look beyond the M$ hype of putting EVERYTHING in the browser and start to remember why Java is so great they would sey that using browser is not the way to go. Java is a platform independent an opensource project. But using different browser types/versions and flash doesn't seem to be opensource or independent ???

    So to all of you out there: wake up from the M$ hype and return to what Java was made for.
  55. Can't agree with you Reborn. I see nothing wrong with html/browser front ends. Enforcing a few key rules will make a browser application work as well as a client-side app AND be simple to develop.

    1. Require all users to use one type of browser. This will make all scripting and dhtml simpler. (Why not? Installing a client-side app on a PC is just as restrictive)

    2. Once a user clicks on your browser-based application, open a new, menu-less window to avoid back buttons and the like. This way you supply all buttons and links and it works like an application should.

    3. If your users demand a "rich" control that cannot be made with html/JavaScript, think of something that will work. Or, throw it in an applet if you must.
  56. The return of the real desktop apps?[ Go to top ]

    [webapps are just as good as rich-clients]

    For who? Developers or end-users?

    When it comes to writing a file on the users behalf, just how do you explain where the file is actually saved. On the server... on their client machine.

    File-systems and web-browsers aren't a good combination for end-users.

    I try to think about what a technology platform provides, or doesn't, for end-users. While webapps do provide obvious value for many situations, there are warts that will never be resolved.

    -Gary
    http://www.geocities.com/gary_keim/vre.txt
  57. The return of the real desktop apps?[ Go to top ]

    <Gary>
    When it comes to writing a file on the users behalf, just how do you explain where the file is actually saved. On the server... on their client machine.
    </Gary>

    I don't understand the problem here, Gary. Files can be stored in both places.

    I think a message to the user such as "Your file will be stored on the (insert company name) server. Please click this link to download a copy to your machine" should be adequate.

    If you have users that can't comprehend a simple message like that then perhaps they shouldn't be using a computer.
  58. The return of the real desktop apps?[ Go to top ]

    <Race Bannon>
    I don't understand the problem here, Gary. Files can be stored in both places.

    I think a message to the user such as "Your file will be stored on the (insert company name) server. Please click this link to download a copy to your machine" should be adequate.
    </Race Bannon>

    Race, I realize that technically files can be saved to either the server or the client. The point I'm trying to make is that when you allow files to be saved to the client, you confuse the user and degrade the value-proposition of a webapp.

    Users have an understanding that the web-browser provides access to data on the server. The basic end-user doesn't even want to know about files. They just want their state stored for future use. [My Cooper'ism may be showing here.] Or they just want to click a link and view the server resource.

    In your scenario, can I use the "File|Save as" menu to accomplish the same thing as your smart link? If not, why?

    I'm a sophisticated user and I still can't figure out how to correctly enter a file:///// url.

    Once a server-generated file is saved on a client, it can't be access universally and can now get out-of-sync with the server-side version.

    I've seen some pretty gross mis-uses of the webapp concept in my time (and IMHO). End-user files should not be stored on the client, but they often are. Even worse, some webapps I've seen require the user to always save to the client. That app should not be a webapp. Now I can't access that data from the airport terminal.

    If Swing was easier to use and access, it could easily compete with VB and be even better due to it's Xplatform nature. But for some freaking reason SUNW doesn't seem to feel there is any problem on the client. Actually, Gosling was reported as saying in the MSFT trial that they had dropped the ball on the client-side. I agree, and you can read about what I'd like to see here:

    http://www.geocities.com/gary_keim/vre.txt

    Not the above is a shared server resource that, if you save it to your client, will probably get out-of-sync with the server version. ;^)

    There is a place for webapp and a place for rich-clients. They should be implemented where appropriate.

    Gary
  59. The return of the real desktop apps?[ Go to top ]

    If Swing was easier to use and access, it could easily

    >> compete with VB and be even better due to it's Xplatform
    >> nature

    Agreed.

    Swing has suffered (still suffers) from two main problems:

    1) Appearance.
    In general, it is too easy to find (many) examples of Swing UI's that *look* very bad. This is due in part to the fact that the Standard Windows look & feel is terrible. Also, the Swing framework does very little to help in this area -
    consequently, it takes more effort to make Swing UI's look nice.

    However, it is definitely possible
    http://www.jgoodies.com

    2) Performance.
    I personally think that UI programming is quite complex - and many Java UI developers dont really know what is going on under the hood - and therefore write very inefficient code. Also, the fact that its a managed environment means that its memory usage is substantially higher than a native app.
    Some of the performance problems were inherant in Swing - though JDK1.4 has improved on that.

    A third problem (or perhaps symptom?) has been a genuine lack of *good* 3rd party UI components. The Sitraka stuff (formerly JClass) is the major vendor I know if - and there components are rather poor.

    Future of Java on the Client?
    What I think is really interesting is the emergence of the client-side container in Eclipse (the kernel, not the IDE). The fact that the Eclipse Kernel has been "ported" to Swing in JLense (very new open source project) indicates that its a good candidate for a client-side container JSR.

    It will be interesting to see how this technology progresses in the next 12 months.

    -Nick
  60. The return of the real desktop apps?[ Go to top ]

    Do real Enterprise Applications, not some local petstore, needs flash?

    Do we need to see the Lord of the Rings or some sketches are enough?

    > [...]Separate content from code. Separate content from layout [...]. The easier the integration of our work, the more likely the solution is to be chosen,
    So, I guess using XSLT to generate XUL would be a simple solution.

    > Flash MX is a bit of a paradigm shift for sure
    Flash MX Remoting is a new an interesting approach but it is proprietary.

    > The latest version of Mozilla kciks serious butt.
    And XUL plays an important role in that act of kicking.

    > We are for the moment making all our front-ends in the time consuming js, dhtml, struts, ... . But convincing our boss to use webstart (or at least look into it) is another problem :)
    As Steve said "If our architecture is correct, and our design is good, then it shouldn't matter to us whether the front-end guys are using HTML, Applets, Swing, Flash or Etch-a-Sketch." So if your Front Controller renders an XML(XUL) document instead of forwarding to a JSP you don't have to convince your boss of anything ;)

    > Right now, I don't see companies jumping on rich-client user interfaces in the B2B arena, or for internal applications with Web interfaces.
    Because there is not much to jump on... There is no easy to integrate rich-client product available, as far as I know.

    > Once a user clicks on your browser-based application, open a new, menu-less window to avoid back buttons and the like.
    Using a Flash based UI all these troubles are gone.

    > A third problem (or perhaps symptom?) has been a genuine lack of *good* 3rd party UI components. The Sitraka stuff (formerly JClass) is the major vendor I know if - and there components are rather poor.
    Maybe because component developers are not very good UI designers. All the UI elements designed in Java, C++ or VB are just insipid, compared to Flash based UIs. We are using the same GUI elements for almost 20 years now. Isn't the time for a change? Some guy was dreaming of a Space Odyssey to happen in 2001 ;)

    > Most comments I have heard about Flash is that it requires dedicated flash programmers (the learning curve for Action Script and the Flash API's is steep.
    What if you could use Flash as a presentation layer without writing one line of Actionscript? What if you would be able to integrate a Flash based UI with your backend without changing a line of your existing code?

    >Flash is a designer tool for artists, I highly doubt developers will take on the task for creating complex Flash components. That program is a career by itself.
    I agree. Especially J2EE developers shouldn't even bother about the presentation layer. Just choose the alternative which best fits your needs and is easy to integrate with your backend. We use containers and persistence frameworks because it does our job and saves us time. Let's use the same approach when we choose a presentation framework.

    > All people want is a rich UI thats easy to develop, with no deployment hassle.

    Zulu (zulu.netspedition.com) gives you that. Or it will :)

    Ovi
  61. The return of the real desktop apps?[ Go to top ]

    All the UI elements designed in Java, C++ or VB are just

    >> insipid, compared to Flash based UIs. We are using the same
    >> GUI elements for almost 20 years now. Isn't the time for a
    >> change?

    Do you think Microsoft Office could be done in Flash??

    -Nick
  62. The return of the real desktop apps?[ Go to top ]

    <Nick>
    Could MS office be done in Flash?
    </Nick>

    I didn't see an answer to this question. Just wondering why some might think MS considers Flash a threat.

    Java is the real threat and the weakest aspect is Swing.

    -Gary
  63. The return of the real desktop apps?[ Go to top ]

    |
    | I didn't see an answer to this question. Just wondering
    | why some might think MS considers Flash a threat.
    |

    It wasnt quite my point. I personally think that Flash is not suited to developing complex UI's like MS Office.

    Essentially, if Microsoft had a CLR on every windows desktop (which currently makes up about 90+% of the desktop market), it would make sense to target the CLR for browser-based UI.
    Flash would be the only competition to this - yet I dont see the two competing head-to-head. They are suited to different tasks in my mind.

    |
    | Java is the real threat and the weakest aspect is Swing.
    |

    I disagree.
    In Swing we have a very good UI programming model - one that promotes good MVC design.

    Its weaknesses have generally been in performance and appearance. (see above for my earlier comments).

    It will be interesting to see what Sun's new Windows look and feel will be like in terms of Perf and Apperance with the Updated Windows Look and Feel due in JDK 1.4.2.
    I am told that in this release they have delegated the drawing to native components (in much the same way that Apple did). They are even going to support XP Skins...

    However, Look&Feel aside - I personally feel that more could be done to assist non-UI programmers write decent-*looking* UI's in Swing. There are just soo many examples of really, really ugly Swing UI's available on the internet. Its little wonder Swing gets a bad name. I would say that many of these are developed by non-UI programmers (and possibly by programmers that are completely blind).

    It certainly is possible to develop nice UI's in Swing - IntellIJ and Weblogic Workshop are at least 2 examples of commercial products (we have some internal ones).
    Netbeans is often held up as an advertisement for Swing - sadly, I see Netbeans falling into the "Ugly" UI domain.

    I am keen to see a higher-level framework appear for developing client applications (as we already have on the serverside)....

    -Nick
  64. The return of the real desktop apps?[ Go to top ]

    |
    | .. on that promotes good MVC design.
    |

    I disagree.
    Yes, models are sepeated out but nearly everyone combines their view and controller. Just how does Swing promote the seperation of view and controller?

    VB promotes a seperation of view and controller. Your subroutines are the controller and the view is stored in a resource file, as it should be.

    The reason Swing apps turn out ugly is because the developer has so many other problems to address, they don't get around to sexing it up. Bugs, performance problems, etc.
  65. The return of the real desktop apps?[ Go to top ]

    |
    | I disagree
    |
    You mean you partly disagree...

    Well, technically you are correct, a good MVC design seperates the view from the controller AND the view from the model. However, of these two seperations - the most important is seperating the view from the model.
    This is because you will almost always have different presentations of the same model. On the other hand, while its good practice to use different contollers to implement strategies, most applications get by with just one controller.

    |
    | The reason Swing apps turn out ugly is because the
    | developer has so many other problems to address, they don't
    | get around to sexing it up. Bugs, performance problems, etc
    |
    If you are implying that Swing applications have more bugs and performance problems than other frameworks, then I would beg to differ. The only real competitor is VB. However, VB has significant limitations in what the language can do for you. Also, in terms of reliability, the lack of typesafety and COM conspire to offset any advantage gained from the "simpler" language.

    The main problem is that Swing & AWT dont do a lot at all to make applications pleasing to the eye. Generally, you have to put in more effort than you would, say, with an MFC application (but at least it wouldnt crash).

    The other main problem is that many Swing applications that you see are developed by non-UI developers (or poor UI developers). The facilities are there in Swing to make it look nice - just not always the expertise and the effort that is required.

    Regards,
    Nick
  66. The return of the real desktop apps?[ Go to top ]

    Idd, the Zulu implementation of the petstore looks nice. And you don't hear me say that you CAN'T make really great apps in the browser.

    But isn't there something fundamently wrong that you would like to recreate a desktop environment within a browser, when you allready have a desktop env. ???

    We will allways have the problem of browser type/version as long M$ lives. Why not use Java where it is know for: platform independt implementations.

    OK, i know the ancient problem: the users have to install the JRE. But don't users have to install a new versions of a browser, you can't use Zulu implementations on a IE 1.0 :)
    Now when M$ has to include the JRE form Sun, that problem will be gone and a fair competition (as far if that is possible) can be started.

    Now, my vision is more something like: using webstart + fast GUI (perhaps JLense ???).

    Maarten
  67. The return of the real desktop apps?[ Go to top ]

    | > [...]Separate content from code. Separate content from
    | layout [...]. The easier the integration of our work, the
    | more likely the solution is to be chosen,
    |
    | So, I guess using XSLT to generate XUL would be a simple
    | solution.

    Generating XML from the business tier to the presentation tier *is* another alternative. However, what do you parse that XML into, for presentation...we can use XSLT to transform the XML into HTML, for a JSP presentation tier, or it would look like your Zulu product provides an XML definition of a Flash UI, if I'm correct ? You can then use XSLT to render your XML to Flash ? Good idea..

    However, the definition and design of the presentation tier then becomes a task for someone that understand an XML format. A fundamental problem I see, is that when presentation tiers have to be designed in XML, or using an XSLT definition, or in Swing, etc, then we're asking a PROGRAMMER to do a job best done by a DESIGNER.

    Shouldn't we leave the presentation tier design to the designers, and make sure that whatever technology we're using , the task of INTEGRATION is as simple, scalable and seamless as possible ?

    | Flash MX Remoting is a new an interesting approach but it
    | is proprietary.

    Just because it's proprietary, doesn't mean it's not a serious contender however. I see no risk to a project in using Flash Remoting...and the price of the product won't even scratch the budget of a large Enterprise deployment.

    | So if your Front Controller renders an XML(XUL) document
    | instead of forwarding to a JSP you don't have to convince
    | your boss of anything ;)

    But how much work remains once you've rendered that XML ? Sure, the creation of the XML was a no-brainer, but what task then remains...?

    | Because there is not much to jump on... There is no easy to
    | integrate rich-client product available, as far as I know.

    Flash + Remoting + J2EE.......


    | I agree. Especially J2EE developers shouldn't even bother
    | about the presentation layer. Just choose the alternative
    | which best fits your needs and is easy to integrate with
    | your backend. We use containers and persistence frameworks
    | because it does our job and saves us time. Let's use the
    | same approach when we choose a presentation framework.

    * exactly *

    Best wishes,

    Steven
  68. The return of the real desktop apps?[ Go to top ]

    I definitely agree with the third problem/symptom. Probably one of the biggest reasons that VB did so well was VBXs and OCXs. People knew they could get a bunch of components, and companies knew that if they wrote components they could sell them to a bunch of VB programmers. This made it very attractive to both developers and software companies.

    I am sensing a reversal of the "let's put everything in a web browser" trend, which I think is good. Some things were jammed in there that never should have been. Hopefully a stronger market in Java "controls" will appear as a result, which may make client-side development in Java more appealing.

    Mark
  69. The return of the real desktop apps?[ Go to top ]

    Race Bannon?! The only race Bannon I remember was the suave, cool guy from Jonny Quest. So I did search on google and found many other Race Bannons including a reknowned, gay leather designer and an author on "Safe S/M lovemaking".

    Race Bannon! LOL!!
  70. The return of the real desktop apps?[ Go to top ]

    Do you think Microsoft Office could be done in Flash??


    Well, maybe I'm a dreamer and I've seen too many SF movies ;) but I really think that much more complex applications than Office will soon have better user interfaces. Maybe in Flash maybe using something else, but the presentation layer lacks in major changes compared to the other layers. I don't see why can't a small footprint display server or a display proxy be able to render very complex flash interfaces. In fact this is what Zulu project is trying to accomplish.

    >But isn't there something fundamently wrong that you would like to recreate a desktop environment within a browser, when you allready have a desktop env. ???

    Well, is Xserver - the Unix Window System display server - fundamentally wrong when it remotely provides a GUI?

    >We will allways have the problem of browser type/version as long M$ lives

    I'd say no, as long as Flash remains an add-on/plugin for the platform, be it browser, desktop OS or mobile device.

    >Why not use Java where it is know for: platform independt implementations.

    Just because Java as well as the other traditional languages make very hard the development of the "next generation" GUI. I really see no terms of comparison between the user experience a Flash based UI provides and the one offered by a Java/C++/... based UI.

    >Now, my vision is more something like: using webstart + fast GUI (perhaps JLense ???).

    I agree, Webstart is a good thing. Too bad, as Nick said, Sun doesn't give it the attention it deserves. On the other hand a fast GUI is a mandatory but not sufficient condition for a good user interface.

    >Generating XML from the business tier to the presentation tier *is* another alternative. However, what do you parse that XML into, for presentation...we can use XSLT to transform the XML into HTML, for a JSP presentation tier, or it would look like your Zulu product provides an XML definition of a Flash UI, if I'm correct ? You can then use XSLT to render your XML to Flash ? Good idea..

    That's right. Use XSLT to transform the XML into XUL (http://www.mozilla.org/projects/xul/xul.html). Indeed, Zulu takes a XUL stream defining the UI and renders it into a Flash movie.

    >However, the definition and design of the presentation tier then becomes a task for someone that understand an XML format.

    The task of defining and designing of the presentation tier of a web based application is currently done by web developers that understand an XML-like format. I'm talking HTML here... Even more, many web based applications use XSLT to generate the presentation layer and the front end designers are the ones using XSL to define the transformation, be it into HTML or anything else.

    >A fundamental problem I see, is that when presentation tiers have to be designed in XML, or using an XSLT definition, or in Swing, etc, then we're asking a PROGRAMMER to do a job best done by a DESIGNER.

    I agree with the fact that if Swing is used for the presentation layer, a programmer is needed. This is not the case though with XSLT/XML/XSL.

    >Shouldn't we leave the presentation tier design to the designers, and make sure that whatever technology we're using , the task of INTEGRATION is as simple, scalable and seamless as possible ?

    Absolutely. That's one the main objectives of Zulu.

    >But how much work remains once you've rendered that XML ? Sure, the creation of the XML was a no-brainer, but what task then remains...?

    After generating the XUL document/stream, Zulu takes care of rendering it for you.

    Ovi
  71. The return of the real desktop apps?[ Go to top ]

    |
    |but I really think that much more complex applications than
    |Office will soon have better user interfaces
    |

    Perhaps. The key thing here is that it must be simple to program and simple to maintain. Its difficult for me to say not having done any Flash programming - but I dont get the feeling it is either (as I mentioned previously - it seems that you require a Flash specialist - amongst the 100's of developers we have, I could probably count on 1 hand the number with Flash expertise.

    |
    | Well, is Xserver - the Unix Window System display server -
    | fundamentally wrong when it remotely provides a GUI?
    |

    Well, its not quite the same thing though is it?
    X is quite low level - whereas what we are talking about here is a desktop environment delivered by the browser.
    It can certainly be done (check out www.webos.com) but its rarely, if ever, reliable/maintainable when the UI complexity increases.

    |
    | Zulu
    |

    I will have to check this out...

    Cheers,
    Nick
  72. The return of the real desktop apps?[ Go to top ]

    Perhaps. The key thing here is that it must be simple to program and simple to maintain.

    I completely agree.

    > it seems that you require a Flash specialist
    This is true for Flash Remoting, not for Zulu. If you have a Flash-based front end capable of generating the interface from an XML stream and handle UI changes using XForms, there is no need for a Flash specialist.

    > X is quite low level - whereas what we are talking about here is a desktop environment delivered by the browser.
    I was referring to XServer's capability of delivering a GUI over TCP/IP and the possibility of using a similar approach over HTTP.

    | Zulu
    > I will have to check this out...
    Please let me know what do you think about the concept.

    Ovi
  73. The return of the real desktop apps?[ Go to top ]

    Zulu

    I read your homepage but it seemed a bit light. Is the page working correctly or are most of the links non-performing?

    My framework/tool also takes XML input... seems required for todays programmer on the go to feel buzzword-compliant. ;^) Of course, it's also human-readable (and editable) and foregoes serializations woes.

    I'm doing the same thing you are but I have a WYSIWYG tool for generating the XML and the rendering/some-controlling/some-models are implemented in Swing classes. It''s that Swing part that's difficult to do. I don't do XForms but simply Swing listeners plus a higher-level event-model (think old AWT bubbling event model) that insulates the controller from the details of the UI heirarchy.

    I'll be releasing version 0.1alpha of my product in the coming weeks. Look for it!

    -Gary
  74. The return of the real desktop apps?[ Go to top ]

    I know there is not much information on the main page about Zulu. I'm working on it. The project is still in development. There are some sample XUL element implementations on the XUL page.

    Good luck with your project and keep us posted.

    At http://luxor-xul.sourceforge.net you can find other XML(XUL) - Swing implementations.

    Ovi
  75. The return of the real desktop apps?[ Go to top ]

    Ovi,

    Sorry, I had JS disabled when I visited your page. Better now. ;^)

    I could write to XUL but it doesn't look sufficient. It would be good if I _could_ write/read XUL. I'll check out its extensibility.

    Yours stuff looks prime for for web stuff. I'm shooting for desktop+applet.

    chow,
    Gary
  76. The return of the real desktop apps?[ Go to top ]

    I've looked at XUL and it also seems too tied to the web. You need layouts. So, there's already a cross-platform interface to the web called Applet, which now has a new lease on life thanks to The Judge. Also, people don't write XML by-hand, for the most part, but use high-level tools. What makes you think XUL will rule without a good x-platform authoring tool? It may, but most of the HTML I come across is generated by web component containers... jsp, php, etc.

    And, Zulu requiring Flash means it's more than 6-steps from Kevin Bacon.

    Am I wrong?
  77. The return of the real desktop apps?[ Go to top ]

    1. Michael Caine was in Zulu
    2. Michael Caine starred in "The Cider House Rules" with Charlize Theron
    3. Charlize Theron starred in Trapped with Kevin Bacon

    Therefore the Zulu open source project has a Kevin Bacon index of 3.
  78. The return of the real desktop apps?[ Go to top ]

    Yours stuff looks prime for web stuff.

    Yes, Zulu's main target is web based UI. Although I do have plans to use it in simple desktop applications.

    > I've looked at XUL and it also seems too tied to the web.
    XUL is a User-interface Language designed for building portable user interfaces, not necessary for the web.

    > You need layouts.
    XUL defines some basic layout elements like: box(hbox, vbox, groupbox), deck, grid, spacer, tabs, tree and I see no reason why it couldn't be extended.
    Furthermore the exact position and size of the UI elements can be controlled with CSS styles.

    Ovi
  79. The return of the real desktop apps?[ Go to top ]

    XUL

    iframe, overlay, etc are found in dhtml. It's certainly a laudable goal. I just feel that you need to go get too many pieces to make it work: mozilla, Flash, whatever.

    Java will now just be there and it should be the prima langua for xplatform UI.

    Hackers just love to do everything in some cool way. But if there's no high-level tool to hide the complexity, it doesn't fly, in my opinion. Any good hacker can do everything in XML. The rest of the world doesn't want to bother, hence FrontPage and all the others.

    So, in summary, no tool, won't travel.
  80. The return of the real desktop apps?[ Go to top ]

    XUL Extensibility

    I don't see how it can practically be done. It's just a UI description and a collection of renderers. Given that various implementation platforms will have more/less capability, it seems unlikely that a uniform behavior can be accomplished.

    I have a single Java class library where I can guarantee that extensions will work as expected. Swing is a good baseline for xplatform UI. Why abandon it?

    Sorry if I come off as argumentative. This issue is important to me and... it's fun!
  81. The return of the real desktop apps?[ Go to top ]

    Java will now just be there and it should be the prima langua for xplatform UI.

    Although I am a Java devloper and a big Java fan I don't see anymore a language being the right tool for developing a UI.

    > So, in summary, no tool, won't travel.
    If some developer wants to code in XUL, he/she can use an XML editor for that. Although Zulu renders an UI from an XUL input, it is designed to do it on the fly. So the XUL streams (although they can be provided as XUL documents), usually they are dynamically generated by applying XSLT over the business layer XML. XUL streams are generated and sent to Zulu, the same way HTML is generated and sent directly to the browser in a standard J2EE, .NET, php based or you name it, architecture.

    Ovi
  82. I see nothing wrong with html/browser front ends. Enforcing

    >> a few key rules will make a browser application work as
    >> well as a client-side app AND be simple to develop.

    I just dont see the point of reproducing a desktop environment in the browser. For a truly rich UI, the JavaScript/DHTML complexity becomes rather horrendous and difficult to maintain - and its rarely reliable.

    If you are in a position to dictate browser versions on the client, then why give yourself the limitations of the browser as a client? With Webstart and at least you will have a proper limitation-free UI framework (like Swing / JFace) and leverage client-side Application Containers like Eclipse/JLense.

    >> (Why not? Installing a client-side app on a PC is just as restrictive)

    No its not restrictive. Use Java Webstart or any other JNLP implementation.

    -Nick