Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Barence writes "Mozilla claims that its new Firefox Mobile browser could be the beginning of the end for the hugely popular app stores created by Apple and its ilk. Mozilla claims Firefox Mobile will have the fastest Javascript engine of any mobile browser, and that will allow developers to write apps once for the web, instead of multiple versions for the different mobile platforms. 'As developers get more frustrated with quality assurance, the amount of handsets they have to buy, whether their security updates will get past the iPhone approval process ... I think they'll move to the web,' Mozilla's mobile VP, Jay Sullivan, told PC Pro. 'In the interim period, apps will be very successful. Over time, the web will win because it always does.'"

I've used the local storage features and they're great. Even made a simple hash store based on it [github.com]. But you're still stuck in the browser, so the user experience isn't quite as good as a native app. Also, you have all of the overhead of the browser, so even the leanest and meanest Javascript will have a hard time keeping up with the speed of a native app. At least, that has been my experience with the iPhone and Mobile Safari.

But it's definitely moving in the right direction, especially when you throw in CSS-driven animation (which is sadly slow on the iPhone).

Local storage is pretty cool, and the CSS animation and stuff doubly so. There's still the problem of having a good way to back up local storage.... *sigh*

That said, it's still not even slightly close to what you can do in a native app. Even if performance was identical, the DOM is beyond half assed as a GUI environment. There's not even a drag and drop mechanism built in that works across all browsers. There's no way to guarantee that your handlers won't get stripped out by some overzealous UI library that you load. Basic functionality like contentEditable (for WYSIWYG editing) is barely supported in any browser, replete with hundreds of serious bugs that make it very hard to deal with. There's no way to set up an automatically recurring callback with a guaranteed period. There's no way to spawn multiple threads of concurrent execution (except for a FireFox-specific mechanism). There's no standard way to talk to hardware. And those are just the huge problems.

Even simple things like specifying which UI elements should grow proportional to the window size is an utter pain. Creating clickable buttons that don't get their text content selected can be rather entertaining. Convincing the browser to not deselect the selected text in a contentEditable region when you do so is doubly so. Then, you have that fun box model that only a committee could love (all of us are dumber than any of us). Don't get me started on trying to do column layouts with CSS. I could go into specifics, but if you've ever tried to build any significant web application, you're already nodding in agreement....:-)

Yeah, it's going in the right direction. It's got a long way to go, unfortunately. Right now, it takes mounds of custom GUI libraries just to get usable UI, mainly working around the fact that the web browser just wasn't designed to do this stuff. When I can write a web app that's lightweight and doesn't require bringing in something as heavyweight as Prototype just to get anything done, we'll be at least in the right ballpark./p>

You see, the difference is, this time we're dealing with something that actually is write once, run anywhere. Who honestly wants to maintain two separate codebases? Sure, if Apple decides iPhones shouldn't have Internet connectivity or a built-in browser, they can beat what's coming. I'm not seeing that happening, somehow...

I'm pretty sure I'm not the only android user that would disagree. I have a friend who's a die hard mac fan, who's getting a Droid. There are a lot of things the users don't like in the iPhone, Apple's App Store and AT&T.

Only supporting 1, a SINGLE, ActiveSync account, for one. That I think is perhaps the biggest flaw in the iPhone email setup... this coming from the Pre, which could support multiple ActiveSync accounts, so I could sync GMail and my Corporate mail. With iPhone, it's one or the other.

Taken in isolation, that's true, but the fact of Firefox's speedy Javascript implementation means that Apple will have to follow suit with Safari. In other words, you don't need Firefox on an iPhone to take advantage of the apps that will become available as a result of this development.

That's the point of this whole thing. With better apps that just run in the browser, you don't need the app store anymore. Other "app stores" pop up to sell you subscriptions to rich web applications that you access over your phone's net connection.

I should clarify my last reply; while Firefox Mobile is moving forward with better performance on mobile devices, Apple can't just let Safari sit forever. Sooner or later, they'll have to bring its performance up to par too.

Different screen resolutions, different interfaces, etc, etc. You won't be able to write once, run anywhere. Or are they thinking they can force everybody to use Firefox on both phones AND computers? That's as bad as Microsoft, isn't it?

Not until mobile OSes allow for direct hardware access from the browser. Palm's Web OS does, but I can't imagine Apple allowing Fennec to access the accelerometer or camera, say. Particularly if it begins to cannibalize their App Store profits.

I understood 7Ghent's intent not as actual direct hardware access (in the kernel-mode sense) but as any feature of a computing device that JavaScript and the HTML and CSS DOM don't necessarily expose. I have lots of apps that use APIs for 3D graphics, reading the joystick or accelerometer, reading the camera or microphone, playing audio objects with variable pitch and volume, importing and exporting files chosen by the user, and connecting to multiple web servers (which XMLHttpRequest doesn't allow due to S

XMLHttpRequest can connect web servers that want to be connected (and define appropriate policies) right now.

Cross-Origin Resource Sharing [w3.org] is a good start, but it's not a complete replacement for arbitrary network access. For one thing, it would pose problems for a "mash-up" application whose client-side code downloads data feeds (not necessarily the RSS feed that a web browser can read upon installation) from several web sites that make the feeds available to the public but don't have the resources to process requests to opt-in to every single web application that wants to read the feed. It also rules out peer-t

They can pretty easily flag those as being available to XHR from anywhere, then. If they really want them to be available that way, of course.

The problem is that it defaults closed, and a lot of web site administrators aren't going to 1. know how and 2. care to fix it. Imagine if web sites had to whitelist Referer domains. And restricting XHR using a list of exceptions to a client-side same origin policy isn't even secure; the original web server could just proxy the requests at a cost in server bandwidth ($) and latency (ms).

some people are trying to fill this gap with Web Sockets [...] various proposed 3d APIs for canvas

But until they do, phones that run Firefox and web applications designed for HTML5 and Firefox-specific extensions thereto

The right solution in this case would be a 401 Unauthorized result, not a client-side-enforced limitation. Are you envisioning a situation in which the data is available to humans for free and to proxies for free but to client-side scripts for pay?

The scenario CORS is supposed to help with is that of a user being logged into site A (call it The Bank) without site B being able to send certain requests with the user's credentials to site A and read the responses. If site B wants to make requests from their own server, they don't have the user's credentials and will get a 401 or equivalent. If site B wants to make the requests via the browser (which does send credentials with requests), then the request is only sent (in the preflight case) if the righ

I have 30 apps (not including the pre-installed ones and direct Safari links) on my iPhone, all free (I'm a cheapskate, sue me). Of those 5 directly use the camera, 12 have some location awareness, 4 do direct audio capture and processing, and three use the compass. Maybe these will become web-enabled hardware APIs, but I don't think any of them are today. So, more than half of my applications would have fewer features if implemented as web applications. At least 10 of them wouldn't be on my phone witho

Firefox already has location awareness, the next version of Fennec is expected to have a camera API, and I believe the phone that Mobile Firefox is debuting on provides an API for the microphone that Firefox can use.

I thought the same thing, then I saw Quake live, which, though it does have its own plugin/extension it is very much a "real game" done in a browser. While the iPhone might not have the horsepower to do it yet, technology moves quickly.

Enter WebGL, recently released as a draft spec by Kronos Group, the people who maintain the OpenGL standard; that problem is close to being solved as well. The only remaining question is whether device vendors will provide web browsers running on their platforms access to OS and hardware APIs on par with the native SDKs.

First of all, you can be 100% certain that unless Mozilla's made some kind of specific arrangement with Apple, this will not be allowed on the App Store. It's plainly and obviously against the SDK terms.

Second...how many times have people complained that web apps are totally inadequate substitutes for native apps, for many types of application? I mean, sure, you can make an RSS reader, or a Twitter client, but what about (for instance) Myst? That's now an iPhone app, weighing in at over 500MB, if I recall correctly. Do you really think that's going to be a viable app to distribute as a web app?

Third, unless you're going to have some sort of subscription thingy worked out, how are you going to make money on web apps without intrusive ads? Again, consider Myst. No one is going to accept ads suddenly popping up when they try to link from Myst Island to Channelwood. And I doubt that people will want to pay a monthly fee to access a single-player game, either.

Fourth, if you're writing a plain web app, however fancily mobile-enhanced, how are you going to make use of the cool features of different phones? The iPhone has a camera, accelerometers, GPS, and multitouch. I admit I'm not terribly well-versed in the features of other smartphones, but a) do they all have these? b) can you access them from web apps? and c) can you access them all in the same way from web apps?

I'm betting the answers to these are all, to greater or lesser extent, "no."

Mozilla can dream about "killing the App Store." But if it ever happens, it's not going to be Firefox Mobile that does it.

Spot on. I'd also add that since telcos are already complaining about the data-load that the iPhone (and others) are adding to their networks, the cost of the kind of volumes that would be needed make the "web" a decent mobile app platform is (for the moment) prohibitive.

But let's say that bandwidth goes up and cost comes down, your final point "can you access them all in the same way from web apps?" is the final nail in the coffin. As a result of the differences, developers will make (again) the same decis

1: You're missing the point. The point is that developers will move to browser independent webapps rather than writing an iPhone+blackberry app+htc touch app, etc.2: Web browsers are not appropriate for everything, but they're becoming increasingly faster, and increasingly more appropriate for more intense tasks.3: There's already lots of subscription websites - Mozilla need not do anything to support this - people can do this on their own.4: The browser already has access to everything you listed: camera,

You're missing the point. The point is that developers will move to browser independent webapps rather than writing an iPhone+blackberry app+htc touch app, etc.

You're missing the point. If that were going to happen, Palm would have had a smash success on their hands. As is, they've had just enough success to keep the wolves at bay. Developers AND users don't want browser apps. And from what I've read, Apple will remove the app at the first sign of success. Simply put, article's rant is nothing but a wet dream. It simply isn't going to happen - at least not any time soon.

Web browsers are not appropriate for everything, but they're becoming increasingly faster, and increasingly more appropriate for more intense tasks.

Right - and that's only just barely started to happen on the desktop where enough power exists to allow for JIT of JS. Mobile devices are no where near powerful enough at this point to allow for those types of optimizations. Maybe sometime over the next decade... Until then, its not practical, and that's just from a CPU perspective. Broadband radios drain the holy crap out of the battery. Forcing basic functionality to the browser is simply going to make users even more unhappy in addition to the crappy interfaces.

You're point four is certainly a good one but that also means additional layers on layers. That's not going to fly and simply make it unusable for vast too many applications, given the limited nature mobile platforms.

Simply put, a wet dream is a wet dream, no matter now much you want to rationalize its real. In the end, your friends are still going to roll their eyes when you insist you nailed that super model last night. Even if everyone wanted to buy into your wet dream, the technology just isn't there yet.

Inconclusive. Developers and users like the store model. If the store sold polished browser apps (like bookmarks with a little authentication piece), would end-users even notice the difference in many cases?

It obviously wouldn't work for every app, but the "find a restaurant/movie theater near me" apps are essentially internet applications anyway with a little bit of native display logic.

Fourth, if you're writing a plain web app, however fancily mobile-enhanced, how are you going to make use of the cool features of different phones? The iPhone has a camera, accelerometers, GPS, and multitouch. I admit I'm not terribly well-versed in the features of other smartphones, but a) do they all have these? b) can you access them from web apps? and c) can you access them all in the same way from web apps?

If Apple chooses to go that route, they're going to have to be extremely careful not to run afoul of the US' antitrust regulations dealing with this sort of vendor lockout. Especially if it harms the customers or damages competitors. Just because Apple was able to get away with this sort of crap under the previous DoJ doesn't make it a guarantee that there anti-competitive behaviors will be allowed into the future.

No one is going to accept ads suddenly popping up when they try to link from Myst Island to Channelwood.

Well, they could be subtle and work it into the game dialogue/gameplay...

"Bring me the BIG BLUE pages!""D'Ni" could become "Sun'i" and they could have everyone drinking Java there.The "Linking Books" could be Nooks or Kindles.The clock puzzle could have a brand on the face.

This sounds like Steve Jobs before he announced that the iPhone would be supporting native apps and not just web apps. It already had a pretty fast, capable browser, and there were hardly any apps for it. Within a week of shipping an SDK, there were hundreds.

Well, Firefox doesn't have that much to compete with on the mobile front. Lets see, Mobile Safari is decent, but its a bit behind the times and of course will be slow to move to new technologies without a major update by Apple. Android's Browser is pretty decent, and is perhaps one of the best ones, but fragmentation may eventually make it unusable due to older versions of Android. Mobile IE is a joke, Opera Mobile is decent but doesn't really excel in any are (well, aside from making Windows Mobile handset

What the PHB-tard from Mozilla forgot was the initial way of developing apps for the iPhone was in Safari via HTML, CSS and Javascript. Since day one Safari on the iPhone supported sending multi-touch info to Javascript code and many, many other Apple originated extensions to Webkit and proposed HTML and CSS standards (which Mozilla will have to add to Firefox if they haven't already). The iPhone app market exploded when a native SDK became available. Comparing developing apps in Javascript to native SDKs, on any platform, is like comparing skateboards to cars - yeah, both are transportation, with one being a toy and the other the real thing.

One big difference was that, originally, there was also no way to get your "Web App" into the iPhone Springboard (that thing that launches Apps). So you had to hope that your user would bookmark it. Of course, launching your Web App consisted of launching Safari and going to your bookmarks to find the App and then waiting for it to load across AT&T's 2.5G network.

The iPhone has improved enough to use Web Apps. I use sigalert.com on my iPhone to view traffic--it sits in Springboard and, when I tap it,

I'd say this comment misses the point of phone apps pretty terribly. At least the ones I use tend to rely almost entirely on the phone's hardware features. Not just accelerated graphics and GPS and camera, but tie-ins to the address book and calendar, etc.

The Web Apps offline storage stuff has been shipping in Gecko since Firefox 3.0, I believe. You can use Zimbra in an offline browser today, compose mails, and it will save them to its local storage area and then send when you go online.

As in, this has been a solved problem for at least a year and a half, and going on two browser major updates now.

This is exactly why proprietary systems that are built on anti-competitive practices and don't give you the ability to install applications without approval are a very bad idea in the long run, regardless of initial cool factor.

It's a little shortsighted to use "always" to describe the web's winning streak for two reasons:

1) The web has not always won. Despite Google's Office suite, Microsoft continues to dominate the office space and will continue to do so for the foreseeable future. So at least in one market, thick clients have continued to win out over thin clients.

2) The web is just not that old. Claiming that the web will win because it has always won is a weak appeal to tradition made especially weak by the fact that the web is realistically 13-15 years old.

The only place I can think of where a web app seems to have made significant progress where a regular app is available is in e-mail, and much of that can be attributed to most webmail accounts being free.

Retail and distribution. Classified ads. Matchmaking/dating. Socializing and people finding. These are just a few of the sectors where the web has quickly risen to dominance, representing a large portion of the economy.

I want local apps, with local data, that I can synch with anything (one of my PCs, on-line storage...).

I don't want to be dependent on a wireless net connection to access my apps nor my data. In my experience, even wifi is flaky. And I can't trust 3rd parties to have my apps and data available, secure, and safe.I'm a big ASS fan. I'd be interested in local javascript apps, with local data storage, maybe...

Plus the smallest-common-denominator issue: as long as different devices have different capabilities (color, accelerometer, multi-touch, video/3D acceleration...)

"Over time, the web will win because it always does."
Yeah, over time... "over time" linux will win too. It's true most of the apps from the app store could have been made identically as web apps. But then they wouldn't have been on the app store - and no one would have ever seen them.
I'm continually shocked at the amount of money the non-nerds (bosses, project managers, those other people who I'm not sure what they do except go to corporate lunches) at my work spend on the app store. MONEY! that's crazy - I've never seen people voluntarily spend MONEY on apps before! But Apple made a great system for "the normals". They don't want to trawl the web for nifty web apps (like this JavaSript platform game [mrspeaker.net] I may or may not be shamelessly plugging). The just want a happy little environment where they can buy stuff while pretending to be typing important emails during meetings.

The current beta is far worse than the native Maemo browser (itself based on Firefox):
- No inertial scrolling.
- One window per instance, no tabs. This is a deal killer. I don't necessarily need tabs, but opening a separate instance for each page I want to view simultaneously is unacceptable.
- Extremely slow to start and load pages.
- Package is not "optified" - it installs to the device root instead of/opt, taking 20MB out of 256 available in the root.
- Currently there are only three add-ons not marke

I'm still not convinced. There is still a lot that needs to be implemented, such as context-sensitive menus. I have not been able to find a way to save a link or an image, and it's only by trial and error that I was able to open a link in a new tab (open the keyboard, hold ctrl, wait for message about new tab, open tab bar, click on new tab).

The mock-ups I found here [mozilla.org] look good, but they are a long way from actually being implemented.

1. Java is THE dominant platform if you want to program anything that works on pretty much all mobile phones on the planet. Apart from the iPhone, and some Windows Mobile phones, I don’t think there is a phone that can’t do Java.2. In the real world, not many people care about the App Store or the iPhone. It has only 3-4% percent of the global market share, and technologically already was surpassed when it came to the market in Japan, was a novelty for about a month in most of Europe, and only in the USA has gained more than 10% for obvious reasons. Which means, others are still hugely dominant. So much in fact, that I don’t even think it’s worth targeting the iPhone platform. (I’m sorry, but if you now think I’m trolling, that’s the reality distortion bubble, created by the hype. I’m in no way hating the iPhone or anything. It has great raw power and a good UI. I’m just stating the facts as I know them from actually being in the market, and keeping up to date, because I need that to make a living. Prejudice is just stupid, and am happy to be corrected.:)

So I really see no point in yet another layer of inner-platform failure [wikipedia.org], to use JavaScript, when you already have fast Java with accelerated OpenGL, EAX-like audio support, and tons of functions. (Be aware that as much of it is accelerated, Java on mobile phones is vastly faster per raw CPU power, than on desktop VMs.)

If they can offer me all those hardware-accelerated APIs, an ability to check if the phone supports them, a fast JavaScript compiler, and 96% of all phones of the world having it pre-installed, I might consider writing for their platform.;)

Sorry but you are wrong. The iPhone has 17% of the mobile share globally, 50% of the global app usage, and an insane 65% of the mobile HTML request. Unlike you I did the research instead of making shit up. Want the source? Here [macrumors.com]

Sorry but you are wrong. The iPhone has 17% of the mobile share globally, 50% of the global app usage, and an insane 65% of the mobile HTML request. Unlike you I did the research instead of making shit up. Want the source? Here [macrumors.com]

Sorry, but the MorganStanley slide is talking about 'smartphone' share - and not even market share but _shipment_ share. I am very sure that my current phone along with hundreds of millions of other SonyEricsson or Nokia phones didn't count in their survey, although they've been dealing with GMail or Google Maps just fine years before the iPhone was a glimmer in Steve's eye.

While you seem to have some industry experience, I think you perhaps write off the iPhone a little too easily. I can certainly see some parallels with Apple's Mac strategy in the 80's, but they have done a lot of things right (from a dev point of view), and are seeing success accordingly. 100k apps and rising speaks for itself really.

I agree that the iPhone has a small marketshare of total mobile phones, however the vast majority of mobile applications (where a web app won't do), are targeted towards smartp

It has only 3-4% percent of the global market share, and technologically already was surpassed when it came to the market in Japan

True that it currently has 3-4% of global market share of all phones - but here you are talking about Java, which does not run on all phones either. So why not speak to the smartphone percentage, which is more like 20%.

As for Japan, if it was surpassed years ago then why is it so popular [bcnranking.jp] there? It's not number one (that's a list updated every week), but it's been in the top ten ever since it was pointed out that it reached number one [cnn.com].

In the real world, not many people care about the App Store or the iPhone.

Except for thirty or forty million users worldwide. By all means feel free to leave them to me.

I'm just stating the facts as I know them from actually being in the market, and keeping up to date, because I need that to make a living.

I think you need to do a better job keeping up. I'm in the market as a full time mobile developer, so my living depends on this too...

when you already have fast Java with accelerated OpenGL, EAX-like audio support, and tons of functions. (Be aware that as much of it is accelerated, Java on mobile phones is vastly faster per raw CPU power, than on desktop VMs.)

You won't find a much bigger Java fan than myself. But the reality is that even if you have some of that on every platform, you have almost no platforms that offer all of that - and the testing required across so many devices makes "reality" that you have to target a handful. Real-world apps are moving in droves to the iPhone/Android, and only the simplest apps or some games are still going to J2ME platforms.

Now if you are including Android in there it's a different matter, but it's really different than J2ME.

All that said... I agree with your conclusion that the mobile browser app market is just not compelling compared to the iPhone or Android - or even J2ME. They'd have to add a ton of stuff just to get close and the native platforms swill simply always be ahead of the game.

This is joke of the year material. For those who don't know, the current versions of Fennec for the Nokia N900 basically crashes left and right on pretty much anything. Fennec isn't threating anything, anything soon.

I still think that local apps will be preferreable. The thing is that a lot of apps are only useful on the web, so the concerns about not being able to access them w/o a net connection are baseless. Not all apps, but there's lots of social networking apps and others that need networks.

Like Apple will allow them on the iPhone and I doubt it will get me to switch from Google Android browser. I enjoy using the Opera browser for Android sometimes but even that doesn't feel as intuitive. I doubt Firefox will be better.

Sorry, but having a structure that manages Movies, Videos, Audio, Apps seemlessly for Apple only Hardware will never be threatened by a non-Apple product that has no means to duplicate the AppStore via iTunes.

Opera Mobile claimed to be the fastest browser of them all, but all the masses got was a fast browser that locked up almost ALL of the time and was bogged down by incredible resource usage. I've been hearing about Firefox Mobile for years now; I'll believe it when I see it.

Plus, Safari is one of Apple's core tools! Does anyone think Mozilla can finagle their browser into Apple's app store? That'd be awesome if they pulled it off, but I see it as being quite unlikely.

Currently, Opera 10 is available on every handset which is open to 3rd party. Read it as iPhone excluded.

J2ME (via Opera Mini), Symbian (which has 40% share and not even mentioned by Mozilla), Windows Mobile and Android supported. It is basically the same engine as Desktop one, bit by bit thanks to their ultra portable web renderer. Even "dead" (chap 11.) UIQ3 is supported somehow with a native client.

They are packing "Widgets" which are based on W3C standards for desktop right now, Opera 10.20 alpha does run same widget across 3 desktop platforms. Linux, OS X and Windows. It doesn't need to crack into their build system to predict they will go mobile with that idea.

What bothers me is, PC Pro, a UK based site doesn't even ask why on earth Symbian is not even mentioned or supported since Symbian is actually a british thing to begin with. Nor they fail to bother checking Opera which supports some handsets/operating systems which are abandoned by vendor themselves.

For web designers, widget developers, there is nothing to bother. They as a small company always supported standards, somehow failed to get market share because of it. So, there is no "Opera specific" quirk. It is all W3C.

Web browsers do make a pretty convenient cross-platform frontend, giving you effortless ability to run parts of the application remotely. The downside is making the same program work the same in each different web browser can be a pain (esp. I.e.... shudder).

Anyone know if the latest versions of IE have fixed their appallingly bad string manipulation performance, which was (is?) orders of magnitude worse than all of their competitors?

... who thinks FF is lacking quality control recently? I have 3.5.2, but it crashes way too often and feels slower. Javascript also stutters. It pauses now and again, as if it were trying to catch up to something. It could be blazing fast between pauses, but if its freezing, it ain't blazing.

You can tout your own horn all you want, but show me the evidence.

This isn't necessarily off-topic, just poorly referenced to the topic. The summary cites the original article's claims of "the fastest javascript engine," so clearly Firefox performance claims are being made here. And I, too, thought that existing versions of firefox (I'm running 3.5.5 64bit linux) don't provide strong support for Firefox Mobile to live up to this hype.

Mozilla is suggesting that Firefox should essentially be the OS for smart phones. If that came to pass, all the apps on your phone could be, at best, as stable as Firefox. Which makes the stability of Firefox definitely on topic, in addition to the speed.

ECMAScript has been described as Scheme with C syntax, or what Lisp might have been had the M-expressions [wikipedia.org] ever been implemented. Are your complaints about the language itself or about the DOM?

I think the article started off heavily biased against Apple already. It plainly states: "app stores created by Apple and its ilk". Seriously?! Is someone at Mozilla so jealous that Apple has developed a profitable business model that they have to resort to ad hominem attacks?