Posted
by
timothyon Friday February 04, 2011 @12:22AM
from the lookie-here-it-ain't-got-no-server-attached dept.

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

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 standardizedacross multiple operating systems. The building blocks are well understood, highly developed andwell documented.

So why does it seem as if everybody wants to make us dependent on a 24/7 connection to theweb, and why does it seem everyone wants to turn the browser into the building block uponwhich 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 inthe cloud?

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.

> 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,

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"

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

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

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

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.

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 ab

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.

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

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.

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

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.

- 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)

+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 perf

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!

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.

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.

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

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.

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,

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 c

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.

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

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 slashdotter

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.

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

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?

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.

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.

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

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.

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.

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 ar

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 advan

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 [freedomdefined.org] 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?

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.

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

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.

We've been doing desktops since dirt, and have it pretty well understood, reasonably well standardizedacross multiple operating systems. The building blocks are well understood, highly developed andwell 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 theweb

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 inthe cloud?

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 [mozilla.org] for file input objects (<input type="file">)?

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 unedu

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 c

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

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 a

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,

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.

Whyt he fuck does the new system, in your "Comments" section for your account, take you to the parent conversation when you click on it instead of your fucking post? It's very stupid, is this some new "default" functionality I need to turn off? Seriously, why would I want to dig through a conversation tree looking for _my_ post, instead of being taken right to it?

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.

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.

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.

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:(.