Please create an account to participate in the Slashdot moderation system


Forgot your password?
Google Microsoft The Internet Twitter Technology

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."
This discussion has been archived. No new comments can be posted.

Microsoft, Google, Twitter Debate HTML5

Comments Filter:
  • iPhones run ARM compiled apps and Apple laughs all the way to the bank...
    • Exactly. Fart apps run much smoother on iPhones than their Java equivalents on Android phones.

    • Re: (Score:2, Troll)

      Apple made a good choice going with native applications for the iPhone, even though I detest the OS itself. The other OS vendors picking Java or .NET bytecode runtimes was really a strange choice for resource-limited devices.
      • Apple made a good choice going with native applications for the iPhone

        I don't know about that. There are more developers that work in Java and .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.
        • by PCM2 ( 4486 )

          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.

        • There are more developers that work in Java and .Net.

          What are the sources you have to back for such a claim?

          • You are correct in asserting that I am making an assumption without any hard figures on developers. However, I am feeling pretty sure that 90% of the world's developers aren't writing code for a company that produces 10% of the hardware. For all the attention Apple is getting these days, they are still a very small player in the overall market.
            • 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 has been on cell phones for ages (even my dumphone can do it). Actually, originally Java was created especially for embedded devices.

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

  • It'll be nice for the Apple users that some flash (the forbidden fruit in their case) can be translated or rewritten into HTML5. Your move, Jobs.
    • Jobs here, I will just make you hold your phone in another silly way. Your move, clone.
    • Your move, Jobs.

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

      • 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

  • by fahrbot-bot ( 874524 ) on Friday June 17, 2011 @03:28PM (#36478720)

    The promise of HTML5 is 'write once, run everywhere,' ...

    Isn't that what they said about Java? For which it humorously was said to be, "write once, wait everywhere"...

    • Unfortunately, java is many, many times faster than the best javascrirpt vm powering html5.

      • by Anonymous Coward

        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

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

      • by PCM2 ( 4486 )

        They're taking another crack at it with JavaFX, but the problem now is that it's pretty late to the party.

        • 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

          • by Lennie ( 16154 )

            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.

    • by Anonymous Coward

      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.

      • Oracle actually does a pretty good job. It's also got a language that as far as I can tell is Java with PL/SQL syntax (as well as actual Java). Depends on your definition of language I guess.
    • by dgatwood ( 11270 )

      Isn't that what they said about Java? For which it humorously was said to be, "write once, wait everywhere"...

      No, no. It's write once, debug everywhere. Get it right....

    • write once, debug everywhere in my experience.

  • by MrEricSir ( 398214 ) on Friday June 17, 2011 @03:29PM (#36478730) Homepage

    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.

    • by Anonymous Coward

      Isn't it interesting, then, that Adobe is planning on adding the ability to publish as HTML5 from Flash?

    • But one of the arguments against Flash on mobile is that it is still a bit buggy and Flash isn't optimized for touchscreens. Since mobile is becoming a larger market, developers can either wait for Adobe to get it right or develop in something else.
    • I'm pretty sure Flash took off because one thing: video. The total lack of standardization in video codecs and plugins in a formative years of the web really made Flash necessary for anyone who wanted to publish a single video file and be certain that just about anyone could play it. Used to be that you had to publish for all of: Quicktime, Windows Media, and RealPlayer. And then you still didn't have any control over the playback. Flash gave so much more control over video content and it is now the main us
      • Re: (Score:2, Insightful)

        by Anonymous Coward

        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)

          by yarnosh ( 2055818 )

          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

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

  • will keep them talking until the sun rises so that they all turn to stone.
  • Because they run in a browser that frames your experience differently over different platforms. most apps take up the whole screen and the users is forced into an experience that is 100% under the designers control.
    • 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?
      • 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.

    • What if the browser on a particular platform strives to make apps running in it look as native as possible?

  • "Write once, run anywhere" is a nice dream, but I'm starting to think it can't be done. Java came close, but it was still more "write once, debug everywhere" in practice. How are we going to get it with HTML5 when Microsoft, Google, Apple, and Mozilla can't agree on which features their browsers are going to support? IE won't do WebGL, Firefox won't do h.264 video, CSS commands to do the same bloody thing have to include the browser prefix... the web page code is STILL full of browser checking and doing dif
    • by Necroman ( 61604 )

      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,

  • I prefer apps over websites in a browser for my android phone for a lot of things. Having a browser between myself and what I'm doing is annoying. Also, my plan has a very low cap for data transfer, so webpages take up more bandwidth even if a lot of it is cached. With an app I can download the app at home over wifi and use it out in the world over 3G. Things like graphics don't get transferred over the connection, just a bit of text. Example: GasBuddy This app is very slick and well written, I think e
  • Are we positive... (Score:4, Insightful)

    by marcello_dl ( 667940 ) on Friday June 17, 2011 @03:52PM (#36478978) Homepage Journal

    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.

    • by earls ( 1367951 )

      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.

      • 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 [] demo, but compared to a native client, it's pretty slow - try opening Notepad and typing, and then try opening Acrobat and scrolling...

    • by drb226 ( 1938360 )

      Games will still be native

      Don't underestimate the number of zombies^H^H^H^H^H^H^H people that play FarmVille.

    • The problem is if I'm not connected I can't access my apps. Unless they allow me to download and host them myself, fuck that. This is fine for companies that have their own servers and operate thin clients, but I don't want to be reliant on an infrastructure I don't control and that can fuck me over at a critical moment.
    • by kwerle ( 39371 )

      In no particular order and for no particular reason, I'm just going to disagree with everything you say.

      • - web apps are easy to deploy.

      Be that as it may, the difference in various browsers means the results are not always what you were hoping.

      • - 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. []
      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

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

  • by Anonymous Coward

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

  • by Animats ( 122034 ) on Friday June 17, 2011 @04:43PM (#36479572) Homepage

    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.

  • 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

  • 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

  • by Twinbee ( 767046 ) on Friday June 17, 2011 @05:06PM (#36479866) Homepage

    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.

    • "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, "

      If there's one thing Java should have taught us is that NO ONE want's a unified a

  • 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?

  • by davide marney ( 231845 ) * <> on Friday June 17, 2011 @05:42PM (#36480274) Journal

    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.

  • by Graymalkin ( 13732 ) on Friday June 17, 2011 @06:01PM (#36480446)

    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.

  • We see that you big boys (3-4 corps, you know which) are going rather fast in your crusade to do some progress, and it is to some extent commendable, but, dont forget - in the end, you are just 4 corporations, regardless of how big and influential you are. (yes, even google). If you lose yourself and forget about the community that builds on the standards by deciding and implementing them without the community, the community will shove those up your ass.

    no really. the hundreds of millions of web develope
  • 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.

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

  • , or at least the portable version PNaCl seems like a good alternative way forward. I know Mozilla and others are opposed to it, but I really think we need something a little better than Javascript if we are going to be writing sizeable applications. Most sizeable applications (word, excel, 3D software, Gimp etc) are written in languages that support static typing, classes etc. There is a reason Microsoft and others do not write their big applications in scripting languages, and it's not just about speed.
  • In my opinion HTML5 is best. I really like few thing about HTML like, you can embed video on web-pages without using any special software like Flash, Not only videos, HTML5 is said to be capable of playing video games on the browser itself. A major benefit is better Direct HTML Support for Drawing, Animation, Video and Audio. iPad Application Development []

The IQ of the group is the lowest IQ of a member of the group divided by the number of people in the group.