Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Why hasn't the Embedded Browser Caught On?
At 9:01 AM on Mar 3, 2005, Sebastian Ferreyra wrote:
Fresh Jobs for Developers Post a job opportunity
We all know HTML/XML/CSS has been for a while now a very flexible framework for the presentation of information and for general interaction with the user. Its drawbacks have always been found elsewhere, in such things as a lack of proper network support, limited control of the printing process, the low performance of scripting engines, and the fact that nothing very big can be done with scripting before mantainability requires hiring a programmer that's worked in a circus juggling bottles of nitroglicerin. (where did I get that from?)
For all these shortcomings, Java has been providing excellent support since before HTML and the other standards I mentioned were even fully usable for application programming. Moreover, it's been obvious to a lot of people for almost that long, how powerful a browser embedded in Java would be for providing what would essentially be an enriched standards compliant client. The list of benefits is too good to be ignored:
- Enhanced printing (efficient mail merging, control of page layout, etc.)
- Client side network services for receiving notifications
Enhanced control of the client machineYet, more than 10 years have passed and I can't avoid asking why such a framework isn't commonplace yet? What happened? Am I missing some great big drawback that's just too big for me to see? I know there are Java based browsers around, such as the Ice browser and a few more, but still, I think adoption should have been more widespread.
Perhaps the reason, or part of it, is the fact that many people still perceive HTML as high-level and they like to do things at the low-level, but I don't know if this is enough to explain it. I started my career doing assembly language and I love low-level programming, but when it comes to getting things done, you have to go with what's best suited for solving the problem at hand. Perhaps I'm wroung, perhaps it's more common than I think.
But if this were the case, then Sun would have perceived the market trend and provided more integration with current browsers, perhaps it would have worked more on the now abandoned HotJava browser. So, what happened? Am I the only one that sees value in this?
Sebastian
17 replies so far (
Post your own)
Re: Why hasn't the Embedded Browser Caught On?
Maybe you have not seen the JDIC project?.V
ps: http://weblogs.java.net/blog/mreinhold/archive/2005/03/mustang_experts.html
Re: Why hasn't the Embedded Browser Caught On?
This only works for Windows and Linux. I'd don't think that's what he's interested in.Re: Why hasn't the Embedded Browser Caught On?
> Maybe you have not seen the JDIC project?Yes, I have seen it, although the link you provided is about a request for Mustang Experts.
I realize I failed to mention it in the post, but the current state leaves much to be desired still. Perhaps I'm wroung, but AFAIK you can't do much more than just embed the browser. You can't bind to events fired on elements, can't modify the DOM, etc.
Probably, at some point this will be available in JDIC, but nonetheless it is suprising that after all this time we're at such a primitive stage with respect to this.
Seb
Re: Why hasn't the Embedded Browser Caught On?
There are two problems here. As has been discussed before writing a browser that can display even 90% of sites correctly is really hard. Since browsers such as IE "correct" bad HTML and have there own enhancements you are always tracking a moving target. I worked for a few years on a browser for the embedded market and it was really hard and you had to test every page on the internet because there was always another problem. I use Firefox and even that does not display all the sites "correctly." Along with that there is the problem that if you are addressing the embedded market then if you have all the features (JavaScript, Style Sheets, plugins...) then your memory foot print and CPU requirement get large enough that your per item cost gets very large.Secondly product such as ICE or Espial are quite expensive. So much so that I think a lot of developments just go to a Windows CE type solution.
Re: Why hasn't the Embedded Browser Caught On?
Well, displaying HTML as it is found in the wild is a very difficult proposition.However, I think the idea here is to use your own well-coded HTML for creating the display of your GUI.
I think it should be an attractive way of doing things, but since it hasn't caught on, I may be wrong.
Currently engaged in Weffo web architecture outline and the Flying Saucer xhtml and xml+css renderer
Re: Why hasn't the Embedded Browser Caught On?
I think that implementing and embedding a full java compliant and performant browser (XHTML, CSS, Javascript, etc) and interacting with it through DOM calls, is far too complicated for what you get out of it.Re: Why hasn't the Embedded Browser Caught On?
> I think that implementing and embedding a full java compliant and performant browser (XHTML, CSS, Javascript, etc) and interacting with it through DOM calls, is far too complicated for what you get out of it.Well, the implementation would be done only once, and available for all, like Swing. So it would be just about embedding it.
Interacting with the DOM, other than the verbose method names should be no different than interacting with Swing, AWT or SWT on a properly deviced embedable browser.
Seb
Your basic assumption is wrong
You say: "We all know HTML/XML/CSS has been for a while now a very flexible framework for the presentation of information and for general interaction with the user."This is just plain wrong. HTML is a great framework for presenting information. Interacting with it is quite different - and much more difficult. HTML is quite limited.
A few examples:
The select-and-drag way of interaction is not supported.
Making a multi-level menu where the items are enabled/disabled depending on state is very hard.
Multi-select lists isn't easy to do. Just a simple notepad application is hard, if you want to support undo/redo.
So using HTML instead of e.g. Swing, AWT or SWT for an even slightly complex UI seems like a bad idea.
Re: Why hasn't the Embedded Browser Caught On?
> > I think that implementing and embedding a full java> compliant and performant browser (XHTML, CSS,
> Javascript, etc) and interacting with it through DOM
> calls, is far too complicated for what you get out of
> it.
>
> Well, the implementation would be done only once, and
> available for all, like Swing. So it would be just
> about embedding it.
>
> Interacting with the DOM, other than the verbose
> method names should be no different than interacting
> with Swing, AWT or SWT on a properly deviced
> embedable browser.
>
> Seb
I agree that it can be done. My point is that if you have to go through the hassle of deploying the JRE and the browser to the client renouncing before hand at the ubiquity (and speed) of the native browsers, you are not gaining much compared to a standard Swing/SWT.
If you are already deploying a desktop app to you client what are you gaining in embedding and delivering a beefed-up web site? You can achieve the same thing (and much more) directly with a Swing app.
Your java-browser powered web site will still be much limited in comparison to a full app.
Vania
Re: Your basic assumption is wrong
> The select-and-drag way of interaction is not supported.That depends on the browser actually, IE supports it. I'm not sure about firefox.
> Making a multi-level menu where the items are enabled/disabled depending on state is very hard.
This is not hard really, if you're going to do it in Javascript. But the idea is to use Java for the browser's peripheral interface, menus included. HTML is left for documents, forms and various panes, where its flexibility is exploited best.
> Multi-select lists isn't easy to do.
I've developed quite sophisticated (attractive, efficient and intuitive) user interactions with HTML/CSS/Javascript. I've fallen short in the things I've mentioned before, like proper network support and customized printing capabilities.
> Just a simple notepad application is hard, if you want to support undo/redo.
Precisely, undo/redo could be handled well with Java.
Seb
Re: Why hasn't the Embedded Browser Caught On?
> ... if you have to go through the hassle of deploying the JRE and the browser to the client renouncing before hand at the ubiquity (and speed) of the native browsers, you are not gaining much compared to a standard Swing/SWT.Well, if you're using the native browsers, through JDIC, for example, you don't need another one. If you were to use a Java based browser, then that should be part of a single installation process along with the rest of the client.
Speed isn't an issue. I haven't played with the Ice browser in a while so I don't know how it stands with standards compliance specifically, but it used to have faster page scrolling and layout than IE a few years ago. and it's 100% Java.
> Your java-browser powered web site will still be much limited in comparison to a full app.
That depends on architecture, exploiting each technology at what it does best can't be beat. The problem as I see it is the current lack of proper tools.
Seb
Re: Why hasn't the Embedded Browser Caught On?
The application I am working on is doing this. Our problem was not finding an embedded browser that could render all the sites on the web, it was finding an embedded browser that could render just our own UI well. We use a mix of standard data entry forms and HTML... the browser component is just a part of the UI. However, when we started porting our application to the Eclipse RCP, we found that the Eclipse Forms UI replaced much of what we were getting from the browser. We still use the browser as part of our UI, but not as much as we used to.The big problems we had in doing this were 1) finding a browser component that is affordable and actually renders nicely is not easy; and 2) the programming becomes more complex when you embed a browser component. I really think these are the big issues. Eclipse has a nice browser API that makes things fairly easy, but it's not a very comprehensive API - certainly not like using other UI widgets such as buttons or combo-boxes. So you do have to adjust how you program to use the browser widget, which means you now have to weigh your options - is it worth the extra effort? In our case we thought so, but we removed a lot of what we did with the browser when we saw that we could get reasonably similar results in a lot of cases using the Eclipse Forms API, which resembles a browser-based GUI somewhat (we still embed the browser control in some of our Eclipse Foms UIs, usually as the summary page of a multi-page form).
We still use the browser widget some, but now it's mostly for our interactive HTML-based report viewer and our help viewer. We do still have a few very graphic UI forms that are all browser widget - sometimes there is no easier way to do a graphic-intensive form than to use HTML, CSS, and Java Script... and in Eclipse the browser widget is either IE or Netscape, both of which can render our UIs very nicely.
Re: Why hasn't the Embedded Browser Caught On?
1.) Till recently most browsers were very large.2.) There are embedded browsers but they tend to have problems.
3.) Most of the use cases the area you want to present in a browser window is much smaller than the typical web page either embedded in a desktop app or in a device.
I think three is really the kicker HTML based solutions to date are not flexible enough to nicely layout a page if the dimensions change.
Things are changing see minimo but it really needs to handle two things well first it needs to be a far better layout engine to handle odd display area sizes and it needs to continue to support "standard" plugins so it can be beefed up as needed for a particular solution. This means browsers such as firefox need to move almost all functionality to a plugin module. This includes things such as javascript.
For the dynamic layout problem I feel its up to the W3C to step up and help develop current technologies to the point that a web page can display correctly for a number of display sizes a simple extension to http to send the preferred display size and a few more parameters such as supported standards for a browser would be a significant help. This would allow websites to send "alternative" markup easily for a number of cases.
Even better may be to develop Http Meta protocol mtp:// to exchange meta information before the first http connection is established.
Re: Your basic assumption is wrong
> > The select-and-drag way of interaction is not> supported.
>
> That depends on the browser actually, IE supports it.
> I'm not sure about firefox.
No, unless your changing the origional assertion. If we are talking about standard HTML, XML ... then no! Sure you can do anything with IE because you can customize it with ActiveX controls but that is just normal development specific to Windows on x86 platforms. But this is not standard. You are falling into the trap of thinking that anything IE does is standard.
> > Making a multi-level menu where the items are
> enabled/disabled depending on state is very hard.
>
> This is not hard really, if you're going to do it in
> Javascript. But the idea is to use Java for the
> browser's peripheral interface, menus included. HTML
> is left for documents, forms and various panes, where
> its flexibility is exploited best.
There is already a swing component that renders HTML, sort of. Why not just use that? I'm not sure what you propose that isn't already supported in swing.