Chromeless Supplants Mozilla's Prism Project

mikejuk writes "Mozilla Labs has dumped its Prism project, that was intended to bring web applications to the desktop, in favor of a revamped and repurposed Chromeless, a way of building experimental web browsers, to provide yet another way to create a desktop app using web technologies."

Comments

Single point of failure development

[icebike]

Why does everything have to be built on desktop apps dependent on the web or web browsers?

We've been doing desktops since dirt, and have it pretty well understood, reasonably well standardized
across multiple operating systems. The building blocks are well understood, highly developed and
well documented.

So why does it seem as if everybody wants to make us dependent on a 24/7 connection to the
web, and why does it seem everyone wants to turn the browser into the building block upon
which everything else depends?

And don't get me started on clouds!!!

What do we gain besides a huge dependence on things outside of our immediate control.

Did events in Egypt not teach us anything about putting every thing on the web and in
the cloud?

Re:Single point of failure development

[ColdWetDog]

Browsers are lightweight, 'easy' to program. Cheap. More or less OS independent. So that's where the impetus comes from.

But I agree, sticking everything in the stupid browser is annoyingly limited. I can't imagine Photoshop or Maya being browser based. Hell, their browser based help systems don't even work well and that's just linked text - something a browser ought to be good at.

But the vast majority of users don't go past simple stuff - where a browser UI isn't bad. And Bog knows we ought to put everything on the network so that the poor little user can't screw things up.

That's our job.

Re:Single point of failure development

[PRMan]

Not only this, but it's not like desktop applications can't call web services or something. Just set up your desktop apps to call web services.

If the mobile internet has taught us anything, it's that we should be trying to cram everything into the browser, especially where it doesn't belong.

Re:Single point of failure development

[dvbuser]

making applications web dependent is another way to invade peoples privacy

Re:Single point of failure development

[mcrbids]

why does it seem as if everybody wants to make us dependent on a 24/7 connection to the web

How else do I say it: Because it's *easier*! Rumors that desktop application development is "well understood", well documented, and highly developed, are incorrect.

I'm an application developer, supporting both client-side and web-based models, and it's much, much easier to support a web-based model than a client-side model. With a web-based model, you can almost always replicate bugs reported by end users without much fuss. You hold the cards, so you can recreate problem scenarios and not have to bother the client with all that.

But, with client-side development, you run into situations where (I shit you not!) a combination of an antivirus package and MS Office (no, I'm NOT KIDDING) causes your application to mysteriously stop working. You can't recreate it, despite having a test machine with the same version of windows, similar hardware, etc. The only way to reproduce the problem is on the client's computer, and they are behind a firewall that prevents any remote desktop software from working.

Have you ever travelled 600 miles in order to discover that the problem was their antivirus in combination with a dumb file association with MS Office?

But when it's web-based, the problem is significantly easier to manage. Browsers are much more standardized than desktops. Javascript runs pretty much the same on 32 bit systems as 64 bit systems, PPC, ARM, or i386, Windows, Macintosh, Linux, or iOS, regardless of firewalls, antivirus, or whatever.

And to be truthful, end users are often unable to grasp basic things like saving files, let alone backing them up. But when it's web-based, I can provide a very, VERY strong assurance that backups have occurred within the last 24 hours, 365 days per year!

See the difference yet?

Re:Single point of failure development

[Redlazer]

You may be right, but consider the flip side of your argument: Imagine the disruption and outrage caused if the US, UK, or Canadian government did the same thing, and turned off our internet?

Re:Single point of failure development

[visualight]

All the browser based applications I've ever used suck compared to something similar written in c or c++ (maybe a reflection of how accessible it is to crappy devs and not of the concept). But really I've not run into many of those, there's just not that much need for actual applications in the browser.

What I do see more and more every week are "web apps" (hear me vocalize the quotes) that really need to be web pages. It's as if people can't put up a paragraph of text with a photo unless there's 4 layers of abstraction and 3 jquery scripts to help them.

Re:Single point of failure development

[c0lo]

why does it seem as if everybody wants to make us dependent on a 24/7 connection to the web

How else do I say it: Because it's *easier*! Rumors that desktop application development is "well understood", well documented, and highly developed, are incorrect.

See the difference yet?

Rumors that Web interface is easy to build are grossly exaggerated.
If they are without JavaScript, you are stuck within the "power of expression" of HTML. If they are "powered" by JavaScript, the cross-browser compatibility and debugging/tracing on "what the hell is wrong" becomes quickly a nightmare (everything is Runtime and interpreted, no strong typing, a very loose "Object Oriented" programming paradigm, managing the "context/status of the application" may - and will - create troubles due to the lack of concurrent programming, almost everything is asynchronous, etc).

The best combination for crafting an application I encountered: sandboxed but still rich/smart clients, potentially written as an "update-able plugin". SWT/Eclipse Framework is the first example to spring in mind - many others may exist - : write your application as an Eclipse Plugin and use Eclipse Framework the way an "Web application uses a browser".

Re:Single point of failure development

[exomondo]

And don't get me started on clouds!!!

FTFY

Re:Single point of failure development

[dakameleon]

The issue is not that desktop applications can't access a network service - indeed, an increasing majority of desktop programs appear to be doing so - but that web "apps" provide a certain advantage from a development perspective. It's the thick-client-vs-thin-client for the GUI world - a web "app" gives you all the following basically for free:
- cross-platform - get the browser independence right, and you don't have to account for the vagaries of Windows, Mac and Linux.
- globally accessible - log in anywhere with a "terminal" in the form of a browser window (see: e-mail)
- lightweight versioning and updating - no need to roll out updates to each and every user, just update the pages served (see: Facebook)
- familiarity - everyone understands the language of hyperlinks, or can be taught to very quickly.

Some apps will not migrate to the web for some time yet - games, system and basic utilities like text editors, and heavyweight programs that need serious access to hardware. "Productivity" stuff can move over pretty damn easily.

Re:Single point of failure development

[rastos1]

Why does everything have to be built on desktop apps dependent on the web or web browsers?

The idea of Prism has it's place. Imagine for example a Prism set up for Internet banking. Separate settings, tighter security, no risk of infecting the browser on some random web site, ...

Re:Single point of failure development

[exomondo]

making applications web dependent is another way to invade peoples privacy

Sorry your data was stored on a system that also hosted data of an accused criminal. The system has been confiscated by the FBI so your data is gone.

Whoops,
Cloud Data Provider.

Re:Single point of failure development

[Rinnon]

That's the way someone who understands computers thinks. We are not the majority of people who use computers anymore. The majority of people do NOT understand the way computers work, they just happily sign on to Facebook or their Email when they want to. The idea of being able to go to their friends house and access all their stuff there seems like something out of Sci-Fi to them. It's super cool, and nothing but convenient. I mean, why WOULDN'T you want to be able to do that?

Things like privacy issues aren't really a concern to them either. You ever tried to tell someone about the way Facebook operates, and had them say they don't care about any of that? Happens to me all the time. Also, as a general rule, a lot of people (especially in North America) see what is happening in Egypt, and say to themselves "But that could never happen here."

Finally, in closing, a lot of people do not WANT things in their immediate control. Having all your data on your computer means that it could break, or could get a virus, and then it's in danger of being lost unless Geek Squad can fix it. Many would rather trust it to Google than to themselves. Having worked previously in Geek Squad many moons ago, I have to say, for some of them, trusting their data to anyone but themselves was the wise thing to do.

Re:Single point of failure development

[Anonymous Coward]

> Browsers are lightweight, 'easy' to program. Cheap. More or less OS independent.

So, that's the technology argument. It's kind of weak in the sense that it leaves room for someone to say "hey, but desktop software can do the same thing, better," which is probably true. It's a fine enough position for a tech-y to take.

But consider that most people in business environments don't have access to install applications on their machines. This includes management and pretty much everyone not in IT. Therefore, the web browser is pretty much the only "programmable" "device" that the aforementioned business user could possibly hope to "install" software on (other "devices" that can carry executable code -- PDFs, Word Docs, VBScript email attachments -- are blocked by anti-virus software).

The software services industry -- that is, consulting firms that write code for large corporate projects -- have to generally abide by this "zero installation" policy. If not explicitly, then because of the pain of trying to change IT policy and also the pain of patching X thousand desktop applications. IT "knows" most firms aren't writing the kind of robust self-updaters that Google and MMORPGs have to deploy. So yeah, it's just easier for everyone to put presentation logic into the browser, and then throw a custom server backend into the IT data-center.

In my opinion, that's why there's this push to cram everything into a browser. It's not because it's a technologically superior platform. It's because corporate IT policy tries to prevent their business users from "screwing up their machines" by locking them down as much as possible, and the cost of fighting this policy is so atrociously expensive (in terms of both politics and patching the systems) that it becomes irrational for any "solution provider" to suggest deploying that kind of software.

I don't think there is enough money to be made in any other deployment scenario (e.g. home user) to drive the economics in another direction, and so you continue to see the push towards building and promoting more standards-compliant browsers.

That's OK because the landscape really is getting better: HTML5 brings localStorage, IE9 has better CSS3 compliance, the big-3 browsers (sorry Opera) seem to have enough market share to keep each other competitive, consumer software vendors are finally awakening to the brilliance of package managers (aka App Stores). Hopefully, unless something tragic happens at Google or Mozilla, most of the pain of developing browser applications should be gone by the end of the decade.

Re:Single point of failure development

[SanityInAnarchy]

I can't imagine Photoshop or Maya being browser based.

There already are some photo-editing solutions, and WebGL is on the way.

Hell, their browser based help systems don't even work well...

That's not the fault of the browser -- there are plenty of browser-based help systems which work so much better than "on-line" help systems that I wonder why anyone does it that way. (Read "on-line" as "computerized help system, but still locally" -- the term probably predates popular use of the Internet.)

Re:Single point of failure development

[SanityInAnarchy]

Why does everything have to be built on desktop apps dependent on the web or web browsers?

On the "web browser" front, what's your problem here? Do you have a pressing need to make an app work on a computer which has no web browser?

We've been doing desktops since dirt,

And we did shared servers long before that -- used to be a computer wasn't something everyone had on their desk.

The building blocks are well understood, highly developed and well documented.

The same can be said of the Web.

So why does it seem as if everybody wants to make us dependent on a 24/7 connection to the
web,

Ok, how the hell did you get modded up with FUD like that? This is exactly the kind of FUD people used to spread about Linux -- untrue and you know it, so why say it?

Web apps can and do have offline modes, for the cases where it matters -- and there are plenty of desktop apps which require a constant internet connection. So on that count alone, there's no significant difference between a web app and a desktop app.

What's more, have you noticed how absurdly pervasive Internet access is these days? It's on airplanes. They won't even let you use your cell phone, but they'll give you wifi. Other than planes, anywhere you have a cell signal, you can have Internet. Granted, it's overpriced now, but this is also just the beginning -- and already, complaining about this is getting to be as absurd as complaining that you don't want to computerize your records/books/whatever because computers require power and paper doesn't. Internet is a utility.

You had more of a point with your subject line -- web services are indeed single points of failure. So are operating systems. Making something a web service means if it's at all decent, it's also now OS-independent, which means I've now lost the single-point-of-failure of Microsoft.

And don't get me started on clouds!!!

I agree, mostly because the term is so ill-defined. It has 2-3 different meanings, each as cloudy as the next.

Did events in Egypt not teach us anything about putting every thing on the web and in
the cloud?

Events in Egypt taught us that when a government denies its people as fundamental a right as communication, the rest of the world will step in to help.

Re:Single point of failure development

[theurge14]

If you can't imagine Photoshop being browser based then I suggest you visit pixlr

Re:Single point of failure development

[SanityInAnarchy]

If they are without JavaScript, you are stuck within the "power of expression" of HTML.

If they are without JavaScript, they're probably not the target market anyway. But suggesting that this limits you to HTML... really? I guess server side code doesn't exist?

If they are "powered" by JavaScript, the cross-browser compatibility and debugging/tracing on "what the hell is wrong" becomes quickly a nightmare...

Having done web development, frankly, no it doesn't, not if you know what you're doing.

everything is Runtime and interpreted, no strong typing,

Which means the application itself was much, much quicker to develop and easier to maintain. Also, I have to say, I've never once been saved by the type system that I can remember -- the kinds of bugs I run into, even if they're runtime, never arise because I was using an object of the wrong type. Not once.

a very loose "Object Oriented" programming paradigm,

Erm... What's "loose" about prototypal inheritance? What makes classical inheritance better?

No offense, but are you sure you actually understand the JavaScript object model? It may be that you understand it and dislike it, and prefer other models instead -- but most people who hate JavaScript for not being "OO enough", in my experience, don't really understand JavaScript at all.

managing the "context/status of the application" may - and will - create troubles due to the lack of concurrent programming,

Also means we don't need locking. That's right, web apps don't deadlock.

almost everything is asynchronous,

You say that like it's a bad thing.

Re:Single point of failure development

[Yvanhoe]

I honestly think that the point is mostly to get out of the office documents mess : Sharing a word/excel document amongst non-tech savvy users is a nightmare. Microsoft versions not working correctly with each others and open office users having their own mess. People in this case usually end up saying "ok, let's open a google doc for this and everyone share it"

Once again, it is Microsoft's fault.

Re:Single point of failure development

[MerlinTheWizard]

So why does it seem as if everybody wants to make us dependent on a 24/7 connection to the web, and why does it seem everyone wants to turn the browser into the building block upon which everything else depends?

Because it's a potentially endless source of revenue. It's really that simple.

Re:Single point of failure development

[SplashMyBandit]

Java Webstart applications can be run in the browser or on the desktop (at around twice the startup speed, in my experience). The Webstart technology handles versioning updates, and just about everyone already has a modern version of Java installed already and the Java quickstarter installed. Shame such technology is no longer fashionable as it solves many problems that lots of other tech is trying to get to (Flash, Javascript etc). Java Webstart is not perfect but it is pretty good for interactive web apps that exceed the simpler stuff that Javascript is (very) good at.

Re:Single point of failure development

[polyp2000]

As far as i am concerned being Operating System agnostic is the key.

There will be a time when web based applications surpass their desktop counterparts. (There would be those who would argue in some areas it already has).

Being able to access my email on any device or operating system through Gmail (or whatever your poison) by doing nothing more than supplying credentials, is something that is a very good example and one which most of us couldnt live without. Particularly here on slashdot where most of us are gadget freaks.

Good point about Egypt though...

N.

Re:Single point of failure development

[Canazza]

I'm a web developer too, and most of my JS troubles come from different browser behaviours.
I mean, for the average web app there's no difference if you're using something like jQuery, but even then, every so often, IE throws up an issue (But jQuery's quite good at making it play along, or degrade nicely).
Complicated web apps are harder to do properly on all browsers due to the way sandboxing works over the different browsers. There's no use testing some apps locally as some browsers will refuse to do AJAX calls to the local file system, or communicate between IFrames if running locally, which means running a server to debug.
Sandboxes are the biggest hurdle in creating multi-platform apps, some, rightly imo, refuse to load local files into their app, but in some cases they don't. I wrote an app that ran a simple filter on an image stored locally on the users PC. It used getAsDataURL() through the FILE input element, which is only implemented (AFAIK) in Firefox 3.5 +, to load a local image file as a base64 string, and output it to the canvas. As this doesn't exist in Chrome, IE, Opera etc, I'd have to do a server-side work around, or insist the user have a plugin (like Gears) that allows local file access (As it was a proof-of-concept mash up I didn't bother).
It's this inconsistency in what is and isn't availible that makes web apps harder to write cross-browser.

JS is faster to develop with than any other language I've used (except maybe Actionscript, but only because of the way it handles classes, and they are essentially the same language otherwise)
It's still a hell of alot easier than writing a desktop app cross-platform.

Re:Single point of failure development

[serviscope_minor]

- cross-platform - get the browser independence right, and you don't have to account for the vagaries of Windows, Mac and Linux.

That is exactly the same. Browser independence is probably as hard, if not harder then OS independence. Besides, if you program to a good toolkit designed for the purpose, like QT, then you get platform independence.

- globally accessible - log in anywhere with a "terminal" in the form of a browser window (see: e-mail)

Moderately so. At the moment, many advanced features will only work with very recent browser builds or betas (webgl...) and are painfully slow on all but the latest i7.

- lightweight versioning and updating - no need to roll out updates to each and every user, just update the pages served (see: Facebook)

If only everyone used package management... but yes, it allows for easy incremental upgrades.

- familiarity - everyone understands the language of hyperlinks, or can be taught to very quickly.

This I disagree with. Not the collection of worde per-se, but the implication that it applies to web appps. Hyperlinks are really now being used as handy onclick anchors. In many web apps, they don't link to anything so much as act like a GUI widget.

Re:Single point of failure development

[icebraining]

If they are "powered" by JavaScript, the cross-browser compatibility and debugging/tracing on "what the hell is wrong" becomes quickly a nightmare (everything is Runtime and interpreted, no strong typing, a very loose "Object Oriented" programming paradigm, managing the "context/status of the application" may - and will - create troubles due to the lack of concurrent programming, almost everything is asynchronous, etc).

There's also GWT.

Re:Single point of failure development

[kangsterizer]

Cause otherwise, people develop little apps.
App to read site X. App to read site Z.

We lose in genericity (yeah i invent words today), standardization, etc.

This is very seriously happening on smartphones and that will spread eventually. The problem is that those apps are more buggy, not free, not compatible, etc - basically destroying everything the current browser stands for.

By making a simple version of the same browser that give you a feeling of these "little apps" they probably hope to keep all the advantages of the current browser in the "sexy" app form.

Of course that's only one argument, but all others arguments are well known and already made in many other posts.

Re:Single point of failure development

[Stooshie]

That's where flash comes in. It works on all browsers the same way, and I can compile an offline desktop app from, pretty much, the same code if the users request it.

Re:Single point of failure development

[c0lo]

If they are without JavaScript, you are stuck within the "power of expression" of HTML.

If they are without JavaScript, they're probably not the target market anyway. But suggesting that this limits you to HTML... really? I guess server side code doesn't exist?

Lapse of mouth, my apologies (the server side logic is implicitly understood as present)

If they are "powered" by JavaScript, the cross-browser compatibility and debugging/tracing on "what the hell is wrong" becomes quickly a nightmare...

Having done web development, frankly, no it doesn't, not if you know what you're doing.

Yeap, this is why many Web2.0 interfaces look different enough in different browsers?

everything is Runtime and interpreted, no strong typing,

Which means the application itself was much, much quicker to develop and easier to maintain. Also, I have to say, I've never once been saved by the type system that I can remember -- the kinds of bugs I run into, even if they're runtime, never arise because I was using an object of the wrong type. Not once.

Yes. yes, I believe you... you are a very accurate typer and never mis-type a variable name when using it.

a very loose "Object Oriented" programming paradigm,

Erm... What's "loose" about prototypal inheritance? What makes classical inheritance better?

No offense,

None taken. Method overriding is awkward and method overloading is missing. Because of the missing strong-typing among others.

and but are you sure you actually understand the JavaScript object model?

Yes I do.

managing the "context/status of the application" may - and will - create troubles due to the lack of concurrent programming,

Also means we don't need locking. That's right, web apps don't deadlock.

No, indeed no deadlock, they simply suffer from race-conditions. Awfully.
For instance, loading the /. and pressing the "LogIn" link too soon (before the necessary scripts are fully initialized) results in nothing. Need to reload the entire page and wait a bit (2-3 seconds) until the adverts (requested via JS) ran completely before the script on the "LogIn" link is initialized (by a JS that runs later). And this behavior is not even consistent across many attempts.

almost everything is asynchronous,

You say that like it's a bad thing.

Yes, it is. It does mean extensive workarounds when you need a synchronous behavior.

Now, look, we may have different real-life experiences in regards with GUI and business systems. it's OK if we agree to disagree.
The /. forum is probably OK with Web+JS, nobody is hurt of a "reload page to login" or a "double submission" (this because of the "server-side logic" acting weird at times). I don't think however that a GUI for a stock-trader can be reasonable written in JavaScript running in browser: any mis-synchronization hurts, any bugs have the potential to bring loses, any slippage in the delivery of an update causes missed opportunities.

Re:Single point of failure development

[Neil Boekend]

and open office users having their own mess.

Once again, it is Microsoft's fault.

A problem in Open Office is a fault of Microsoft? How?

Re:Single point of failure development

[Max_W]

Because, it is very difficult to go to a location and install a desktop application. I was there and did it. Thank you very much.

Then the PC breaks down and I had to drive to install again. DLL error - drive again. On 100 PCs it is OK, on 1 - an error. Then on thin clients I had to spend 4 hours to install one desktop application, because it was missing some file in the OS.

Nowadays, I do not care what OS or what PC is on a location. Browser, htpps connection, login, password, that is it. Change complicated password periodically.

A desktop application without a good reason is a nightmare. Yes, we do need some fundamental desktop applications: Firefox, GIMP, Notepadd++. But to build a desktop application for each business process is insane.

Re:Single point of failure development

[Max_W]

A spare Internet connection makes the Internet access practically uninterpretable. Egypt is rather an exception, but still one could use a satellite dish link, like they use nowadays on the ships.

Re:Single point of failure development

[Yvanhoe]

Open Office's main problem is that it is structured so that it can open/save MS Office documents. That is how.

Re:Single point of failure development

[140Mandak262Jamuna]

And the cool thing is this: If some small company comes up with a killer app/idea/concept, if they are using cloud based service, I can just sue that tiny company on some pretext. Let loose my army of lawyers and get enough subpoena to get every last detail of their plans and ideas in the discovery process. Then I will laugh all the way to the bank, selling their ideas before they could meet the venture capitalists to raise enough money for version 1. Hoot! Who said cloud does not have value?

Let me ask you, if I sue your clients and come after you with a discovery subpoena, how hard will you protect your client's data? How easy it would be for me to download their entire damn development plan?

Re:Single point of failure development

[C0vardeAn0nim0]

We've been doing desktops since dirt, and have it pretty well understood, reasonably well standardized
across multiple operating systems. The building blocks are well understood, highly developed and
well documented.

that's exactly the problem. multiple. operating. systems. making a desktop app that runs on all of them is a pain in the ass, an for commercial developers, expensive. no wonder that the majority of multi-plataform apps are opensource. now, developing for web, finally bring the dream of "write once, run everywhere", something that java promissed but failed to deliver in large scale.

So why does it seem as if everybody wants to make us dependent on a 24/7 connection to the
web

HTML5 can store data locally, i guess this includes the applications files, so you can still use them while offline.

And don't get me started on clouds!!!

What do we gain besides a huge dependence on things outside of our immediate control.

Did events in Egypt not teach us anything about putting every thing on the web and in
the cloud?

most non-techie people i know have problems installing updates, anti-virus, doing backups and all that. put it on "the cloud" and let professionals handle that.

and "huge dependence on things outside of our immediate control" ??? why do you use different standards for your personal data and your money ? i bet you keep your money on a bank, so why not your data ? it's not like it'll be unavailable if the web goes down, as long as you keep local copies.

and what does egypt have to do with web and clouds ? are you implying that a nation-wide internet shutdown will paralize us ? it didn't paralize the egyptians. the existence or not of the web had zero effect on the egyptian protests.

Re:Single point of failure development

[gbjbaanb]

you're partly right - webapps are written in script because its easy to do so, not because it makes the best apps. That encourages the crappy devs, but they've been courted by language designers for a while now - .net, java all designed to 'make programming easier', not better.

That evolved the browser/web ecosystem to be a kind of 'lowest common denominator'. A bit like Java's JVM being a platform you develop on instead of developing native apps.

Web is a similar abstraction. We can write thick client, 3 tiers apps using C but everyone has the buzzword of 'the web' in their heads and starts going bonkers with javascript and back-end php or whatnot.

The best apps I've seen are ones that treat the web server as part of the presentation layer and keep it as thin as possible - basically acting as a gateway to the real business logic servers that are written in 'serious' languages. (and then you can replace the webserver front-end with a thick client one if needed)

Still, its probably a good evolution until someone can come up with a better client programming system. I don't think that will happen as we have to have downloaded script clients (or the code will start to be thick-clients again with all the need to install extra stuff that you were originally trying to get away from). Google's native client is a good idea, but I don't think it'll take off.

Re:Single point of failure development

[RobbieThe1st]

+sI suppose it all depends on what your aiming for. If you developed an app -exclusively- for Firefox, it would run perfectly well on a Windows, Mac(Intel and PPC), Linux(x86, amd64, arm... or any other obscure variant) and even my cell phone(N900)! That might not be your entire market, but between that and Chrome compatibility, you can probably make do. Conversely, if you write an OS app, it's usually got to be recompiled for each OS/platform combination, tested, etc. And often times, Javascript is perfectly fast - Give up on canvas/pixel models and start using SVG elements(Ignore IE) and you'll be surprised at how fast it can be rendered - On a number of platforms it'

Re:Single point of failure development

[rjstanford]

A big part of this was the long-time lack of local "sandboxed" applications on Windows systems. If it had been easy for people to install lightweight software on their desktop in such a way that IT wasn't threatened by its very existence, we might never have reached this point.

Then again, one of the big "security features" of these apps is the idea that internet access is far less dangerous (when granted to an untrusted application) than local network access. On the desktop, we've been pushing the inverse model for years - which works better for trusted software. Its a very fun problem to watch.

I don't think there is enough money to be made in any other deployment scenario (e.g. home user) to drive the economics in another direction, and so you continue to see the push towards building and promoting more standards-compliant browsers.

We'll have to see how the Apple "Mac App Store" model does on this side. It might make a difference, especially if there's a way to add your enterprise app store into the mix. Might not. We'll see.

Re:Single point of failure development

[Qzukk]

The web became the new visual basic, mostly due to the fact that it took some small amount of skill to drag and drop form elements onto a window in a way that doesn't fuck up if the user's resolution is not exactly like yours, while the html browser will reflow the text so it may still look like shit but at least the form will scroll if it doesn't fit, instead of putting the buttons off the bottom of an unresizable modal dialog that windows won't let you drag up off the top of the screen so you can see them.

tl;dr: UI is hard! The web makes it the browser's responsibility.

Re:Single point of failure development

[kelemvor4]

Why does everything have to be built on desktop apps dependent on the web or web browsers?

We've been doing desktops since dirt, and have it pretty well understood, reasonably well standardized across multiple operating systems. The building blocks are well understood, highly developed and well documented.

Mozilla makes web browsers. They're trying to create a dependence on their product like Microsoft did with windows years ago.

So why does it seem as if everybody wants to make us dependent on a 24/7 connection to the web, and why does it seem everyone wants to turn the browser into the building block upon which everything else depends?

And don't get me started on clouds!!!

What do we gain besides a huge dependence on things outside of our immediate control.

Did events in Egypt not teach us anything about putting every thing on the web and in the cloud?

It's not what WE gain, it's what corporations gain in the form of DRM, and tracking your online activities so they can make more money. There's nothing magical or new about any of this, companies will do what's in their best interest regardless of what's in the customer's best interest. Sometimes those two interests cross paths, and sometimes they don't. There's way too many uneducated consumers out there to do anything about it with methods other than cyberwarfare (DDOS etc) or government legislation. However, do not forget that the legislators are in the pockets of the companies in the first place and therefore aren't serving your interests either (again, unless your interests by chance happen to be the same as the corporations interests on a particular issue).

Re:Single point of failure development

[kelemvor4]

If you weren't joking about that somehow being comparable to photoshop, then you may want to consider a photoshop trial or at least reading about the subject. pixlr, piknik and the like are no more competition for photoshop than Schwinn is competition for Mercedes.

Re:Single point of failure development

[celle]

"Making something a web service means if it's at all decent, it's also now OS-independent, which means I've now lost the single-point-of-failure of Microsoft."

Or linux, or OSX, or bsd, etc. You've also gained the multiple points of failure of web services with their variable ethics for securing personal information, bigger target for data sellouts/hacking(facebook), ISP data rate games, connection stability, browser compatibilities, etc.
    When it's your machine you control what's going on. You can always switch OSes, change programs, control where your data is stored, backup to your own media, verify your own security, etc. You don't have that luxury with web services.
Need examples, China hacking Google, big one -- AT&T, hell practically everyone providing customer data to US government in violation of law(GW Bush era), abuse of National Security Letters, every month or so a personal records leak at some company/government department(happens so often I've stopped bothering to keep track), etc.
    The cloud is useful for accessing public data and doing temporary transactions but is not the place for business/private/personal information. You don't put your private records in the local library do you?

Re:Single point of failure development

[mcrbids]

I was about to come in here and say pretty much what you said, but you'd already said it, and Slashdot doesn't let you moderate in any forum that you've replied into.

So... well said!

Re:Single point of failure development

[DragonWriter]

So why does it seem as if everybody wants to make us dependent on a 24/7 connection to the
web

Web apps don't necessarily depend on a 24/7 connection to the web.

Re:Single point of failure development

[dhammond]

The technology is not quite there to build browser-based apps that can adequately replace desktop apps. But that's the whole point of the Chromeless project as I understand it.

I have, in the past year, switched from a desktop email client to Gmail. It is tantalizingly close to being a perfect setup. There are just a few things that don't quite work as they should (better desktop notifications, opening links in my default browser, for instance). If those things were fixed it would be great. Meanwhile, I can switch to another computer and have all my email on the go. If my computer dies, I have not lost anything. And it supports offline use (no 24/7 connection to the web required).

Okay, I'll get off your lawn now.

Re:Single point of failure development

[kubernet3s]

I've never seen webapps as a way to supplant desktop applications: indeed, most webapps which have this as their goal are simply atrocious. I think the point of projects like Chromeless and Prism is to change web browsers, not desktop computing.

The web browser is a fine, robust piece of software, but its sensibility is extremely outdated: when is the last time any of us actually "browsed" the web, outside of something like stumbleupon? I use my browser to read newsfeeds, check email, and to look things up, and do not need a lot of fiddly browser chrome bits flying around in my face...except when I do, which is where prism becomes valuable. The browser is a tool for doing all those things which require bookmarks, an address bar, back/forward/refresh buttons, and multiple tabs. Doing everything you do on the internet through a chromed browser is like reading books through a pair of binoculars. It wastes screen real estate for no reason.

Historically, the solution has been to make the browser ultralight, a la Chrome and Midori, but then you get browser's which are TOO light. Sometimes we need a dashboard of fiddlybits. What projects like Prism and Chromeless do is modularize internet functionality, so that web-based services can blend seamlessly with desktop applications. The cloud is a silly philosophy, but that doesn't take away from the unchromed web's utility

Re:Single point of failure development

[benjamindees]

What do we gain besides a huge dependence on things outside of our immediate control.

Data concurrency.

Re:Single point of failure development

[tepples]

A problem in Open Office is a fault of Microsoft? How?

Because Microsoft too long to publish specifications for its Office document formats.

Re:Single point of failure development

[tepples]

Give up on canvas/pixel models and start using SVG elements(Ignore IE)

Ignoring nearly half your market is business suicide. You can't just direct users to install a browser because the user isn't necessarily an administrator.

Re:Single point of failure development

[tepples]

Most home users and many small business users aren't willing to pay $720 per year for redundant satellite Internet access, especially with the 200-300 MB/day cap that both HughesNet and WildBlue appear to impose.

Re:Single point of failure development

[tepples]

HTML5 can store data locally, i guess this includes the applications files, so you can still use them while offline.

So what should your application do when it runs up against A. the user agent's limit of 5 MB for offline application files linked from the CACHE MANIFEST, B. the user agent's limit of 5 MB for data in localStorage, or C. the user agent's lack of methods first introduced in Firefox 4 for file input objects (<input type="file">)?

Re:Single point of failure development

[tepples]

When it's your machine you control what's going on. You can always switch OSes

Not if the machine verifies the machine's manufacturer's digital signature on each stage of the bootloader and kernel.

Re:Single point of failure development

[badkarmadayaccount]

There are JS libs that fix that. GIYF.

Re:Single point of failure development

[SanityInAnarchy]

If they are without JavaScript, you are stuck within the "power of expression" of HTML.

If they are without JavaScript, they're probably not the target market anyway. But suggesting that this limits you to HTML... really? I guess server side code doesn't exist?

Lapse of mouth, my apologies (the server side logic is implicitly understood as present)

Then what's your point? If the problem is that raw HTML isn't fun to write, I always work with at least a tool like Haml, and often plenty of server-side libraries which handle HTML generation.

If they are "powered" by JavaScript, the cross-browser compatibility and debugging/tracing on "what the hell is wrong" becomes quickly a nightmare...

Having done web development, frankly, no it doesn't, not if you know what you're doing.

Yeap, this is why many Web2.0 interfaces look different enough in different browsers?

I wouldn't say "looking different" is necessarily a problem for all apps, and there certainly is significant work needed to support multiple browsers -- though certainly no more than it takes to deal with multiple OSes, or even just multiple weird setups on a single OS, if you really want to go back to desktop apps. (Remember, the original claim is that web development is easier than desktop development.)

But that's also not the point. You were complaining about debugging/tracing and figuring out "what the hell is wrong", and that was never the hard part. It wasn't that we couldn't figure out what IE was doing wrong, it's what we'd have to do to work around it so it'd run in IE.

Yes. yes, I believe you... you are a very accurate typer and never mis-type a variable name when using it.

Never mis-typed a variable name and had it turn up as something other than, say, "undefined" -- and there are tools which check for poor style, like implicit use of globals.

Method overriding is awkward and method overloading is missing.

I disagree with the former, and don't really care about the latter. That might be a matter of taste, though.

No, indeed no deadlock, they simply suffer from race-conditions. Awfully.
For instance, loading the /. and pressing the "LogIn" link too soon (before the necessary scripts are fully initialized) results in nothing. Need to reload the entire page and wait a bit (2-3 seconds) until the adverts (requested via JS) ran completely before the script on the "LogIn" link is initialized (by a JS that runs later)....

While a race condition is possible, I don't see how what you suggested could possibly be a race condition. Poor design, maybe -- there's no reason why the ads need to load completely, they should be using the DOMContentLoaded event -- but having a UI control not work until it's initialized makes perfect sense.

A race condition would be more like, you click the login link and this somehow screws up the page state so nothing works until you reload the page.

almost everything is asynchronous,

You say that like it's a bad thing.

Yes, it is. It does mean extensive workarounds when you need a synchronous behavior.

While I prefer a saner concurrency model than either, I think the issues with threading are a bit more difficult to deal with than the issues with async. At least with an async model, I know my data isn't going to change out from under me within a given block, whereas with a thread, I have to guard against that data changing at any time, no matter what else I'm doing.

it's OK if we agree to disagree.

I don't think that's really needed, but I get the point -- I disagree with you, but I don't hate you.

Re:Single point of failure development

[SanityInAnarchy]

You've also gained the multiple points of failure of web services with their variable ethics...

How is this different than software developers with variable ethics? The only difference is where the data is stored, and since a web application can operate entirely offline, including offline storage, that's a design detail.

bigger target for data sellouts/hacking(facebook),

I'm not really sure what Facebook has to do with this, especially as there are plenty of non-web applications for talking to Facebook -- so again we see that taking it off the web doesn't necessarily help. In this case, it's not that Facebook is web-based, but the fundamental nature of this sort of social network -- Facebook could be implemented with entirely non-Web clients, and it'd still have the same problems. Blaming the Web for Facebook is about as logical as blaming PHP, because Facebook happens to be written in PHP.

When it's your machine you control what's going on.

I don't see how this changes anything. You'll have to be way more precise about what I'm supposedly controlling here. If what you mean is this:

You can always switch OSes,

Yes, I can -- and the more of my programs are OS-independent, the easier it is. When the majority of what I do with a computer is on the Web, it's inherently OS-independent.

change programs,

If I ignore the issue of data, I can change web applications much more easily than native applications. There's no installing/uninstalling, I just open another URL.

If I consider data, then I can only change native applications when they've put some effort into being interoperable -- in particular, they have to share formats, etc. I don't see how this is different than web applications cooperating through APIs and common protocols. Right now, I have some (though far from all) of my emails in Gmail, and some of my schedule data in Google Calendar, and a vanishingly smaller fraction of my documents stored in Google Docs. In the case of Gmail and Google Calendar, both support open standard protocols (iCalendar, IMAP), so any other service could import my data that way. Google Docs publishes an API which would make it similarly easy.

control where your data is stored,

I control exactly how much data I put in each web service.

backup to your own media,

As mentioned above, if standard protocols are supported, it should be similarly easy to backup to my own media as it is to import my data wholesale to another service. Of course, this assumes I'm better at backup than, say, Google. For most people, it's a safe assumption that the web service can't possibly be worse at backup than the user.

verify your own security,

While the exposure is going to be a bit different, unless I'm sandboxing stuff to an absurd extent, a local proprietary app doesn't allow me to "verify my own security" any more than a web app does. A local open source app is significantly better, and I would argue that it's likely more secure, but I doubt I would ever be tempted to verify it myself by doing a code review.

You see, just because it's physically on your machine doesn't mean you have control. You may theoretically have control, but ultimately, the only way you have control is by not installing software you don't trust. The fundamental principle is the same here -- you don't use web services you don't trust. The only real difference is that open source might have had a bit more peer-review.

China hacking Google, big one...

Same problem happens if China hacks Microsoft and delivers an unwanted Windows Update, giving them full access to your machine. Or are you going to disable updates, and thus be vulnerable to China gaining access through an unpatched vulnerability? All this means is they hav

Re:Single point of failure development

[SanityInAnarchy]

And can you "keep the flow going while resources are still loading" more easily with a synchronous model? Especially with some sort of threading model? That's where I'm confused -- I don't mean that async is easy, but it certainly seems easier than the alternatives.

Nice Idea

[Nerdfest]

I used Prism (or tried to) for a few standard sites that I pretty much always keep open. Nice idea but there always seemed to be a few problems (with the Linux version anyway). I always had difficulty in getting more than 2 to run at a time, and most plug-ins were at least tedious to use if they worked at all. It had/has promise though ... I hope Chromeless improves it a bit. In the meantime, I believe Chrome has the same sort of functionality. I may get around to trying it out but I find that when running Chrome the need to run a different instance of the browser is not as important because of their process model.

Re:Nice Idea

[drinkypoo]

The fundamental problem with prism is that it wanted to open links in itself. So if you're using say Facebook as a prism app then you want external links to open in your actual system web browser, and they don't, they open in prism. And all your prism windows associated with a single --app flag will open with the same (lack of) decoration. So the prism paradigm is broken if you use anything with external links. If it doesn't have external links then it's fucking stupid for it to be a web-based application at all; if anything you want to target XUL, and there is already xulrunner. Therefore not only did prism have no reason to exist, but nor does chromeless.

Mozilla has too much on their plate.

[Anonymous Coward]

Seriously, fix Firefox 4.0 first then play with all these hobby projects.

A positive step forward.

[Musically_ut]

While I letting Prism go would upset a few people, I think concentrating more on Chromeless is going to be a good choice in the longer run. The project is very promising, more general than Prism, and can use the boost in interest and concern, especially in the documentation section. Going a step further, using Chromeless is going to make more people look at XULRunner, the program which fires both Firefox as well as Thunderbird. Problems uncovered in applications (browsers) built using Chromeless are, hence, likely to make XULRunner itself better. These benefits will trickle down to Firefox as well as Thunderbird.

Hence, I welcome the change whole heartedly.

Re:A positive step forward.

[Inner_Child]

Going a step further, using Chromeless is going to make more people look at XULRunner, the program which fires both Firefox as well as Thunderbird.

Great! Because the only thing better than software that doesn't integrate well with one platform is software that doesn't integrate well with *any* platform!

Agree!

[knide]

Totally agree! I don't really see the point!

Re:Main Frame Madness

[c0lo]

"The Cloud" is mainframe madness on a large scale. Mainframes were killed off years ago for many reasons. Single point of failure: internet is down, you, your business is down. No thanks.

To which I'd add: internet is down, can't even play them games offline. No thanks.

As someone who's struggling with the mess of XPCOM

[rsilvergun]

I'm sorry to say Gecko isn't going anywhere as an application platform. Too many macros and directives and such, and too much room for error... :(

Re:Main Frame Madness

[SanityInAnarchy]

Power is down, you, your business is down. No thanks, we'll stick to paper.

Really? That's the best you can come up with? They have internet on airplanes now. It's getting harder and harder to find a place without Internet. Internet's down at work? Grab some laptops and head over to your local Starbucks.

Oh, and I hate to be the bearer of bad news, but much as I wish they'd die, mainframes are still going strong, and IBM is even selling new ones. If you want job security, become a mainframe programmer.

Unique information,

[susanaseo]

This is the first place where I have got this unique information and I was a bit hopeful that it was going to happen sooner or later.

Re:Chromeless...Chrome-less?

[syockit]

Wow, I'd love to have bash in my browser too! I'm tired of scripting with Javascript and having to learn XUL. Now I expect more linux gurus to write extensions for Firefox! Oh, I'd also love to be able to launch wget from within the hidden browser bash to download... web pages.

Re:Too bad

[MaskedSlacker]

I used Prism to provide links for my kids to their favorite games as icons on the desktop. I loved the ability to hide the GUI features that would just distract them. I will miss this software. it was very useful.

Makes a shortcut that runs 'chrome --app="http://url"' (or chromium-browser, or whatever your chrome executable is)

Change... change.. change

[xtracto]

That sucks... I used to have a PRISM shortcut to open a Live Excel spreadsheet which I used to annotate daily tasks (pomodoro style) online without having to open the whole browser. Unfortunately it does not work with the minefield builds anymore.

One of the reasons technologies do not "mature" is because developers keep jumping between different alternatives after they get "bored" with the current ones :(.

Where's the link to Mozilla labs blog post?

[thinktank2]

Why are slashdot stories linking to web sites that aren't directly related to the story? This story would have been better linked to the blog post at Mozilla Labs: https://mozillalabs.com/blog/2011/02/prism-is-now-chromeless/

Chrome

[Arancaytar]

It should be noted that "chrome" is the name of Mozilla's xml-based user interface (not the web rendering engine). It is unrelated to Chromium or Google.

Re:Main Frame Madness

[icebraining]

http://www.w3.org/TR/html5/offline.html
http://diveintohtml5.org/offline.html

No Internet needed

[Lennie]

This is just based on webtechnology, you do NOT need a working internet connection to use it.

Even then, HTML5 has support for offline use, for when your connection is down.

Picnik

[brunes69]

You may think "photoshop can't be browser based", but you may be surprised. As an example, my wife recently directed all her desktop photo apps and only uses picnik.com. Granted, it is certainly not photoshop - but I can see it eventually getting there, maybe as early as a year or two.

Really, with Canvas and WebGL, there is nothing browsers can't do today that a desktop app can do.

Re:Chromeless...Chrome-less?

[Lennie]

Actually the interface in Mozilla browsers is called the chrome. Mozilla was already using the name for years when Google released their project. You could even say Google. Now that Mozilla allows developers to create their own interface (thus chrome) they called it chromeless, because an interface does not yet exist, the developer can create their own.

Don't be so hard on him

[jprupp]

He was just saying that web development is hard, and indeed it is with it's mishmash of HTML, JavaScript, CSS, server-side languages, asynchronicity, multiple browsers to support. It's not easy, and most don't get it right even after the third try, it's kind of a hideously complex art nowadays. We fortunately have jQuery and frameworks and all kinds of aids, but this still doesn't make it too easy on the developer. You find it easy because you're at the other end of the learning curve, as most slashdotters, but don't tell me you didn't sweat it.

Re:Don't be so hard on him

[SanityInAnarchy]

He was just saying that web development is hard,

...while replying to a post which said it's easier than the alternative -- which was replying to a post which said we should go back to desktop apps for everything.

indeed it is with it's mishmash of HTML, JavaScript, CSS, server-side languages, asynchronicity, multiple browsers to support.

Contrast that with your options with a desktop app. Any little quirk in what versions of software the user has installed, or how they're configured, or how they talk to each other. As mcrbids said:

...combination of an antivirus package and MS Office (no, I'm NOT KIDDING) causes your application to mysteriously stop working.

And that's assuming you're only doing Windows. Now imagine you want to do other OSes -- Mac, Linux, etc. Now you've finally got all that handled, maybe you used some decent cross-platform toolkit like qt or wxwindows, and suddenly your boss goes OMG IPAD, so you've now got a brand-new platform with its own UI toolkit and its own rules -- oh, and Android, just to be sure.

Multiple browsers is a bitch, but it is much easier than the alternative.

As for the blend of technologies you have to use, I'd say much the same thing. HTML isn't the best GUI toolkit, but it does have some advantages. If multiple languages is really an issue, you can find options to run JavaScript on the server. On the desktop, you're likely stuck with either async or threads, and as far as stability goes, I'll take async every time.

It's not easy, but it's easier than desktop development.

Who you gonna call?

[danlip]

based on XUL (pronounced ZUUL). I ain't afraid of no app.

Local browser-based help

[tepples]

there are plenty of browser-based help systems which work so much better than "on-line" (computerized, local) help systems that I wonder why anyone does it that way.

Probably because browser-based help systems either A. lack search (if they operate through the file: scheme), B. require a web server running on localhost (for which a firewall presents a scary warning), or C. require a $60/mo subscription to mobile broadband if used on a laptop on a bus.

Re:Local browser-based help

[SanityInAnarchy]

C is becoming less and less relevant. Not only are mobile subscriptions prevalent, but we have wifi everywhere. It's on airplanes.

I find myself wondering what the overlap is between those who are using a laptop on a bus and those who know how to spider a web-based help system with 'wget -r'.

Re:Local browser-based help

[tepples]

we have wifi everywhere. It's on airplanes.

And on airplanes, it's priced as a luxury service. It isn't on Citilink buses (Fort Wayne, Indiana) or in Glenbrook Square Shopping Center (Fort Wayne, Indiana) at all; instead, one must either pay $720 per year for mobile broadband or do without.

I find myself wondering what the overlap is between those who are using a laptop on a bus and those who know how to spider a web-based help system with 'wget -r'.

For one thing, robots.txt. A lot of sites aren't designed to be spidered; they might be database driven, with different sets of CGI parameters showing essentially the same data. They might allow only a specified number of page views per hour to counter bandwidth abuse.

Fishing expedition

[tepples]

What, specifically, makes such a fishing expedition any easier with applications that run on a server than with desktop applications?

Re:Fishing expedition

[Mal-2]

With a desktop application stored on the local network, you would first have to know something of interest EXISTS before you could go on a fishing expedition. If it's over a web app, mere traffic analysis may be sufficient to reveal something of interest.

Free as in speech or beer?

[tepples]

The problem is that those apps are more buggy, not free, not compatible, etc

Did you mean "free" as in free speech or free beer? If free speech, then the works on the site probably aren't free either. If free beer, then what's the big difference between having to pay for a specific app to read a site and having to pay for an account to read a site through standard web protocol?

Size limits

[tepples]

Even then, HTML5 has support for offline use, for when your connection is down.

Which works well unless A. Internet Explorer is the only browser installed and your user is not an administrator, or B. you run into size limits enforced by user agents: 5 MB for files linked from CACHE MANIFEST and 5 MB for localStorage.

CACHE MANIFEST and quotas

[tepples]

They do if they depend on more than 5 MB of data. The page you linked mentions storage quotas, and there exist popular user agents that don't let the user increase the quota past 5 MB.

Intermittent connection to the Internet

[tepples]

Do you have a pressing need to make an app work on a computer which has no web browser?

No, but I have a pressing need to make an application work on a computer which has a web browser but an intermittent connection to the Internet. When the connection is down, such as if the user is a passenger in a vehicle, the browser can view only manually downloaded files, the 5 MB of cached application files, and the 5 MB of data in localStorage.