Firefox Mobile Threatens Mobile App Stores, Says Mozilla

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

Comments

web-app-web

[ghetto2ivy]

Not without better connectivity.

Re:web-app-web

[maxume]

Or perhaps the local storage features present in html5.

Re:web-app-web

[maxume]

My above post is flamebait in much the same way that marshmallows are meat.

Re:web-app-web

[some_guy_88]

Yeah, people suck.

Re:web-app-web

[thetoadwarrior]

And I thought I was the only one that liked meaty marshmallows.

Re:web-app-web

[Beardo the Bearded]

Marshmallows are made with gelatin, which is made from meat. (Technically, it's the ground cartilage of food-grade animals)

Vegetarians and vegans won't eat marshmallows because they are basically meat and sugar.

Re:web-app-web

[cheftw]

He was obviously talking about this: http://en.wikipedia.org/wiki/Althaea_officinalis

Re:web-app-web

[maxume]

Right, a little bit of flamebait to hold it together, but mostly sugary goodness.

Re:web-app-web

[Greenisus]

I've used the local storage features and they're great. Even made a simple hash store based on it. 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).

Re:web-app-web

[dgatwood]

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>

Re:web-app-web

[FatdogHaiku]

mmmm... meatmallows...

Re:web-app-web

[SanityInAnarchy]

you're still stuck in the browser, so the user experience isn't quite as good as a native app.

People always say that, but whenever I ask, I can never get a straight answer.

What, exactly, isn't quite as good as a native app, at least in the realm of things you'd even consider making a web app for?

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.

Depends what you mean by "native" -- in many tests, v8 (from Chrome) is comparable to any scripting language, even faster than most.

At least, that has been my experience with the iPhone and Mobile Safari.

I have absolutely no idea how Firefox compares to Mobile Safari -- however, the summary indicates Firefox Mobile claims to be faster.

Re:web-app-web

[SanityInAnarchy]

There's still the problem of having a good way to back up local storage....

I would suspect many apps using local storage would use it as a cache for server storage... but really, that's up to the browser. On my system, I can simply back up "~/.config/google-chrome/Default/Local Storage" and be done. Looking inside, it's a few easily-read sqlite databases, stored as protocol_domain_port, more or less.

On Linux, at least, backing this up is a trivial shell script.

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 is, however, a standard for drag and drop, and several libraries which emulate it in all browsers.

There's no way to guarantee that your handlers won't get stripped out by some overzealous UI library that you load.

Sure there is, just don't use such an overzealous UI library! That's like complaining that X11 sucks because it's theoretically possible to make a widget toolkit that sucks.

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.

I haven't touched it, so maybe you're right. Then again, there are more than enough tools to build your own.

There's no way to set up an automatically recurring callback with a guaranteed period.

That's the nature of a single-threaded system. But setInterval works, and I really don't see why it's inadequate for a GUI system.

There's no way to spawn multiple threads of concurrent execution (except for a FireFox-specific mechanism).

Google "web workers" -- it's not Firefox-specific.

There's no standard way to talk to hardware.

That's by design. What hardware do you need to talk to?

Even simple things like specifying which UI elements should grow proportional to the window size is an utter pain.

Assign a fixed size to elements which shouldn't grow, assign a percentage to the ones which should. This has been known for years. I'm sure you've found something that's "an utter pain", but what is it?

Creating clickable buttons that don't get their text content selected can be rather entertaining.

Your ShellScriptGames link suggests you're not an utter moron, but you're losing credibility here...

<button> ...duh?

Convincing the browser to not deselect the selected text in a contentEditable region when you do so is doubly so.

I'll again grant that I don't know how this actually works.

Then, you have that fun box model that only a committee could love (all of us are dumber than any of us).

What is it about the box model you don't like? This is actually not a rhetorical question -- I'm sure it has flaws, I just don't really know about them.

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

I'm shaking my head... CSS3 supports columns natively, to take one example.

Yeah, it's going in the right direction. It's got a long way to go, unfortunately.

I will agree with this, absolutely. However, most of your complaints are addressed with current or future standards, much of it supported now -- for example, I'm using a Chrome beta, and I was able to see multicolumn layouts. (If you have to support IE, how are you getting local storage and CSS animation to work?)

Re:web-app-web

[value_added]

Marshmallows are made with gelatin, which is made from meat. (Technically, it's the ground cartilage of food-grade animals)

You're right about the marshmallows, but everything else is wrong.

Folks might want to check the Wiki article for a better explanation. Or ask their grandmothers how soup/stock is made.

Re:web-app-web

[totally bogus dude]

What, exactly, isn't quite as good as a native app, at least in the realm of things you'd even consider making a web app for?

If they expect to de-throne the App Store, then they're not just talking about "things you'd even consider making a web app", they're talking about everything. Either that, or they think the games aren't important... even though they seem to be some of the most popular things in the apps store. Plus some of the other popular stuff seems to be things like "turn your iPhone into a remote control for X", which is hard/stupid to do via a web-app.

But the main thing is that you lose access to many of the user-interface elements that make using the device efficient. It might not be such a problem for devices like the iPhone which are primarily touchscreen-driven, but for other phones which use physical buttons, not having access to them makes for a significant decrease in usability. Even on the iPhone: can a web app make proper use of multi-touch?

A possible additional factor is that, to take advantage of the supposedly easier development of web-based apps, you want the server to be doing most of the work. For the end-user, that means latency between their selection an option and something happening. This will vary depending on the app, but again, if you're saying "everything will be a web app", you're increasing the likelihood of this happening. The alternative is to write the entire app in client-side scripting, but that doesn't sound like it'd be much, if any, better than writing a native app in the first place.

Re:web-app-web

[mqduck]

I've used the local storage features and they're great. Even made a simple hash store based on it

Do you need a prescription first?

Re:web-app-web

[LordKronos]

Marshmallows are made with gelatin, which is made from meat.

Wow. Now that I know marshmallows are meat, I need to go rearrange the food groups on my dietary chart. My dinner plans have changed!!!!

Re:web-app-web

[ivucica]

There's not even a drag and drop mechanism built in that works across all browsers.

Since we're talking HTML5, this demo may be relevant. Since we're talking about HTML5, don't complain about "does not work across all browsers". IE6 and Firefox 2.0 surely don't support HTML5. How did I conclude you're also talking about HTML5? Because you mentioned local storage.

Otherwise, yes, there are numerous problems with web as a platform. They all, however, stem from everyone doing things their own way. You may devise a way to battle with HTML problems in different way than I will. If suddenly browser makers decided that my way is correct, you'd go nuts.

The right way to go for web apps would be to ditch HTML and DOM as such, and even some standard JS functions such as setInterval() (which goes against OOP so horribly that it's undescribable). Browsers should have two modes: web and app, and which could be intermixed via iframes in both modes.

Getting everyone to agree to some standard set of features, however, doesn't seem possible. Is Silverlight (as a concept) and perhaps XPI maybe a step in the right direction? Should something similar, but more app-oriented and not implemented as a plugin be developed? And how is anyone supposed to get Mozilla, Microsoft, Google and Apple to agree to a common way to make such a drastic paradigm shift while retaining quality?

Re:web-app-web

[StuartHankins]

Oh great I was just thinking about marshmallows and now I am thinking of horse hooves.

Re:web-app-web

[dgatwood]

On Linux, at least, backing this up is a trivial shell script.

Being able to back up the files and being able to back them up in a fashion that is useful to the user are two different things, though. For example, if I want to restore that backup into an existing system, the merge of those SQL databases is nontrivial at best, disaster-prone at worst, and insane in general.

There is, however, a standard for drag and drop, and several libraries which emulate it in all browsers.

Son of a gun. After all these years, they finally got around to codifying it in a draft standard for HTML5 a few months ago. About freaking time.

Google "web workers" -- it's not Firefox-specific.

Ah. I didn't realize anybody else had implemented it. Upon further looking, I see Safari 4 does. I retract that statement.

That's by design. What hardware do you need to talk to?

No hardware specifically. I was merely pointing out that there are a number of types of software that JavaScript just plain cannot provide. For example, if I tried to build a computer whose whole programming interface was a browser, even trivial tasks like renaming files or copying photos off a flash drive would not be practical without significantly changing the basic model for interaction between the browser and the hardware.

Assign a fixed size to elements which shouldn't grow, assign a percentage to the ones which should. This has been known for years. I'm sure you've found something that's "an utter pain", but what is it?

Among other things, percentages don't always do what you want. For example, if you need a 100 pixel area and a second area beside it that tries to be the same as the remaining size in the enclosing container, different browsers seem to interpret that "100%" subtly differently (with IE typically being the worst offender). Things get even hairier if you want fixed width margin areas. The classic one that's a pain in the ass to get right is trying to specify a border image. Yes, the new border-image tag helps with this, but it still leaves a lot to be desired. For example, there's no way to use a gradient (e.g. -webkit-gradient) as a border with -border-image and still retain the ability to round the borders with -webkit-border-radius. And it's not a bug in Safari; it is a flaw in the spec.

There are all sorts of little quirks when working with the box model. It's not that the box model is fundamentally wrong---it's pretty solid on the whole---but that there are all those little edge cases that keep coming back to bite you on the you-know-what. :-)

...duh?

I can't remember what problems I've had with the button tag, only that I've had problems with it.

What is it about the box model you don't like?

There are just a lot of odd things about it, mainly because not everybody implements it the same way. The whole thing also has an annoying flaw in that it is based on an arbitrary device-independent pixel size, but most browsers don't support fractional pixels, making it really rather problematic to do precise layout, and it doesn't provide a way to work with true physical pixels for when you want to do layout in a less generic fashion.

Regarding the columns stuff, I haven't looked at the CSS3 column bits. That either didn't exist or wasn't supported in Safari the last time I tried to do a columnar layout. (Couldn't care less about IE.)

Re:web-app-web

[dgatwood]

Since we're talking HTML5, this demo may be relevant. Since we're talking about HTML5, don't complain about "does not work across all browsers". IE6 and Firefox 2.0 surely don't support HTML5. How did I conclude you're also talking about HTML5? Because you mentioned local storage.

Thanks for pointing that out. The HTML5 drag-and-drop stuff is a relatively new addition to the spec and I wasn't aware that it had gone in.

Re:web-app-web

[ivucica]

I too have only realized that it exists upon stumbling upon that site.

Re:web-app-web

[sskinnider]

mmmm. Meat and sugar!!!!

Re:web-app-web

[SanityInAnarchy]

Either that, or they think the games aren't important...

There's something specific. I can work with that.

What about a web browser isn't suitable for games?

Plus some of the other popular stuff seems to be things like "turn your iPhone into a remote control for X", which is hard/stupid to do via a web-app.

Depends what X is, but it doesn't sound particularly hard.

for other phones which use physical buttons, not having access to them makes for a significant decrease in usability.

So expose them as keystrokes, which web apps do have access to.

Even on the iPhone: can a web app make proper use of multi-touch?

I'm not sure, though apparently Firefox Mobile exposes even the accelerometer to the web app.

A possible additional factor is that, to take advantage of the supposedly easier development of web-based apps, you want the server to be doing most of the work.

That's only if you assert Javascript isn't appropriate for this. I disagree. As you say:

The alternative is to write the entire app in client-side scripting, but that doesn't sound like it'd be much, if any, better than writing a native app in the first place.

Except that you still have the advantage of write-once, install anywhere, automatic sandboxing, updates, and everything else.

If you think the only advantage of a web app is being able to write it in your own language on the server-side, you have wildly missed the point.

Re:web-app-web

[Swift2001]

You want to trust your phone's security to javascript? Are you nuts, Firefox? How many security updates has Firefox released for the javascript component?

And that's just for starters.

I was angry at Apple for one thing: no Google Voice. I've since gotten Google Voice in my browser, and you know what? I don't care for it that much.

Re:web-app-web

[SanityInAnarchy]

For example, if I want to restore that backup into an existing system, the merge of those SQL databases is nontrivial at best, disaster-prone at worst, and insane in general.

Would you expect to be able to do the same with cookies?

The simple solution is, choose one database or the other, don't try to merge them. It's got one SQLite database per domain, and chances are, you really don't want to try merging them within a domain.

About freaking time.

Sure, but again, it's something various UI libraries have had for awhile.

Upon further looking, I see Safari 4 does. I retract that statement.

Not all of the demos seem to run, but I have gotten a few to work on Chrome 4 Beta.

For example, if I tried to build a computer whose whole programming interface was a browser, even trivial tasks like renaming files or copying photos off a flash drive would not be practical without significantly changing the basic model for interaction between the browser and the hardware.

Check out the demo of Chrome OS.

And no, it doesn't seem like there's much difference at all -- you'd just need to expose an API, and only to trusted apps. Take Chrome Extensions -- when writing an extension, I can choose exactly what I need to access, and users will know that when they install it. I have one installed right now that, in theory, has access to "all my private data on youtube.com" -- while I still wish it could do what it does without that, it's still much easier to swallow than an extension having access to everything.

Chrome extensions are pretty much chunks of Javascript and HTML. In extreme situations, you can include a plugin inside your extension, but that's a last resort.

For example, if you need a 100 pixel area and a second area beside it that tries to be the same as the remaining size in the enclosing container, different browsers seem to interpret that "100%" subtly differently (with IE typically being the worst offender).

I guess I'll have to test this out, but I'm curious. How are they different, especially in non-IE browsers?

Worst case, it is possible to have CSS effectively style things as though they were table cells.

The classic one that's a pain in the ass to get right is trying to specify a border image.

Is this something non-web GUIs have right?

I can't remember what problems I've had with the button tag, only that I've had problems with it.

I know the biggest objection I usually run into is people who want to re-style everything. There seems to be a mantra among designers that "default is ugly" -- specifically when referring to form controls, especially buttons, checkboxes, etc.

What's often forgotten is that there's nothing in the spec which says they have to be ugly. Indeed, modern OSes allow these things to be styled quite a lot, and the defaults don't look bad on OS X -- or Linux, IMHO.

But I'll give you the benefit of the doubt here -- it might have been something else.

The whole thing also has an annoying flaw in that it is based on an arbitrary device-independent pixel size, but most browsers don't support fractional pixels, making it really rather problematic to do precise layout

I suppose I consider the lack of "precise layout" in this sense to be a feature. That is, while it would be nice if we could get everything lined up to the sub-pixel, as a user, I prefer sites with simpler designs -- things which are flexible, where layouts are measured in ems and flow with the font size...

Regarding the columns stuff, I haven't looked at the CSS3 column bits. That either didn't exist or wasn't supported in Safari the last time I tried to do a columnar layout.

I do see some obvious problems with it, but it does look like it works for most of what people were wanting. It does work on this Chrome beta.

Re:web-app-web

[dgatwood]

I guess I'll have to test this out, but I'm curious. How are they different, especially in non-IE browsers?

I honestly don't remember. It has been two or three years since I dealt with that one. It was mostly off-by-one-pixel type errors, I think, but again, not something I've dealt with lately. Seems like there was some case I ran into where IE rendered an inner box at about two-thirds the width of all the other browsers or something really bizarre like that, but it was probably a one-off that would literally require reproducing the entire structure just to hit it.... :-)

[re border image] Is this something non-web GUIs have right?

Don't know. That's just an annoying nit I noticed a couple of weeks ago. :-)

Re:web-app-web

[totally bogus dude]

Well, perhaps games could be workable IF the browser provides the code with full access to all of the device's features, including graphics acceleration, audio mixing, proper responsive input, and so on.

But: what's the real-world likelihood of there being a standard method for accessing all these device-specific functions? It's still pretty hit-and-miss as to whether browser X will support Canvas or lay out your CSS the same way as other browsers or support SVG or embedded fonts... etc etc. And that's on a full-fledged PC. So, the iPhone and Symbian and Android and the other things are all going to somehow get together and offer a standardised way to determine the device's capabilities, and access those capabilities?

Possibly Firefox Mobile will be brilliant and nobody will prefer another browser, and app developers will be able to take for granted that it's installed (and up to date?), and the Firefox Mobile developers will rigorously test it on every smartphone capable of running it to make sure it behaves perfectly. But then... is a world full of Firefox Mobile-only apps any better than a world full of Internet Explorer 6-only apps? Hasn't the internet community been fighting an uphill struggle for years and years to try to get away from a browser monopoly? Is the answer to replace it with another one?

But, what's the likelihood of other browser vendors creating something that's actually compatible and actually gives you "write once, install anywhere"? We don't even have that on PCs, with a considerably more mature market and faster internet access than smartphones. Even if they try, it'll still be like writing web apps today: gotta use a library with a whole bunch of tricks and workarounds for the different browsers that have been encountered. Good luck abstracting away slight peculiarities in input methods, graphics acceleration, screen sizes, processing power...

Ultimately there's two logical reasons why I generally dislike web apps, and one practical reason. The logical reasons are that: a) you have to be online to use it; and b) you're running an app within an app.

a) shouldn't matter on a smartphone right, because you always have internet access through the cellular network? However: maintaining a 3G connection chews up battery life, so playing a game which chews up battery life while also maintaining an internet connection is just going to make things even worse. Secondly, people aren't always in range of a tower when they'd like to use their apps; and thirdly, sometimes it just doesn't work. This is just the standard argument against being dependent on hosted services. Plus little things like payment models: they might sell you a product, but if they take their servers down you suddenly can't use it anymore. So I guess we'll have to lease all our apps instead.

b) comes back to my comment about the phone's physical buttons. "Expose them as keystrokes" you say. So how do I exit the browser app, then? This is similar to having shortcuts in web apps for PCs. Alt+F traditionally accesses the file menu, and for consistency it'd be nice to have Alt+F access your web app's file menu. But... what if you actually wanted to access your browser's File menu? There are workarounds but they're just that: workarounds.

The only real solution I see to b) is to make the "web app" act and behave as if it's a standalone app, so that you, as a user, don't have to be conscious of the fact that you're running an app-within-an-app. This could perhaps be solved with an app launcher; you could even potentially get around problem a) by caching the files locally so you can run it offline, with an automatic check for updates if you do happen to be connected. In other words, create a little package management system around the web apps. Of course, there's no reason you can't build a similar system around native apps, so it's no more an advantage of web apps than it is of native apps.

Theoretically, web apps could work. You'll probably have answers for all the drawbacks I've mentioned. But

Re:web-app-web

[SanityInAnarchy]

IF the browser provides the code with full access to all of the device's features, including graphics acceleration,

WebGL.

audio mixing,

You got me here.

proper responsive input, and so on.

What's wrong with input as it stands?

what's the real-world likelihood of there being a standard method for accessing all these device-specific functions?

What about them is device-specific?

It's still pretty hit-and-miss as to whether browser X will support Canvas or lay out your CSS the same way as other browsers or support SVG or embedded fonts...

Is it still hit-and-miss if you take IE out of the equation?

is a world full of Firefox Mobile-only apps any better than a world full of Internet Explorer 6-only apps?

Not that I want to see this any more than you do, but the answer is, unquestionably, yes. Firefox is open source, and is already more standards-compliant than IE6 ever was.

The logical reasons are that: a) you have to be online to use it;

"Work offline" + offline storage.

b) you're running an app within an app.

So's anything that runs on an OS. So's anything that uses a runtime -- any Java, Ruby, Python, Perl, most Lisp apps, even C, if it happens to be compiled for LLVM. As a logical argument, it falls flat on its face until you have something specific.

So how do I exit the browser app, then?

Same way you exit any app, I suspect...

This is similar to having shortcuts in web apps for PCs. Alt+F traditionally accesses the file menu, and for consistency it'd be nice to have Alt+F access your web app's file menu. But... what if you actually wanted to access your browser's File menu?

I've never really felt the need to have a menu in a web app. But you do have a point here, and I'd think this is something that could be negotiated in two ways:

First, it's entirely up to the browser whether the web app can override the browser's keyboard shortcuts.

Second, both the browser and the web app could theoretically allow the user to customize keybindings. It's nowhere near as convenient as it could be, but it works.

It would be better if the app could detect the scheme in place by the browser. One hack would be to look at the user-agent string...

But it's worth mentioning that every existing app has the exact same problem -- some keystrokes (or buttons) are used by the OS. I wouldn't want to use alt+f2 in a Linux app, and I _couldn't_ use ctrl+alt+del in a Windows app.

Of course, there's no reason you can't build a similar system around native apps, so it's no more an advantage of web apps than it is of native apps.

Well, except that such a launcher already exists in Chrome (both the browser and the OS) -- but you're right, having a launcher is not an advantage of web apps.

But then it comes to my practical reason for disliking them: nearly all of them suck compared to native alternatives.

Assuming native alternatives exist, maybe... But I often, repeatedly, challenge people for specific problems they have with web apps, and I don't often get a response of something a native app can do that a web app can't, other than something which is, currently, categorically out of their reach due to API limitations. (For example, high-end CAD software can't be a web app until we get some decent 3D graphics.)

Their only advantage is that you don't need to install them, so you can access them from any computer.

That's far from the only advantage. Theoretically, you could also make that an advantage of native apps, and the only reason it would apply more to web apps is that everything already has a browser.

But some

Ahem

[Captain Splendid]

Yeah, worked for java didn't it? Not sure Apple's any likelier to just roll over any more than Microsoft or Adobe did.

Re:Ahem

[palegray.net]

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

Re:Ahem

[MichaelSmith]

But the only really successful app store is on the iphone, and apple won't allow firefox on that platform.

Re:Ahem

[timbck2]

Step 1: Jailbreak your iPhone.
Step 2: Install Firefox Mobile.
Step 3: ???
Step 4: PROFIT ?!?

Re:Ahem

[aztracker1]

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.

Re:Ahem

[Jugalator]

3. Reach merely a fraction of the iPhone market where people are geeky enough to bother...?

Re:Ahem

[timbck2]

Yep, that sounds about right...

Re:Ahem

[contrapunctus]

step 1.5: Change SSH password.

Re:Ahem

[Abreu]

Dominance over a small fraction of a large enough market can be a very lucrative proposition...

Re:Ahem

[m.ducharme]

But would still not be enough to drive out the app stores.

Re:Ahem

[Anonymous Coward]

Firefox itself isn't the moneymaker, the apps are, so it'd really be a fraction of a small fraction of the market -- and in most cases, it'd be a small fraction of a small fraction. Generally, that's not all that lucrative a proposition.

Re:Ahem

[darjen]

If I recall correctly, javascript/ajax did actually catch on way more than applets.

Re:Ahem

[christopherfinke]

Yeah, because it's not like Android has an enormous company like Google betting on its success oh wait it does.

Re:Ahem

[el cisne]

Come on! That is comedy gold right there!

Re:Ahem

[palegray.net]

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.

Re:Ahem

[palegray.net]

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.

Re:Ahem

[prozaker]

how can you tell he is a die hard mac fan?

Re:Ahem

[Anonymous Coward]

One man's comedy gold is another man's stfu.

Re:Ahem

[Yvan256]

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?

Re:Ahem

[jo42]

You have it backwards. The original way of developing apps for the iPhone was via webapps running in Safari. Then Apple released the native SDK and the world changed forever.

Re:Ahem

[selven]

And where people are already capable of getting whatever app they want, defeating half the point.

Re:Ahem

[maxume]

The souvenir vial of Steve Jobs sperm.

Re:Ahem

[MichaelSmith]

I take your point but I expect Steve Jobs will try to improve javascript performance while structuring the APIs to ensure that his OS retains control.

Re:Ahem

[h4rr4r]

Nope, because they can't actually force anyone to do anything. And even if they tried you could use iceweasel.

Re:Ahem

[shutdown -p now]

First thing I thought about, as well. This has already been tried; it didn't work. HTML5 is still not a replacement for a rich client-side application. Furthermore, compared to any decent modern client UI framework - e.g. Cocoa (including the iPhone variety), or JavaFX, or WPF/Silverlight - HTML5 is still too much of a kludge, and too hard to deal with.

Re:Ahem

[aztracker1]

The fact he just updated his computers (bought a new macbook, imac 27" and a mini) to retire his old G4, and macbook.

Re:Ahem

[ckaminski]

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.

Re:Ahem

[HarrySquatter]

Yeah cause Android has been such a smashing success. Oh wait...

Re:Ahem

[SanityInAnarchy]

First, "the world changed forever" -- really? If you're not at least saying that ironically, I'm going to find it hard to take anything you say seriously.

Now, certain iPhone apps do need native APIs. Certain will want OpenGL, and I'm not sure Mobile Safari supports WebGL. But you don't have to look very far to find an example of a developer who, disgruntled with the iPhone app store review process, has chosen instead to release it as a web app.

Re:Ahem

[Anonymous Coward]

It worked for apple all these years in PC sales hasn't it? a small very lucrative portion of a gigantic market seems to be Apple's way of doing business..

The problem is webapps will NEVER WORK in the write once run anywhere fashion that people keep dreaming up

No matter what you do to HTML, CSS, etc.. your still left with Lowest Common Denominator syndrome.. which is horrible enough in an ecosystem such as PC/Console gaming (well its got to run on the ds/psp/pc/ps2/ps3/xbox360 and the wii.. we will write our engine to work on the weakest platform and if the money from the platform owner is big enough we will sell our services to 'tweak' for that platform.

Unless every gizmo manufacturer agrees to NOT have a native UI, and foundation that makes its device somewhat unique.. there is no chance in hell that any "webapp" will ever be worth its time of development .. or that it will actually "run everywhere" there are simply too many variations in hardware capabilities (screensize, bandwidth, local storage are only the tip of the iceberg) for any modestly complicated app to actually be done to a "standard' that will for example NOT require extensive modifications for each platform (requiring buying in to each platforms hardware/development enviroment etc) or be so generic it may as well simply exist as a URL accessed via the platform's browser.

This is what is ultimately going to kill Palm if they dont have a native SDK that they are not telling anyone about yet..

Give me a single financial reason to target the webos enviroment rather than just writing a mobile webpage that works on all devices ? what do i gain for tying myself to that sinking ship?

Re:Ahem

[Anonymous Coward]

I don't know what ActiveSync is good for, but I get my corporate exchange mail and my gmail updated simultaniously over wifi flawlessly. email on the iPhone == win.

Re:Ahem

[beelsebob]

The annoying thing is, every time Mozilla have announced the fastest javascript engine on earth in some form or another, Chrome and Safari have mysteriously been faster than it still. I'm willing to bet the same will be true on mobile phones.

Re:Ahem

[NoOneInParticular]

I think your argument is missing something, something about what heppened to your dev. Say, if you would be able to write ...

But you don't have to look very far to find an example of a developer who, disgruntled with the iPhone app store review process, has chosen instead to release it as a web app, was wildely successful doing this, people recommended this application to all their friends, making the developer a shitload of money. All because he didn't target the app store.

... then I would say you would be onto something. As it stands, the above would be untrue, and nobody cares that some dev somewhere decides to kill his business in order to stick it to the man.

Re:Ahem

[teh kurisu]

The odd thing about the way apps were brought to the iPhone is that, although Apple touted web-apps as the future when the first phone was released, many important (mostly HTML5) features that could have made the web API an almost viable platform didn't arrive until iPhone OS 2.1, a point version after the native SDK was released.

Page caching, offline DB storage and the ability to run an app full-screen from the home screen are all features that are available now but weren't available pre-2.1. With them it's possible to make (relatively basic) iPhone apps without having to go through the App Store approval process, which I thought would have been quite a major incentive by now.

Re:Ahem

[MirthScout]

ActiveSync is basically for Exchange. So, yes you can get your corporate Exchange email and your gmail via imap or pop3 at the same time.
But you can't get your corporate Exchange email, contacts and calandar AND gmail via Exchange (ActiveSync), gmail contacts and Google calendar (both only syncable over the air via ActiveSync). It is very limiting.

What I want is to access my corporate email, contacts and calendar (Exchange ActiveSync) and also my Gmail, Gmail contacts and Google Calendar (using ActiveSync). Just can't be done with the current iPhone software.

Re:Ahem

[palegray.net]

That certainly can't be ruled out. Hopefully, Apple would try to capitalize on other "app store" type ventures but with web apps. Some people really like the fact that Apple reviews everything (although the review process is frequently pretty jacked up), and they may be able to retain that as a selling point. Who knows?

Re:Ahem

[palegray.net]

As per my other reply at the same hierarchy level as the GP, the concept of faster web applications on mobile devices should wind up applying to Safari as well. Honestly, resolution and interface problems really aren't that hard to accommodate. Good web developers have been producing apps that run well on multiple platforms for years.

Re:Ahem

[StuartHankins]

Yep. Before I got an iPhone I got an iPod Touch 2G. I jailbroke the iPod almost immediately. But losing all my apps & settings with each update is such a PIA that I'm unlikely to ever jailbreak the iPhone. It's too bad, there are many programs (Categories, MobileTerminal, etc) from the jailbreak people that are SOOO much better than any of the apps in the App Store.

Re:Ahem

[SanityInAnarchy]

As it stands, the above would be untrue, and nobody cares that some dev somewhere decides to kill his business in order to stick it to the man.

You'd have a point, if he had a business to begin with. Thanks to the App Store's psychotic review process, he didn't.

Re:Ahem

[hazydave]

Well, the latest numbers (estimates, and it's definitely not Apple releasing the numbers) claim that about 9.5% of iPhones are jail-broken. Not a non-trivial number.

But that's kind of avoiding the point entirely... if the point of this is to put on apps that get around the iTunes store, requiring Firefox on the iPhone is putting the cart before the horse... once you can run Firefox, you can run any binaries, iTunes approved or not.

The real point here should be that iPhone programmers are ALREADY using Javascript, HTML5, and CSS to get around the iTunes store's restrictions. Sure, there are a limited set of apps, but the latest Safari on the 3GS ran Javascript about 30% faster than my DROID, which was pretty fast itself. So really, the iPhone doesn't need Firefox for this.

And then there's the Palm Pre... same basic CPU (600Mhz-ish Cortex A8) as the DROID and the iPhone 3Gwhiz, and hey, it's main applications API is ... wait for it.... Javascript, HTLM5, and CSS. And it seems to work ok.

Re:Ahem

[hazydave]

10. Wears rose colored glasses, with the phrase "Engineered by Apple in California" on the stems.
9. Lives in California, uses computers, wears polo shirts.
8. Gets really defensive when someone says "cult", even if discussion is about Scientology, or the Moonies.
7. Index finger is longer than middle finger. Or was that rabid IBMers?
6. Slighty faded "Power PC Forever" tattoo on left bicep.
5. Love doll with Steve Jobs face overlay seen in his bedroom at last party.
4. Waits in line at new Apple store openings, even if he has nothing to buy that day.
3. Always speaks of "vast Microsoftian Conspiracy" in hushed tones.
2. Considers "Arrogance" to be the most Virtuous of the Virtues.

and the number one way I can tell he's a die hard Mac fan:

1. Kids are named "Steven Mac" and "Laurene Lisa"

Javascript

[lul_wat]

Javascript: Off

Or Apple just blocks firefox from the iphone...

[Anonymous Coward]

Or, Apple DELETES firefox from your iphone without your consent.

Re:Or Apple just blocks firefox from the iphone...

[Beardo the Bearded]

Or they change the API:

if( fireFox ) {
    delay( 5 seconds );
    throttleBandwidth( 50_PERCENT );
    originalCall();
}

Re:Or Apple just blocks firefox from the iphone...

[sys.stdout.write]

throttleBandwidth( 50_PERCENT );

If you need to define a constant for fifty percent, then you need to work on your programming skills.

Re:Or Apple just blocks firefox from the iphone...

[Sir_Lewk]

Methinks he did that simply for the benfit of the reader. throttleBandwidth(50); could mean any number of things.

Nope.

[7Ghent]

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.

Re:Nope.

[FooAtWFU]

How many apps do you have?

How many apps do you have that do direct hardware access?

Re:Nope.

[Anonymous Coward]

You can already write webpages that can access Apple hardware (at least the GPS) from javascript.

Re:Nope.

[Anonymous Coward]

Well mine are all on the droid - but it seems to be most of them. Google Places uses the GPS, Google Goggles uses he camera, Google Sky Map uses the compass and accelerometer. I guess the Weather Channel and Flixster don't use the hardware. I don't actually know for sure that Google Voice does, but in order to do dialing it must be more that javascript. So out of 6 apps I have installed 4 of them use the hardware.

Re:Nope.

[SpeedBump0619]

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 without their specific hardware features.

Re:Nope.

[christopherfinke]

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.

Re:Nope.

[BZ]

Fennec on the n900 has access to the accelerometer and camera.

Fennec can't run on the iPhone at all (since it includes a JS engine), so the Apple case is pretty irrelevant to it...

Re:Nope.

[Anonymous Coward]

But, if they're writing the browser, wouldn't they have the same access any other app maker would? JavaScript doesn't have APIs to cover direct access, though. So, Firefox would have to release firefox-only API calls until they could form some sort of standard process. In the meanwhile, firefox would be the only browser to support these APIs, so they'd be doomed to fail unless Apple, Rim, Palm and Google all came to the table.

Boy this will be an interesting discussion

[vivek7006]

iphone fans vs firefox fans ........

Re:Boy this will be an interesting discussion

[Anonymous Coward]

Correction - iphone does not have fans. It has only fanbois.

Re:Boy this will be an interesting discussion

[Anonymous Coward]

Even better: watch the Firefox fans who spent 18 months whining about how Apple should allow "real apps" instead of just web apps now make a sharp about-face.

Re:Boy this will be an interesting discussion

[Anonymous Coward]

It's at times like this I ask myself - Who would Don King back.

Re:Boy this will be an interesting discussion

[Grem135]

"It's at times like this I ask myself - Who would Don King back." LMFAO !!!

Re:Boy this will be an interesting discussion

[nacturation]

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?

How I do get Firefox on my iPhone?

[Anonymous Coward]

Does that run in Safari?

Hardware connectivity?

[aliquis]

Uhm, isn't the issue that your browser can't access your hardware? Guess sooner or later it will become 3D accelerated and maybe one can have the GPS submit coordinates to the page running the javascript or something. But shouldn't it still be somewhat limited?

How good does the iPhone work?

Don't "native non-webrelated apps" have any benefit longer?

Re:Hardware connectivity?

[Rei]

To each product its own needs.

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?

Re:Hardware connectivity?

[aliquis]

I doubt people will push their webapps for mobile phones against IE though, rather webkit and maybe firefox.

Another thing I wonder is if this will involve visiting webpages / have a collection of "apps" in your browser or how it's supposed to work. Because I doubt people want to surf to various webpages if they see the browser and such. I guess also one maybe want to have a consistent look of the user interface across applications.

Re:Hardware connectivity?

[BZ]

> Guess sooner or later it will become 3D accelerated

Being actively worked on.

> maybe one can have the GPS submit coordinates to the page running the javascript

Possible in Firefox 3.5 and later.

> But shouldn't it still be somewhat limited?

Depends on your phone, obviously. The browser will have to sandbox apps coming from the untrusted web, of course, but a lot of apps don't need much in the way of trust...

> Don't "native non-webrelated apps" have any benefit longer?

I think they do, sure. For one thing, you own the data. This is a problem that still needs to be solved for web apps.

Seems Unlikely

[saisuman]

I saw my wife playing Assassin's Creed on the iPhone today. I can't imagine a game of that quality being remade in Javascript unless it comes with some funky O3D-like capabilities.

Re:Seems Unlikely

[Darkness404]

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.

Re:Seems Unlikely

[WiseWeasel]

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.

Re:Seems Unlikely

[FlyingBishop]

Well, that's basically it. The bottleneck with gaming is really graphics, and if you've got optimized graphics routines, what's doing the higher-level processing is not as big of an issue as one might think.

Re:Seems Unlikely

[beelsebob]

You mean like WebGL?

Not that I think that games of that quality will be able to run in the browser *anyway*, but there is already a javascript standard for 3D canvasses, and using OpenGL ES.

Re:Seems Unlikely

[Joehonkie]

Quake live's "plugin" is basically a full game executable, same with Battlefield Heroes and quite a few other games. So it's just the browser launching a stand-alone app. It'll be quite some time before we see a game like that running in Javascript, although there have been a few solid 2D games written in Javascript.

Re:Seems Unlikely

[ivucica]

Which is why O3D is being developed and proposed.

Um...how do you figure?

[danaris]

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.

Dan Aris

Re:Um...how do you figure?

[BlackSabbath]

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 decision that they've often faced in the past i.e. develop for the platform with the biggest market share, OR can I make enough money of the others to justify the extra cost in custom code for their platforms?

Re:Um...how do you figure?

[BHearsum]

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, accelerometers, GPS, and multitouch. And yes, the hardware is abstracted away by the platform and made available through a standard API.

Re:Um...how do you figure?

[ducomputergeek]

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?

PhoneGap?

Re:Um...how do you figure?

[hedwards]

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.

Re:Um...how do you figure?

[GooberToo]

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.

Re:Um...how do you figure?

[blackpaw]

Myst on the iPhone! awesome!

That tempts me to buy an iPhone, just so I could play Myst on the train.

Re:Um...how do you figure?

[natehoy]

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.

Re:Um...how do you figure?

[selven]

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?

You solve this problem by having some sort of subscription thingy worked out. Or at least a one time payment. Piracy is impossible when you aren't distributing most of the program.

Re:Um...how do you figure?

[Dog-Cow]

And one day maybe you won't be an idiot.

Apple DOES NOT HAVE A MONOPOLY.

No amount of wishing will change this fact.

Re:Um...how do you figure?

[IntlHarvester]

Developers AND users don't want browser apps

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.

Re:Um...how do you figure?

[danaris]

PhoneGap?

...is a parked domain with a standardized GoDaddy link farm.

What was it supposed to be?

Dan Aris

Re:Um...how do you figure?

[danaris]

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.

You think they're going to do this now, just because Firefox Mobile has come out? When people railed ceaselessly against Apple for even suggesting that this was a good way to do iPhone apps?

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

And yet, there's still a marked lack of (say) FPSes and RTSes written for web browsers. Why do you suppose that might be?

3: There's already lots of subscription websites - Mozilla need not do anything to support this - people can do this on their own.

I wasn't suggesting that Mozilla would have to do anything: I was pointing out that it was something the developers would have to do. And something the users would have to do. And something that is very different from what people expect when going to play a single-player game.

4: The browser already has access to everything you listed: camera, accelerometers, GPS, and multitouch. And yes, the hardware is abstracted away by the platform and made available through a standard API.

Well, that's good that they're available. But are you really certain that every single smartphone manufacturer makes them available through the same standard API?

And even if so, it doesn't account for the phones that don't have one or more of them.

Dan Aris

Re:Um...how do you figure?

[Anonymous Coward]

it should had been .com
(http://www.phonegap.com/)

Re:Um...how do you figure?

[darrylo]

Agreed.

While this technology will probably be workable someday, that day is still a while off. If I had to take a wild guess, I'd say at least 5-10 years off. Smartphone processor/GPU performance has got to increase, and the cellular providers must be able to supply the necessary bandwidth (c.f., the recent AT&T stories on how they allegedly might start penalizing high bandwidth users). This, of course, assumes that politics doesn't enter into it (e.g., suppression or disallowing of certain apps).

Remember that Apple tried the webapp-only approach with the first incarnation of the iPhone, and we all know how that turned out.

And, keep in mind that this model falls apart if you have no cell service, such as on an airplane or in the mountains. (Yes, I know that airlines are starting to add in-flight wifi, but I'll bet that the pricing will be initially be at rape-and-pillage levels. I imagine that it'll be years-and-years before it'll be adequately cheap and usable.)

Re:Um...how do you figure?

[Anonymous Coward]

You are conflating the idea of loading applications off of a remote server and having the applications be written in HTML/CSS/Javascript. A web app is usually both, but there is no reason why the browser platform cannot be used for offline, downloaded apps, which would thereby be cross-platform to all phones supporting HTML5. This was what Palm wanted to do with the Pre. Apple ran their app store based on Objective-C instead purely for lock-in: they want iPhone apps to be hard to port.

Re:Um...how do you figure?

[Anonymous Coward]

Second: Myst could be easily done via streaming in resources, assuming you had a good connection.

Third: Ads work, they work for google. They work for facebook. They'll work for other things.

Fourth: You can't access them from web apps yet. So that is a problem. But multiple input features aren't going to be a problem as if an app makes use of it, it's often specialized and thus requires that hardware in the first palce.

Re:Um...how do you figure?

[mlts]

I say it depends on the app. If the app were like the above, "find me a Chinese food place that scored 85+ on the health inspection", either a Web app that was cached, or a native app (binary, or running in a VM like Dalvik or a true JVM) would be just fine.

If I wanted an app that would encrypt databases on my device when I am not using them, I would want that to be completely native with no reliance on anything Web based for maximum security. Same with a utility that mounts a file as a filesystem (TrueCrypt). I wouldn't want this to be a web app where it could be yanked and changed without my permission, or even notice.

If I wanted an app that did something very intricate, I would want it to be a locally installed binary, because with web apps, I have no guarentee about the version I did a project in will be the same version I open it up tomorrow, and there might have been some glitches in regression testing that would make a project done in an earlier version not work properly.

If I wanted an app that would point me to the nearest theater playing the latest blockbuster flick and also having Guinness on tap, I'd almost certainly want this to be a Web app because this is almost exactly what this is made for, because this info is always dynamically updated. Same with an app that fetches me tickets. I want this to be dynamic because ticket ordering systems change, and I want the latest version on my device no matter what.

So, both native apps and Web apps both have a place on a device, depending on their function.

Re:Um...how do you figure?

[sznupi]

Most importantly, it isn't the first time when mobile Gecko is supposed to forever change mobile browsing experience. Unfortunately Mozilla seems to think that hardware improvements will nullify their inability to fit Gecko into phones...meanwhile Webkit and Opera, among others, are doing it successfully for quite some time.

Re:Um...how do you figure?

[danaris]

Third: Ads work, they work for google. They work for facebook. They'll work for other things.

Yes. Google, and Facebook. Which are very popular desktop applications, written from scratch in C++.

Oh, wait, no they're not; they're websites .

No one is disputing that websites can make money from ads in a meaningful way. But please show me some significant desktop applications—or native iPhone apps—that have no current webapp equivalent, that are making their money from ads. Immersive first-person games are the only example of this I can think of offhand, but I'm sure there are others.

Fourth: You can't access them from web apps yet. So that is a problem. But multiple input features aren't going to be a problem as if an app makes use of it, it's often specialized and thus requires that hardware in the first palce.

...So...it's fine to just ignore the features of the iPhone that make it cool when you're developing a cross-platform app. OK, sure, that's fine. Let's just change Super Monkey Ball to have a little on-screen set of arrow keys to control the tilt of the world, then, shall we?

Look. Mozilla isn't just talking about expanding the kinds of web apps that are viable on smartphones. If they were, I'd be agreeing with them 100%: that's not only a very good thing, it's almost certain to happen. But they're talking about killing the App Store. That means being able to do everything the App Store does...and do it better.

I really, really don't see that happening for a web browser any time soon.

Dan Aris

Re:Um...how do you figure?

[Joe Tie.]

When people railed ceaselessly against Apple for even suggesting that this was a good way to do iPhone apps?

They did a lot more than suggest, they demanded. And I was one of those who complained. And while I still maintain native applications are needed, I'll admit I was quite wrong about web apps. They actually can work rather well at times, even over edge. Even if the iphone never really fixed a lot of rough edges there in terms of integrating it all.

Re:Um...how do you figure?

[danaris]

They actually can work rather well at times, even over edge.

Sure, they can at times, but Mozilla's claim is (essentially) that they can not only do everything that native iPhone apps can do, they can do it enough better that they will "kill the App Store."

I think that is, at the very least, an extremely premature claim.

Dan Aris

Re:Um...how do you figure?

[GooberToo]

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.

You just answered the primary question for your self and didn't even realize it.

It obviously wouldn't work for every app

And that's entirely the point. Why learn yet another language and yet another framework and yet another set of libraries, plus the huge performance hit, to satisfy a small portion of potential applications when at the end of the day you'll still need to learn the native tools to address the other 70%-80% of the applications which are not suited as a browser app.

Re:Um...how do you figure?

[StuartHankins]

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?

Especially since when trying to download apps I sometimes run into the "file over 10MB" limit and they refuse to install over the phone network. You must enable wifi or download them from a computer to install.

Re:Um...how do you figure?

[StuartHankins]

Webapps are typically very limited. They just don't provide the power that thick apps do. Each browser implements a different set of capabilities, and some of those are implemented differently. Heck, IE still doesn't score well on Acid3! This weakness will mean we won't have truly rich web apps as a norm for some time, unless they're tied to a specific platform / browser -- which means you aren't gaining the browser independence that was the reason for implementing as a web app to begin with.

Re:Um...how do you figure?

[ichigo 2.0]

And even if so, it doesn't account for the phones that don't have one or more of them.

This problem has always existed and isn't relevant. Either a software requires a piece of hardware or it doesn't, usually a user wouldn't even need a software that requires a certain kind of hardware unless they have the hardware in question.

Re:Um...how do you figure?

[IntlHarvester]

Just like how webapps on the desktop never caught on, because native APIs are more capable, right?

Re:Um...how do you figure?

[Eunuchswear]

What makes it impossible to fit geko into a phone? My phone uses a geko based browser (microB on the n900). Works for me.

Deja Vu

[tverbeek]

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.

Re:Deja Vu

[ceoyoyo]

My first thought too. Hey, web apps are just fine! You won't even be able to tell the difference!

Yeah right.

Besides, Mozilla doesn't have the fastest javascript renderer on the desktop, why would their first foray into the mobile world be better than everything else?

Re:Deja Vu

[jo42]

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.

Re:Deja Vu

[Darkness404]

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 handsets able to surf the web decently...) and Blackberry browser has come a long way but still lacks a few features.

Re:Deja Vu

[Apple Acolyte]

That is absolutely true, tverbeek. SJ tried to make that argument and it was largely laughed off by developers who were awaiting local apps and APIs. If Apple had continued to make that argument and had never rolled out the App Store, the iPhone (and its software platform) would not be the success it is today.

Re:Deja Vu

[R3d M3rcury]

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, it launches Safari and loads the page. I barely notice that it's not a native application because, even if it was, the slow part would be getting the data from the Internet anyway.

The problem is that Apple promotes native Apps more than Web Apps. Apple has a whole infrastucture for selling Apps, allowing developers to make money selling Apps. The only thing that Apple has for Web Apps is a listing page.

Re:Deja Vu

[Senor Wences]

Exactly tverbeek: I immediately thought of the iPhone webapps when I read about Mozilla's "threat."

http://apple.com/webapps

As Steve Jobs proposed with iPhone 1.0, developers were urged to push the capabilities of web technology to develop web applications for the iPhone. Today there are 4293 tuned web pages that take advantage of the technology the iPhone has to offer. For instance, the Most Recent under All Categories web app that loaded for me this evening was one that used the web browser and the GPS. Web apps can take advantage of the iPhone's hardware and software and not have to be run through the App Store. I have always thought that the only failure of the iPhone was that nobody developed a richer Internet that took advantage of a mobile Internet device like the iPhone.

Re:Deja Vu

[Anonymous Coward]

Bullshit. Web apps never were first-class apps on the iPhone. Can you make a web app show up in your apps listing as an icon? Can you keep a web app on your phone---that is, not have to redownload it every time you use it? That last question goes along with being able to easily sell the app. Can you use hardware accelerated graphics in a web app?

Apple could have given Javascript all the necessary APIs but instead they wanted to make sure iPhone developers would be making code that would be hard to port to other platforms.

Re:Deja Vu

[Anonymous Coward]

Right. Plus the developers who were complaining so loudly about webapps were the few ObjC types who would pay thousands of dollars to attend an Apple dev conference and wanted to corner the market.

You can't say that webapps were rejected because they were never really tried. Once Apple figured they could get away with a lockin strategy, that's what they went with.

Re:Deja Vu

[Changa_MC]

You're mistaken. Webapps were originally the ONLY apps for the iPhone -- that makes them first-class, only-class. The API out now was only released after everyone hated on safari for a while.

Yes, you can make a web app show as an icon on the home screen, I just did 20 minutes ago. And it is cached on the browser, so the second time did not require internet -- although maybe next time it will, we'll see.

But good luck making a complex app in any browser on a tiny device where battery life is precious. Firefox is not magically 10 times less demanding than safari.

Misses the point pretty badly

[ZombieRoboNinja]

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.

Re:Misses the point pretty badly

[Jaxoreth]

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.

Not to mention offline operation and storage. Without a net connection you can't send email, but you can still compose an email.

It's been my hope that the proliferation of mobile apps would legitimize local apps in general. Many of the strikes against Web apps on a phone also apply to desktops (or at least laptops, in the case of battery life).

Re:Misses the point pretty badly

[BZ]

> Not to mention offline operation and storage.

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.

Re:Misses the point pretty badly

[Jaxoreth]

> Not to mention offline operation and storage.

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.

Or I could use a traditional POP/SMTP client, using a fraction of the memory and CPU. And that's not counting the Web server.

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

Offline email has been a solved problem for over two decades, in fact.

Re:Misses the point pretty badly

[BZ]

> Or I could use a traditional POP/SMTP client,

Sure thing, though the equivalent would be closer to an IMAP client with a local cache of the messages.

> Offline email has been a solved problem for over two decades, in fact.

Yes; my point is that the "web application not usable when offline" problem is in fact solved.

Re:Misses the point pretty badly

[Anonymous Coward]

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.

Gee, is it that difficult to envision a locally installed javascript library that provides an API to the address book, calendar, etc?

Apple will just block it on the iPhone

[syousef]

Care to hack your phone over it?

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.

no web browsers on iphone

[street struttin']

i thought web browsers weren't allowed on the iphone, or opera would have done it. So no firefox on iphone, either...

Re:no web browsers on iphone

[Culture20]

True. Apple doesn't want people to know how badly iphone Safari sucks in comparison. I say that as a happy iphone user. I was also using konqueror-embedded years before, and enjoyed it much more on an ipaq through an IR tether with my old nokia phone. Web browsing on iphone is the worst experience ever.

Is it just me?

[v(*_*)vvvv]

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

Re:Is it just me?

[Silentknyght]

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

Re:Is it just me?

[ceoyoyo]

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.

Re:Is it just me?

[v(*_*)vvvv]

I guess suggesting this open source project has failed in certain regards would earn you Troll mods here, but some of you get what I am getting at. For example, when I list on eBay, I paste about 500 lines of HTML in their description box. FireFox literally freezes for 2 seconds. This has forced me to use IE8 for this, and before FF 3.5 I had never had to resort to IE. A part of me died.

From the original article:

"Anyone who knows JavaScript and HTML can develop a great app without having to learn a specific mobile platform," Jay Sullivan, vice president of mobile at Mozilla told PC Pro.

That sounds like pure PR speak from the mouth of the PR machine itself. Vice president of mobile? Mozilla is playing politics. Hint 2: It's a PC Pro article.

Anyone remember XUL? At least back then it felt like the developers were doing the selling. Of course, it never took over anything.

Really, if you think twice about this article, it is fake news going for fake buzz. It is a corporate propaganda piece.

Re:Is it just me?

[ceoyoyo]

Firefox is far from perfect. I've found it to be slow on OS X (although I've heard it's faster on other OSes). I went to install it on my girlfriend's netbook and it crashed on launch. I still don't know why - she didn't see any reason to choose Firefox, which wouldn't start, over IE, which would.

Firefox is a great project, but like any software, open source or otherwise, it will only remain that way if the developers respond well to criticism and keep their focus on quality.

Re:Is it just me?

[v(*_*)vvvv]

Yes. And on a more positive note, even if the train derails, someone can fork it and put it back on the right track. At least that wouldn't happen if Mozilla were proprietary, in which case the company would just implode (Netscape).

Always...

[daVinci1980]

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.

Re:Always...

[ceoyoyo]

Where has the web won?

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.

Re:Always...

[westlake]

1) The web has not always won.

Suppose, for example, the SSD or its successor became almost unbelievably small, capacious, efficient, and cheap.

Local storage is no longer a problem for your mobile device even if what you need are high resolution marine charts or topographical maps for the whole of North America.

Databases that are updated infrequently - but when you need to access them, you need to access them now.

Re:Always...

[Anonymous Coward]

I'd say it also won in dictionaries, enclopedias, maps, and it's winning in multimedia where bandwidth allows (I'm thinking of news sites, iTunes, and youtube -- Hulu hasn't really displaced conventional TV in any meaningful sense).

I think the web has so far lost, for the most part, in video games (yes there are lots of web games, but I don't think that's where the money is -- maybe I'm wrong), office/productivity, quality video content > ~5 minutes in length (I don't think bittorrent counts as "the web"), long-form written content such as novels, instant messenger (displacing the telephone in a lot of contexts, but ultimately most people use specialized client software for this).

Re:Always...

[Anonymous Coward]

What exactly are you trying to say?

Re:Always...

[WiseWeasel]

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.

Re:Always...

[Jesus_666]

In short, the web wins where it competes on a nontechnical level. People aren't using the internet for matchmaking because HTML + serverside scripting is such an attractive way of implementing it, they do it because the internet gives them a convenient way of networking with people.

On the other hand, Mopzilla is arguing here that the WWW is always superior when compared to other ways of implementing applications. They're arguing that the web "has always won" as an application framework. Apart from webmail, there isn't much substance to that. Web-based calendars/scheduling software? Web-based IMs? Web based imaging software? There's probably tons of examples for those but none I hve heard of because they're irrelevant for the regular user. I know of 280 Slides (even if I had to google the first part of the name) but that doesn't change the fact that I do presentations in Keynote. I know Google has some kind of office suite but it's no OpenOffice.

Add to that the fact that web apps tend to integrate horribly and I don't see anything but hot air in that guy's comment. Things would be slightly better if those web apps were built against a common toolkit that esures at least a modicum of consistency (note: Mozilla offers exactly that and they'd be very happy if all those apps would be built on XUL) but that still doesn't change the fact that an interface that conforms to one device's look and feel will look completely alien on another.

Either you use some kind of data-centric layout-less interface description language that produces pseudo-integrated ugly interfaces everywhere or you have to write one interface for every device (there goes write-once-run-everywhere) or you just accept that your app will look out of place on most devices. Apps that don't look the part don't make the sale.

Re:Always...

[ceoyoyo]

Good points, but the question here is apps vs. web apps. None of your examples are really web apps, never mind have regular applications as alternatives.

I will certainly give you that the web has pasted the newspaper and phone book businesses though.

Re:Always...

[gbutler69]

Microsoft Office is MUCH less important then most people tend to believe. In almost every company I've worked, although every single desktop had MS Office, only about 2 to 3% of people actually used Office in any meaningful way that leveraged features unique to it.

Re:Always...

[Anonymous Coward]

Yet,
If this development results in just one less "there's an app for that" advert on TV, I will be most grateful.

Re:Always...

[Anonymous Coward]

I'd say that Web apps are fighting a close fight in the MUA department. Here, Outlook, Thunderbird, and mutt still are used, but if someone isn't at their home computer (or a computer/device that can store mailboxes and supports POP/IMAP/SMTP), a Web app like Zimbra, Google Mail, or OWA will certainly be in use. Especially in student computer labs, or places where persistant storage of data isn't workable.

Another Web app is remote storage of files. Other than backup utilities like Mozy and Carbonite, people don't tend install an application that gives them upload/download access via the Web to a storage site. Instead, people tend to use Flash uploaders/downloaders to get the files to and from places. Of course, people can download and install a utility that would let them mount a remote storage volume as a drive, but this isn't done if a person is not on their home machine.

Finally, another app category that is 100% Web based are banking sites. No bank hands you an install disk for software to use just on their site. Instead, you pull up your browser, visit the bank's SSL based site and do your work there.

Re:Always...

[Anonymous Coward]

Re: #2....even if it were old, past performance is not indicative of future results.

I don't want web apps.

[obarthelemy]

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

Re:I don't want web apps.

[Anonymous Coward]

I'm a big ASS fan

Talking about mud flaps, has your girl got them?

It's the flashy "store" people want

[nmoog]

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

Beta is terrible

[jspenguin1]

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 marked "experimental" and even in experimental there's no AdBlock Plus (at least, that I can find). Hopefully, these problems will be fixed, but for now, I'm staying with the native Maemo browser.

Re:Beta is terrible

[christopherfinke]

No inertial scrolling.

The nightly I'm using has it.

One window per instance, no tabs.

The betas have had tabs for a long time. They're in the left toolbar.

Package is not "optified" - it installs to the device root instead of /opt

Fixed 3 weeks ago

Currently there are only three add-ons not marked "experimental"

I myself have written five add-ons for Mobile that are out of the sandbox, so I don't know where you're getting your numbers.

even in experimental there's no AdBlock Plus

Support added 2 weeks ago

It sounds like you haven't tried Fennec since the early betas. Might be time to give it another shot.

Re:Beta is terrible

[Anonymous Coward]

Odd... I installed it 30 minutes ago from the official repository (firefox.com/m, download link). I clicked the "get add-ons" on the welcome screen and it only gave two options (URL fixer and some location add-on). Even the weave button on the welcome screen did not work.

Going to the actual add-on site showed 3 add-ons (the two above plus weave). I spent about 10 minutes looking for adblock (most of that waiting for it to become responsive after freezing) and gave up. I didn't see a button for a new tab, but it probably just wasn't intuitive.

I will try the latest nightly before I pass judgement again.

Re:Beta is terrible

[jspenguin1]

Odd... I installed it 30 minutes ago from the official repository (firefox.com/m, download link). I clicked the "get add-ons" on the welcome screen and it only gave two options (URL fixer and some location add-on). Even the weave button on the welcome screen did not work.

Going to the actual add-on site showed 3 add-ons (the two above plus weave). I spent about 10 minutes looking for adblock (most of that waiting for it to become responsive after freezing) and gave up. I didn't see a button for a new tab, but it probably just wasn't intuitive.

I will try the latest nightly before I pass judgement again.

Gaah.. didn't mean to post anonymously...

Re:Beta is terrible

[christopherfinke]

I clicked the "get add-ons" on the welcome screen and it only gave two options (URL fixer and some location add-on).

Those are add-ons recommended by Mozilla. This page implies that there are 726 total add-ons for Mobile, with AdBlock Plus here.

Re:Beta is terrible

[jspenguin1]

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 look good, but they are a long way from actually being implemented.

Re:Beta is terrible

[sznupi]

Don't bet on it much...how many times Mozilla promised "revolutionizing" mobile browsing? Remember MiniMo? How their conclusion from that project was "we'll wait until the hardware gets more powerful"...and again they ended up with bloated pig.

In the meantime, Webkit and Opera Mini are doing much good for mobile web for a few years already.

APIs missing from common JS implementations

[tepples]

How many apps do you have that do direct hardware access?

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 Same Origin Policy).

Re:APIs missing from common JS implementations

[BZ]

Firefox and Fennec already expose accelerometer data to the DOM (via events). There's ongoing work to define APIs for microphone and camera access. File import is done (see File objects in Firefox and the web apps specs); file export is being thought about (some security concerns here). XMLHttpRequest can connect web servers that want to be connected (and define appropriate policies) right now.

So no, the web won't displace existing phone apps tomorrow. In 18 months, who knows.

Re:APIs missing from common JS implementations

[tepples]

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

Cross-Origin Resource Sharing 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-to-peer communication among devices and communication that doesn't meet the request-response paradigm of .

How would a first-person shooter video game or a video chat application be written as a web application? (As I understand the stipulations of the article, plug-ins compiled to native code don't count. Device makers and network operators often restrict plug-in installation, and even if not, the plug-in might not be available for a given device's architecture and native API.)

Re:APIs missing from common JS implementations

[BZ]

> it's not a complete replacement for arbitrary network access

Sure; apps with no security restrictions will always be able to do things that web apps can't do.

> web sites that make the feeds available to the public

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.

> It also rules out peer-to-peer communication among devices and communication that
> doesn't meet the request-response paradigm

To some extent, yes (though some people are trying to fill this gap with Web Sockets, which is a bit of a kludge).

> How would a first-person shooter video game

Probably using various proposed 3d APIs for canvas. But yes, I don't think the web is a good it in all cases, by any means.

> or a video chat application

This people are working on already. In particular, the ability to give (at user discretion) a web app access to the device camera and microphone; then the data can be moved around as desired.

Re:APIs missing from common JS implementations

[tepples]

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 do not yet threaten the iPhone and apps on its App Store.

Re:APIs missing from common JS implementations

[BZ]

> And restricting XHR using a list of exceptions to a client-side same origin policy isn't
> even secure

It actually is, for non-public resources (ones requiring a login).

Two things.

[Hurricane78]

Two things, my friend:

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

Re:Two things.

[Anonymous Coward]

I think you are forgetting the fact that iPhone users pay *money* for *crap*. On no other platform do people do that.

Re:Two things.

[defjesta]

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 smartphones. As you can see on this graph, the iPhone is currently in third place with around 13% marketshare. Not insignificant, and not bad at all for just over 2 years on the market.

As another poster mentioned, Apple has made it very easy to sell and buy Apps on this device, so most people that own an iPhone will spend money on Apps. Contrast this to Symbian where it takes a pretty dedicated and sometimes technical user to buy and install an application.

So, in the "real world" the iPhone is quite a dominant force already. It may yet prove to be a fad, and the mobile industry does move very fast, but I don't think so. I am personally seeing an increasing amount of consulting requests specifically iPhone related, and interest from corps is sky high.

With regards to your Java point; J2ME is nice (sometimes ;-), and it certainly has the largest install base of any mobile language, but the sad reality is that it is nowhere near "write once, run anywhere". For a cross platform J2ME mobile project, you will usually spend at least 50% of your project time porting and getting things running on devices that all implement it a little differently and have their own quirks. So supporting the majority of smartphones (Symbian, Blackberry, Win Mo and iPhone) will require a lot of specialised code anyway (unless you use a cross platform framework, but that has it's own drawbacks).

All iPod Touches and iPhones are essentially the same (barring some hardware differences like processor speed, bluetooth, etc), and an App written for one will almost always run on any other (I have had some obscure issues that crop up between different models, but nothing of significance). This is heaven from a dev's point of view!

Re:Two things.

[shutdown -p now]

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.

Come to think of it, what WinMo phones can't do J2ME? Yes, it's not in the base platform, but the platform is open, and the development is all native code, so writing (or porting) an efficient JVM shouldn't be a problem, and it could be installed on any WinMo phone.

In fact, a quick Google search finds a bunch of existing J2ME-on-WinMo implementations, some commercial and some free, including one made - of all companies - by IBM (?!).

So presumably any WinMo phone can run J2ME apps, once you install the runtime. Or am I missing something?

Re:Two things.

[dunkelfalke]

The only Windows Mobile devices without J2ME out of the box I've ever seen were some older PDAs without phone functionality.

Re:Two things.

[Tom]

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

You couldn't be more mistaken.

When the iPhone came out, the likes of Nokia laughed about it. They're not laughing anymore. There's a reason every second smartphone that's launched with marketing hype is labeled "iPhone killer".

The iPhone is a success that has surprised even Apple. Try to find the last time that anyone came into the mobile phone market from nowhere and went to even half the market share, and still growing.

Re:Two things.

[Hurricane78]

There simply was no runtime available for a long time. But sibling commenter is right. Most modern WinMo devices do support Java. I just wrote “some”, because I knew that some didn’t support it. I did not know that it’s that well-supported nowadays. Thanks for the correction. :)

Re:Two things.

[Eil]

As another poster mentioned, Apple has made it very easy to sell and buy Apps on this device

Buy? Yes.
Sell? Score:5, Funny

Amazingly Accurate

[sexconker]

I expect slapchop articles to be stupid, wrong, and shitty. I expect to be able to bitch and moan about them. It's why I come here.

But this article has that distinctive truthiness to it that flies in the face of what the masses love.

99% of the applications on the various mass-market marketplaces (Apple's, Google's, and Microsoft's) are pointless crap that would be better served up via a standard web page.

Of course, the browsers on those phones are crap, and no one bothers to get Opera Mobile even though it blows the shit out of your phone's standard browser (especially if your phone supports the non java version).

The bottom line is that this is a good thing.
I see far too much time, money, and energy wasted on "apps" (both by developers and by users) when a competent mobile web page would be a much better choice for the consumer.

But of course, if you can mask your web page as an "app" and SELL it on a virtual store that advertises for you, well shit yes the developers are going to focus on "apps" and ignore their mobile sites.

I seriously hope Firefox runs well on all the major mobile platforms (Windows Mobile 6.5 and up, iPhone OS, Droid, and the other one that a I always forget the name of, no not Blackberry). I'd love to have a competent browser SUCCEED in the mobile space. We already have Opera, but as I stated before, no one uses it. People will use Firefox.

(If you want to complain about my use of "truthiness", I'll just tell you it's as cromulent a word as "distinctive".)

Re:Amazingly Accurate

[Jesus_666]

Of course websites have the distinct drawback of requiring an internet connection. I use an iPod touch. Same APIs and capabilities as the iPhone, same app store. No ability to use web apps if you don't have a WLAN to connect to. And even if I switched to an iPhone, I'd need a ludicrously expensive plan to cover all the data traffic I'm generating just by accessing my apps.

A web app identical in capabilities to a regular app would impose additional usage costs on me (starting with a 700 EUR phone). And it's not even cheaper - the only thing I actually bought on Apple's store was a firmware upgrade. Everything else on my iPod is freeware, shows ads not obtrusive enough to annoy me or has restrictions I don't mind. Expenses: Zero.

Not every user is like me but on the iPhone/iPod touch platform there's a lot of connectivity-relevant usage scenarios, from "I can easily afford an unlimited flatrate for my iPhone" to "I use an iPod touch". Not every one of them would be happy to have their apps require an internet connection - in fact, everyone hated it when Apple had the exact same idea; JavaScript performance was not the reason.


If they come up with a way of letting me interact with websites without me having to use the internet, I'm listening. Until they have finished bending logic into a Slinky I'm going to stick with native apps.

Re:Amazingly Accurate

[sexconker]

But you need internet access (via wifi or cell radio) to get the App. (Or can you sync from PC?)

Most of the apps I've seen are along the lines of tapping into social networking sites, looking up local restaurants, reviews, movie listings, etc.
Tagging places you've been / are going.

Very few apps that are useful are net-independent.
Nearly all of the apps that are net-dependent (useful or not) could be done via a simple web site - no need for an app.

Whether the developer is making use of the actual tilty / touch / etc stuff that they can't do / do easily through the web, or whether they think the provided browser is too slow, too ugly, etc. is a different matter. I think if a mobile Firefox takes off, what few legitimate concerns there are will melt away.

Re:Amazingly Accurate

[Cederic]

no one bothers to get Opera Mobile even though it blows the shit out of your phone's standard browser

Wtf? I had Opera Mobile on my phone, bought an Android phone and the browser that came with that was significantly better.

I now have a Nokia n900 and all three of the browsers are better than Opera Mobile. FFS I'm running full scale web pages (with embedded flash and all that shite) and they're working fine and with no ads because I have adblock installed.

What I'm not sure is whether the Mozilla browser I'm using is Firefox Mobile or whether I need to download that too...

Re:Amazingly Accurate

[sexconker]

I had Opera Mobile on my phone, bought an Android phone and the browser that came with that was significantly better.

Because of the hardware differences most likely.

Re:Amazingly Accurate

[Jesus_666]

I do need internet while downloading the app (whether directly or through the PC) but not while using it. And many apps don't need data access all the time - for instance, an app that does currency conversion or shows the TV programme only needs it to fetch the new rates/programme once in a while.

When I'm outside an area with WLAN coverage, web apps simply break. Native apps work with a day-old data set at worst.

Of course there are apps that only make sense with constant data access but those apps don't constitute 100% of all useful apps. There are even apps that don't need the internet at all - for example unit conversion apps for anything but currencies. Or, as found on my iPod, a white noise generator (very useful when trying to sleep in noisy conditions).

Re:Amazingly Accurate

[hkmwbz]

Wtf? I had Opera Mobile on my phone, bought an Android phone and the browser that came with that was significantly better.

You were probably using Opera Mobile 8. Opera Mobile 10 kicks the shit out of everything else. Yes, it handles full scale web pages and all that.

ECMAScript is Lisp with C syntax

[tepples]

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

Re:ECMAScript is Lisp with C syntax

[wisnoskij]

Now i will state now I am no expert at JS.

It just does not seem like nice language, if all the needed functionality is their they seem to have done a good job of hiding it.
and as to Scheme, it looks horrible, and C is very outdated compared to new OO style languages, so that is not a shining endorsement to me.
and just in general, how much better have they made JS run, I would think it would be almost impossible to give it the efficiency of a full language, even running on my computer that is probably about 1000 times more powerful then a mobile device a JS app could never hope to run 3D animations, drawing a few solid rectangles on the screen seems to be all it can handle without lagging.
It is a scripting language, and does a decent job at that, but you would no more write Halo in Unix Shell script then you would use JS.

Re:ECMAScript is Lisp with C syntax

[jo42]

ECMAScript is Lisp with C syntax and the speed of a snail in a wind storm.

Re:ECMAScript is Lisp with C syntax

[tepples]

and the speed of a snail in a wind storm.

The whole point of the article is that this alleged slowness is no longer the case, at least for Firefox. Are you talking about Internet Explorer?

Re:ECMAScript is Lisp with C syntax

[Jesus_666]

You do realize that most modern OO languages use some extended form of the C syntax? Off the hand I can only think of OCaml as a non-C-like OO language. Okay, and Object Pascal (aka Delphi).

Re:ECMAScript is Lisp with C syntax

[wisnoskij]

yes, but the keyword their is extended.

Re:ECMAScript is Lisp with C syntax

[NoOneInParticular]

Unless some radical breakthrough in compiler technology happened overnight that could suddenly make dynamically typed, dictionary based dispatch languages run as quick as statically typed, virtual table based dispatch languages, speed gains in javascript will not make apps written in it come significantly closer to the speed of compile-time type-checked languages such as java, objective-c, c++, or for that matter, Flash Actionscript.

Theoretically there is no reason that a JIT compiler for achieving this cannot be build, but despite years of very serious effort to achieve this, it just isn't there, not even close.

Fennec? Ahahhahaha

[dnaumov]

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.

Re:Fennec? Ahahhahaha

[Cederic]

Luckily the n900 comes with a Mozilla browser that's completely stable and doesn't crash.

That's only my perception, and I've only had the phone a few days, so there's still plenty of time for it all to go wrong, but it does mean that n900 users can continue to use their desktop class browser until the new one is sufficiently stable.

Just like we never use desktop apps anymore...

[ForestHill]

Yeah, that's why the vast majority of apps we all use on a daily basis on our computers are web apps. Or not. In fact, for me, there's not a single web app I use on a daily basis...

Re:Just like we never use desktop apps anymore...

[Anonymous Coward]

Gmail is a pretty big web app...

Re:Just like we never use desktop apps anymore...

[ForestHill]

Sure is, but I check my gmail with an IMAP client. Facebook with an iPhone app (and sometimes their web page, too.)

Re:Just like we never use desktop apps anymore...

[multipartmixed]

And then there are people like me, who use almost nothing BUT web apps.

In fact, the only app I have run today, so far, that doesn't run in my browser is... my browser.

Sticking my snout in here.

[Anonymous Coward]

Opera mobil.

I want Flash 10 support

[ksemlerK]

integrated into Firefox Mobile. It would allow for streaming media from sites such as Youtube, Hulu, and Tube8.

Comment removed

[account_deleted]

Comment removed based on user account deletion

PastryKit

[fandingo]

Ars Technica had an article about a hidden framework that Apple was developing before Apps hit with 2.0. http://arstechnica.com/apple/news/2009/12/pastrykit-best-iphone-web-app-library-you-never-heard-about.ars

Actually looks pretty cool and could allow more web-based apps.

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.

One possible outcome

[Anonymous Coward]

This is just speculation, but lets say that all of the OTHER smart phone companies want to see the Apple App Store lose some business. Since there is no real rival to the App store, these companies have nothing to lose by supporting webapp capabilities through Firefox Mobile. They would gain a buzzword and compatibility with a potentially unlimited amount of software. So what this means is that iPhone users still use the App store, and everyone else uses some open repository of free and non-free webapps or buys directly from the developer. Seems logical to me and only takes the assumption that not everyone on the planet uses an iPhone.

Comment removed

[account_deleted]

Comment removed based on user account deletion

PLEASE not Javascript

[dirkdodgers]

Hear my plea, oh Mozilla developers. What must I do to appease your wrath?

Please don't build another application platform on Javascript. Just make Java a first class citizen in the damn browser and be done with it.

Heck, any proper language with a proper standard library will do. I'm not partial to Java. All I care is that it isn't Javascript. Javascript should have died in 1996.

Javascript helps no one. It is a shitty language with shitty tools that has spawned so much shitty code that it threatens to fold the universe in on itself.

Re:PLEASE not Javascript

[BenoitRen]

Your post is yet more evidence of how misunderstood JavaScript as a language is. It's actually quite neat and versatile. No wonder the language's core (ECMAScript) has so many derivations.

Re:PLEASE not Javascript

[NoOneInParticular]

Javascript is neat and versatile, and also very, very slow. Once Javascript can compete with, say, Flash for rendering video in the browser, it might be possible to take this whole web application business seriously. Until that time development in Javascript is going to live in the twilight zone between serving up static pages and creating applications.

Re:PLEASE not Javascript

[BenoitRen]

JavaScript before the newer engines was slow, but not that slow. I have an MSN client programmed in JavaScript on the Mozilla platform, and it runs great on my Pentium II 233 Mhz.

The newer engines like TraceMonkey, V8, etc. speed up JavaScript quite a bit, though.

I wonder why you complain about JavaScript being slow and then propose Java as an alternative. Now that is slow, especially as a browser plug-in.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Mozilla needs new top management.

[Anonymous Coward]

Firefox is the most unstable program in common use.

So maybe: Firefox: Off.

uh

[Anonymous Coward]

Hey, I've got an idea, write a browser that's so mutantly written it's not native anywhere and isn't even ALLOWED in the Android OR iPhone OS app stores and see where it gets us! Fantastic plan, Mozilla. I didn't switch to Chrome because it was awesome. I switched because Firefox has horrible gnome integration. The entire browser gui literally IS a web page of sorts.. You just can't take that web stuff too far, and you have. Me, I like fast. Circular saw duct-taped to a scud missile fast. I call it WebKit.

Give me a break, you just made that up.

[WiiVault]

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

Re:Give me a break, you just made that up.

[Marcika]

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

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.

In short: GP is very likely closer to the truth than you are.

Re:Give me a break, you just made that up.

[Anonymous Coward]

The suggestion was that that the iPhone is far more used than its marketshare would suggest. Seems pretty clear to me at least. Are you trying to be obtuse?

Re:Give me a break, you just made that up.

[Anonymous Coward]

Apple iPhone + iPod Touch combined has shipped 30 to 40 million units.

The global mobile market is 1 billion units.

Do the math.

Re:Give me a break, you just made that up.

[harmonise]

iPod Touch

...is not a smartphone and so isn't relevant to this discussion.

Re:Give me a break, you just made that up.

[hazydave]

It's relevant in that Apple quotes numbers of "iPhone OS" device shipments (actually, up to about 54 million, as of their last released figures), about 40% of which are iPods Touch. They don't break down the iPhone vs. iPod numbers, though independent industry watchers do.

One billion phones per year is interesting if you're a phone vendor, but only interesting in the smart phone context as a larger percentage of that total becomes smart phones. They are currently a premium, of course, and that's shown in the numbers: 20 million iPhones a year, 21 million Blackberries, 75 million Nokia's, etc. Just over 10% of all phones shipped. If I were a smart phone vendor, I'd be far more interested in selling smart phones to the next 100 million potential phone buyers, than worrying about taking some percentage of Apple's share.

As a developer, you can go wide or go deep... plenty of developers just do iPhone apps, and haven't looked at Web-based, WebOS, Android, or J2ME at all. Others do fewer apps and try to run them everywhere. The main challenge in the latter case is obvious: you're rewriting the same program over and over. Not 100% effort per port, but you better believe the effort is worthwhile to add that third, fourth, or fifth-place platform. In the former case, you just hope you backed the right horse... which I don't personally believe is Apple. They have never been one to lower prices based on outside competition... perhaps internal competition (eg, now that have the 32GB iPhone, we make the 8GB iPhone cheaper, or cancel it entirely). They're not the guys to get these next 100 million folks using application phones. Not RIM either. Nokia hasn't cracked the US market, despite their global dominance.

Android maybe... they're #2 on apps already, and they support hardware specs both below and above that of the iPhone, already. And given the open platform, hardware vendors are likely to want Android on as many phones as possible, thus removing the need to do custom OS implementations -- they can always customize the GUI, make the phone seem "less smart" if that's what you need to sell into the FREE to $50 (subsidized) market. There's still going to be resistance .. folks happy with dumb phones might like the promise of a smarter phone, but they'll reject the $30 per month extra cost.

Re:Give me a break, you just made that up.

[Anonymous Coward]

Sorry, but the MorganStanley slide is talking about 'smartphone' share.

Yeah, because you're really going to run all those wonderous new web-based apps with a NON-smartphone.

You're talking web-based apps, you're talking smartphone. It's like including bicycles and Razer scooters in the numbers of vehicles that will soon be carrying reverse-parking sensors.

Therefore, WiiVault's quoted numbers are correct.

Re:Give me a break, you just made that up.

[hkmwbz]

Ahem, Opera Mini and the Bolt browser.

MOD PARENT UP

[dlgeek]

Damn, why'd my mod points all have to expire yesterday?

Any specific gripes? I think it's pretty great.

[weston]

All I care is that it isn't Javascript. Javascript should have died in 1996. Javascript helps no one.

Helps me. Nice multi-paradigm functional-OO-imperative language mix wrapped up in familiar syntax. The various DOMs have kindof sucked, and there's a few gotchas (you have to know your scoping rules, that the number type is IEEE 754 double precision, why non K&R bracing style will bite you, plus some misc other things), but overall, I find a lot to recommend it.

Do you have specific gripes, or just general bad vibes?

Good idea but won't happen

[thetoadwarrior]

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.

What a joke!

[tyrione]

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.

Bandwidth

[SparafucileMan]

And, if my app requires significant bandwidth would normally be used by the user, I now have to source it all myself for every user?

That sucks.

How about an actual browser?

[MrCrassic]

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.

If it was surpassed in Japan, why so popular?

[SuperKendall]

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

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.

Re:If it was surpassed in Japan, why so popular?

[thaig]

Java runs on non-smartphones so ... :-)

Phone Gap Allows some of these things

[Anonymous Coward]

http://phonegap.com/

Delusional

[Anonymous Coward]

Everyone seems to think what the phone needs is a good browser. Inevitably the experience ends up worse than on the desktop, even if the code is shared with a desktop browser. The devices are getting better, but it's not there. I'm skeptical that it will ever be.

Web apps again?

[Vermyndax]

Whattaya know. Just thought I'd point out - this strategy didn't work out so well for Apple when the iPhone first came out. They were booed into submission.

Mozilla's logic is not sound

[icepick72]

Sure the web always wins; however that doesn't mean Mozilla will win any more than Apple, because there are many other companies on the web too, using the web, developing features based on the web standards, creating new web standards.

Trusting the client

[tepples]

[Cross-Origin Resource Sharing] actually is [secure], for non-public resources (ones requiring a login).

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?

Re:Trusting the client

[BZ]

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 right CORS response is received, and the data is not made available to site B unless the right CORS response is received.

Since the browser is the entity here which knows both which trust domain is making the request and which trust domain the request is going to, it needs to be the one which enforces the data not leaking from A to B unless A explicitly wants it to.

Re:Trusting the client

[tepples]

If the problem is cross-site request forgery, the right solution would have been not to block all accesses but instead to block cookies and HTTP authentication for requests that fail a cross-origin check. Then the web application would have just as much access to the other server as does an anonymous user or a proxy running on the application's own server.

Re:Trusting the client

[BZ]

That would be possible if the browser had full control over the HTTP library. Apparently some do not.

You should review what "Ad Hominem" means

[gbutler69]

I don't think it means what you think it does. http://en.wikipedia.org/wiki/Ad_hominem

Re:You should review what "Ad Hominem" means

[nacturation]

You're right. Given that the article involves no logic whatsoever for that statement, it can't be ad hominem since that would imply an error in reaching a logical conclusion. Questions of whether "hominem" applies to corporations being another matter, of course.

Revenue?

[Polo]

So this generates a revenue stream for developers how?

Pardon me Mozilla I couldn't help but notice

[Orion Blastar]

that mobile devices don't always have Internet access. The user may run into a dead spot without 3G+ or WIFI connectivity. The Mozilla Firefox Mobile loads Javascript programs from "The Cloud" I would assume as to where the data is stored and the Firefox Mobile is the client.

In some places Internet access is forbidden, for example if I try to write a Docket Calendar application for Firefox Mobile and the lawyer takes it into a courtroom that blocks cellular signals and doesn't have Wifi, or he gets on a plane and has to have all electronic devices shut off or at least turn off networking so it wouldn't interfere with the equipment on the plane my Cloud based Docket Calendar app is useless to him as he couldn't connect and access my program and his data. If I wrote a native app with a native database he could download his Docket Calendar from his law firm servers and then go to court and access his data from the native database and while on the plane check his data with the networking feature switched off when he is told he can use electronic devices again. I've developed many web applications for lawyers and they work best on their Intranet, but on mobile devices and laptops it always has to have a native database on the hard drive or storage for when there is no Network access.

One more thing, you could have the Firefox developers develop a small Firefox Server app that runs on the Mobile device and serves up programs the user can download so that they work regardless of if they have a network signal or not and then caches the data when connected and syncs up with the main servers when it has network access again. It can mirror the main application site and download updates when connected and upload changes from when the mobile unit was offline. It would be cool if you did that as Netscape used to write web servers and the Mozilla Foundation should still have access to that code.

Re:Pardon me Mozilla I couldn't help but notice

[A12m0v]

Plus why wont I just use Safari instead of Firefox to access web apps? Firefox isn't gonna be faster than Safari in Javascript anytime soon. They also forgot that the iPhone already has web apps that can be accessed using Safari.

Re:Pardon me Mozilla I couldn't help but notice

[Orion Blastar]

Yeah but Firefox is more compatible with other web sites than Safari is, at least based on my experience with it. I was on Uncyclopedia and Safari users complained that the new MediaWiki software didn't work too well with Safari web browsers and they had to switch to Firefox to work with MediaWiki. There are also web sites designed for Internet Explorer that don't work with Safari or Firefox, but Firefox can use a browser agent plugin to emulate an IE browser agent sig and fool the web site to work. I am not aware of such a thing for Safari. Also Firefox has limited ActiveX control support via certain plugins that Safari won't render.

So it is not just about Safari HTML/Javascript apps at the Apple App store, but any web site or app someone wrote for the generic HTML/Javascript that Safari may not support so the user downloads Mozilla Firefox Mobile to work with web sites and apps that won't work with Safari.

"More intense tasks"

[Animats]

Javascript "increasingly more appropriate for more intense tasks."

Yeah, right. I'm getting really tired of web sites that use 100% of the CPU while doing essentially nothing. It's bad enough on a desktop machine. On a phone, that eats the battery.

Just Marketing (I hope)

[Lemming Mark]

I guess this is no more crazy than the marketing commercial ventures put out. And there's some truth to the idea that the web always wins. But doing everything using the web when it could be done as well or better using a public API + native apps implementing it strikes me as a bit backwards, like "It's javascript / AJAX based!" is becoming the new technology bubble. AJAX is a very powerful hammer which makes a lot of other problems look like nails. It's just worth remembering some of those problems might only *look like* nails!

I have no objection to there being an AJAX interface to pretty much anything, I just don't want it to be the only choice. But I'm a bit bewildered when people talk as if local apps -> web apps is an inevitable good -> better transition. In this case they *really are* different tools with different uses and some (increasingly substantial) overlap.

Also, does anyone see the irony here, given that when the first iPhone launched Apple claimed it didn't need native apps because you could just javascript, etc? OK, so Firefox / Fennec has a faster JavaScript engine but still...

Flash?

[arielsom]

Something else that is worth watching is Flash. They have an export to iphone app planned for CS5, even if I'm kind of sceptical about it. And even if Flash dev still sucks, it beats developping with DHTML.

Re:Flash?

[aristotle-dude]

Flash? Yeah, they have some flash exporter but it produces crap code. The only reason why those flash exported games were allowed on the store was to prevent an outcry on the web. The code the exporter produces uses private apis which is against the SDK rules and it loads everything into memory limiting how much graphics and sound you can have. Natively written apps load gfx and sound on the fly as you need them.

Cache it?

[EETech1]

Couldn't they set aside space for applications on the phone, and store much of the application code on the device for the next time it's used? Just check versions, and update only when there are changes?

From apple

[fulldecent]

"we didn't reject the new Firefox Mobile Browse app from running on iPhones and iPod touches... it's still 'under review'"

Apps spend their time in libraries

[tepples]

speed gains in javascript will not make apps written in it come significantly closer to the speed of compile-time type-checked languages such as java, objective-c, c++, or for that matter, Flash Actionscript.

You're right that JavaScript, Python, Lua, and other languages without rich static type systems probably aren't the best for inner loops as of 2009. But remember Amdahl's law: an application is only as fast as the components where it spends the most time. Often this is libraries; if the platform maker optimizes the droppings out of those, speedups show up across the board. A web application, for instance, spends a lot of time in the natively implemented standard library, the layout engine, the canvas engine, etc, which are the same whether or not the app is written with a static or dynamic type system.

Oh, and Objective-C message dispatch is dictionary-based too.

Mozilla promises, Opera delivers and gets ignored

[Ilgaz]

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.

Why bother if app store rejects competition?

[Ilgaz]

If Apple allowed 3rd party, it would change the Safari in good way too. They would find themselves competing with 3rd party companies/engines and would feel forced to fix quirks, add better features, add better performance.

As they are in safe (!) area with app store rejector interns, they don't feel like doing anything.

On Symbian S60 (which Mozilla ignores), there is a browser called "Skyfire" which is a shell to a "all plugins installed" Firefox. Believe or not, it can even play wmedia embedded (at least at Nasa TV). There is Opera 10 Mobile beta which is also amazingly unique since it is the exact same browser on desktop without any proxies, just with opt-in compression. There is a Webkit based browser, a Chinese and very impressive browser etc. Idea is, Nokia gets feedback/flamebait from customers asking why their own Webkit based browser doesnt do some things they do and they feel forced to enhance it. Or, they can easily say "Hate our ROM browser? Just click a competitor sisx file, install and use it."

Chair throwing guy could be right that amazing amount of apps on app store may have something to do with the browser being unusable.

Don't forget the idiot marked you as flamebait too, besides app store rejector geniuses, there is also a customer base who will easily abuse their mod points whenever they see something like your post.

Yes, but does it matter?

[SuperKendall]

Java runs on non-smartphones so ... :-)

That's very true. I why I looked into moving to J2ME development almost a decade ago.

But it doesn't matter in a large number of cases because not all devices support all aspects of the J2ME profile, they have really tiny screens and horrendous input mechanisms. Sure a ton of devices HAVE java, that's impressive - but the problem is from a developer standpoint it almost doesn't matter, and it really doesn't matter these days. If someone knew Java well there's pretty much no chance they'd look at J2ME for development when they could move to Android with such little fuss.

Here and now...

[hazydave]

This was actually being discussed independently of Firefox. Specifically, toward unseating (or at least, knocking down by a notch or two) the Apple iTunes store.

In fact, that has nothing to do with Firefox. You'll never get Fenec/Firefox in the iTunes store. If you have a jailbroken iPhone, sure, but then, you're already not dependent on the iTunes store.

But this is already a potential with the current iPhone Safari browser. You have a fast JavaScript engine there already. With HTML5 features like local data and local app storage, and the hooks are pretty much in place. And there have been claims that app developers are already using this as a means to bypass the app store.

Certainly it's not for every application, but there are a ton of things done on smart phones that are really just information aggregators and other app classes that don't need anywhere near the realtime performance you might for a videogame.

Another datapoint... applications on Palm's new WebOS pretty much are, already, HTML5, Javascript, and CSS. And yet, it's faster than most iPhones. And at least when introduced, the Palm Pre ran Javascript about 1/3 the speed of the iPhone 3GS (I'm sure they have improved that performance since).

The odd thing about all of this is really how fast Javascript already is on the iPhone... it ran SunSpider about 30% faster than I got on my DROID phone, again, about 3x the speed of the original WebOS browser. Apple has gone to fairly crazy lengths to otherwise prevent any sort of alternate applications distribution mechanism from hitting the iPhone. The won't support Flash, ever, because that would allow games and applications written in flash, not through the iTunes store. They don't allow Java for the same reason... both of these things cripple the iPhone, making it a second-class citizen of the web (well, in ways other than just having a 480x320 pixel screen, anyway), but that's considered ok, so long as the iTunes channel remains the only feeding tube. They even outlawed a Commodore 64 emulator... apparently, 8-bit 6502 and BASIC code of the early 80s also represents an dangerous alternate applications channel. And yet, here's this Javascript engine, fast, and essentially the same API available on most other smart phones, and the core API for WebOS. They seem to have screwed up here.

I think it needs to be stated, too, that just having these facilities does not a complete solution make. The OS itself must allow web applications to be launched from one's normal application launcher, or it starts to make these rather second class. There needs to be management of the applications cache... how do I uninstall the app I'm done with. And for users who are less savvy than the typical /. reader, the lack of integration may get confusing... I have to go HERE to delete some apps, and THERE to delete these others?

Re:Mozilla promises, Opera delivers and gets ignor

[Cederic]

Opera Mobile, Opera Mini and Opera Desktop version are all unavailable for my phone. Opera 10 is not available for my handset. Which is running a linux distro with user access to root.

It's hard to get much more open than that.

Luckily the handset came with a Mozilla based browser that's better than Opera.

oh YEAH?

[garote]

oh YEAH? Well _I_ have a friend who's a die-hard PC user, who's getting an iPhone!

Take THAT!!!1!!!1

Re:oh YEAH?

[aztracker1]

The original post was pointing out that the iPhone App Store isn't the only really successful app store.

Re:oh YEAH?

[garote]

Yeah. And I'm pointing out that your sample size of 1 is not very convincing.

It did work for Java - on phones

[mdwh2]

Yeah, it did work on Java - 2 billion Java phones that are all compatible. Just because Slashdot decides to focus on a phone with just a few percent market share, that decided to drop Java support instead taking us back to the dark old days when every platform needed its own version, doesn't change the reality of what every other phone on the market can do. Who cares if Apple roll over or not.

ORLY?

[bahamat]

Strong words from somebody who makes a browser that can't pass Acid3.

Consider the future

[eyeverve]

I read through most of the comments and I think people are getting stuck on arguing this issue based on the present and past. You have to consider the future. Wireless connectivity will improve, browsers will become more capable, and slightly more open hardware (everything but the iphone) will be more popular.

Also, the general population is gravitating towards having their lives'/data exist in the cloud. Yeah it is mostly email right now, but in the near future everyone will use access their documents, pictures and music from the cloud only. There won't be too much of a need for local storage at that point.

Gaming will of course lag everything else getting into the cloud because it is more intensive, but give it time.

So I agree with the comment from Mozilla. The concept will most likely be true given enough time.

Re:Consider the future

[dn15]

This is partially true, but it's not as if the sophistication of native apps will stop either. Web apps are behind now, and I think they will remain behind in the future, because they're not native code making full use of native APIs.

Re:Consider the future

[eyeverve]

I agree with your statement. I don't think native apps will go away, but I do think they will be the minority. I use an Android powered phone and the apps I use 95% of the time require that data be pulled from the cloud for some reason or another. Once web apps are allowed to interact more heavily with mobile device and connectivity speed increases, apps that use cloud data will most likely just shift to being web based.

Been there, done that

[dn15]

There are already plenty of web-based apps that will run fine on any mobile device that uses a WebKit-based browser –meaning iPhone, iPod touch, Android, Palm's WebOS, and more. Examples range from a Twitter client called Hahlo, to Google Reader. This is nothing new and nothing exciting.

I like Mozilla and their products, but web apps on mobile are the same old story as web apps on the desktop. Native apps will always be better, and any advantages that web apps may have had are easily compensated by making your native app able to sync its data to online services.

Bizzaro World

[Wovel]

Why does this "story" exist. It is a Mozilla press release I suppose, not clear what value or new information was conveyed in the summary or the FA.