Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Chrome Google Role Playing (Games) Games Technology

Google Demonstrates Chrome Native Client With Bastion 154

Multiple readers sent word that Bastion, an action RPG from indie developer Supergiant Games originally made for Xbox Live Arcade, has shown up in the Chrome Web Store. The purpose of the move is to showcase the browser's Native Client technology. From the article: "Ian Ellison-Taylor, Google's director of product management for the open Web platform, said that Native Client, also called NaCl, can currently improve browser performance by 1 to 10 times. 'What would it be like if we could run native code inside the browser,' he asked the crowd, and he enumerated two goals for the Native Client project. He said Google wants to bring native applications to the Web for performance and security reasons, and it wants to enrich the Web ecosystem by bringing popular, long-in-use programming languages to the Web."
This discussion has been archived. No new comments can be posted.

Google Demonstrates Chrome Native Client With Bastion

Comments Filter:
  • by Anonymous Coward on Friday December 09, 2011 @06:50PM (#38320308)

    This is so revolutionary. Now we can run native applications on our computers! Just imagine the possibilities! Oh, wait. We already can. And they aren't inhibited by some horrid browser-based sandbox.

    • by AmiMoJo ( 196126 )

      Considering the difficulty that many users seem to have with noticing those big scary warning messages about how the free screensaver they just downloaded can rape their PC I think offering a sandboxed environment might be a good idea. Microsoft seems to think so too as that is exactly what Windows 8 will offer.

  • by roman_mir ( 125474 ) on Friday December 09, 2011 @06:51PM (#38320338) Homepage Journal

    can currently improve browser performance by 1 to 10 times

    - this reminds me of the quote from the historical documents:

    -Good Lord! That's over 5000 atmospheres of pressure!
    -How many atmospheres can the ship withstand?
    -Well, it was built for space travel, so anywhere between zero and one.

  • bad idea (Score:1, Funny)

    by locopuyo ( 1433631 )
    How would that be more secure? I can only think of things that make it less secure. It is also Satan's anus poised over web standardization.
    • Re:bad idea (Score:5, Informative)

      by Qwavel ( 733416 ) on Friday December 09, 2011 @07:21PM (#38320684)

      I'm guessing they mean that you are more secure now that you can run apps in your browser which you previously had to install into your OS. The privileges enjoyed by an NaCl browser app are really minimal compared to the same app installed with admin on Windows (which is how most users do it).

      Regarding web standardization, note that NaCl is nothing like Flash or Silverlight: rather then replacing standard web technologies with proprietary technologies, it is primarily a way to optimize pieces of web technology. You take your bundle of HTML/CSS/Javascript and replace pieces of the javascript with native code. And you don't do it with some proprietary google language - you do it (eventually) with whatever language you want.

      To me it seems like a reasonable way to move the web forward without subverting it (or even altering it much).

      • Since NaCl == Sodium Chloride == Salt, let's make this discussion more interesting by replacing all instances of "NaCl" with "salt".

        "note that [salt] is nothing like Flash or Silverlight". The first consistently taste great, while the others vary in flavor from one OS to the next. I kid, I kid :)

      • Re:bad idea (Score:4, Insightful)

        by kripkenstein ( 913150 ) on Friday December 09, 2011 @10:28PM (#38322230) Homepage

        To me [NaCl] seems like a reasonable way to move the web forward without subverting it (or even altering it much).

        There are a few big problems with that:

        • NaCl is not portable. NaCl apps only run on x86 and x86_64, not ARM or PowerPC or anything else.
        • NaCl is not a standard or even a proposed standard, and all other browser vendors are opposed to it (because of the previous issue, and because it is controlled by Google). As a consequence, NaCl apps only run on Chrome (and on x86 and x86_64).

        The web is all about open standards, viewing the same web from any browser or any OS, and so forth. So NaCl, that only runs on two archs and on one browser, is a step backwards.

        • Re:bad idea (Score:5, Insightful)

          by suy ( 1908306 ) on Saturday December 10, 2011 @07:01AM (#38324380) Homepage

          NaCl is not portable. NaCl apps only run on x86 and x86_64, not ARM or PowerPC or anything else.

          NaCL binaries are not portable in the same way I can't install the FireFox's Windows binaries on Linux (or the armel ".deb" from packages.debian.org on my amd64 computer), but honestly, who cares? Mozilla and Debian guys just compile it for each supported platform. There is also the possibility of creating a "fat nexe" that supports all platforms.

          As a consequence, NaCl apps only run on Chrome (and on x86 and x86_64).

          Is open source code on an open source browser. I would prefer it being a plugin (I think at some point there was one) so I can run it in all my browsers. But this is no different than any other proprietary feature on other browsers. I'm currently using Mozilla's proprietary "crypto" JavaScript API for an application, and it only runs on Mozilla's browsers. Not convenient, for sure, but what should I do? Not use the feature at all? Or try to make something valuable from it, so other developers might consider incorporating it?

          • NaCL binaries are not portable in the same way I can't install the FireFox's Windows binaries on Linux (or the armel ".deb" from packages.debian.org on my amd64 computer), but honestly, who cares? Mozilla and Debian guys just compile it for each supported platform. There is also the possibility of creating a "fat nexe" that supports all platforms.

            And what happens when I'm browsing the web on my MIPS-based TV? I'm at the mercy of the website author to specifically support my architecture. Today, I can visit

            • by suy ( 1908306 )

              And what happens when I'm browsing the web on my MIPS-based TV? I'm at the mercy of the website author to specifically support my architecture. Today, I can visit any website and it will work. There is no dependency on any architecture specific stuff. Most developers will only bother compiling for x86 and ARM in all probability, which will hurt anyone else.

              First, MIPS (or any other architecture) is not left out by design, just by implementation. The sandbox requires a deep study of the assembler language of the architecture to avoid all kinds of holes, so there aren't much implementations available because the technology is quite young, but if it ends up being useful, the MIPS manufacturers will be interested in supporting it. If you have a really minor architecture, chances are high that you will have little support for other kinds of hardware accelerated pr

          • There is a fat nexe for x64 and x64_64, but nothing else. That still isn't portable.

            Portability is important on the web. People expect to visit websites from their web browser, and for them to work regardless of their OS and CPU. NaCl doesn't work like that.
  • by orn ( 34773 ) on Friday December 09, 2011 @06:55PM (#38320388)
    Like I really want anyone and their uncle to be running native code on my machine. We went to a sandbox model for a reason! If this is active now, how do we shut it off?
    • Re: (Score:2, Informative)

      by Anonymous Coward

      You should read up on how NaCl works. It is in a sandbox. One based on software fault isolationi.

    • Like I really want anyone and their uncle to be running native code on my machine. We went to a sandbox model for a reason! If this is active now, how do we shut it off?

      It's not active by default, yet, and it is sandboxed. Native sandboxing is possible.

  • by Mr. McGibby ( 41471 ) on Friday December 09, 2011 @06:56PM (#38320402) Homepage Journal

    I tried Bastion this morning on my arguable beefy 8-core 8 GB machine. SLOW AS SNOT. So either it's slow or I need to change some configuration setting. Maybe I'm missing something, but wasn't doing this crap in the browser supposed to make it "just work" (tm)?

    • by 0123456 ( 636235 )

      Maybe I'm missing something, but wasn't doing this crap in the browser supposed to make it "just work" (tm)?

      They said it would 'just work' (so long as you're using a supported browser), they didn't say it would be usable.

    • Not sure what issue you had but I just gave it a go and it was quite smooth. The game it's self isn't my cup of tea but it ran just fine. Narration was funny, if I could have use my controller I prob would have played at least to the end of the demo..

    • It just worked for me, and I'm running a Core 2 Duo 3 year old processor with a medium range graphics card. I'm running Chrome 15

    • by Ambvai ( 1106941 )

      Low end i5, 4gb with onboard video. The first stage was about as smooth as the downloaded version with the exception of a periodic tiny skip about every two seconds. Chrome 15.0.874.121 m.

    • by VortexCortex ( 1117377 ) <VortexCortex AT ... trograde DOT com> on Saturday December 10, 2011 @05:20AM (#38324028)

      Single core code... You bought more cores thinking coders (especially poor indie ones) were going to support all of them at once?
      My 7 year old 3ghz single core machine, w/ 3GB RAM and a crappy $50 Nvidia GeForec FX 5200 runs this fantastically.

      As a coder myself I take great pains to ensure my software can take advantage of as many cores as you throw at it, but in reality, most programs do not. What's the individual cycle speed of one of your cores? Less than my 6 year old laptop? Yeah, don't expect low quality software to run well on your high quality rig.

      I wish Erlang wasn't crap when it comes to games -- it was a step in the right direction.

  • Reminds me of IE 6 (Score:3, Insightful)

    by Billly Gates ( 198444 ) on Friday December 09, 2011 @06:58PM (#38320430) Journal

    I am a little uneasy of making a web browser a proprietary platform. PcMag had an article about Chrome being the next IE 6 of the browser wars 2.0 [pcmag.com].

    IE 6 was a great browser in 2001 regardless of its security shortcomings found years later. Everyone on slashdot back then admitted to using it but were scared and assumed the WWW would die soon because of it. Everyone seems to be oblivious that Google is another evil big corporation no different than Microsoft. Actually synergy is behind Google now, like it was with MS a decade ago.

    Dart is chrome only, the javascript libraries are Chrome only or particulary run much better on Chrome (google ones like V8), this and many other proprietary HTML 5 code like that site with the band a few months ago that only work in Chrome. This game will use HTML 5 but has other proprietary hooks to make sure it wont run in any browser.

    Google is making it clear they look at the browser as an operating system. At least Microsoft today is running away from ActiveX and trying to do good with IE 10 which will be the most open and standards compliant browser to date. Firefox is dying and is losing popularity. In a year or two from now it will be a IE vs Chrome world.

    Anyone else bugged or am I just paranoid? I just want a great browser and not a simple fast one, but with the real goodies underneath it that are dependent on Chrome.

    • by Qwavel ( 733416 ) on Friday December 09, 2011 @07:40PM (#38320868)

      I agree that Google is just another big evil corp and should be watched closely - I'm a fan of much of what they have done, but I still try to remain critical.

      But this is nothing like what MS tried to do to the web. I'll repeat some of what I posted above: with NaCl, Dart, WebM, and SPDY, Google is not replacing web technologies with proprietary technologies - they are optimizing pieces of web technologies.

      Even when you use these technologies you are still writing a standard web app and it still runs on all browsers - just without the Chrome optimizations. For NaCl for example, the primary use case (according to Google) is that you take your bundle of HTML/CSS/Javascript and replace pieces of the javascript with native code. When deployed to other browsers your app uses the original javascript instead of the optimized NaCl alternative.

      More importantly, these technologies are all open source and restriction and royalty free. So, for example, Amazon is now using Google's SPDY technology in their browser without any royalties or advantage to Google.

      To me these seem like reasonable ways to move the web forward without subverting it.

      So, if you want to be pissed at Google then note that a couple of weeks ago they cancelled their project to make Green technologies competitive with coal. That didn't get nearly enough press. But when it comes to the web they (for now) still appear to be behaving themselves.

      • Even when you use these technologies you are still writing a standard web app and it still runs on all browsers - just without the Chrome optimizations. For NaCl for example, the primary use case (according to Google) is that you take your bundle of HTML/CSS/Javascript and replace pieces of the javascript with native code. When deployed to other browsers your app uses the original javascript instead of the optimized NaCl alternative.

        So I have to write my stuff twice? I barely have enough time to write what

        • So I have to write my stuff twice? I barely have enough time to write what's needed once!

          Or three or four times. ARM needs the boost more than x86, anyways, but honestly given that Javascript still doesn't seem suited for more than twirling fobs, I'm not sure what the real point is. I mean, if the performance does become high enough that it's feasible to push games into the browser, I can only see that as a combination of annoying users--just like flash does--while offering an inferior experience to a sta

      • SPDY and WebM are not the same as Dart and NaCl.
        WebM is just plain good, no doubt.
        SPDY gave them an advantage since they had it first and others were shy to make such a hack (because it is a hack), however, its getting adopted since SCTP would be a pain.

        Dart and NaCl received a strong push back from half or more of the community so I don't need to bore you with details you have already read.

        So they enforce it - and they can, due to Chrome's grow rate and their hand over a lot of things. They buy out compan

      • by Anonymous Coward

        For NaCl for example, the primary use case (according to Google) is that you take your bundle of HTML/CSS/Javascript and replace pieces of the javascript with native code. When deployed to other browsers your app uses the original javascript instead of the optimized NaCl alternative.

        So does that mean there's a version of Bastion written in javascript that runs everywhere, and a native version that works better in chrome?

    • by DragonWriter ( 970822 ) on Friday December 09, 2011 @07:52PM (#38320964)

      I am a little uneasy of making a web browser a proprietary platform.

      There's two different uses of "proprietary" that are common, one is in contrast to FOSS (which Native Client is), and one is in contrast to "standard" (with regard to which, per the Native Client FAQ, Google thinks Native Client is too immature to consider trying to standardize at this time.)

      Lots of technology gets integrated into browsers to be proven before being submitted for standardization.

      Dart is chrome only

      No, its not. The VM isn't integrated into Chrome yet, the only way to run it in a browser is compiling to JS that runs on any modern browser, so its not even runs-better-on-Chrome, much less Chrome-only.

      Its possible that the when the VM is integrated in Chrome it will be runs-better-on-Chrome.

      the javascript libraries are Chrome only or particulary run much better on Chrome (google ones like V8)

      V8 isn't a javascript library, its the JavaScript engine that Chrome uses, parallel to SpiderMonkey or whatever the engine is that Firefox uses now.

      [...] proprietary HTML 5 code [...]

      You are misusing either "proprietary" or "HTML 5" here.

      • by BZ ( 40346 )

        > V8 isn't a javascript library,

        You misunderstood.

        Google's JavaScript libraries are purposefully written to run faster on V8 specifically, often at the expense of performance in other browsers. And at the same time, V8 is written to run the code patterns those libraries use faster, often at the expense of other code patterns used elsewhere.

        The net result is that Google properties work better in Chrome and at the same time Chrome works better on Google properties.

        • Google's JavaScript libraries are purposefully written to run faster on V8 specifically, often at the expense of performance in other browsers. And at the same time, V8 is written to run the code patterns those libraries use faster, often at the expense of other code patterns used elsewhere.

          That might be a problem if V8 [google.com] wasn't open source, or if Google was preventing anyone from seeing how it works. As it stands, your argument makes about as much sense as saying that Linux and GCC were evil because earlier versions of Linux couldn't be compiled on anything but GCC. The thing is, nothing prevented anyone from changing Linux to compile in other compilers, or studying GCC to learn how to make other compilers compile Linux (and, indeed, today it's possible to compile Linux with other compilers).

          So

          • by BZ ( 40346 )

            > what's preventing anyone from implementing these
            > optimizations in other javascript engines

            They make other (non-Google) sites run slower?

            > Is it reasonable to prevent Google from optimizing
            > anything just because other browsers and libraries
            > would then be slower?

            I didn't say anything about preventing Google from doing whatever they want. I'm not sure where you got that.

            I'm also not sure where you got your "evil" bit from. I made a factual statement, with no value judgments attached to it

            • They make other (non-Google) sites run slower?

              That would be bad, but I find it hard to believe. Do you have an example of an optimization in V8 that makes some code run *slower* than it would without that optimization? It seems more likely that other engines are just better than V8 for some types of code; it's hardly surprising that V8's optimizations are focused on the type of code that appears in Google's libraries.

              I didn't say anything about preventing Google from doing whatever they want. I'm not sure where you got that.

              I'm also not sure where you got your "evil" bit from. I made a factual statement, with no value judgments attached to it.

              Sorry, I misunderstood you. I thought you were supporting the argument that Google is trying to do something similar to what Microsoft di

              • by BZ ( 40346 )

                > It seems more likely that other engines are just
                > better than V8 for some types of code

                Well, yes. But some optimizations are just mutually exclusive because they require different design tradeoffs.

                As for the rest... Google is definitely being evil in various ways, and is in fact much like Microsoft in the late 90s, in my opinion, but what they're doing with V8 is just self-interested, not so much evil.

                • So, the fact that V8 runs better some javascript in the wild has nothing to do with Google being evil. And "self-interested" seems a little uncharitable, seeing that V8 has a BSD license -- in other words, they're going out of their way to make the javascript engine they develop and use available to anyone interested, not even requiring modifications to be given back to them.

                  Google might be evil in other ways, but can we agree that the original point of this thread -- comparing what Google is doing with Chr

                  • by BZ ( 40346 )

                    Actually, I agree with the original point of the thread. What Google is doing with Chrome is:

                    1) Explicitly authoring its own web properties to specifically work better with Chrome, in hopes that its high market share for things like search and webmail will increase Chrome adoption.

                    2) Authoring its own web properties to only work with WebKit (e.g. a number of Google's sites sniff UAs and send WebKit-only content to any mobile UA).

                    3) Urging authors to create Chrome-only content (and more generally, togethe

                    • Your points 1-4 seem valid to some extent (even though, for example, I have never seen any difference in google search or gmail between Firefox and Chrome, and I use all combinations), but I think saying that's even remotely similar to what MS did is blowing things out of proportion. I think (2) and (3) are somewhat natural for anyone developing a web browser. For example, Mozilla did essentially (3) and allowed people to do (2) with Mozilla (now Seamonkey) and then Firefox for the longest time, in the form

                    • by BZ ( 40346 )

                      > I have never seen any difference in google search or
                      > gmail between Firefox and Chrome

                      Offline gmail only works in WebKit, by design.

                      > For example, Mozilla did essentially (3)

                      Mozilla has consistently tried to convince people to author pages that work in all browsers, in my experience. But I'm not omnicient, of course. ;)

                      The extensions thing you raise is interesting. I have to admit I'd never thought of it that way before, if only because I'd never used any such extensions. But yes, the number o

    • No, you're entirely right.

      I'd point out that Firefox isn't dying. It's actively developed and fully open (top to bottom), faster than many in some areas (slower in some others - so far).
      Plus, it stills gains more users every day - its just that the others, well, THE other (Chrome) is gaining *even more* users per day.

      The heavy advertising, bundling as opt-in and so on is probably working out. And that, and the Google integration you describe certainly reflect the issue.

      Google finally will be able to control

  • Good question (Score:3, Insightful)

    by 0123456 ( 636235 ) on Friday December 09, 2011 @07:02PM (#38320466)

    What would it be like if we could run native code inside the browser?

    The massive swamp of security vulnerabilities that was ActiveX?

    • Ironic, every modern browser supports something like ActiveX.

      I love when ignorant people such as yourself talk about shit you don't understand at all.

      ActiveX is nothing more than a plugin system. It just happens to be system wide in Windows, and IE takes advantage of that ... IE6 and its ancestors had a lot of issues because OTHER developers marked ActiveX controls as SAFE FOR INTERNET USE and SAFE FOR SCRIPTING ON THE INTERNET when they were not and had no reason at all to be used.

      The IE implementation er

      • I think you're missing something important. Every bit of JavaScript you run on modern browsers is compiled into machine code in memory, marked as executable, then executed -- right on the metal.

        This is why mistakes in the compiler and/or buffer overflows in JS supporting code can so easily cause remote code execution. All the "sandboxing" NaCl provides is the same as what JS provides -- NONE! Do you actually think that there are Zero buffer overflow vulnerabilities in any of your favorite softwares?

    • by dkf ( 304284 )

      What would it be like if we could run native code inside the browser?

      The massive swamp of security vulnerabilities that was ActiveX?

      I'd agree, except that Google actually appear to have made real progress on the problem of sandboxing native code. I'm not 100% sure that they've solved it — alas, I've not had the time to study it in enough depth — but it at least looks quite likely. Key things that are restricted include access to the parts of the OS that read and write files, with much of the sandboxing focusing on ensuring that nothing can jump to a bad instruction. Without unrestricted access to the OS, a process really can

  • Hey... I have some great proprietary technology that can increase the performance of any program by at least 1 times. Please send $1 to Happy Dude, at 742 Evergreen Terrace...
    • Hey... I have some great proprietary technology that can increase the performance of any program by at least 1 times.

      You do realize that improving by 1 time is doubling, right?

  • by The Raven ( 30575 ) on Friday December 09, 2011 @07:03PM (#38320486) Homepage

    Can someone describe the differences between NaCl (Salt?) and ActiveX? They both seem to be methods to run native code inside a browser sandbox. What are the ways Google's offering is superior? Is it better at all than the current implementation of ActiveX? I like Google, but this particular initiative seems kind of backwards thinking.

    • by tepples ( 727027 ) <tepplesNO@SPAMgmail.com> on Friday December 09, 2011 @07:11PM (#38320584) Homepage Journal
      NaCl defines a subset of x86 instructions that are verifiably type-safe, just as .NET IL and JVM bytecode are verifiably type-safe. The browser verifies the binary before executing it.
    • ActiveX, once you (or BFU) enabled it, can do anything user account is allowed to do. NaCl program is sandboxed, so even when you allowed it to run, it cannot do anything harmful.
      • by 0123456 ( 636235 )

        NaCl program is sandboxed, so even when you allowed it to run, it cannot do anything harmful.

        I remember people saying that about Java.

        • NaCl program is sandboxed, so even when you allowed it to run, it cannot do anything harmful.

          I remember people saying that about Java.

          And it's true. Early on there were some JVM bugs that allowed malicious apps to break out of the sandbox, but those have been fixed, and sandboxed Java code is sandboxed very effectively.

      • Comment removed based on user account deletion
    • Can someone describe the differences between NaCl (Salt?) and ActiveX?

      Native Client (NaCl) is a sandboxed environment that verifies and then executes a safe subset of x86 code. It is an open source technology integrated into Chrome that works pretty much everywhere Chrome does, and is a bridge to the real goal, which is Portable Native Client, which does similar things but uses LLVM bit code and client-side compilation so it isn't dependent on actually running on an x86 machine (opening it up to ARM-based d

      • (opening it up to ARM-based devices, particularly.)

        Actually, NaCl already works on ARM. Though PNaCl will make it easier to develop for, as you won't need to maintain different builds for each platform.

  • by Greyfox ( 87712 ) on Friday December 09, 2011 @07:16PM (#38320636) Homepage Journal
    Run native code WITHOUT the browser. Revolutionary idea, I know. You could pass on all the frameworks required to shoe-horn procedural programming onto a stateless protocol, give HTML and XML markup a miss, not write any javascript, and... just... write an application. And maybe it won't need 34MB to run in, and maybe it'll actually be instantly responsive. Maybe... just maybe... that's what you really need to do.
    • by ceoyoyo ( 59147 )

      Heavens. You could use some other port than 80 and a protocol other than HTTP for communication too.

    • And if you don't want that application to put your security at risk via the arbitrary code execution exploit du jour, all you have to do is run that application in a separate limited user account. And make sure all your important files' ACLs prohibit access from that account. And don't use runas, use an actual separate login session, because of window shatter attacks. It's so easy, I bet everyone runs their applications this way. I'm sure you do. ...Right?

    • by goruka ( 1721094 )
      And lose the ease of deployment that web based apps have and the multiplatform goodness of Native Client? No thanks.
      • by celle ( 906675 )

        "And lose the ease of deployment that web based apps have and the multiplatform goodness of Native Client? No thanks."

        What, get off you lazy ass and do real work for real pay. Who would have of thought?

  • ... rubbing salt in Adobe's wound.
  • by goruka ( 1721094 ) on Friday December 09, 2011 @08:56PM (#38321630)
    Native Client is like a plugin that makes all other plugins obsolete.

    -It can do everything you can do with Flash, Unity, Silverlight, etc.
    -You can use any language to develop for it, C, C++, ObjC, Python, C#, you name it.
    -Can access everything JS can (using the Pepper plugin API).
    -It's from a trusted vendor (Google), so most people will not be afraid to install it.
    -Will come pre-installed in the soon to be most popular web browser.
    -It's open source
    -It's much more secure than existing plugins due to sandboxing.

    And, yes, I can understand HTML5 purists, but the truth is that:

    1) Not everything can be made into a web application using HTML5+JS.
    2) There's way too much code and applications written in other languages..
    3) Cross-Platform web deployment is very attractive. Compile for x86 and ARM and 99.999% of the devices on the planet can be supported.

    So, disable it if you don't want it, but this is a very attractive idea with a lot of potential for us developers, and even Adobe is trying somehting similar with Alchemy [adobe.com] on Flash. It's a much more realistic way to bring actual real applications to the web than the dream that HTML5+JavaScript is.
  • It is quite surprising that, up until now, no one has thought of using a bytecode solution, that guarrantees portability and performance.

    We have gone from the one extreme, i.e. an interpreted dynamic language, to the other extreme, i.e. native code. There is a sweet spot in between, that of bytecode, that offers portability and good performance on par with native code, and also better security than native code.

    • by Guspaz ( 556486 )

      Haven't they sort of? Google plans to use LLVM to make it portable (an intermediate form that can be translated to different instruction sets as needed), Microsoft uses CIL with Silverlight (which as much as the Linux community might not like it, is opensource and supported by the two top desktop platforms), Java has their own thing going...

      • But there is not a web bytecode standard. And I think LLVM cannot be used for JIT.

        • by Guspaz ( 556486 )

          If you can natively execute LLVM after an initial translation step, why would you want to JIT it?

  • Unfortunately I get the message "requires an OpenGL card" on Windows XP SP3 with an NVidia GTX260, which definitely has working OpenGL. I've seen reports of this problem on MacOS too.

    Hope Supergiant Games can fix this - since this is a web-delivered application, I'd hope they can grab hardware/OS details, with user permission, to help in resolving the issue.

  • Think of how most developers are using Javascript nowadays: it's a target language for their compilers.

    Whether the source was Java (GWT compiler) or Javascript itself (YUI compressor, Google closure compiler) the fact remains that what browsers are given to run is not what the developers wrote. Which is standard practice in the software business (it's called compilation) and for good reasons.

    Now, JS makes for a poor machine language. So we could either beat around the bush with an intermediate bytecode la

  • He said Google wants to bring native applications to the Web for performance and security reasons,

    Perhaps it's just me and the security advantages of running native code instead of JS or anything on the JVM are immediately obvious to everyone else, but this sounds like Google is somewhat out of touch nowdays and lets marketing people "sell" the technology decisions to geeks...

  • 'What would it be like if we could run native code inside the browser..."

    This sounds awesome. Maybe I will finally be able to run a browser inside my browser.

For God's sake, stop researching for a while and begin to think!

Working...