Home

News: Maybe we don't need objects to build client side apps?

  1. Adobe announced last month that it had achieved 100 million installations of AIR. Appcelerator received $4 Million dollars in venture funding last year to deliver an open source alternative to AIR named Titanium. Sun - excuse me Oracle - spent the better part of the last two JavaOne conferences extolling the virtures of Rich Internet Application development using JavaFX. Microsoft drew 10,000 people to the Mix conference to talk about StarLight. I can't help but think that all of this activity is a result of the failure of SWING to provide us with a great framework for building client-side applications. The thing that annoys me most is that the older I get the less I seem to be able to read JavaScript. And yet JavaScript appears to be the direction of the language of choice for building desktop applications. I guess with all this JavaScript and custom new scripting languages running desktop apps that maybe we don't need a real object oriented programming language on the client side?
  2. Objects are not the issue[ Go to top ]

    Javascript can be written fully Object orientated. It also provides closures, which Java wants but can't decide on how. The main issues around JS are that is isn't loosely typed (for better or worse) and the fact that, in the browser, it still has to deal with the dom and browser quirks ...
  3. I agree with Ingo, js can be written fully OO (and you can write fully non OO java ! ). Concerning the DOM and browser quirks, there are now a lot of frameworks to avoid that. I use Extjs daily and I nearly never deal with DOM anymore (like in Java, the most time I loose is in searching the quite large API)
  4. Even on the intranet?[ Go to top ]

    The move to rich browser-based clients on the Internet is understandable, but do people think we are going to move away (or have already moved away) from rich Java-based clients on the Intranet? Interested in your thoughts? Cheers, Ashley.
  5. Re: Even on the intranet?[ Go to top ]

    The move to rich browser-based clients on the Internet is understandable, but do people think we are going to move away (or have already moved away) from rich Java-based clients on the Intranet?
    I think it will happen. It fits in with virtualization and clouds and all of that jazz. It's a lot easier from a maintenance and support perspective and networked programs have great benefits from a security perspective. Where I work we don't build any new fat clients. It seems to me that we need a new platform for distributed applications separate from the browser and if something like that were to come about, everyone would be better off. In a way, that has already happened. Java applets and shockwave and flex are really separate platforms that integrate with the browser. In a lot of cases, the browser acts merely as a container for these tools and the user is really not interacting with the web but running a fat client running inside the browser. The next step is for these apps to run outside of the browser or perhaps relationship is flipped and the browser is a small part of this platform. I think the only companies that could make that happen right now are Microsoft and Adobe (and perhaps Oracle with it's recent purchase) and it won't surprise me if this were to be the next battle for internet/intranet supremacy.
  6. Desktop development at all?[ Go to top ]

    Good comments James. I'm having a similar experience. My open source test project delivers a SWING-based Java desktop. It's basically a fat client to a set of Web services that actually run the test. For a while I've been getting requests for an Eclipse plug-in and a more team-oriented way to build tests. Using a toolkit like Ext with AIR or Appcelerator seems to be the way to go. I don't have to get bogged-down in learning/writing/maintaining an Eclipse add-on (instead users access an Ajax interface through Eclipse's built-in browser) and I can deploy the work as a desktop app when customers need it. I just wish that the fat client could have been written in Java so I wouldn't have to maintain code in two domains of knowledge. -Frank Cohen http://www.pushtotest.com
  7. Titanium[ Go to top ]

    Hey Frank, Interesting discussion. I recently heard Javascript described as the assembly language of the web. I think that's probably a very telling sign. However, Titanium does provide the ability to write your desktop applications in C/C++, Ruby and Python - in addition to Javascript - and you can even mix and match functions, variables, etc between the languages - at the same time. I do believe that as desktop resurges in importance (again!) and mobile becomes common place (again!) that we need to re-think (again) our client/server architecture- something I've been pushing for a number of years. This does provide us with the ability to cleanly separate our back end SOA services (and even those of other providers) with our application code. Titanium is also open source and extensible and we'd love to work with anyone in the java community to bring java support to titanium. you can fork titanium at http://github.com/marshall/titanium or visit us on #titanium_app at irc.freenode.net to talk about titanium dev.
  8. Re: Desktop development at all?[ Go to top ]

    I just wish that the fat client could have been written in Java so I wouldn't have to maintain code in two domains of knowledge.
    There's no technical limitation preventing this from happening. It's just the lack of a standard (official or defacto, doesn't matter) that enough people buy into. I've been doing a cursory study of game theory and there's a specific concept in it that I think everyone needs to understand: "The Tragedy of the Commons". This is the mathematical analysis of a situation where if everyone contributes, everyone gains but if one person doesn't contribute, they gain even more, as long as most everyone else continues to contribute. This comes up a lot with situations like international fisheries and pollution controls. What hit me was that this and related situations explain so much about our industry. Why Windows has dominated the OS market, why X86 is becoming the standard computer architecture. In this case, it explains why we run clients on plugins inside of browsers. Many people can (and have) devised better architectures for networked applications but no one is going to bother with it in order to run one application. Flash is basically a required part of the browser now. Java has a pretty good toehold too. And Javascript is, of course, ubiquitous. If everyone turned around tomorrow and started using some awesome client platform, we'd all be better off. But anyone who continued to use Javascript has the advantage they get the customers because they don't require anything more than what the customer already has. So no one plans to change.
  9. i hope that in this forum the question of whether to use objects or not is a rhetorical one ;) as for air/flex vs. html/js: i have been using air/flex for the last 6 months. though i have been following this technology for a few years, it is only recently that i have some hands on experience. a few insights follow: 1. air/flex both the flash runtime in order to run. Specifically for Flex, this can be viewed as a virtual machine that is embedded in the browser. Similar to JAVA VM, it relieves the application from dealing with the specifics for each "environment". An analogy can be made that flex/air are to html/js, as java is to c++/c in terms of cross platform. 2. flex is now a mature application development framework that is very impressive. As one that has experience with both desktop application development with Delphi and .NET and web applications with JSF/js/html/etc.., i was very much at home with a web application with the type of paradigms and components are available within flex sdk. 3. adobe, historically a company targeted with tools towards graphic artists, are pushing into the developer space - and they are pushing hard, especially into the java community. After, they are primarily battling Microsoft. Apart from pushing and sponsoring open source projects that are community driven, the sdk itself is open source, there is a formal spring-adobe integration that is very interesting, they opened up a market place to showcase and sell applications as well as components and much more. 4. moving an application from browser to desktop and back is very very very simple. Desktop applications have the privilege to make use of a bunch of stuff that are not readily available, or easy to implement, in comparison to web applictions - having a local database, working offline, opening parts of the application through keyboard shortcuts, etc. In general, most of the code that once ran in a browser will on the desktop with just a few project definition and compilation changes. 5. lastly, there is also an eclipse plugin for flex - it still has some work to be done in terms of refactoring capabilities, but in general it is mature, robust and has all that would be expected from and no, i don't work for adobe ;) what sparked my comments is the quote from the initial post that i do share with the author, which is part of my enthusiasm The thing that annoys me most is that the older I get the less I seem to be able to read JavaScript. And yet JavaScript appears to be the direction of the language of choice for building desktop applications.
  10. Frank, I fully understand your concerns, IMHO JavaScript is weak and when the number of lines increase it becomes a nightmare to manage. I don't believe Flex, AIR, SilverLight and JavaFX are going to replace the old web technologies because the future of web is bright, no longer Internet Explorer is the only player driving the web and we are going to see tons of innovations in the web space trying to achieve the same level of "richness" of those browser plug-ins. Furthermore, the mobile web is going to be the same as the desktop web, that is, the same technology, One Web, as guys at Opera say. There is a server centric approach to make RIA applications programming mainly in Java. For instance with ItsNat (the project I'm involved) you code web applications with the same style as in client but in Java using Java W3C DOM APIs and receiving Java W3C DOM Events. And of course GWT is here too if you want a client centric approach coding in Java.
  11. I guess with all this JavaScript and custom new scripting languages running desktop apps that maybe we don't need a real object oriented programming language on the client side?
    For any standard, non-AJAX server side based webpage, you don't need OO javascript. It's a fact that javascript is more and more the way to go if you want to run a decent application in the browser. Look at Chrome, that specifically aims at optimizing the execution of javascript code. I found Ext and decided it was worth the (steep) learning curve, as it can be used in OO fashion, it's cross browser compatible, and it has most of the components I need (And it looks good too). Besides that I love the dynamic language features which I begin to miss in Java :) Note that I say 'application' as it shouldn't be used for a simple website. I find coding in javascript very, very convenient. It's not a static typed language, and not scrictly an OO language, but it's possible to write OO like 'classes', which is good enough for me. Having said that, I'm now learning AS3 and guess what: Coding is more of the same... (Ofcourse it's based on ECMA script too). Pity is that Flash doesn't come with all the UI components you need, for that you have to use Flex or build them yourself. Coding in Flash is a nightmare, so you'd need FDT, FlashDevelop or something alike. I think the baseline here is that you should use the right tools for the right problem, and that the learning curve is not in the language you use; it's in using the components and learning the component API, on top of some solid experience in separating application architecture/business concerns. Well separated concerns may lead to a more complex OO design, which might be better maintainable once you know the patterns used and once you know your way through the code base. For the user interface (complete applications), I'd pick the suite with the best UI components (Ext IMHO). For simple webpages, my choice is still plain old JSP's...