Microsoft, Google, Twitter Debate HTML5 87
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."
Meanwhile... (Score:1)
Re: (Score:2)
Exactly. Fart apps run much smoother on iPhones than their Java equivalents on Android phones.
Re: (Score:2, Troll)
900mb gorillas (Score:3)
I don't know about that. There are more developers that work in Java and
Re: (Score:2)
And yet, Objective-C keeps climbing on the list of most popular programming languages/platforms. I highly doubt all those Objective-C developers are building Mac OS X applications.
Re: (Score:2)
There are more developers that work in Java and .Net.
What are the sources you have to back for such a claim?
Re: (Score:2)
Re: (Score:2)
But we were not talking about Apple's platform in particular, but rather native code in general. Most certainly, not only iOS devs write native code. In fact, most desktop applications running on Windows today are pure native code (typically C++). So, from a popularity point of view, a decision on native code or VM as a basis for app is not at all clear.
Java ME (Score:3)
Java ME has been on cell phones for ages (even my dumphone can do it). Actually, originally Java was created especially for embedded devices.
Re: (Score:2)
Java ME is pretty impressive. I installed Opera Mini on an old LG Keybo I, and goddamit, but it's got multi-tabbed browsing and supports enough Javascript to post on Slashdot.
Replacing the forbidden fruit? (Score:1)
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
What the fuck does this even mean? People move their Flash app to HTML5 and then the millions upon millions of iPhone and iPad users in addition to the millions upon millions of desktop users get to use it. How is this bad for anyone? Why would anyone need to "make a move"?
Re: (Score:1)
If anything, NOT having Flash on the i-devices is what is driving Flash to HTML5 adoption. If Flash was "everywhere" [and assuming it actually worked well, both user-experience and performance-wise], there would be no impetus for anybody to switch. And with more mature tools for Flash development than there are for HTML5, new web sites would be more likely to select Flash as well.
But there being one major platform without Flash, and with Flash sucking so badly on other mobile devices, if you want people w
The promise... (Score:4, Funny)
Isn't that what they said about Java? For which it humorously was said to be, "write once, wait everywhere"...
Re: (Score:2)
Unfortunately, java is many, many times faster than the best javascrirpt vm powering html5.
Re: (Score:1)
Unfortunately, java is many, many times faster than the best javascrirpt vm powering html5.
regex-dna cpu secs
JavaScript V8 4.76
Java 6 -server 23.60
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=java
Re: (Score:1)
And on everyone of the other 8 comparisons, the JavaScript V8 program was slower than the corresponding Java program.
The median JavaScript V8 program was 3x slower [debian.org] than the corresponding Java program.
Missed opportunity (Score:2)
If Sun would have taken Flash more seriously as a competitor, they would have included some video decoder in the JRE (and image rotation, etc.). Now Flash is used exclusively used for video and music streaming, and for most online games. Although Java is still healthy on the serverside, and in thick client business apps, applets are rarely seen outside of a few university CS/math sites.
Re: (Score:2)
They're taking another crack at it with JavaFX, but the problem now is that it's pretty late to the party.
Re: (Score:1)
No one is taking JavaFX seriously. Add to security holes of JRE and now true hardware acceleration of html 5 in IE 9 and Firefox and it is dead.
Java applets were depreciated in HTML 3 thanks to Microsoft. They did a great job killing it and lobbying/bribing w3c members to depreciate it. This scared web developers enough to switch to Flash when they saw that. ... not that I am not still mad at them 12 years later.
What irrates me the most is the only way to create JavaFX applets is to use Adobe tools??? Netbe
Re: (Score:2)
The Java-plugin model is dead, maybe even the whole plugin-model is dead when browsers keep releasing new updates to their browsers as fast as they are doing now. Even Microsoft is back in the game. They want to release IE10 next year. IE6 is much closer to dead by then, so maybe we can start to forget about IE6 completely by then.
Re: (Score:1)
I would, but the knowledge base is written in Java and I'm still waiting for it to load
Re: (Score:1)
Every language that comes out says "write once...". Then they hit the actual platforms they are running on. Suddenly its write once try it everywhere.
I remember the same claims for fortran, cobal, C, C++, Pascal, ADA, Python, the 5 different version of Java, and on and on...
Write once run everywhere becomes more realistic with framework that can be used on all platforms. Has not really happened yet.
Re: (Score:1)
Re: (Score:2)
No, no. It's write once, debug everywhere. Get it right....
Re:The promise... (Score:4, Insightful)
and I still think that write once, debug everywhere is better that write n times, and debug everywhere
Re: (Score:2)
write once, debug everywhere in my experience.
Missing the point (Score:3)
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.
Re: (Score:1)
Isn't it interesting, then, that Adobe is planning on adding the ability to publish as HTML5 from Flash?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Insightful)
I'm pretty sure Flash took off because one thing: video.
Flash was all about: Animation and Interaction.
Flash was used a lot and popular well before it was used to play web videos and that was the purpose Macromedia had for the software. The fact that Flash was popular lead to the discovery that it was a good wrapper for playing video as well. Flash required some "tricks" to get it to play video. It wasn't until, I think, Flash 5 that video support started to become integrated and easier to use natively?
Certainly Flash and YouTube became a real symbiotic relat
Re: (Score:3, Informative)
Websites made entirely with Flash should be killed with fire. It is bad for the user (hard to link/bookmark inside the site) and bad for admins (much more difficult to track usage and maintain). Honestly, I could live without Flash were it not for its video applications. But hopefully people will start using HTML5 for that. As a web developer (programmer, not designer) I also hate working with Flash because it is opaque. You can't make simple updates to content/functionality without loading up the authori
Re: (Score:2)
The thing is that if you're doing any serious app development, there's more to it than the client side. I have never worked on a project that was all JS or AS. In fact, JS is generally the smallest component in my experience. If you're just writing a game or something, fine, plenty of AS3 programming and no server stuff, but that's not really a web app.
THe problem I've encountered is that most Flash developers only know Flash. They don't really understand the server side at all.
Re: (Score:1)
Yes, but flash is irrelevant on mobile. It really is. I run Android. I run flash maybe 1 out of 1000 times I use my phone. This is HTML5 vs Applications. Flash has nothing to do with that, really. I don't know of any serious developer saying "Our future is Flash!" Java is even heavily frowned upon.
It's really a question of HTML5 or Native. And, like Microsoft itself and their Native cash cows, native has nowhere to go but down.
Hopefully Gandalf (Score:2)
HTML 5 will never feel as 'native' as an app (Score:1)
Re: (Score:3)
Re: (Score:2)
javascript is just a language so it's a simple matter of writing a library to access the underlying hardware through a foreign function interface.
Sandboxing in a browser via the js engine and vendors 'standardising' apis are secondary issues.
Re: (Score:2)
What if the browser on a particular platform strives to make apps running in it look as native as possible?
Write Once, Run Anywhere (Score:2)
Re: (Score:3)
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,
Re:Write Once, Run Anywhere (Score:4, Informative)
abstraction layers on top? JQuery type implementations.
Those already exist [infoworld.com] for mobile devices, jQuery Mobile included.
Apps also spare bandwidth (Score:1)
Are we positive... (Score:4, Insightful)
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.
Re: (Score:2)
OnLive disagrees.
And you can use an HTML5 RDP server to deliver office suites and any other Windows apps directly to the browser. Works like a charm.
Re: (Score:2)
Do you mean, an HTML5 RDP client?
If yes, then I'd assume that would be something using canvas. Is there an implementation that can do so at a decent speed? I've seen this [ericomaccessnow.com] demo, but compared to a native client, it's pretty slow - try opening Notepad and typing, and then try opening Acrobat and scrolling...
Re: (Score:2)
Games will still be native
Don't underestimate the number of zombies^H^H^H^H^H^H^H people that play FarmVille.
No (Score:2)
Re: (Score:2)
In no particular order and for no particular reason, I'm just going to disagree with everything you say.
Be that as it may, the difference in various browsers means the results are not always what you were hoping.
http://www.readwriteweb.com/hack/2011/05/doom-ported-to-javascript-and.php [readwriteweb.com]
Ignore moore's law at your own risk. It isn't so much that computers are getting faster, now - they're getting smaller and drawing less power. Today's "mobile device" is as powerful as yesteryear's computer, and that trend
orly? (Score:2)
the move toward apps instead of websites is being driven less by technology than the imperative to make money.
Genious conclusion! /sarcasm Really, though. True "technology" advances lead to interoperability, not mini walled gardens.
let me fix this for you all..... (Score:1)
"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 CONTROLLING next-generation Web USERS, and whether mobile developers should build websites or apps......
this isn't about you or me , its about how they are gonna control the next generation.....
Re: (Score:1)
If you run Windows I highly suggest you try IE 9. It is catching up and is very html 5 compliant. Still webkit owns it for now with all the features. IE 10 will hopefully bring this to a close.
As much as many of us at this website delore IE, it is nice to get users to ugprade so we all can enjoy HTML 5. As long as IE 8 and earlier keep being used as the most popular browsers in the world, you can bet webmasters will ignore us and only focus on html 4 and CSS 1.x. ... if only WindowsXP could be retired soone
Compatibility needs a strong buyer (Score:3)
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 long as they pick a standard and stick with it. (Score:2)
It's just too damned expensive to have to migrate to a whole new incompatible technology with no upgrade path because some 20-something at Microsoft had a brainwave. (Yes, your old app will still run. Good luck selling that fully developed VB6 application). Extend and improve. Do NOT replace unless there's no other option.. and guess what? THERE'S ALWAYS ANOTHER OPTION!
So, an open standard like HTML5 and Javascript? By all means. Bring it on. Improve both incrementally. Stop wasting everyone's time on point
First problem (Score:2)
But Raffi Krikorian, infrastructure engineer at Twitter, also called out the limitations of HTML5, saying it's "really nice to look at," but can't do things such as send notifications to users.
I don't know if it's part of HTML itself, but GMail manages to send me desktop notifications via Chrome. I'm not seeing a problem here.
Also, is anyone surprised that the Microsoft guy is the loudest skeptic? I mean, I've heard a lot of good arguments from a lot of skeptics, but this really seems like a case of "follow the money". Twitter is skeptical because they can actually build a better experience, in some circumstances, with a custom client -- but they're still doing HTML. Microsoft has to be looking a
Re: (Score:2)
Notifications are part of HTML5 [html5rocks.com]. As far as I know, only Chrome supports it at the moment, but it is being standardised.
Unification forever (Score:3)
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.
you mean "hacks" (Score:1)
"As this story shows, the idea of unifying architectures and OSs is so strong that it's already happening in browser land. "
Considering the number of hacks required to anything significant with JavaScript and CSS, I would hold off on that prediction.
"there's just too much innovation in Linux, Windows and Mac"
Linux - Innovation Zero.
Windows - Innovation Meh.
Mac - Innovation not bad.
".NET is a good step in that direction, "
ROFL.
If there's one thing Java should have taught us is that NO ONE want's a unified a
Choice of experts (Score:2)
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 [ajaxian.com] what can be done realistically with HTML5?
"HTML5" is an ecosystem, now (Score:4, Informative)
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.
I smell some bullshit (Score:3)
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.
Watch out (Score:2)
no really. the hundreds of millions of web develope
Dump everything! (Score:1)
HTML5 is the new codeword for "dump everything you have and start over!"
C/C++ is the future (and the past). Like it or not, C/C++ is truly the only write once, run everywhere (except Windows Phone) solution around.
Not the way (Score:2)
Just give us a good OpenGL-like API and a bytecode environment, with a JIT compiler, and open-source will build its own browser environment.
HTML5 is too complex to be used as a cross-platform application deployment tool.
Software needs to be built in easy to understand layers. And HTML5 just gives us one enormous complex and opaque layer. This is not how software should be built!
Just give us a bytecode environment, and if we want to, we'll build HTML5 on top of it, or we might choose our own rendering layer.
Google Native Code... (Score:2)
HTML5 is best (Score:1)