The Sad State of the Mobile Web 220
snydeq writes "Despite being the much better development platform for today's smartphones, open Web standards still face an uphill battle on mobile devices, Fatal Exception's Neil McAllister writes, noting that here, as on the desktop, the main hurdle is scalability. But whereas successful Web development for the desktop is a matter of scaling up, mobile Web development calls for applications that can effectively scale down as well — an imperative that is fast making the state of the mobile Web 'even sadder,' McAllister writes. 'The more that modern Web applications take advantage of the new client-side technologies available in desktop browsers, the more the divide between the desktop Web and the mobile Web widens.' As a result, developers are forced to fall back on basic Web technologies — a tactic that too often translates simply into writing separate UIs for mobile users. 'The result? Mobile Web applications are in pretty much the same boat as they were when the first WAP-enabled handsets appeared: two separate development tracks, one for the desktop and one for mobile.'"
Re:I have a better idea (Score:1, Informative)
Re:Outdated? (Score:4, Informative)
The iPhone uses the same rendering engine as Safari. The Nokia 770 shipped with a version of Opera that could render almost everything that the desktop one could, but was painfully slow with some sites (e.g. Google Maps), but that was more to do with the slow CPU than anything else. My cheap Nokia phone has a WebKit browser too, and the tiny screen is more of a limiting factor than the browser's capabilities. Flash support on mobile devices has been a little tricky until not, but now Adobe is pushing hard to get full Flash supported on everything with an ARM CPU that's going to stop being a problem soon. In terms of HTML, CSS, and JavaScript, handheld devices are just as capable as ten-year-old desktops with small screens running modern software.
Note, however, that TFA talked about web apps, rather than web sites. Web apps are typically very JavaScript heavy, and so may have problems on mobile devices if the JS engine can't keep up. This is completely different to the WAP era, however. Back then, mobile browsers couldn't browse normal sites. Now they can, but they may experience problems on a few web apps that do a lot of the client side (these didn't even exist in the WAP days).
is this why /. is the sucks to read on my iphone? (Score:4, Informative)
except for the flash based ones, slashdot is the most annoying to navigate on my iphone
Re:I have a better idea (Score:3, Informative)
The only real problem is that the nested comments quickly run out of width when the nesting gets too deep. Oh and that floating Full/Abbreviated/Hidden thing on the left doesn't work, but then I don't use it on the desktop either.
Re:Pot, meet kettle (Score:4, Informative)
Lack of Unicode in /. is on purpose (5:erocS) (Score:3, Informative)
Slashdot doesn't even support Unicode.
This is on purpose because people were abusing bidirectional characters [slashdot.org] to distort the layout and forge comment scores.
There are many problems w/MCallisters article (Score:3, Informative)
This is an important debate, but Neil McAllister's article suffers from a number of problems. For example, it references the recently popular Webkit Comparison Table [quirksmode.org] along with Peter-Paul Koch's claim that there is no “WebKit on Mobile”. The article didn't point out that some people like Alex Russel have dug deeper [dojotoolkit.org] and have found that the facts don't support PPK's conclusions as strongly as one might think. Yes, if you include lots of older devices, there's quite a divergence in Webkit deployments, but what PPK and Neil McAllister don't say is that compatibility is much better on devices that ship recent versions, it's especially good for core features, and it's improving all the time.
McAllister also implies that the mobile Web is in trouble because "On my BlackBerry, JavaScript performance is abysmal". Using that argument, I can prove that Windows will never be successful, because I could in the early days show you PC's that ran it with abysmal performance. The potential of technologies like Javascript needs to be evaluated using the best implementation you can find; that shows what's possible. He does go on to say: "And even when a handset vendor does improve JavaScript performance, as Apple did with iPhone OS 3.0, it's a relative increase." Aren't they all? "You're still dealing with a poky handheld processor (and in Apple's case, one that developers speculate is too feeble for Flash or Java)." Uh, so now the reason that the HTML and Javascript will fail is that ARM processors are too slow to run Java? What's the connection I'm missing? The fact is, that there are some pretty good AJAX sites for mobile, so we know the ARM processors are good enough to run that Javascript. Try, for example, going to http://www.gmail.com using Safari on your iPhone. Not a usable experience? Even works offline using HTML 5 local storage (not Gears). Also, even if Javascript performance were somehow related to Java performance, I bet the Android folks would like to hear that Java doesn't run right on ARM processors, since the entire upper level infrastructure of Android, including user applications, is built on just that combination (as optimized using the Dalvik VM).
Unfortunately, articles like this can do real damage. Many people who are not expert in these things are struggling to figure out which mobile application development models are going to be workable. I happen to believe that the Mobile Web will, like the desktop embodiment of the Web, grow as disruptive technologies tend to: from something that's a bit shaky at first to the model that dominates? Why? Because unlike Mr. McAllister, I believe that the underlying processors and system technologies are capable of running it, and the value of a model that is fully cross-platform, can support zero install operation (you might want to install a mapping application to find a restaurant, but you almost surely don't want to install the restaurant's application to read menus or get discount coupons), can also scale to support installable applications (Widgets [w3.org]) and offline operation, is compelling. Furthermore, as has been the case for years, the Web has the unique value of allowing you to link to the over 1 trillion [blogspot.com] Web pages, without jumping out from some proprietary application container to a Web browser. Whether I'm right about the likely success of the mobile Web or not, this whole question deserves a much more careful analysis than McAllister's article provides. Unfortunately, there will be many people who read it and jump to the conclusion that the mobile Web is failing. A shame.
Re:I have a better idea (Score:3, Informative)
browser (Score:2, Informative)
Did you jump through the hoops and put the opera mini browser on it? I know the guys at the howard forums recommend that over the stock browser that comes with that phone.
Re:Pot, meet kettle (Score:4, Informative)
If it crashes your phone, there's something wrong with your phone, not the site.
Because clearly, when so many other pages work, and this one particular site causes my phone to crash, the fault is with my phone.
If a Website, even a maliciously crafted one, can crash your phone, then you have multiple problems with your phone. First your browser or browser plug-in is flawed. Second, your phone's OS is failing to properly handle a crashing program. There might be something wrong with the site as well, but your phone definitely has several things wrong with it.
Re:is this why /. is the sucks to read on my iphon (Score:3, Informative)
except for the flash based ones, slashdot is the most annoying to navigate on my iphone
Just create a separate account, then log into that account and do:
Then go to your iphone and log in with the new account. Simple as that.
Re:Outdated? (Score:3, Informative)
Double tap on a paragraph and it will zoom to fit.
AutoFill passwords works fine for me, perhaps you forgot to turn it on (Settings -> Safari -> AutoFill). Do bear in mind, many sites manipulate login forms to prevent saved passwords from working.