Ask Slashdot: Chromeless Cross-Platform Browser?
blakieto writes "Mozilla has the Prism project, which turned into Chromeless, which seems to have died [Note: last update was May 31]. I'm seeking a no-interface-what-so-ever cross-platform browser for use as a 'user interface host' to a self-hosted web app. Slight background: I've a professional market web app, with a large portion of the customer base unable to access public Internet connections. So, I want to make a version of my product self-hosted, with the web server and web app and everything necessary to run the web app locally installed on a user's machine. I have everything except a chromeless browser. Oh, and my customers are local police & highway patrol type organizations, most likely running an aged Windows box (probably IE6, too)."
I'm not sure I understand. Prism still exists, and it sounds like what you want, so I don't understand why you say it "turned into Chromeless."
It's also very easy to embed Internet Explorer in things. A friend of mine once "wrote a Web browser" in Macromedia Director using about six lines of code.
Breakfast served all day!
While web applications are often a bad idea, this takes it to a whole new level of bad. Your users get none of the benefits of a web app, but many of the drawbacks.
If you care even the slightest about your customers and their experience, why not just provide them with a real native application that has the same functionality, in addition to a sensible UI and architecture?
Use a mature, cross-platform toolkit like wxWidgets or Qt, and you'll be able to support all sorts of Windows systems, in addition to many other platforms.
Use firefox with --chrome="path_to_your_homepage"
You can always use Java and it's Java display HTML. A single file (.jar) containing everything: server & browser. http://www.devdaily.com/blog/post/jfc-swing/how-create-simple-swing-html-viewer-browser-java. // timtux.net
Super easy to create an app that's nothing but a webkit instance. Unbelievably easy.
Are you more interested in the HTML/CSS rendering engine or in the JavaScript engine? That may determine whether you want to use something like Prism or Chromeless vs WebKit. My gut tells me you might find WebKit easier to embed and work with, but I don't know if Google or Apple are sharing their fantastic JavaScript engines, and your needs for speedy JavaScript will definitely play a role in your choice.
We're doing this at work, and we've weighed many options. Chrome's app mode, Prism, custom xulrunner app, embed IE, custom QtWebKit app; they all work, and with little effort. It's great how many options there are.
Why would you think chromeless was dead? It looks like a project that started last Oct with a new release every few months. It's only been a few months since their last update, and the forums have recent activity. They also have commits up until the end of last month? Are you trying to motivate the devs?
We are happily using prism for our customer's (also in law enforcement) whose IT department refuses to let them install "firefox". Right now prism is great but it would be nice to eventually get those ff ver 4 and ver 5 faster javascript interpreters (engines?).
I'm not sure if using --chrome would help us because I suspect I would have to use the firefox setup.msi file which would give away our secret as usually the IT department is the group going around installing our software on our user's machines. Unless creating my own ff installer is simple (I'm experienced creating an msi file but the prism one is so simple because all it does is copy files - no registering of dlls or registry changes).
I don't mean to plug anything for anything else, but on my 486 I use OffByOne in Windows. It's the FASTEST browser i've ever used, and I mean that, and not 'marketing fast' like kmeleon / firefox.
It comes at a cost of lack of CSS, source and no update since 2006, though.
Prism didn't actually evolve into Chromeless, it lives on in a project called WebRunner: http://www.salsitasoft.com/webrunner/ Prism was originally called WebRunner, funny fact. I wouldn't expect Chromeless to die just yet.
People like yourself, who were apparently born after 2000, aren't aware than for decades we used networked native applications quite successfully. In fact, most users of those apps who are now stuck using web apps will say that they'd love to go back and use real applications again. Their productivity would rise immediately.
Sure, those systems didn't consist of "web browsers", "web servers", "HTML5", "JavaScript" and all of the other buzzwords that the ignorant today consider to be the only way to create networked applications. But these native apps did run on many different systems, and they could communicate with server software running locally or remotely. It was quite trivial to implement auto-update functionality, so that users always had the latest version. It was more than possible to ensure that the communications were done securely. Basically, anything a web app can do today could be (and was!) done using a native app in 1975, if not earlier.
You guys don't even need to look any further than your dear web browsers like Chrome and Firefox to see how all of the supposed benefits of web apps are just as easily realized when using native apps. Then there are the many benefits that only native apps offer, like much better data security and significantly better performance.
"The âoeChromelessâ project experiments with the idea of removing the current browser user interface and replacing it with a flexible platform which allows for the creation of new browser UI using standard web technologies such as HTML, CSS and JavaScript." ...What about XUL?
If they what they have now is IE, why not use IE? I mean, besides the horrible incompatibility.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Then the inferior web application would be ditched.
That isn't so clear from the OP. Would you rather maintain versions of a program for Windows, Linux, Mac OS X, iOS, and Android, including the annual fees payable to Apple for access to the iOS platform, or would you rather maintain versions for Gecko and WebKit, with no annual fee?
Yea, exactly. And, provided you do your coding right, those versions can be one and the same. Perhaps some extra css for nonstandard features(like rotating text), but it could probably be done with a single version. And, honestly, compared to the VB applications that are probably in use(see http://www.thedailywtf.com/ ), it could easily feel snappy.
I'm not sure about this instance, but MS frequently requires that long to get the implementation right. Sometimes even longer, it's been like 16 years now and they have yet to get profiles right. It's absolutely inexcusable that after all this time I can't just copy or rename a profile more or less whenever I want without having to use special tools to do it.
Or how about the registry. Why they haven't given up on what was clearly a bad idea a long time ago is beyond me.
Oh, and my customers are local police & highway patrol type organizations, most likely running an aged Windows box (probably IE6, too)
It seems like you need to code something using MSHTML (or hire someone who can do that for you). Almost all modern standards compliant HTML/JS engines have quite indecent memory requirements - and from your words I can conclude your clients PCs may have very weak configurations.
UNIX [...] allowed multiple users to use the same physical computer, and as part of this it gave each user their very own isolated "home directory".
It also allows the administrator to mount /home noexec.
First, why not just install the app and put a URL link on the desktop pointing to http://localhost:7777/? Second, are you really sure it makes sense to have a self hosted web app? I, for one, absolutely despise when companies ship some tool that installs a web server on my machine and makes me use it through a web browser. IIRC, HP did this kind of garbage for managing their printers. Write a god damn native app if it is just going to install on my local machine!
I realize that you probably want to save some money and not write two pieces of software that do the same thing, but how hard can it possibly be to make a UI in .NET that is at least as good as your web interface? Share code if you have to. If you've written the software correctly, you should be able to share the model level functionality between the two apps. Or install the web app on the local machine but create an API that the native app can hit.
It really sounds like you are approaching this problem from the completely wrong angle.
Don't forget, when looking for an innovative browser feature that you need implemented, look no further than Opera, because they already did it.
http://www.opera.com/support/mastering/kiosk/ Opera kiosk mode has plenty of features that would work great for you.
insight through the mind
That would depend on whether or not I thought I could provide a quality user experience through a standard HTML/JavaScript interface. I could also pare down that list of platforms initially. If I'm targeting business, chances are I can require Windows without much risk. Maybe branch out into OS X to get a slightly larger market share. I can probably ignore Linux completely (sorry Linux users, but that's just the way it is) At this point, the cost of iOS shouldn't be a big deal and I'm really just writing a UI. The hard bits, the business logic, will all be shared either through common libraries or centralized server.
On Win32 you can easily embed MSHTML with a little bit of COM glue. Of course for other platforms YMMV. You could consider using WebKit and writing a simple shell for it. Alternatively, if you don't mind a bit of Windows pollution on non-Win32 platforms you could use WINELIB to compile your MSHTML shell so that it functions just the same. Wine embeds Gecko in quirks mode so there is a surprising amount of compatability support.
Or you could just write it in PyQt and have it run on Windows, OS X, and Linux without a recompile.
I'm not sure I understand. Prism still exists, and it sounds like what you want, so I don't understand why you say it "turned into Chromeless."
I think he meant this announcement, that focus is shifting from Prism to Chromeless.
But, OP is wrong about "[Chromeless] seems to have died [Note: last update was May 31]" - yes, the last blogpost was May 31, but the last source code commit on github was less than a month ago. That doesn't sound 'dead' to me.
So Chromeless sounds like the way to go here, for what OP is looking for.
I built a simple app using http://www.kirix.com/labs/wxwebconnect.html . Since I was using wxwidgets anyway, it was a no brainer.
For those of you who question the approach, it enables you to develop a a single UI, that can easily be used both locally and remotely. In my case, for an embedded medical product, I have one set off CSS that is used when run locally and using a touchscreen, and another set of CSS that is used for remote on any web browser.
Doesn't help me on iPhone or Android. And I'd have to consider that I'd lose the benefits of native development tools and OS integration. I'm not normally overly concerned with making a program cross-platform.
Look at CEF: http://code.google.com/p/chromiumembedded/
It lets you self-host a HTML widget(s) and works on Win32, OSX and Linux. Its a wrapper around the Chromium browser, I use it in the Steam client for showing web pages in our thick app.
The OP is, which is why I recommended it.
I personally have a personal project I developed as a web app. I then changed direction and it eventually evolved into a media center platform using Nginx, php w/fpm and a customized version of Surf. basically just stripped out all the UI widgets and set it to fullscreen on a Linux box connected to my TV.
Thats not the point though. What I am saying is no matter what you are trying to accomplish you will probably have to find something open source and customize it to your needs. I dont need anything other than Linux support for what I am doing, but I think there are unofficial Win builds of Surf.
You will no doubt have to do customizations though.
Replace %windir%/system32/userinit.exe with webkit.exe and a custom config file
Right, as someone suggested it's very easy to embed the customized browser component into your own thin frame. Many browsers provide these components. Just put it up together with integrated web server, database or whatever you need to run the application. It can be easily automated using custom installer. If I were to write something similar from the scratch I'd think about separately supporting offline and online modes with transparent synchronization. There are plenty of pseudo-HTML5 libraries emerging these days that try to use the best facilities available in your system.
The OP said he wanted something cross-platform, but made it sound like he'd be selling in a niche market where Windows would most likely be a given. I don't think we know nearly enough about the OPs actually requirements. I think he's probably approaching it all wrong. A locally installed web app is almost never a good idea.
Another option which possibly meets the requirements of the poster better is to sell a web appliance to these clients - a server box with a simple web server serving only this webapp on it which can be put inside any firewall on a local network - they just plug it in, and it serves pages on the intranet to any and all clients which need them. That would address the problem of clients without internet access, without trying to turn the web app into a desktop app and losing all the convenience of a web app. Easy to roll out updates, doesn't matter what device config is accessing it or what software runs on clients, handle all new devices automatically with no changes, central store of information which only has to be updated once, users can collaborate on data, etc, etc. All those things are much harder with a desktop client.
Otherwise when clients roll out platform x mobile phone for example which his cross platform browser app doesn't support, he's not completely out of luck, as he just deals with the server appliance, and all clients just need a web browser of some kind, not to run his specific binary. Trying to support an app which is in fact a browser *and* his software on umpteen different client platforms which are constantly changing at different clients is going to be way harder than supporting one server machine with known config which he can replace/update as necessary.
In a native app. If your web app already supports most browsers, just pick the most convenient one for each platform - mshtml/trident on windows for example. Otherwise just host a webkit variant. The steam client from Valve has done both at various points in time.
Geez....
Pampered, aren't we?
http://webian.org/shell/
That could easily be changed into what you need..
The Vimperator extension allows turning almost all GUI elements off, including tabs. It is also quite configurable, and a solidly cross-platform solution. I suppose the UZBL project, which by default provides just Webkit and extremely few UI options, could suit your needs, although it probably demands a lot of work and might be difficult to prepare for all platforms.
Or how about the registry. Why they haven't given up on what was clearly a bad idea a long time ago is beyond me.
They have given up on the registry. It's only included in Windows right now for backwards compatibility. Microsoft has been encouraging developers to stop using it for years now.
You may have OS and OS version independence, but you may not have web browser indepedence. And you can get quite a degree of OS version independence at least, and some OS independence and ease of installation/auto-update, especially if you use something like Java (which admittedly has its own disadvantages).
Server side crashes or failures can lose data, especially if your develoeprs are stupid. Porbably that's much rarer, but you do lose all your data at once. Client side crashes (or just unexpected browser or server behaviour) can lose small amounts of data, too, as anyone who's made the mistake of typing a lot of text in to a box in a web form rather than pasting it from a text editor can tell you.
I don't see why a web application would be easier for another developer to pick up.
The downside is a bit bigger than just speed, although speed is important (hint: in an interactive application a delay of a second or two is a very long time). The UI is never going to be quite as satisfactory and always a lot more mouse-intensive and fiddly. You're pretty much forced in to a page-based idiom. It's difficult to get the keyboard to work properly in a web application (accelerator keys? shortcuts? tab order? what do return and escape do?). It hasn't escaped users that most of the advantages to web apps are to the supplier/sysadmin and not to them. Web apps are always going to seem like an on-the-cheap alternative to users.
Grr, and this web browser keeps pausing and briefly ignoring my input as I type, leaving out some letters. Firefox appears to keep briefly thinking the page isn't responding because it's too damn slow.
One solution would be to use Appcelerator Titanium: http://appcelerator.com./
I've used this and it's a doddle to create a standalone webkit browser running your app. You can also embed Ruby or Python or (I think) PHP in your app if you want and there's an online packaging service that packages up your app to install as an .msi for Windows or other formats for Mac and Linux. Also, this is a fully featured Webkit browser with full CSS3 and HTML5. It's not the crippled version supplied with Adobe AIR.
It may also be helpful to know that if you drag a Google Chrome App (which is basically a web page zipped up with some metadata) from the browser to the desktop and then launch it from the desktop, it comes up without any chrome. Well, yes it's still Chrome but there's no... oh stop it, you know what I mean.
Years and years ago, Microsoft recognized the need for a standalone application that uses HTML as the UI. They call these class of apps "HTML Applications", HTA for short. You may be surprised to know that HTA lives on, even in Windows 7. The spirit -- if not the letter -- of HTA seems to have been promoted to a first-class UI approach in Windows 8, in which (we are told), the entire Windows UI will based on HTML 5 and CSS 3.
Running as you are on old Windows platforms, HTA might work well for you. One tip I'll pass along: you don't need to limit yourself to JavaScript when writing an HTA. You can use other scripting languages that talk to better to the underlying OS, such as Visual Basic. You'd be surprised how far you can go with this approach.
"We receive as friendly that which agrees with, we resist with dislike that which opposes us" - Faraday
If it's what he knows, more to the point if it's all he knows, then it's the only idea.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
As the information on the Mozilla add-ons page regarding the Prism add-on indicates, (https://addons.mozilla.org/en-US/firefox/addon/mozilla-labs-prism/), Prism is succeeded by Chromeless at Mozilla, but WebRunner has evolved from it as well. Have you researched it?
No, that's not an advantage of webapps, to the degree that you'll do at least as much work to make the fonts and such user-defined in a webapp as you will on a native program, probably even more. If you want user configurable, you probably don't want a webapp in the first place.
One trick is to use Google Chrome like this:
chrome --app="http://mail.google.com"
It's of course not fully featured with tray icon stuff etc. but it is supported feature of Chrome.
Using SWT and java it is pretty easy to embed a web browser in your app. it will correctly pick out a native installed browser and embed it. you can even add your own chrome. or use Visual Basic / .NET and IE, or the kiosk idea in opera like other posts mentioned.
Internet Explorer invented the term "kiosk mode" when it was introduced with IE4 in 1997. ;)