Posted
by
timothy
on Saturday July 23, 2011 @03:41PM
from the oh-you-want-everything dept.

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 [mozillalabs.com] 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 [mozillalabs.com], 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.

Words Cross-Platform hint at this not being an option, nevermind IE's blatant disregard of standards.

How about the words, "Oh, and my customers are local police & highway patrol type organizations, most likely running an aged Windows box (probably IE6, too)"? Claiming you want something cross-platform is all well and good when you're trying to sound like a good Slashdotter, but when the facts are that your customers are all on Windows, it seems pointless to worry too much about it.

Pretty much my thought. If they have out-dated boxes, the odds that they'll do much more than click Next/Next/Next/Finish on an MSI to get your product up and running is close to nil. Writing a wrapper around IE is super simple, allows you to control the experience greatly. And since you control everything from web server to web page, you don't care what standards it supports as long as it supports your needs.

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.

No mod points or I'd just mod up. Why add the extra overhead of a server and a browser to your app. And on older machines.
Can you say slow rube-goldberg machine (and just as fragile likely).K.I.S.S.; keep it simple and don't add all that junk when you get nothing for it.

No mod points or I'd just mod up. Why add the extra overhead of a server and a browser to your app. And on older machines.
Can you say slow rube-goldberg machine (and just as fragile likely).
K.I.S.S.; keep it simple and don't add all that junk when you get nothing for it.
Mycroft

Perhaps there are plans to turn the application into a network wide, integrated solution once the bugs are worked out and the security force has habituated. Think about it. He's programming for law enforcement-style organizations, and there's no way they're going to a) be able to shell out for an overhaul at once, and b) want to prove that the solution is workable on an individual level before linking it up. Or maybe there is no reliable connection, but network functionality will be built in.

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.

Many applications can be written to install/run completely with user privileges. Though some platforms make this easier than others. A lot of apps I download for OS X, I just launch from the download location and only copy to/Applications when I know I want to use it long term. And even then, I can make the app owned by me so updates don't require admin privs.

Back in those unix days, most people connected to a server using "telnet" and ran the application on there. There were certainly still a few of those around in the mid to late 1990s. Web based apps are a modern day equivalent of that.

Yeah really, I had a job previously where we'd have to do a lot of logging with a web app. Unfortunately, it would be slow, sometimes the entries would crash out and the app would often times be down when the router would crash.

I'd personally rather have just done the logs on paper in most cases, but that was against company policy.

Actually, there is a comprehensive networking and collaborative side to this WebApp, and those clients selecting to use the app with no network simply loose out on that feature. However, it's fully available within Intranets. Plus, mobile workstations can operate without any connection and then collaborate filly and securely when a connection is established.
I'm somewhat amused by how much people have read into my situation from the scant info I've offered. Simple story: limited resources, and a client tha

Because you want to charge your customer for some crapy hunk of klugeware you build out of code snip-its you had laying around from other projects, instead of building something appropriate for their needs.

Hmmm. Perhaps one of the most important "needs" is "low cost". This is government, after all, and Americans have spoken clearly that they want SMALL GOVERNMENT. Well, this is the kind of crime enforcement computer system you get with small government. This is the very end result of voting for fiscal conservatives, who are just trying to maximize tax dollars. So not everyone can afford a system that will pay off in the long run, some of them have to do what the voters told them to do.

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/ [thedailywtf.com] ), it could easily feel snappy.

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

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.

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.

Updates. Web apps always run at the latest version, desktop apps do not.

This is false: suppose that a given Web application's releases are linearly ordered, that is to say, given any two distinct release versions, one is always "later" than the other. Then any hosting organization with sufficient resources can run twodistinct versions —at most one of these versions can be the "latest," contradicting your claim that "Web apps always run at the latest version."

Java can be a useful sort of in-between option, and has Java WebStart. Pity the UI takes so much work to make it look acceptable, and a pity it's difficult to make your application fit in with the platform, but it's certainly a lot more capable client-side.

Updates. Web apps always run at the latest version, desktop apps do not.

Except the poster had to create a local app because said devices have no internet connection. Otherwise he'd just mandate that the web version be used instead.

So it's a desktop app, just fashioned after a static web app.

Also, updates may be easier to deploy, but there's often a lot of howling and screaming and such from existing users. You hear it every time Facebook changes anything. You also hear it when Netflix changed their interfac

Those who modded you up are idiots, and so are you. The summary explains that the app already exists and is a web app. He's only looking for a way to make it self-contained so it can be hosted on the client.

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

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.

Portable firefox in the application install with a link to that runtime would be usefult as well.. since this way you have a single runtime to test against... Though I don't see how prism is not a fit anyhow... since the development of this needs to support a browser from 3 months ago, at least you have a fixed point to work against for your desktop install.

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.

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.

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. Un

Prism didn't actually evolve into Chromeless, it lives on in a project called WebRunner: http://www.salsitasoft.com/webrunner/ [salsitasoft.com] Prism was originally called WebRunner, funny fact. I wouldn't expect Chromeless to die just yet.

"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?

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.

First, why not just install the app and put a URL link on the desktop pointing to http://localhost:7777/ [localhost]? 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.

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.

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.

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 [suckless.org]. 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 th

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 t

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. E

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.

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.

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.

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 [wikipedia.org] 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 t

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?

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.