|
Replies:
9
-
Last Post:
Jan 12, 2007 7:12 AM
by: evickroy
|
Threads:
[
Previous
|
Next
]
|
|
|
|
|
|
How to kill the Seductive Web Browser?
Posted:
Dec 14, 2006 5:42 PM
|
|
|
Dear All,
So Java 6 is upon us, with all its desktop improvements, and frankly looking at the current crop of increasingly hacky AJAX web applications I'm starting to think maybe Swing/Java Web Start rich clients are the future.
The problem, though, is that the Web browser is seductive.
When my client first comes to me and says 'we just want a simple, entry-form application', then really a browser-based app is the right choice.
Later when my client says 'we want you to link these two drop down boxes to update in real time', then I could rewrite the whole thing in Swing/JWS, but you can also just hack in a bit of AJAX and you get to the same place quicker.
Even later when my client says 'how about a bit of drag/drop here, or a dynamic menu there', then again you could bite the Swing/JWS bullet, but really, you've already invested in your browser UI and, with just a bit more JavaScript/DHTML, you can hack it in.
This process continues until one day you realise your web app is so bloated and full of hacks you wish you had done it in Swing/JWS to start with, but by then it's too late. So my question is:
What is the killer feature that, at the start you know you might want, that is enough to make you say 'I should start off with a Swing/JWS client'?
The problem seems to be that most anything (real-time updates, drag/drop, wizard-type state management, etc.) is do-able in some scrappy combination of JavaScript/DHTML/server-side framework, even though you could no doubt implement it much more cleanly and robustly in Swing/JWS.
So what isn't possible, or at least advisable, in JavaScript/DHTML? Where do we draw the line, before we invest so much in our Web UI that it's too expensive to change?
Richard
|
|
|
|
|
|
|
Re: How to kill the Seductive Web Browser?
Posted:
Dec 15, 2006 8:02 AM
in response to: kennardconsulting
|
|
|
My hope is that despite the apparent problems with JWS that people start using it anyway. If some people start using it by default, then some users will need it. If some users need it, it's more likely to be available generally. It would be nice to see Java support spiral up. It starts with having a good enough platform. (Is JWS good enough?) And then a few people just plain developing on it. Early adopters face extra pain but can also face greater rewards if successful. It could be the right time now or soon.
I see it as a Microsoft vs. Java vs. the general web vs. Mozilla battle coming up in the next few years. I think the web generally is in the strongest position right now. But in a few years, one of those other parties might gain some real ground. Could happen.
|
|
|
|
|
|
|
|
|
Re: How to kill the Seductive Web Browser?
Posted:
Dec 16, 2006 3:02 AM
in response to: kennardconsulting
|
|
|
The obvious thing that a WebStart application can do, but a browser based system can not, is work offline.
I would be much happier about the Revenue's online tax return submission if it was WebStart based and allowed you to continue working even if their system had crashed or was chronically overloaded (which isn't unusual close to the deadline).
|
|
|
|
|
|
|
|
|
Re: How to kill the Seductive Web Browser?
Posted:
Dec 18, 2006 2:01 AM
in response to: mthornton
|
|
|
Exactly, working offline is the borderline. Now I don't know how are things in the USA, but in Europe being connected 100% of the time is just plain fantasy. While it's theoretically possible in your home country with a mobile connection, as soon as you move abroad the bills raise even 100x and you have to rely upon hotel wi-fi and such - but they are still expensive (even though not 100x).
Besides of this, I don't want to be always online and to put everything online. But I guess I'm a conservative mind...
Message was edited by: fabriziogiudici
|
|
|
|
|
|
|
|
|
Re: How to kill the Seductive Web Browser?
Posted:
Dec 18, 2006 7:58 AM
in response to: fabriziogiudici
|
|
|
> in Europe being connected 100% of the time is just plain
> fantasy.
I find my cable connection pretty reliable, however the reliability of a link to some specified server is significantly less. There are plenty of places where the link can break or be merely very congested. So, for example, early evening links between my home and office are frequently poor.
Links to the Revenue's systems can be expected to be poor in the vicinity of January 31 each year (no doubt a different date in other countries).
|
|
|
|
|
|
|
|
|
Re: How to kill the Seductive Web Browser?
Posted:
Dec 18, 2006 8:06 AM
in response to: mthornton
|
|
|
Neither my experience with cable connections is bad, but I was referring to mobile connections - i.e. wireless.
|
|
|
|
|
|
|
|
|
Re: How to kill the Seductive Web Browser?
Posted:
Dec 18, 2006 12:38 PM
in response to: kennardconsulting
|
|
|
Working offline is not the only benefit of a Java Web Start approach on Ajax hack.
With a JWS client you can achieve a real desktop integration; add the application in the icontray, launch native app and so.
For example, our docdoku.com application (a document centric collaborative tool) allows to edit a file with the associated program file and after the user has saved it automatically re upload the file to server.
|
|
|
|
|
|
|
|
|
Re: How to kill the Seductive Web Browser?
Posted:
Dec 18, 2006 12:39 PM
in response to: kennardconsulting
|
|
|
Working offline is not the only benefit of a Java Web Start approach over Ajax hack.
With a JWS client you can achieve a real desktop integration; add the application tothe icon tray, launch native app and so.
For example, our docdoku.com application (a document centric collaborative tool) allows to edit a file with the associated program file and then, after the user has saved it automatically re-upload the file to the server.
That feature is purely impossible to implement in ajax !
|
|
|
|
|
|
|
|
|
Re: How to kill the Seductive Web Browser?
Posted:
Dec 22, 2006 2:05 PM
in response to: kennardconsulting
|
|
|
I usually draw a number of lines to decide which technology to use.
Is the architecture decidedly pull or push, i.e. is it mainly to query or to post information? If it is pull, I like to lighten the architecture as much as I can, and use existing bases--the browser, in this case. If it is mainly push, I'll probably make it a Java client.
Is there a real possibility of expanding the technology? It might be easier to update a browser-based app--just update the page and let them pull--than a stand-alone application. It's tricky here; haven't worked it out myself.
Is it really necessary to keep a connection to a server? Can we collect all the data at once, then send it? If so, go offline application. If you really need that live connection, however...
Are speed and handling of the essence? You probably won't get much faster than with a homegrown desktop application. You also have more control over error handling than with browsers.
People generally feel more comfortable with a browser application because it doesn't require them to install extra software: they can use the familiar face of their browser software instead of a dedicated program. They feel more in control when using a browser.
|
|
|
|
|
|
|
|
|
Re: How to kill the Seductive Web Browser?
Posted:
Jan 12, 2007 7:12 AM
in response to: tarbo
|
|
|
> People generally feel more comfortable with a browser
> application because it doesn't require them to
> install extra software: they can use the familiar
> face of their browser software instead of a dedicated
> program. They feel more in control when using a
> browser.
ALL of my users are more comfortable with Excel, Word, and Outlook, so they expect EVERY application to react and perform in a similar manner. They are comfortable with the browser interface, but they don't consider it an interface for doing any real work. Just interactive reporting, online shopping, simple state management, or... browsing. 
There is no single answer here because it really depends on the requirements of the application you are currently developing and the expectations of the user. The good news is that you have both options in your toolkit. Just use the right tool for the job at hand.
Erik
|
|
|
|
|
java.net RSS
