Slashdot Mirror
Microsoft, Google, Twitter Debate HTML5
jbrodkin writes "The annual USENIX conference featured an all-star lineup of engineers from Microsoft, Google, Twitter and Flipboard debating whether HTML5 is the 'holy grail' for building next-generation Web applications, and whether mobile developers should build websites or apps. The promise of HTML5 is 'write once, run everywhere,' but the panelists did not agree on whether the technology is good enough to make browser applications feel 'native.' There was general agreement that HTML5 is lacking on mobile devices, and that for better or worse the move toward apps instead of websites is being driven less by technology than the imperative to make money."
Isn't that what they said about Java? For which it humorously was said to be, "write once, wait everywhere"...
It must have been something you assimilated. . . .
The underlying technology matters, sure, but you're not going to be replacing Flash anytime soon without an authoring tool that people can actually use. The reason Flash took off wasn't because the plugin was easy to get, it was because the authoring tool made it simple to build a basic web app without a lot of hassle.
There's no -1 for "I don't get it."
will keep them talking until the sun rises so that they all turn to stone.
L'esperienza de questa dolce vita (The experience of this sweet life) - Dante Alighieri, The Divine Comedy
Are we positive we want to delegate all to the browser?
- web apps are easy to deploy.
- web apps can't match efficiency of native apps (it doesn't matter when you have a multicore desktop, it matters when your smartphone has way less autonomy than it could.
- web apps everywhere means they will have to be secured (compared with web 1.0 with standard ports for every protocol and a multitude of client/server software vs. port 80 and a handful of browsers)
- web apps can be seamlessly upgraded (even when user doesn't want to, though)
- native apps are hard to deploy (a free OS with package management, look at debian or experiments like nixos, solves this problem)
- FOSS native apps can be owned by the user.
Anyway, this is just a trend. Games will still be native, and people will hold onto their office suites, and some html5 features reduce the dependency from the network (local storage) which is good.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
abstraction layers on top? JQuery type implementations. Remember the days of yore where Javascript behavior was wildly different between all the browsers (and it still somewhat is). Well, other people came around and created abstraction libraries on top of it to make it easier and more consistent across all the browsers. there are people out there that will continue to do this. HTML implementation and specs have been changing rather rapidly, so it may still be a little while before we get abstractions, but it will happen.
Its not what it is, its something else.
Also can HTML5 take advantage of hardware? For example a few years ago almost no smart phones had acclerometes and gyroscopes; many have them today but not all. How does HTML5 take advantage of them?
Well, there's spam egg sausage and spam, that's not got much spam in it.
Apple made a good choice going with native applications for the iPhone
.Net. Apple had a lot of devs follow them initially because they were the 'next cool thing', but I don't know how it will work out for them in the long run. I'd rather have a larger have a larger developer base over a native language support any day.
I don't know about that. There are more developers that work in Java and
HA! I just wasted some of your bandwidth with a frivolous sig!
Java ME has been on cell phones for ages (even my dumphone can do it). Actually, originally Java was created especially for embedded devices.
abstraction layers on top? JQuery type implementations.
Those already exist for mobile devices, jQuery Mobile included.
Breakfast served all day!
The reason we don't have compatibility is that the sellers have more power than the buyers. When sellers are many and weak, as in desktop PCs, compatibility is good.
In aerospace, compatibility is made to work. There's a specification, and both sides of an interface must conform to the specification. That's why you can unbolt a Pratt and Whitney engine from a 747, bolt on a Rolls Royce engine, and go fly. In telephony, you can buy many basic components from a number of suppliers. Phone compatibility with cellular networks is technically a tougher problem than JavaScript compatibility, yet carriers make the phone manufacturers and cell site manufacturers interoperate properly.
It's about power, not technology.
As this story shows, the idea of unifying architectures and OSs is so strong that it's already happening in browser land. But for desktop land (where apps/programs will ultimately be as obviously it's faster and more versatile) there's just too much innovation in Linux, Windows and Mac land for everything to be unified at this point in time. .NET is a good step in that direction, but even then, the framework requires a rewrite for each OS, so bugs can appear. Perhaps wait a couple more decades, and we'll have a universal GUI (well for 99.9% of users at least), preferably open source and free of course! That will go with a unified CPU/GPU/APU architecture with unified memory, data and power ports. Yum.
Why OpalCalc is the best Windows calc
Right, so they put a language designer (a theorist), a developers relations manager (a PR guy) and an infrastructure engineer (someone who talks wires and servers) to talk about front-end development. How about calling actual front-end engineers to talk about their craft? How about asking the guys behind the Aves game engine what can be done realistically with HTML5?
There are a lot of things lumped under the "HTML5" moniker that go well beyond HTML the language: WebGL, Web Sockets, SVG, Geolocation, File API, Real-Time Events, Threading, not to mention the very large assortment of styling modules lumped under "CSS3". HTML5 represents more of an ecosystem now, like .NET.
No, it's not the end of the line for other ecosystems, this is just another new one. A very, very important one, to be sure, but it obviously won't fill every need for a client UI out there. That said, if my new shiny app could even remotely be done as a web app, I'd be a fool to spend a whole lot of time and money porting it.
"We receive as friendly that which agrees with, we resist with dislike that which opposes us" - Faraday
Complaints about HTML/Web apps not feeling "native" is a canard. Hundreds of millions of people use web pages every single day, from the most technical neckbeards to the least technical AOL grandmas. Now non-technical users probably aren't spending much time on sites with bullshit user experiences but there's a mind boggling number of websites people use daily. Native apps are also rarely bastions of usability and paragons of user experience virtue. Web apps don't need to "feel native" because the appeal of "native" apps doesn't really exist in the minds of actual users. These hundreds of millions of users aren't being held back from anything because they're using web pages instead of native apps.
Users want services and content and they're happy to access them through a web browser. In fact a web browser makes it easier for them in most cases because they don't need any special software before they access said content and services. Whatever device they're using likely has a web browser accessible. If they see a URL they can pop open their laptop or pull out their phone and access it immediately.
When they're on their phone they don't want it to take forever to load when they're stuck in a slow 3G area with no WiFi. They want it to work on the iPhone they just bought as well as their Windows PC back home. If they buy a Mac for their kids they want it to work on that as well.
The major features HTML5 added were ones that help web pages not feel more like native apps but have better interaction with clients. Clients aren't as limited as they were in the past (I remember a time before the <img> tag) and a richer DOM is important for the increased amount of work (Javascript, CSS, etc) being done on the client side.
These people complaining about performance on mobiles is just jackassery. The mobile web experience had the same sort of constraints that native mobile applications have. Mobiles have tiny batteries, often have small screens, are controlled with fingertips rather than mice, and often have slow high latency internet connections. Again it goes back to graceful degradation that users are already expecting. Maybe the mobile version doesn't load the 2MB PNG background and the uncompressed 1MB Javascript from a totally different server (requiring a second set of DNS lookups) out of which you only used two functions. The mobile native app wouldn't have the 1024x1024 icons or the 50MB 1080p intro movie bundled with it either.
HTML5 doesn't need to bring a more desktop-like experience to mobiles. It also doesn't need to make apps that look native. It needs to be used to make web apps functional and do their business with the least cognitive load on users as possible. It should scale well no matter how large the screen is or how shitty the connection speed. Instead of all singing all dancing bullshit I'd much rather see a page load on my phone and then let my fucking CPU go to sleep so I don't waste my battery trying to read a tweet or a Facebook message.
I'm a loner Dottie, a Rebel.