Slashdot Mirror


WebGL Standard To Bring 3D Acceleration To Browsers?

Several sources are reporting that while native audio/video support has been dropped from the HTML 5 spec, the Khronos Group has released a few details about their up and coming WebGL 3D acceleration standard. "The general principle behind WebGL is to offer a JavaScript binding to the group's OpenGL ES 2.0 system, allowing code run within the browser to access the graphics hardware directly in the same way as a standalone application can. As the technology would rely solely on JavaScript to do the heavy lifting, no browser plugin would be required — and it would be compatible with any browser which supports the scripting language alongside the HTML 5 'Canvas' element."

173 of 239 comments (clear)

  1. i for one ... by neonprimetime · · Score: 4, Funny

    >>> Does WebGL sound like your dreams come true, or are you frightened by the thought that all those hideous Flash-only marketing pages will now have access to 3D acceleration?

    ... am frightened

    1. Re:i for one ... by isama · · Score: 1

      How about a simple plugin like flashblock? in this case GLblock.

    2. Re:i for one ... by fuzzyfuzzyfungus · · Score: 2, Informative

      Since the GL wouldn't be a plugin; but rather javascript accessible, you'd probably want something along the lines of a greasemonkey script that stripped all references to webGL from site scripts before execution. Not total rocket surgery; but could be tricky if you want webGL features and want to avoid the webGL ads. On the plus side, adblock-style URL based blocking would still work, since(unlike flash blobs) the webGL stuff would just be part of the HTML/javascript/CSS of the page...

    3. Re:i for one ... by ojintoad · · Score: 2, Funny

      I already have enough trouble shooting the monkey in 2d. I'll never win that free IPod now.

    4. Re:i for one ... by isama · · Score: 1

      But it would be nicer if it would edit the js so that the user could still start the webGL code by clicking a button or something ala flashblock. That way the user can decide weaher something is an ad or not :)

    5. Re:i for one ... by Lord+Bitman · · Score: 1, Insightful

      Flashblock is horribly inadequate. I'd prefer a solution that didn't involve "yes, I've wasted your bandwidth and other resources loading this flash for you- OH CRAP WAIT, IT'S FLASH! I'll tell it to go away now..."

      --
      -- 'The' Lord and Master Bitman On High, Master Of All
    6. Re:i for one ... by simcop2387 · · Score: 1

      either that or an option in the browser to disallow it or allow it based on the site, ala noscript, just a little more fine grained.

    7. Re:i for one ... by jibjibjib · · Score: 2, Informative

      Flashblock doesn't load the flash content until you click it.

    8. Re:i for one ... by BitZtream · · Score: 1

      The funny part is that all those flash-only marketing pages could already have OGL access if anyone wanted it. Theres nothing stopping Flash version 152123112.51 or whatever they are up to this week from supporting OpenGL if anyone actually wanted it.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    9. Re:i for one ... by Lord+Bitman · · Score: 1

      Flashblock removes the flash from the page, then adds it again after you click it. All of this happens while the page is loading, I think before the firing of the "onload" event- usually. it's a race condition, and it often leaves you with flash "loading, then unloading". It's not "flashblock doesn't load the flash until...", because flashblock is not responsible for loading the flash plugin- firefox is.

      How to tell that this is happening:
        1) Go to a large page which has a flash that plays sound as soon as it loads. The sound will start briefly, then stop when flashblock unloads the flash.

        2) Use ubuntu karmic, which has a broken flash plugin that crashes almost every time it is loaded. Notice the "hey, this thing's crashed!" popups that appear even though the flash is "blocked"

      --
      -- 'The' Lord and Master Bitman On High, Master Of All
  2. Could someone explain... by 93+Escort+Wagon · · Score: 1, Interesting

    ... who the Khronos Group is, exactly? The linked article refers to them as 'a consortium', but I've never heard of them.

    Basically I'm wondering if this is any different than my friend Jim announcing a web standard.

    --
    #DeleteChrome
    1. Re:Could someone explain... by Anonymous Coward · · Score: 1, Informative

      The khronos group is a working group behind the opengl standard iirc

    2. Re:Could someone explain... by e4g4 · · Score: 4, Informative

      read about them...here They appear to be the people who run the OpenGL standard; Apple, Intel, and several others are members.

      --
      The secret to creativity is knowing how to hide your sources. - Albert Einstein
    3. Re:Could someone explain... by pburt · · Score: 1
    4. Re:Could someone explain... by fuzzyfuzzyfungus · · Score: 1

      The Khronos Group is the body behind the (current) further development and standardization of OpenGL. In terms of getting this adopted on the web, the support of the browser guys is what counts; but Khronos is the standards group of note behind OpenGL.

    5. Re:Could someone explain... by 93+Escort+Wagon · · Score: 1

      Thanks to all for the replies and Google proxy searches. I guess I should have been more direct, though, and simply said:

      Shouldn't Slashdot submitters or editors provide an explanatory link when referencing a group/individual when it's probable a large number of readers won't have a priori knowledge of the group/individual? Alternatively, if I'm going to have to do some background research anyway - then a submission like this could be distilled down to the single sentence "The Khronos Group did something interesting today" with no further explanatory text. I'm sure in Googling the group, I'd quickly find the interesting item on my own.

      --
      #DeleteChrome
    6. Re:Could someone explain... by Anonymous Coward · · Score: 1, Funny

      I see Google and Opera as members as well.

    7. Re:Could someone explain... by beelsebob · · Score: 2, Informative

      Simple answer, yes, the editors should do that. But, in this case, no such thing has happened. The Khronos group is an organisation that slashdotters almost all know as well as the ISO or IEEE.

    8. Re:Could someone explain... by MemoryDragon · · Score: 1

      Yepp we again then can expect another standard which probably every browser vendor will integrate except microsoft which once it is standardized will roll its own web d3d...
      Been there done that, read up about SVG, CSS 2.0, transparent PNGs, Flash/Silverlight, Corba, OpenGL etc...

    9. Re:Could someone explain... by sam0vi · · Score: 1

      Welcome to Slashdot and the Internet! (He must be new here, since he doesn't know about Google)

      --
      When my Karma level reaches 0 I feel in piece with the Universe
    10. Re:Could someone explain... by sam0vi · · Score: 1

      You REALLY must be new here.

      --
      When my Karma level reaches 0 I feel in piece with the Universe
    11. Re:Could someone explain... by zobier · · Score: 1

      Google's O3D plugin

      is available in Internet Explorer, Firefox, Chrome, and Safari and works on any Linux, Mac, and Windows computer that meets the minimum hardware requirements.

      --
      Me lost me cookie at the disco.
    12. Re:Could someone explain... by MemoryDragon · · Score: 1

      Well the plugin situation worked excellently for svg, didnÂt it?

  3. Javascript and direct hardware access. by Tackhead · · Score: 4, Funny
    What could possibly go wrong?

    What's next, a way to make web browsers faster by making /dev/kmem remotely writable?

    1. Re:Javascript and direct hardware access. by BuR4N · · Score: 3, Interesting

      "What could possibly go wrong?"

      WebGL is based on OpenGL ES and together with javascript bindings its a really neat way of expand the usage of a browser without the need for a multitude of different plugins (each coming with their problems and security issues). Standards is good for you, and to make certain applications we will need 3D directly in the browser (I'm not just thinking geek stuff here, lots of stuff like you need a standalone program for today could run directly in the browser, planing your home, drag around those furnitures and when your happy, just click order !).

      --
      http://www.intellipool.se/ - Intellipool Network Monitor
    2. Re:Javascript and direct hardware access. by BikeHelmet · · Score: 1

      This isn't such a bad idea, to be honest. OpenGL shaders can be made using almost any language in existence, including(but not limited to) C/C++, Java, Python, Ruby, etc. etc.

      I can see more problems with letting a website block keyboard presses and mouse buttons, and that doesn't seem to be hugely abused in Firefox.

      I do hope there's some sort of filtering for malicious content. Up until now OpenGL has been run from "trusted" programs that already have full access to your computer. I remember a while back when I messed the order on some OGL calls, it completely froze the rendering thread. (by "design" - not a "bug" :P )

    3. Re:Javascript and direct hardware access. by ivoras · · Score: 5, Insightful

      It's "direct hardware access" in the same sense as the 2D accelerated DrawRectangle() is "direct hardware access".

      --
      -- Sig down
    4. Re:Javascript and direct hardware access. by CarpetShark · · Score: 1

      What could possibly go wrong?
      What's next, a way to make web browsers faster by making /dev/kmem remotely writable?

      Next, a way for HTML emails to crack your encryption using your GPU.

    5. Re:Javascript and direct hardware access. by MemoryDragon · · Score: 1

      Actually it already is there to some degree what do you think is the dom node and images etc... they all have hooks somewhere into the hardware.
      The way I see it javascript will only be used for scripting on the 3d scenegraph and 3d elements themselves. There is no more hardware connectivity than what already is given with the javascript/dom connectivity.

    6. Re:Javascript and direct hardware access. by aaaaaaargh! · · Score: 1

      Standards is good for you, and to make certain applications we will need 3D directly in the browser (I'm not just thinking geek stuff here, lots of stuff like you need a standalone program for today could run directly in the browser, planing your home, drag around those furnitures and when your happy, just click order !).

      *Sigh* Apparently, I'm the only one left that really doesn't want to run applications in my browser but simply uses a web browser for browsing the web. If I want an application, then I want to run it as a ordinary executable stored on my machine, want to have full control over its installation, deinstallation, and particularly full control over when the application is started. I know it sounds 80ies, but look, it has some advantages...

  4. The Khronos Group by MediaStreams · · Score: 3, Informative
  5. Port 80 by Anonymous Coward · · Score: 2, Insightful

    Does EVERYTHING need to be reinvented (poorly) on port 80? Really!!!???

    1. Re:Port 80 by tepples · · Score: 3, Insightful

      It does when firewalls block everything but ports 80 and 443 and software restriction policies block the installation of any software. There's just a lot less bureaucracy to deploy a web application than a desktop application nowadays.

    2. Re:Port 80 by TheRaven64 · · Score: 2, Funny

      Just wait. Next week we're going to announce a binding of the X11 protocol to XML over HTTP. Then you can have rich applications displayed remotely in your browser, using a JavaScript X server using the canvas tag. There is a small amount of overhead created by having every binary X11 message encoded in XML, but we think it's worth it because it runs in your browser.

      --
      I am TheRaven on Soylent News
  6. For the love of god replace javascript by presidenteloco · · Score: 3, Interesting

    Is anyone at all working on something that is not as loosy-goosy and hokey as javascript for client-side computing?

    I've used Adobe ActionScript (stricter variant of JavaScript) and it is getting a little better, but why do we think "oh, it's the client-side. Let's go back to (essentially) Basic for programming."

    (Still moping I didn't get my Applets.)
    (Ok, Java is a bit too ugly (accessor hell)
    but a language with a little rigidity, checking, and simplicity to it wouldn't hurt, would it?)

    --

    Where are we going and why are we in a handbasket?
    1. Re:For the love of god replace javascript by Anonymous Coward · · Score: 3, Insightful

      the limitation is you, not the language.

    2. Re:For the love of god replace javascript by presidenteloco · · Score: 1

      Sorry. What can't you trust on the client, specifically?

      Also, what you are saying is going against the trend, which is to richer functionality on the client for better interactivity, while getting data and
      some heavy-duty processing and identities etc from the server.

      --

      Where are we going and why are we in a handbasket?
    3. Re:For the love of god replace javascript by Hurricane78 · · Score: 5, Insightful

      While JavaScript is not perfect, it is actually a nice little language. It's just that every retard can "program" in it, and then thinks because he wrote a for loop, he is entitled to an opinion about it.

      Few people actually know how to program properly in JS. And the only problem is that JS is too forgiving. Just as the rendering engines for (X)HTML and CSS. But that was the original point. And it's not that bad of a point either.

      Because simple scripts are way easier than people think. Every person who can play a shooter, puzzle game, or configure some stuff on his computer, can write acceptable scripts. And even total noobs can write bad ones. I think that is a nice thing.

      And this is why you can ignore the (non-pro) masses, ranting about JS.

      If it were for me, the scripting interface in browsers would have to support multiple high-level languages anyway: Python, Haskell, Java and Ruby would be those that I'd introduce. But others might want Erlang, Ocaml, and maybe even C++. Why not? If the API is clean, the interpreters work as expected, and everything is sandboxed as it should anyway...

      --
      Any sufficiently advanced intelligence is indistinguishable from stupidity.
    4. Re:For the love of god replace javascript by John.P.Jones · · Score: 2, Insightful

      The client can't trust the server any more than the server can trust the client. Powerful tools and healthy suspicion is needed on both ends, always has.

    5. Re:For the love of god replace javascript by rsborg · · Score: 2, Insightful

      but a language with a little rigidity, checking, and simplicity to it wouldn't hurt, would it?)

      Given the history of the web, browsers and multiple companies injecting their own funky little APIs and features, I think a strictly-typed, more "structured" language wouldn't have cut it.

      ...and you're right, a VM based solution like Java clearly didn't work back in the 90s when PCs were too slow to handle it.

      --
      Make sure everyone's vote counts: Verified Voting
    6. Re:For the love of god replace javascript by gbjbaanb · · Score: 1

      but a language with a little rigidity, checking, and simplicity to it wouldn't hurt, would it?)

      nope. lets get a simple C JIT compiler into the browser! It wouldn't have to do everything, just compile function by function as needed. These functions could be called from javascript so you'd have speed and scripting in one small tidy package - its not as if the C runtime is a large library by today's standards.

    7. Re:For the love of god replace javascript by spiffmastercow · · Score: 2, Insightful

      You know, if I were a damned good sculptor I could probably make a great statue with only a block of wood and a chainsaw... But I doubt the chainsaw would be my tool of choice. That's the problem with javascript -- we have no choice but to use it. Of course, the DOM is the real problem, but really, when have you ever used javascript for something that didn't also involve the DOM, or vice versa?

    8. Re:For the love of god replace javascript by Unoti · · Score: 1

      Most of the pain of the DOM can be circumvented by using JQuery. Try it, grok it, and never think of Javascript the same way again. It makes it more of a declarative thing, like SQL. Super small and short code. I wouldn't want to write everything like this, but it's amazing for what it's designed for.

    9. Re:For the love of god replace javascript by pjt33 · · Score: 1

      And the only problem is that JS is too forgiving.

      Tool support for debugging still has a way to go. And since weak vs strong typing is a religious war it would be nice to have an alternative for those on the strong typing side.

    10. Re:For the love of god replace javascript by shutdown+-p+now · · Score: 1

      While JavaScript is not perfect, it is actually a nice little language.

      From a language design POV, it's anything but. The issue with scope of local variables alone - you know, the one when you declare a variable inside a block that's not the topmost in a function - is something worth killing over. The only other language that does it in the same dumbfucked (sorry, but there really aren't any better word to describe this) way is - was - VB6, but VB6 was in a family of itself, so you kinda expected things to be different there, whereas JavaScript pretends to be a C++/Java lookalike at least syntactically.

    11. Re:For the love of god replace javascript by MemoryDragon · · Score: 2, Interesting

      Dont get me wrong I do most of my work with javascript, and I know the inner depths of the language. And as far as I can see the language itself is as powerful as every other dynamic language like ruby or groovy for instance. But the designers missed a few things, which then have to be simulated and sometimes due to having a simulation of those language constructs can cause cross implementation collisions. Those would be easy to fix, introduce real classes and inheritance or simply make a standard on how to do those things.

      Introduce real namespaces instead of having to hack them via map/objects, and I think most people would be happy!
      The inheritance issue is probably the most pressing because that is one of the 2 key areas which constantly causes cross library collisions the other one being the overriding of base objects and extending them and hijacking of something like $

      But I agree the language itself has been somehow misjudged in the past, because it is so easy to hack a quick script, real javascript if you write big systems with it is almost as hard to handle as C++ and as flexible as Lisp or Smalltalk!

    12. Re:For the love of god replace javascript by SendBot · · Score: 1

      Tool support for debugging still has a way to go. And since weak vs strong typing is a religious war it would be nice to have an alternative for those on the strong typing side.

      Firebug is an excellent JS debugger!

      JS has its types (number, string, etc) and variables are loose. Knowing what those types are and how to use them makes JS a compelling language for a strong-typer like myself.

    13. Re:For the love of god replace javascript by IamTheRealMike · · Score: 1

      Is anyone at all working on something that is not as loosy-goosy and hokey as javascript for client-side computing?

      Why yes, yes they are. Note that these technologies are targeted precisely at weaknesses of JavaScript whilst retaining the things people like about the web - the security, the lack of installation/uninstallation, speed of download, the flexible rendering engine etc.

    14. Re:For the love of god replace javascript by TheRaven64 · · Score: 1

      but why do we think "oh, it's the client-side. Let's go back to (essentially) Basic for programming."

      I don't know. Why, when you have a late-bound dynamic language with a pure Self-style object model and first-class closures are you writing code that looks even remotely like BASIC, a language which only provided simple (and very optional) support for procedural programming? As the other poster said, I think the problem might be you, not the language.

      --
      I am TheRaven on Soylent News
    15. Re:For the love of god replace javascript by Xyrus · · Score: 1

      Running C++ in a browser app? Can't see that one blowing up in anyone's face.

      Of course, the big probale is you need a language that can be made to run in a very secure sandbox. Java, python, and related languages could be made to do so with some work. They run on VM's or have an interpreter. But C++? If you're talking about creating a new implementation that runs in an interpreted/virtualized/sandboxed environment and has built-in memory management thrown in, then that might be a possibility. But then again, why would you want to do that when there are so many other ones out there.

      ~X~

      --
      ~X~
    16. Re:For the love of god replace javascript by Abcd1234 · · Score: 1

      but why do we think "oh, it's the client-side. Let's go back to (essentially) Basic for programming."

      If, by "Basic", you mean a prototype-based object oriented, functional programming language. :rollseyes:

    17. Re:For the love of god replace javascript by Hurricane78 · · Score: 1

      How can you say that you understand the depths of the language, and yet in the same paragraph ask for the implementation of "real classes and inheritance"?

      I understand that most people think that this is how it should be. But it's off the point.

      JavaScript is a prototype-based language. Prototypes replace classes, and basing something on a prototype replaces inheritance.
      I find it quite ingenious, because it merges two concept (classes and inheritance) into one more complete concept. In my eyes it gives you more than pure classes, because you can have complex instance data for "initialization", and even modify the base object after instantiation to influence all the children. Plus many other cool things. All with just one single concept.
      Very elegant!

      I maybe agree with real namespaces. And I thing JavaScript 2.0 has them. But, coming from Haskell, I found no big need for namespaces. Because of the feature of closures. Which also are essentially implicit namespaces everywhere. But the ability to make them explicit certainly is an idea.

      I agree that when you use hacked libraries from others who also did not understand the implications of meddling with base objects, that you can get in messy situations. But I think I remember a function to check if the object is what you expect it to be.

      We really need some new (old) languages for web programming. :D

      --
      Any sufficiently advanced intelligence is indistinguishable from stupidity.
    18. Re:For the love of god replace javascript by Hurricane78 · · Score: 1

      The funny thing is, that when you walk both extremes, you end up with them coming back together again. And the result is the Haskell type system: Incredibly strong/hard, yet you usually do not have to specify type signatures (or even think much about them).

      But I agree that I still miss something like Delphi/JBuilder/NetBeans for JavaScript+(X)HTML+CSS+DOM+(PHP/Java/Haskell/etc.)+SQL.
      One very impressive approach was HAppS: The Haskell application server. The idea is, to replace that huge stack of languages/services/layers by as little of them as possible, integrating all of them. Everything server-side is in there. No need for Apache, a database server, etc.
      Now we only need to integrate the front-end / client-side into it too. ;)

      --
      Any sufficiently advanced intelligence is indistinguishable from stupidity.
    19. Re:For the love of god replace javascript by MemoryDragon · · Score: 1

      Actually you are wrong in your assumption, prototypes
      are just are the exposed method table compilers usually hide, which adds flexibility because you can extend a lot of things that way but it has pitfalls.

      But that was not my issue, my issue was that everyone is enforced to add inheritance on top of prototypes and because there is no standardized way some do it wrong and some implementations collide and some are outright buggy.

      Sorry to say that but saying that prototypes are there is no justification to leave the high level construct out. That is like if you would say you dont need inheritance in C++ because you can gain access to the virtual method table of the compiler anyway or you can simulate it by using function pointers and your own arrays and can add it on top of it.

      From most cases I have seen inheritance was added on top of it in almost any big library, which means there is something missing, and to the worse every library did it differently and even worse the implementations can collide because if one library tries to inherit from an object which has inheritance done by another you are bound to open a real mess!

      Other example, I dont need high level languages because I can roll my own in assembler, is pretty much the same mentality.
      Sorry to be harsh about it, but the insistence that prototype is all you need is outright wrong for the real world use and pretty much every big library for javascript in existence prooves it.
      They usually add following things:
      A shorter notation for

      document.getElementById
      inheritance
      mixins
      and standardized namespaces within the scope of their domain with helper constructs which hide the implicit map hack. (well the last one is not done by prototype which just hijacks the entire javascript base)

      All of this ins indication enough that something is wrong in the approach of providing prototype constructs alone!

      And the funny thing other languages dont have a problem to expose constructs like the prototype and also have a real inheritance on top of it (check out groovy or ruby, or I think even smalltalk), it is always the javascript keep the language clear proponents who want to have it the only way while others like Adobe already have moved on in ActionScript!

    20. Re:For the love of god replace javascript by presidenteloco · · Score: 1

      What I object to (no pun intended) in Javascript has nothing to do with those nice features, which by the way have piss-poor versions of themselves in Javascript (no proper closures etc.)

      Excuse me if I speak at a hopelessly general level in the following. Don't have time to write a paper on it with examples.

      The problem is sloppiness in language design, which provides too many gratuitously different ways to do essentially similar things when programming. Javascript has flexibilities where they are not needed, and this encourages many different programming styles that are hard to grok for practitioners of another style. Javascript encourages dialect ghettos.

      If a language provides a small and mutually orthogonal set of powerful constructs which fit well together, people tend not to have to invent their own meta-programming systems to get things done.

      Javascript is kind of the opposite philosophy: Just throw a random bunch of tools in the back of the pickup, and let's be off. Python and Ruby suffer from some of the same excessive casualness in the fundamentals.

      In short, Javascript and Python seem to be languages designed to allow people to experiment (wildly) about paradigms for programming, while not providing a solid and elegant way (e.g. Haskell functors) of packaging up the result of such experimenting to make it easily re-usable.

      I prefer a language that expresses a coherent opinion about aspects of your programming style while you use it, so that a community of developers who actually understand each others' styles and idioms (and code) develops.

      --

      Where are we going and why are we in a handbasket?
    21. Re:For the love of god replace javascript by Abcd1234 · · Score: 1

      If a language provides a small and mutually orthogonal set of powerful constructs which fit well together, people tend not to have to invent their own meta-programming systems to get things done.

      And yet the power of Lisp, Haskell, and Smalltalk, three incredibly elegant languages, is in the ability of the developer to build their own "meta-programming systems". Lisp has it's incredibly powerful macro system, allowing for things like the CLOS. Haskell has it's system of monads which allows things like Monadic parsers and so forth, allowing for incredibly powerful embedded sub-languages for accomplishing tasks. And Smalltalk doesn't even have an 'if' or 'while' statement, instead encouraging flow control and other constructs to be built into the class library. Meanwhile, all three languages allow one to mix programming models freely (Lisp and Smalltalk both support OOP, functional, and procedural development, while Haskell has superb support for pure, lazy, functional development while allowing one to "package up" procedural code in safe little lockboxes where it's needed).

      So, just looking at that list, I wonder if it's maybe *you* that has the problem, rather than Javascript? I mean, Javascript is really just Self for the web, and Self is just Smalltalk without classes, so if you've got a problem with Javascript, then I can think of very few languages that would satisfy your (incredibly unreasonable, overly picky/anal/restrictive) requirements.

      Frankly, I think Javascript's biggest problem is that, unlike Lisp, Haskell, Smalltalk, Ruby, Perl, or Python, JS doesn't have a strong core community that can help provide guidance and dictate standards for development. While all those languages provide a wide array of tools for getting any particular job done (with Perl at the most extreme end), all have communities whose output includes a standardized set of libraries, tools, and documentation, along with coding guidelines and traditions that can help guide new members of the community. And I strongly suspect Javascript lacks such a community because the growth in popularity of the language has been haphazard, and out of necessity, rather than because a core group was driving it's adoption. And I don't see that changing any time soon, unfortunately.

    22. Re:For the love of god replace javascript by sexconker · · Score: 1

      You can't trust SHIT if it comes from the client.

      You can NEVER verify who or where it came from, or how it was generated.

      Yeah, and the trend is shitty sites with shitty security and shitty content and shitty shit.

    23. Re:For the love of god replace javascript by sexconker · · Score: 1

      Yeah, because the server sure asks for my SSL certificate each time I order crap online, right?

  7. Fast enough for web browsing??! by formfeed · · Score: 5, Insightful
    There goes the "fast enough for a little browsing and office apps"-computer. Yes, yes, I know, hardware acceleration will render the pages faster - but more and more sites will include 3d junk.

    Praise be to Moore and his irrefutable law:

    We are doomed to use faster and faster Computers and more and more energy, to read pages that might - content wise- just as well run on gopher.

    1. Re:Fast enough for web browsing??! by Krneki · · Score: 1

      I have an idea, 3DBlock plugin for Firefox.

      Actually, I'm going to register the name.

      --
      Love many, trust a few, do harm to none.
  8. Honestly? by Iwanowitch · · Score: 4, Insightful

    I like this. Why not? It can be expected that web browsers use decent security practices, 3D drivers are already doing a fairly good job of providing a stable API via OpenGL, and everything is floating towards web browsers as new deployment platform, also for games and 3D applications. Better have an open 3D standard than a need of all sorts of plugins where everyone comes up with his own half-working solution. This is the indie game developer's wet dream coming true.

    Of course, that's the best scenario. How it plays out in practice, we will have to see.

    --
    One CS student VS 893 DOS games: Let's play oldies
    1. Re:Honestly? by tepples · · Score: 1

      This is the indie game developer's wet dream coming true.

      No, the indie game developer's wet dream coming true would a mass-market PC marketed to be connected to an HDTV. Then they could get away from the dichotomy of "consoles are for sofa multiplayer, PCs are for indie games".

  9. I've got an idea! by bonch · · Score: 3, Insightful

    Let's abandon decades of fast native APIs and move all our applications to a browser where they will be dependent on the fluctuating feature set of the browser wars, will require programming in JavaScript, and won't have a standard GUI framework to use so that we'll have to code our own from scratch every time as if it's MS-DOS all over again. This way, people will have a pointless, non-native middle-man between their operating systems and their apps!

    I've wanted nothing more than to program 3D in friggin' JavaScript. OUR 3D WEB GAME IS COMING FOR YOU, ID SOFTWARE.

    1. Re:I've got an idea! by SanityInAnarchy · · Score: 5, Interesting

      will require programming in JavaScript

      Why is this a bad thing? Or what would you suggest as a better language?

      Most people who hate Javascript don't really understand it. I qualify that as "most" because a few people do know enough about it to actually have good reasons for hating it.

      won't have a standard GUI framework to use

      HTML is more standard than about any other GUI framework, even if less featured.

      In fact, something to notice -- most people seem determined to style away the standard GUI elements. Below this message, you'll almost certainly see a "Reply to This" button and a "Parent" button, and unless you've disabled your CSS, they probably look nothing like your standard native buttons.

      The issue is that most web designers hate these things, and think they're "ugly". Whether actual users care is up for debate -- they don't seem to have a problem with Google's homepage, for example.

      we'll have to code our own from scratch every time as if it's MS-DOS all over again

      You mean the MS-DOS, where the network was nearly nonexistent, and applications would largely be written in C or assembly?

      I understand your sentiment that the browser feels like a step back, but hyperbole doesn't help your argument.

      This way, people will have a pointless, non-native middle-man between their operating systems and their apps!

      Better this than Java or C#.

      What's more, it's hardly pointless. Or would you rather go back to the days when if you wanted something cool, like the ability to check the weather, receive email, or watch TV, you'd have to download an untrusted (possibly virus/spyware infested) binary .exe, run it on Windows, and hope it doesn't have some weird incompatibility with everything else on your system?

      I much prefer the ability to try out pretty much anything I want, in my browser, without having to download/install anything, or uninstall it later. Worst case, I reload the page, or close the tab. Absolute worst case, I have to kill the browser, but no permanent harm.

      Oh, and they're portable. I can play with the same apps on Windows, Linux, OS X, an iPhone...

      You could argue that the browser isn't the best possible way we could've accomplished that, but those are real advantages it has over the vast majority of desktop apps, especially "fast" ones.

      I've wanted nothing more than to program 3D in friggin' JavaScript.

      Better than programming 3D in friggin' Flash.

      If people are going to insist on taking the Web in this direction, wouldn't you rather it be based on cross-platform open standards?

      --
      Don't thank God, thank a doctor!
    2. Re:I've got an idea! by Lord+Bitman · · Score: 4, Insightful

      HTML+Javascript /is/ the standard GUI framework, that's the point.

      If you want something to be pixel-perfect, oh no, it may look a bit off.
      If you want something to be useful, HTML has been the way to go for at least a decade.
      This, like everything else ever, is not a "let's add this so people can do this" thing, but a "people are doing this, let's make it easier/more standardized by writing down what people are doing and recommending that future browsers be sure to support this"

      And of course, like everything else ever, most people aren't going to code to the low-level, but will use higher-level libraries since they care more about functionality than "control".

      As for "friggin' JavaScript"... what? When I have problems with writing javascript, it's because of IE6 or Firefox-specific bugs, what's your problem with it? Just don't want to share your source code?

      --
      -- 'The' Lord and Master Bitman On High, Master Of All
    3. Re:I've got an idea! by cromar · · Score: 2, Interesting

      What needs to happen is that the OS needs to become more browser-like not vice versa (bare with me here). Modularity and separating the parts of the OS into distinct UI, data, and code structures offers amazing customization and extension (CSS jQuery), and is something browsers do right. How does that apply to the OS, you say? Imagine a modular OS encompassed basically by 1) a semi-p2p database file structure (like the web basically, but not HTML - something closer to XML), 2) modular code er "pieces" - both compiled and script, but seamless from the end user perspective (plug in compilers,etc), and 3) a standardized UI structure, like HTML but as an OS API that uses modules to style UI elements (like CSS). Don't get me wrong - I'm not talking about cloud computing - I'm talking about total API abstraction for the entire OS. The end of applications per se and the dawn of the module. But whatever, maybe I'm just high.

      (Hell, and maybe security should be a fourth modularized component at OS level...)

    4. Re:I've got an idea! by Anonymous Coward · · Score: 3, Interesting

      The very name "JavaScript" confuses uninformed people who assume "Java" and "JavaScript" are the same thing. Despite posting as Anon, I can say I've never had much problem with JavaScript as a standard. (I know, I know. The name is really ECMAscript these days, but who calls it that?)

      The other side of using JavaScript is that it was slow -- so the 'interpreted versus native' argument would come back up, like it did back in the days of Visual Basic versus Visual C++. But with the advances made in the last... what, year? Two years? JavaScript interpretation is fast. Damned fast.

      So I really don't see the problem. But more than anything I'm hoping Adobe finally works in basic 2D (nevermind 3D) acceleration into Flash. Stupid Flash Video redlines my CPU, but I can watch 720p Hi-Def h.264 no problem.

    5. Re:I've got an idea! by sys.stdout.write · · Score: 2, Insightful

      Absolute worst case, I have to kill the browser, but no permanent harm

      I don't think "absolute worst case" means what you think it means.

    6. Re:I've got an idea! by Trillan · · Score: 1

      I looked at a demo of this a few weeks ago, and even in the current state and on a OS the technology doesn't really support yet (Mac OS X 10.5) it's plenty fast enough to be useful.

    7. Re:I've got an idea! by digitalunity · · Score: 3, Insightful

      I miss VRML.

      j/k j/k in all seriousness, the uses for 3D support in a browser is pretty limited I think. I can think of a few corner cases, such as large set data visualization, but for general use, I think it will end up being misapplied everywhere.

      I did some web programming in JavaScript years ago when browser compatibility was a serious problem and I hated it. I've heard it has gotten much better now, but I don't do web design anymore so I don't really care.

      I find myself in agreement with the GP though that there is a general trend of moving traditional desktop applications to web apps in cases where it makes little sense. Developers are working hard to come up with ways to preserve functionality and use these applications even while disconnected from a network. I think the whole thing is an exercise in futility because there will always be people like me who demand snappy, native applications that are locally stored. For security, privacy, responsiveness and other reasons, I don't see myself changing my mind on this topic any time soon.

      --
      You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
    8. Re:I've got an idea! by ClosedSource · · Score: 1

      "HTML+Javascript /is/ the standard GUI framework, that's the point."

      I've never heard of a kludge described as a standard framework. When HTML was designed, Javascript didn't even exist, so clearly nobody designed a framework.

    9. Re:I've got an idea! by masshuu · · Score: 1

      I think the point of this is to help push us from the closed source/buggy/proprietary usage of external libraries a browser must load and use, to having everything already built in the browser.

      You know those rare fancy flash websites 4 years back that are all fancy and stuff?
      Guess what?
      Now you can do the exact same thing without flash, and without raping someones CPU!

      Now as long as i can compile the browser which is suppose to follow standers, i can view any site that makes use of this new technology without worring about having flash for my OS(like x64 or other CPU architectures) or needing an OS which is supported by the library(like silverlight, and saying theres moonlight is like saying megablocks are an ok replacement for legos, well they fit together... sometimes)

      I would love to have all this, cause then i can sift through the code to make sure theres nothing bad in it without pirating swf decompilers or sifting through il code.

      --
      O.o
    10. Re:I've got an idea! by cromar · · Score: 1

      It's kind of hard for me to explain. I envision something like this for the file structure: everything is a URI Such as local.datafile.inventory or com.somehost.someDataFile.someField.value. The p2p part is just for mirroring and caching really... but that's probably too fantastical and impractical (I couldn't say at this point). So all data is in a uniform format (like XML or whatever would be most appropriate). Then every code piece of the OS is modular so that you can switch out, say the HTML rendering engine, so that the browser isn't a separate application - the OS would rely on abstract modules that can be anything as long as they implement the appropriate interface. That's an example - it would be the same for text editing, image viewing, etc. Each datafile would be attached to a description of that interface - something simple where the data tells you what it should be opened with (what abstract interface it requires) and you can install any module that implements that interface. All code would be separated into these modules - even JIT compilers, whatever the equivalent of the UNIX ELF stuff would be, etc. Then, you would have files that styled the data files. Something like CSS, but more suited to a real UI - the best part of this is that all the data is there, detached from the styling language, so even the presentation of the UI could be modular - you could choose from windowing, touch screen, a sugar like UI, emacs, whatever, all by changing the "CSS" files. (And all UIs definitely suck at this point - I can't wait to see what replaces windowing.)

      Well, anyway, hope that makes a bit more sense. Thanks for the links - that should be some good brain candy for a bit.

    11. Re:I've got an idea! by foniksonik · · Score: 1

      Typically the performance issue in Flash is that designers choose to use compositing at run time so their effects can be dynamic based on user input. Video despite requiring heavy computation to decode is always the same. This makes it easier to optimize and offload to a dedicated processor.

      --
      A fool throws a stone into a well and a thousand sages can not remove it.
    12. Re:I've got an idea! by BitZtream · · Score: 1

      What's more, it's hardly pointless. Or would you rather go back to the days when if you wanted something cool, like the ability to check the weather, receive email, or watch TV, you'd have to download an untrusted (possibly virus/spyware infested) binary .exe, run it on Windows, and hope it doesn't have some weird incompatibility with everything else on your system?

      God I hate this argument. THATS WHAT THE OS IS FOR, which no one seems to understand or willing to fix. We just keep adding more buggy layers that don't actually fix the problem.

      We put OSes in VMs as if its a security fence. If the OS can't be made secure, the VM can't either and adding more code is always less secure and has more bugs. ALWAYS.

      We put browsers on top of OSes as if its a security fence. If the OS can't be made secure, the VM can't either and adding more code is always less secure and has more bugs. ALWAYS.

      Everytime someone comes up with some new middle man it gets worse, not better, and does nothing but add another false sense of security to people who don't understand.

      Your browser can't do any the OS doesn't allow it to do. Web apps are portable because we've started to demand that our browsers function with a common set of code and APIs, you can do the same for the OS you know? In fact its been done before, but done just well enough to please pointheaded bosses and still be too much of a pain in the ass to be useful. You may have heard of it, Posix.

      I would rather not take the web direction and skip that entire bullshit layer and do it at the OS.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    13. Re:I've got an idea! by BitZtream · · Score: 1

      You and I have different ideas of 'standard'.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    14. Re:I've got an idea! by msh104 · · Score: 1

      1. Displaying Virtual Houses before they are build or sold.
      2. Getting an 3d walk in a disco before going out.
      3. cool statistics effects?

      Anyway,

      While applications on the desktop will always have their place, webapps have many advantages as well. they can be used everywhere, on every platform, you have your data stored on a single place that is much easier to backup. Much easier to upgrade. Support knows everybody is viewing the thing, you can outsource the whole thing, and many other motives.

      For these reasons alone, it makes more then sense to move them to the web.
      This desire is recognized by the html5 spec.
      offline store, canvas, video, sound and now perhaps even web3d are among the last components missing for web apps to really kick sky high.

      Sure there will be desktop apps for a long time, but their are good motives to work on web apps as well.

    15. Re:I've got an idea! by TheRaven64 · · Score: 1

      Why is this a bad thing? Or what would you suggest as a better language?

      Yes, it's a bad thing and, no, I wouldn't suggest any one better language. Programming is about choosing the right tool for the job. Sometimes that tool might be JavaScript, sometimes it might be a different language.

      Most people who hate Javascript don't really understand it. I qualify that as "most" because a few people do know enough about it to actually have good reasons for hating it.

      I don't hate JavaScript, although the complete lack of integer support and the bizarre semantics of closures mean that it's a pain to implement and a pain to use. I've written a compiler for a dialect of JavaScript, but decided to break the spec in a few places because it was too ugly (and my implementation wasn't aimed at the web, so legacy compatibility was not an issue). Even if you like JavaScript, that doesn't make the idea of forcing its use for everything a good one.

      Or would you rather go back to the days when if you wanted something cool, like the ability to check the weather, receive email, or watch TV, you'd have to download an untrusted (possibly virus/spyware infested) binary .exe, run it on Windows, and hope it doesn't have some weird incompatibility with everything else on your system?

      As opposed to downloading an untrusted script, running it in your browser, and hoping it doesn't have some weird incompatibility with everything else in your system (i.e. your JavaScript runtime is compatible, it doesn't use any non-standard [or even standard] DOM functions your browser doesn't support, and so on)? A modern OS provides sandboxing and a browser provides sandboxing. We've seen a lot more exploitable bugs in browser sandboxes than OS ones, because they are much more complicated to implement.

      --
      I am TheRaven on Soylent News
    16. Re:I've got an idea! by sys.stdout.write · · Score: 1

      I don't disagree with your general sentiment but I am somewhat puzzled with the post you chose to object to.

      The parent's argument asserted that the worse thing that would happen in his scenario would be the browser crashing, and I simply pointed out that this was being a bit optimistic. Browsers of course are more secure than random executables you download off the Internet, but the "absolute worst case" in this situation is certainly not the browser crashing.

      I used a meme to convey this point. Who cares? Furthermore, the comment scored a 2; it's not as if it was considered the crowning jewel of Slashdot comments.

      In general though, I think you would do well to remember this XKCD comic.

      Thanks.

    17. Re:I've got an idea! by SanityInAnarchy · · Score: 1

      Well, true, worse than that would be a browser vulnerability. But once we start talking about vulnerabilities, that's no worse than any other system, and in fact, a good deal better.

      Put another way, suppose I download a program and let it run locally. How should I protect the rest of my system from it? I could run it as an unprivileged user, but it could always find a local root exploit, or it could potentially read files it isn't supposed to read (modern Linux tends to create files with mode 644, thus world-readabale), or it could fill up my hard drive, or...

      So, I'd have to put it in its own private virtual machine in order to be completely safe. At that point, I wonder if the browser might be faster after all -- and certainly, there could be a vulnerability in the VM just as easily as in the browser.

      The point I'm making is, the browser is the best we've got.

      --
      Don't thank God, thank a doctor!
    18. Re:I've got an idea! by SanityInAnarchy · · Score: 1

      I hope that was sarcasm...

      If not, care to tell me the ways in which Visual Basic is better than Javascript?

      --
      Don't thank God, thank a doctor!
    19. Re:I've got an idea! by SanityInAnarchy · · Score: 1

      in all seriousness, the uses for 3D support in a browser is pretty limited I think.

      Just for fun...

      How about a free-to-play MMO? No download required, just go to this URL and you're in.

      I think it will end up being misapplied everywhere.

      I'd rather this be misapplied than Flash.

      I find myself in agreement with the GP though that there is a general trend of moving traditional desktop applications to web apps in cases where it makes little sense.

      Examples, please?

      Developers are working hard to come up with ways to preserve functionality and use these applications even while disconnected from a network.

      Seems to me, they've succeeded. Google Apps can be used offline.

      I think the whole thing is an exercise in futility because there will always be people like me who demand snappy, native applications that are locally stored.

      You're not the target market.

      In particular, what you're demanding is stupid:

      snappy, native applications that are locally stored.

      If you didn't have that requirement, I'd agree with you. But since when do end-users care about whether an application is "native" or not? If I was doing desktop development, I'd probably still want to use Ruby, or something similar.

      As an end-user, if you're sane, what matters to you is what the application does, and how well it does it, not implementation details like whether the UI is written in HTML, MFC, XUL, Qt, whatever. As long as it works, right?

      One example: Do you use Firefox? The Firefox GUI is written in XML (XUL), rendered by Gecko, the same engine that renders HTML.

      For security, privacy, responsiveness

      These are good reasons.

      So, in other words, you'd have no problems with a web app, so long as it was secure, private, and responsive -- which would probably mean it would have to run locally, and/or connect to a server you control.

      --
      Don't thank God, thank a doctor!
    20. Re:I've got an idea! by digitalunity · · Score: 1

      Well yeah actually it does matter how the application is implemented. Native code will always be much faster than scripted. I can imagine a few corner cases where this might not be true, but those exist in a vacuum and wouldn't ever happen.

      I'm a hobbyist software developer working on a large project right now and I chose Qt for cross-platform development. A lot of people tout web based software as "write once run anywhere" but in practice that isn't really the case. It needs to be able to access PostgreSQL and SQLite databases, as well as visualize the results of a simulation of a specific industrial machine. If I tried to make it a web based app, I would probably be over 100k lines of code instead of the 15,000 I'm at now. Not to mention, I'd still need something to handle my database access and provide results through JSON and the database access would be platform dependent. Clunky eh? With Qt, I literally have 1 codebase with almost no platform specific code and it works seamlessly in Windows and Linux. Haven't tried it on a Mac, but I bet it would work just fine.

      --
      You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
    21. Re:I've got an idea! by DaVince21 · · Score: 1

      Joke's too obvious.

      --
      I am not devoid of humor.
    22. Re:I've got an idea! by DaVince21 · · Score: 1

      Native code will always be much faster than scripted. I can imagine a few corner cases where this might not be true, but those exist in a vacuum and wouldn't ever happen.

      Haven't you read the news? In some cases, JavaScript beats C in speed nowadays. It's been benchmarked and tested in several practical situations.

      --
      I am not devoid of humor.
    23. Re:I've got an idea! by DaVince21 · · Score: 1

      Did you read the summary? "while native audio/video support has been dropped" which can also be read as: "your 'open standards' have been hijacked".

      Not quite true. These standards had only been dropped because there were crazy discussions going on whether to pick h.264 or Ogg Theora, and in the end W3C said "screw it, figure it out yourself". That means neither the proprietary h.264 nor the open Ogg Theora has won this "battle".

      --
      I am not devoid of humor.
    24. Re:I've got an idea! by DaVince21 · · Score: 1

      Back then, duh, but DOM has been around for a long time now.

      --
      I am not devoid of humor.
    25. Re:I've got an idea! by SanityInAnarchy · · Score: 1

      THATS WHAT THE OS IS FOR, which no one seems to understand or willing to fix.

      I understand. What you may not understand is that "OS" is incredibly loosely defined, and in fact, we do have a case of the browser becoming an OS -- Chrome OS.

      If the OS can't be made secure, the VM can't either

      It's much easier to make a VM secure than an OS, for the simple reason that, as you say,

      and adding more code is always less secure and has more bugs. ALWAYS.

      I wouldn't agree with "always", because nothing is ever "always". But consider: The VM itself is less code than an OS. An individual layer, especially one as isolated as a VM, can be secured independently of other layers -- the complexity of code running inside the VM, or code the VM might run inside, doesn't change how difficult (or not) it is to secure the VM. And if the VM is secure, the code running inside the VM won't be able to break out of it.

      We put browsers on top of OSes as if its a security fence. If the OS can't be made secure, the VM can't either

      Not true.

      As a trivial example, consider DOS. From DOS, we could run loadlin, and load an entire Linux OS. Would you then argue that this Linux can't be secure, since DOS wasn't secure?

      Granted, if the OS provides additional security holes in code that the browser uses, that makes the browser less secure. Also, the OS could have holes that have nothing to do with the browser -- for example, a ping of death.

      But if the browser is doing its job, barring deliberate malice on the part of the OS, the code running inside the browser won't be able to affect anything outside the browser, or any other tabs in the browser -- in general, anything it's not supposed to.

      If you still disagree, can you come up with a reasonable example of how an insecure OS could make a secure browser running inside it allow a web app to escape?

      Your browser can't do any the OS doesn't allow it to do.

      All modern OSes allow browsers to be Turing-complete. So again, barring something deliberate on the part of the OS -- like, say, scribbling all over the browser's address space -- a browser can do anything it wants, within itself. The only thing the OS could prevent it from doing is fetch data from the outside properly, or render properly, and I don't know of any OS that currently screws this up.

      Web apps are portable because we've started to demand that our browsers function with a common set of code and APIs, you can do the same for the OS you know?

      No, I can't. I can't do anything; I'm one person.

      The browser has pretty much evolved organically into an application platform. For something native to replace it, you'd have to get enough people to care about it as currently care about web standards -- and the web is used as more than just an application platform.

      You may have heard of it, Posix.

      Posix is not sufficient for modern applications. It can be used, certainly, but does it specify any sort of GUI, say?

      I would rather not take the web direction and skip that entire bullshit layer and do it at the OS.

      Browsers add a fair amount more than what we've been discussing, also. For example: The back/forward buttons, bookmarking, and other bits of navigation -- you get all this for free in a well designed web app. These are things you'd have to reinvent in a native app. Not that it's all bad -- native apps have (I'm told) much better GUI widget toolkits -- but it looks as though you're throwing the entire layer out as "bullshit" without making an effort to understand it.

      In particular, focus on REST and semantic HTML.

      The only advantage of what you're proposing is that you wouldn't have to use Javascript as an implementation language -- that you could use native code. For the vast majority of applicati

      --
      Don't thank God, thank a doctor!
    26. Re:I've got an idea! by SanityInAnarchy · · Score: 1

      That was a lot of fail packed into such a small package...

      All of you stupid slashdot karma whores

      I'm speaking my mind. I have plenty of karma to burn, if it was about that. I do get the occasional troll/flamebait mod.

      need to look around and realize that the rest of the world doesn't give a shit.

      The rest of the world by default doesn't give a shit about technical issues, at all. What part of that makes us wrong?

      Did you read the summary? "while native audio/video support has been dropped"

      Yeah, that's actually not true. Native audio/video support is still there. All that's been dropped from the spec is specific codecs -- in other words, browser vendors can support whatever codecs they want. So what?

      which can also be read as: "your 'open standards' have been hijacked".

      So, someone wants to use h.264 instead of Theora. Sucks, but I can live with that -- these are all well understood codecs that have open implementations, even if those implementations are of questionable legality until the patents expire.

      But are you really telling me that you would rather have Flash suck down 99% CPU, opening up all kinds of security and privacy questions, and still sometimes lag playing fullscreen video on Linux? (And HD video in Flash is a joke on any OS.) Compare this to, say, Firefox "just working" at 1-10% CPU (saving a ton of battery life on my laptop), as just part of the page, with the ability to right-click and "save video as"?

      "Open standards" are always going to be behind the times,

      You're posting this on a website serving HTML over HTTP. Chances are, you use SMTP to communicate at least with your business contacts (assuming you have a job?), and all three of those will be using at least ASCII, if not Unicode, probably UTF-8.

      You could probably find a few open standards which are behind the times. I could certainly find some proprietary ones which are. But the world runs on open standards. Take them away, and you wouldn't be able to read this comment.

      I'm going to use the best tool for the job.

      Flash is the worst possible tool for this job. It's just been the only tool for awhile.

      If you're really going to use the "best tool for the job", then once IE implements HTML5, I suspect you will as well.

      --
      Don't thank God, thank a doctor!
    27. Re:I've got an idea! by SanityInAnarchy · · Score: 1

      implemented differently across browsers

      Not significantly. Certainly not more so than any other language with multiple implementations.

      You might be confusing Javascript with the DOM and various other APIs. I'll admit, that has sucked in the past, but modern browsers tend to at least support standard ways of accessing the DOM, and libraries like jQuery hide that away.

      In fact, this "WebGL" is precisely the kind of standardization that's meant to ease that pain.

      it's loose type system playing havoc with math meaning you have to explicitly declare types anyway if you want things to work without suffering obscure bugs

      I honestly cannot remember the last time I had a bug related to this.

      the fact many important features like namespaces are pretty much just a hack

      A pretty elegant "hack" -- I'm going to chalk that up to you not understanding the language.

      the fact there's no decent tools for building and debugging Javascript apps?

      Firebug.

      At least those languages are well known, solid, and can be implemented well.

      Javascript isn't well known? And if you're claiming it can't be implemented well, citation needed.

      Or are you referring to the bytecode interpreters commonly used with those languages?

      Javascript has several good VMs now, so no, that's pretty irrelevant.

      There's no reason we can't have things run in the browser directly but with a better language and set of libraries to go with that.

      Except that brings us to forcing people to download a new browser, or browser plugin, to support those languages and libraries -- thus removing a major draw of browser-based apps.

      There's some irony in your argument in that you suggest we don't want to take steps back, whilst defending an outdated language.

      If I was defending C, or even COBOL, you might have a point.

      Like say, Java then?

      Java is easily twice as verbose as Javascript, probably a bit more. Java is not only strictly typed, but explicitly typed, down to what kinds of exceptions a method might raise.

      I prefer to write my app, not ream after ream of declaration.

      Now, if you're arguing that the Java VM should be used, I'd say there are probably better choices, but that's at least a possibility -- I don't know what the state of Jython is, but JRuby is pretty solid. But the language itself is an abomination. It's like someone took C++ and asked themselves, "How can we remove features to make this even more annoying?"

      Oh, and just for fun, some things Javascript can do that Java can't:

      • Lambda Closures
      • Function references (see above)
      • Prototypal inheritance
      • eval()
      • singleton methods (foo.some_method = function(){...})
      • monkeypatching (var old_method = Foo.prototype.some_method; Foo.prototype.some_method = function(){... old_method.call(this); ...})
      • inheritance/reuse pretty much any way you want (see above two examples)

      you're giving Javascript far more credit than it's due, it really is a crap language,

      Here, go read.

      I'll agree it could be improved. But I don't agree that it's a "crap" language, especially when compared to Java.

      --
      Don't thank God, thank a doctor!
    28. Re:I've got an idea! by SanityInAnarchy · · Score: 1

      We've seen a lot more exploitable bugs in browser sandboxes than OS ones, because they are much more complicated to implement.

      I suspect also because they see a lot more use than OS ones.

      And that's ignoring the issue of making it cross-platform and easily used.

      --
      Don't thank God, thank a doctor!
    29. Re:I've got an idea! by SanityInAnarchy · · Score: 1

      Unfortunately not.

      I've learned not to assume sarcasm when it isn't truly obvious -- there are far too many stupid and crazy things people could say. Example: "The earth is six thousand years old. Light from faraway stars got here through wormholes..."

      And there are people who truly believe VB is a good language.

      --
      Don't thank God, thank a doctor!
    30. Re:I've got an idea! by SanityInAnarchy · · Score: 1

      Native code will always be much faster than scripted.

      Two issues. First:

      I can imagine a few corner cases where this might not be true, but those exist in a vacuum and wouldn't ever happen.

      There are plenty of cases where it's not true, and these do happen. As a blatant example, Apple is using LLVM in practice, in a few places. Running that particular code in a VM was faster than running it natively -- I believe it's actually C.

      As research in this area continues, I really only expect it to get better, just as compilers have gotten better. The main difference is that "interpreted" languages can have runtime optimizations that "compiled" languages can't -- but there's absolutely no reason a "scripted" language couldn't be compiled, that's an implementation issue.

      The other issue is that even if scripting languages are slower, the vast majority of applications are fast enough in a bytecode-interpreted language, let alone a JIT-ed language, for it to be worth it -- especially when you consider other advantages, like portability, garbage collection, etc.

      Put another way: Would you rather your app be slightly sluggish, or would you rather it leak memory, crash under weird circumstances, be vulnerable to buffer overruns, etc?

      It needs to be able to access PostgreSQL and SQLite databases

      Are these local?

      If not, you could implement this on the server side pretty easily.

      as well as visualize the results of a simulation of a specific industrial machine.

      What do you use for that? Is it something more powerful than an html5 canvas?

      If I tried to make it a web based app, I would probably be over 100k lines of code instead of the 15,000 I'm at now.

      Javascript and Ruby vs C++? I'd imagine it would be less code.

      Not to mention, I'd still need something to handle my database access and provide results through JSON and the database access would be platform dependent.

      Well, if you're handling the database on the server, you get to pretty much pick the platform. If you do it on the client, you could pretty much just use Google Gears.

      As for providing the JSON -- first, no reason it has to be JSON, instead of something else. Second, that's actually pretty trivial -- on the order of 2-5 lines of code.

      Seriously, look up make_resourceful for Rails.

      With Qt, I literally have 1 codebase with almost no platform specific code and it works seamlessly in Windows and Linux. Haven't tried it on a Mac, but I bet it would work just fine.

      That's pretty much what I have with web apps -- except I also have easier distribution (just open the webpage).

      --
      Don't thank God, thank a doctor!
    31. Re:I've got an idea! by ClosedSource · · Score: 1

      You're missing the point. There is no framework. Just a bunch of unrelated things thrown together.

    32. Re:I've got an idea! by DaVince21 · · Score: 1

      True, but the believability of someone thinking VB is a good language for use on the web, especially for dynamic pages like JavaScript would provide access to, becomes kind of a stretch if you ask me. That, and the fact that he posted as an anonymous coward should account for at least something.

      --
      I am not devoid of humor.
    33. Re:I've got an idea! by digitalunity · · Score: 1

      My app accesses SQLite locally on single user installations and PostgreSQL over TCP/IP in centrally controlled network environments.

      Visualization code is not done yet because the physical simulation code isn't done either. It's gotta be able to handle some pretty heavy math for determining heat generated due to friction to predict tool breakage. The physical simulation is multi-threaded, and I don't have any idea how I could do that in a webapp without using Java.

      Regarding ease of distribution, well I guess I dont mind having an installer be required. My app definitely isn't open source and it does have some subtle anti-piracy features built in. 95% of users wont even know they're there unless they start deleting things they shouldn't.

      I really think the web-based app would have been the wrong decision and I'm confident I am headed in the right direction.

      --
      You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
    34. Re:I've got an idea! by SanityInAnarchy · · Score: 1

      My app accesses SQLite locally on single user installations and PostgreSQL over TCP/IP in centrally controlled network environments.

      So, with the centrally controlled environment, I don't see a lot of advantage to sending SQL over TCP/IP, vs talking to a server. With the individual installation, it depends very much what the users want -- I imagine some would love the idea of working on it anywhere, and letting you worry about backup. Others would much rather have the data stored locally, under their control.

      The physical simulation is multi-threaded, and I don't have any idea how I could do that in a webapp without using Java.

      If performance is an issue -- you actually need multiple CPUs -- then I believe there are some new-ish (as in, unimplemented) browser technologies to do that.

      Otherwise, cooperative multitasking is certainly possible, in any language.

      I really think the web-based app would have been the wrong decision

      As I hear more about this, I'm inclined to agree. Still, it's also not a common app.

      --
      Don't thank God, thank a doctor!
    35. Re:I've got an idea! by Lord+Bitman · · Score: 1

      input type=checkbox, makes a checkbox.

      What more do you want?

      --
      -- 'The' Lord and Master Bitman On High, Master Of All
  10. VRML by timeOday · · Score: 2, Interesting

    Anybody remember how awesome and important VRML was supposed to be? They just forgot to convince users.

    1. Re:VRML by Tetsujin · · Score: 1

      Anybody remember how awesome and important VRML was supposed to be? They just forgot to convince users.

      What? No way! I was definitely convinced! I distinctly remember running a VRML plugin at one time, and trying one of a very limited number of available example pages for it with some limited measure of success...

      If I'd had tools like (today's) Blender back then, and the hardware to back it up, I might have done something with VRML...

      --
      Bow-ties are cool.
    2. Re:VRML by Joce640k · · Score: 2, Interesting

      VRML is alive and well ... and living in a group called "Kronos". It's every bit as awesome as it ever was.

      --
      No sig today...
    3. Re:VRML by Spy+Hunter · · Score: 1

      The difference is VRML sucked. OpenGL doesn't suck.

      If you want more detail: VRML was based on a scene graph. Scene graph APIs have proven over time to be the Wrong Way to do real-time graphics. They are complex to implement, inflexible, and slow. The alternative is immediate mode rendering APIs like OpenGL and Direct3D, which are fast, flexible, and relatively simple to implement, and have been very successful. For an analogy to 2D graphics, VRML is like SVG, while OpenGL is like the Canvas element in HTML 5.

      --
      main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
    4. Re:VRML by am+2k · · Score: 1

      They just forgot to convince users.

      Well, it's not the endusers that need convincing, but the content producers. The consumers will just use whatever works for them.

    5. Re:VRML by bigmo · · Score: 1

      VRML was hurt by people expecting to see cyberspace like in the movies. The actual reality was that it was a way to do simple visualizations when you didn't have the horsepower to do it "for real". I still believe that even with all its warts, it was a terrific piece of work for its time period.
      .

      My current (and very talented) designers spend hours producing scenes that can barely be properly viewed on quad core, gigabyte graphics card machines. The scenes are beautifully detailed and very pretty, but I can't seem to get through to them that there is also a place for extremely basic quick "sketches" for mundane functional uses - we do audio visual work and use visualization for planning purposes.

      .
      More than ten years ago, VRML, along with some simple java code for creating it automatically from a 2D sketch, allowed me to, in less than an hour, create a fly through that would run comfortably on a 486 with a 16 MB graphics card. I wouldn't begin to put the simple textures from that up to the beautiful work done today, but it got the job done.

  11. Re:VRML - side note by Tetsujin · · Score: 1

    Anybody remember how awesome and important VRML was supposed to be? They just forgot to convince users.

    What? No way! I was definitely convinced! I distinctly remember running a VRML plugin at one time, and trying one of a very limited number of available example pages for it with some limited measure of success...

    I feel compelled to add, this was a point in time at which streaming audio over the internet was still a big deal.

    --
    Bow-ties are cool.
  12. Browser = the new runtime environment? by HalAtWork · · Score: 1

    So the web browser, in the end, will just be one big common runtime environment? That's one way to get compatibility across OSes I guess. If proprietary plugins were to be written to run entirely in a W3C compatible environment, then we'd be better off.

    But it still seems like there will always be some sort of proprietary extension that one group will try and control. Businesses will want to set up tollbooths just for the sake of a "guaranteed revenue stream". What this really means is a tax that doesn't benefit anyone else. How can we stop rewarding these groups? Is the only way to prevent such tollbooths from being viable and desirable? If so, how?

    For example: A standard gets defined, then tools become available to produce content which includes a proprietary method of achieving a result, but this fragments the audience. Why do sites and users put up with this?

  13. STOP! by markdavis · · Score: 3, Insightful

    Meanwhile I am trying to find a way to get Firefox to STOP automatic animation. It used to be easy- don't use Flash and disable animated GIF's. Now with Ajax and Javascript, it is nearly impossible.

    * Many people (myself included) can't stand movement on pages while we are trying to read things.
    * Some people are using thin clients and animation destroys network bandwidth or overloads the main server.
    * Still others are on slower, older computers and animation slows their system to a crawl.
    * And many more are on laptops/netbooks and animation pegs the CPU and quickly drains the battery.

    IMHO, a well-designed site will never create movement unless the user asks for it (with a mouse-over or click or whatever). But that would be a "in a perfect world" type fantasy.

    Please, don't bother replying suggesting "noscript"- it breaks necessary functionality of sites horribly.

    1. Re:STOP! by Anonymous Coward · · Score: 1, Funny

      [quote]Please, don't bother replying suggesting "noscript"- it breaks necessary functionality of sites horribly.[/quote] ur doin it rong.

    2. Re:STOP! by Krneki · · Score: 2, Insightful

      On my netbook I don't have any problems with Web animations. Most of the stuff is properly blocked by Firefox plugins. Just try to configure them better, it's worth the time.

      --
      Love many, trust a few, do harm to none.
    3. Re:STOP! by markdavis · · Score: 1

      On my systems, pressing escape does nothing to stop any animations.

      http://www.visiosight.com/
      http://samples.gaiaware.net/Timer.aspx
      http://www.volll.com/

    4. Re:STOP! by Hatta · · Score: 2, Insightful

      Please, don't bother replying suggesting "noscript"- it breaks necessary functionality of sites horribly.

      That's what the white list is for.

      --
      Give me Classic Slashdot or give me death!
    5. Re:STOP! by an+unsound+mind · · Score: 1

      Eventually, noscript + AdBlock.

      I've yet to find anything functioning better, and I'll rather have NoScript breaking things over meaningless blinkenlights.

    6. Re:STOP! by Spy+Hunter · · Score: 1

      If you want browser control over animations, then take a look at WebKit's CSS Animation proposal. Instead of driving animations with opaque Javascript you can specify them declaratively in CSS, and as a side effect the browser gains control over the implementation.

      --
      main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
    7. Re:STOP! by gbjbaanb · · Score: 1

      Meanwhile I am trying to find a way to get Firefox to STOP automatic animation

      yep, and when this is a true standard, I've no doubt there will be options to control it better. That'll be far better solution than adblock or other 'all or nothing' (relatively speaking) filtering controls.

    8. Re:STOP! by RiotingPacifist · · Score: 1

      controldescripts allows what your asking for (well the disabling ajax and javascript animations, othertools will block flash and esc will stop gifs), unfortunately setting it up was beyond me, but the functionality to restrict the js commands a site has access to is there, so i just use noscript+temporarily allow default domain.

      --
      IranAir Flight 655 never forget!
    9. Re:STOP! by The+MAZZTer · · Score: 1

      One word: NoScript

    10. Re:STOP! by The+MAZZTer · · Score: 1

      Ooops missed the last sentence of your last post. Oh well, I don't agree with it anyways. Whenever a site seems broken I automatically add it to the whitelist. Of course half the time that doesn't fix it and the site is just plain broken, but at least it's not NoScript's fault then.

    11. Re:STOP! by markdavis · · Score: 1

      Well, if you mean Adblock Plus... yes, all my machines run that. And it does help tremendously. But these animations are not necessarily ads.

      As for time- I have spent lots and lots of time trying... tips appreciated

    12. Re:STOP! by markdavis · · Score: 1

      1) That is a tremendous amount of work (compared to something like Adblock)
      2) In a thin client environment, white lists don't work because users don't understand it and/or don't realize what is happening anyway
      3) It seems no matter how much you mess with it, it still ends up breaking something you need to make this or that site work

      I keep hoping someone will invent some type of intelligent blocking system for animation that understands the typical methods being used and can short-circuit just those elements. Maybe it isn't possible.

    13. Re:STOP! by markdavis · · Score: 1

      That MIGHT work partially OK for people like you or me (with enough effort). But it isn't a solution to roll out to hundreds of users that don't even understand the concept of going directly to a website. They think you have to put a web address into Google, then click on the first link that comes up. I think you know what I mean...

    14. Re:STOP! by Krneki · · Score: 1

      Noscript, Flashblock, Adblock plus.

      Noscript can be tedious, but it's worth the time.

      --
      Love many, trust a few, do harm to none.
    15. Re:STOP! by Hatta · · Score: 1

      1) 2 clicks per site, one time only, is not a tremendous amount of work. Quit being melodramatic.

      2) If other users don't get it, sucks for them.

      3) "Allow all this page" has never failed for me.

      --
      Give me Classic Slashdot or give me death!
    16. Re:STOP! by shiftless · · Score: 1

      Please, don't bother replying suggesting "noscript"- it breaks necessary functionality of sites horribly.

      I tried turning off Javascript one day because I was sick and tired of Google wrapping every link I copied from search queries. That's when I discovered the horrible truth--in 2009 the internet DOESN'T FUCKING WORK without Javascript enabled. What the fuck is this shit?

    17. Re:STOP! by shiftless · · Score: 1

      [quote]Please, don't bother replying suggesting "noscript"- it breaks necessary functionality of sites horribly.[/quote] ur doin it rong.

      Now that's irony...

  14. Re:Its just a fad by kent_eh · · Score: 1

    Getting everyone used to not downloading stuff is step 1
    Step 2 is making it impossible for anyone to download anything
    And step 3 is pay-per-use of the glorious cloud and all of it's constant revenue stream goodness.

    --

    ---
    "I can't complain, but sometimes still do..." Joe Walsh
  15. You need... by StartCom · · Score: 1

    ...Firefox to view this web site.

  16. Re:Wait, what by jack2000 · · Score: 1

    God or bad argument, it does not matter. Sad thing is, it's happening right now...

  17. those are some awfully dry pipes you have there by convolvatron · · Score: 1

    does anyone believe that at any point the hardware would be the bottleneck?

    1. Re:those are some awfully dry pipes you have there by Rozine · · Score: 1

      My hardware is the bottleneck on the current web. Flash + Linux + P4 = slow. So yes, I believe it.

    2. Re:those are some awfully dry pipes you have there by Rozine · · Score: 1

      No, I'm sure that Flash is the bottleneck here. I bet it's really hogging the CPU. For example mplayer/ffdshow decoders play Flash video faster and smoother than Flash. And that's on Windows.

      Yes, sure. Flash is the bottleneck. I agree completely. However, that means that it's not the pipes, it's the processor running bloated unoptimized software. So my point stands - the hardware is the bottleneck rather than the internet, even if it's not really the hardware's fault. This is a consistent experience for me. It used to be, downloading was slow but once it got to my computer, it was fast. Now, downloading is fast, but my computer can't take it. This may be because I'm getting the most expensive internet-only cable package offered, but it's a significant reversal from the mid 90's when I got the Internet. The old argument about the pipes being the bottleneck might still be true for a lot of things, but for the home internet user, it's not necessarily true anymore. And for 3D acceleration, I can almost guarantee that more often than not, it will still be the hardware.

  18. Exploits for the future by Brit_in_the_USA · · Score: 1

    OK - I'm predicting what will happen a few years down the road - Browser based OpenGL exploits based on browsers and/or OS and/or Graphics Vendor Driver and/or GPU hardware bugs in OpenGL implementaiton.
    Fast forward a few more years and exploits in OpenGL spilling over into running OpenCL / DirectX? code on the graphics cards. Which by then will be defacto and be running some core OS services.

    Boy things are going to get interesting....

    1. Re:Exploits for the future by Achoi77 · · Score: 2, Funny

      Yeah... it would be real nice if the general public had access to the source code in some kind of Open fashion regards to browsers such as Firefox or Webkit/Safari/Chrome so that stuff like exploits can be patched, making it would be possible to have tons of eyeballs pore over the code and be able to submit fixes on behalf of the community, or point out bad stuff that perhaps some other developers may have missed.

      That would be cool.

    2. Re:Exploits for the future by Brit_in_the_USA · · Score: 1

      yes that would be cool. I look forward to open driver source code on all OS platforms and open GPU hardware descriptions....

  19. Re:Finally by rhyder128k · · Score: 1

    Why do I get the feeling that if this does become workable and widely used a certain other company is going to come up with its own version that only works with its products?

    --
    Michael Reed, freelance tech writer.
  20. several sources...are mistaken... by daithesong · · Score: 5, Informative

    "Several sources are reporting that while native audio/video support has been dropped from the HTML 5 spec" is hard to reconcile with http://www.whatwg.org/specs/web-apps/current-work/#video (and the same document is available at the W3C, O doubters). It seems (gasp) that several sources can be...wrong!

    1. Re:several sources...are mistaken... by shutdown+-p+now · · Score: 2, Informative

      I think that aforementioned several sources are confusing dropping Vorbis/Theora as a required codec with dropping audio/video elements from HTML5 altogether. Ironically, if you actually open TFA (don't worry, no need to read it) and click on the link that's formed by the words "dropped from the HTML5 spec", the article which opens is indeed about dropping Vorbis/Theora, and it's on the same website. Looks like they don't read their own articles - just like /.

    2. Re:several sources...are mistaken... by Joce640k · · Score: 1

      Translation: "Microsoft dropped it"

      (if they every really intended to do it - why should they when they've got their own agenda for web video, ie. Silverlight)

      I don't see Microsoft jumping on this new bandwagon either. Why should they when Silverlight has 3D? Without support in IE then I don't see anybody using this for anything much.

      --
      No sig today...
    3. Re:several sources...are mistaken... by julesh · · Score: 1

      I think that aforementioned several sources are confusing dropping Vorbis/Theora as a required codec with dropping audio/video elements from HTML5 altogether.

      The two might as well be the same. There is now no video codec that is supported by all browsers, meaning Flash is still the best option for playing videos.

    4. Re:several sources...are mistaken... by shutdown+-p+now · · Score: 1

      The two might as well be the same. There is now no video codec that is supported by all browsers

      You don't need a single codec - you can specify several sources in video element, and browser will pick the first one it can handle. So you specify H.264 and Theora, and that's enough to cover all of them.

      Flash is still the best option simply because IE didn't sign up for HTML5 video. However, for performance reasons, it's still advantageous to use HTML5 where supported, and rely on fallback to Flash when not (video element was specifically designed with that in mind).

  21. VRML, the undead by marciot · · Score: 1

    Didn't VRML die already? Like in the 90s? Things that die should stay that way.

    1. Re:VRML, the undead by Joce640k · · Score: 1

      The Kronos group has had it on life support all this time. Now it's called "Collada" but it's still VRML in disguise.

      --
      No sig today...
  22. Re:Non-standard, but you can do GL in a Java apple by jimshatt · · Score: 1

    You don't have to fiddle with jars and so's/dll's anymore. Check https://jogl-demos.dev.java.net/applettest.html for a demo.

  23. Re:umm... by am+2k · · Score: 1

    You mean something like JOGL or LWJGL?

    Been there, done that, although this is mostly for Java WebStart, not applets.

  24. Re:Am I missing the plot? by AttillaTheNun · · Score: 1

    typo - substitue "pre-HTML" with previous "(i.e. HTML 4)"

  25. We don't need yet another load of crap in browsers by Something+Witty+Here · · Score: 1

    >>>> What needs to happen is that the OS needs to become more browser-like

    Sorry, I need an OS that works properly, and isn't full of unnecessary crap,
    bugs, and security holes. Actually I need that in a web browser but can't
    find one.

    >>> What's next, a way to make web browsers faster by making /dev/kmem remotely writable?

    Oh please don't give the morons any ideas.

    >> Does EVERYTHING need to be reinvented (poorly) on port 80? Really!!!???

    Why is thus modded funny?

    > It can be expected that web browsers use decent security practices

    You have GOT to be kidding.

    BTW re: javascript, I find that browsers crash a lot less with it turned off.

  26. It's not about "speed" by Joce640k · · Score: 1

    it's about using a tool which is suited to the job. Using Javascript to do 3D graphics is like trying to saw wood with a pair of knitting needles.

    --
    No sig today...
    1. Re:It's not about "speed" by shovas · · Score: 1

      Best tool for the job is nice and all. But, really, there are more things to consider than just what immediately seems pragmatic.

      For instance, Word might be "the best tool for the job", but not in my books because of a number of things. Closed-source, expensive, anti-competitive, closed-format, etc.

      As far as javascript + graphics go, it's not just about the fact that C is faster than JS. It's about the platform, the availability, the ease of use, the open standards, the de facto standards, etc.

      Go ahead, try to achieve the same goal and see how far you get without tools that are already available en masse.

      Sometimes "the best tool for the job" takes more into consideration that what immediately seems pragmatic.

      --
      Selah.ca. Pause, and calmly think on that.
    2. Re:It's not about "speed" by Joce640k · · Score: 1

      Sure, let's all start hammering square pegs into round holes.

      Programmers have way too much free time on their hands, the extra workload will be a welcome relief to them.

      --
      No sig today...
    3. Re:It's not about "speed" by shovas · · Score: 1

      That's just it, I think you missed my point: What looks like a square peg based on little information is actually a round one based on more information.

      --
      Selah.ca. Pause, and calmly think on that.
    4. Re:It's not about "speed" by Joce640k · · Score: 1

      No, it's square. OpenGL ES has no immediate mode rendering, all rendering is done via arrays of floating point data, and pointers to them. Support for that sort of data storage is non-existent in JavaScript. I'm not even sure you could pretend that strings are binary data (like they do in PHP).

      --
      No sig today...
    5. Re:It's not about "speed" by shovas · · Score: 1

      This is what I was talking about concerning "best tool for the job." You're throwing the baby out with the bath water because a very specific implementation detail isn't as efficient as it could be.

      You have to think bigger picture. This is pretty much the only way to achieve accelerated graphics in the browser with open standards and decent penetration.

      --
      Selah.ca. Pause, and calmly think on that.
  27. Re:VRML - side note by WinterSolstice · · Score: 1

    I used VRML too - and this wasn't just when streaming audio was a big deal, this was when even having audio WORK was a big deal. I was running shotgun modems last time I used VRML, and it was still fun.

    Getting audio AND X11 up? That was talent.
    Even windows audio was spotty on some cards.

    --
    An operating system should be like a light switch... simple, effective, easy to use, and designed for everyone.
  28. Re:Am I missing the plot? by Wesley+Felter · · Score: 1

    Why can't we have both imperative and declarative support for both 2d and 3d web elements, both backed by access to a DOM?

    Declarative 2D (SVG) and 3D (VRML/X3D) exist but virtually no one uses them, so the browser developers aren't going to put much effort into declarative graphics. You can always define your own declarative format (JSON3D anyone?) and write a library to display it using WebGL.

  29. Please don't by extrasolar · · Score: 1

    If this is available on all web browsers, that means I won't be able to turn it off; or if I turn it off, I can't access the rest of the web.

    Please, don't do this. What's the benefit of turning web browsers into flash players?

  30. Re:We don't need yet another load of crap in brows by julesh · · Score: 1

    BTW re: javascript, I find that browsers crash a lot less with it turned off.

    Funny. I don't remember the last time I had a browser crash while using a non-beta browser.

  31. Re:umm... by julesh · · Score: 1

    Wouldn't this be better to be made as a java library of some form that allows for java applets to have direct access to opengl in browser?

    You mean like this?

  32. What are the real applications for this? by emanem · · Score: 1

    Honestly, what are the real applications for this?
    Online gaming?
    Would developers release a game in JS, with the full source code exposed to hackers/cheaters?
    The only usage would be for other fancy GPU/CPU consuming GUIs?
    Cheers,

  33. Re:We don't need yet another load of crap in brows by Chemisor · · Score: 1

    I use Konqueror, which is certainly not beta, and it crashes all the time. Twice in the last hour, in fact.

  34. Wow! That's exactly what we need! by Chemisor · · Score: 1

    As xkcd already pointed out, developers seem to be out of touch with reality here. How about implementing KMS for a flicker free boot instead? Or heck, what about allowing X applications to sync to vertical retrace? That last one has been in the pipeline for some 20 years, for God's sake!

    1. Re:Wow! That's exactly what we need! by LiquidFire_HK · · Score: 1

      Wait, where did Linux come into this?

      At any rate, you make the mistaken assumption that any developer can and will work on anything. I very much doubt that the people working on WebGL (if there are any - it seems to me it's just an in-progress specification at the moment) are ones that would otherwise work on the things you listed.

  35. Opening the Pandora box by dolmen.fr · · Score: 1

    [...] to offer a JavaScript binding [...] allowing code run within the browser to access the graphics hardware directly [...]

    This is opening the Pandora box. Many new exploits expected. Graphics hardware is designed to be fast, not secure. We will soon see javascript codes hijacking the desktop view, to show more intrusive ads in the best cases, steal personal information in the worst.

    1. Re:Opening the Pandora box by Svartalf · · Score: 1

      Actually, it HAS to be relatively so at the API layer. OpenGL or OpenGL ES, in and of themselves, don't really allow for most of the crap you're talking to- nor do they enable it any more than Javascript already does. Moreover, a shader program can't interact with anything other than the GPU's own memory with current designs.

      --
      I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
  36. Re:O3D? by Floody · · Score: 1

    Wow, I'm amazed that nobody else in this discussion mentioned O3D.

  37. Video/audio did NOT get dropped by Lennie · · Score: 3, Informative

    Their just isn't a recommendation about what codecs should be supported in the spec.

    --
    New things are always on the horizon
    1. Re:Video/audio did NOT get dropped by Svartalf · · Score: 1

      Which does nicely explain what Google was on about when they bought On2 if that's the case...

      --
      I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
    2. Re:Video/audio did NOT get dropped by Lennie · · Score: 1

      You know what the problem is with that, we don't really know. They bought it for 106.5 milion I believe. You know, if Google wanted to use the On2 software, they had to pay On2 3000 per server per year. And Google has a lot of servers and they intend do video for many years (106.5 mil devided by 3000 for 3 years is 10000 servers) So maybe they thought it's easier to just buy them, they get some cool tech and smart people, which they can probably put to good use.

      Maybe I'm totally off.

      --
      New things are always on the horizon
  38. Damnit guys by shiftless · · Score: 1

    You know what, I think 3D could be a great part of the web in the future. But here's the thing. This whole fucking Web 2.x deal is a pile of shit that is already about to collapse under its own weight; the last thing we need is to duct tape more shit onto it. If you don't believe me, try using the Internet on a slow connection, like over a shared satellite link. It's a fucking nightmare. Javascript/AJAX/etc is garbage. Browser "back" buttons don't work anymore, and neither does the reload button in many cases. CSS is great idea until it's abused, as it always seems to be. (Translation: lazy ass developers who pile 500k worth of shit into a single page, then use CSS and Javascript to "hide" it until called on.)

    Could we please redesign this "Web" thingy from the ground up before going any further?

  39. Ever here of "2.5 D"? by Anonymous Coward · · Score: 1, Interesting

    It means using the 3D hardware using an "Orthographic" camera view to do 2-D graphics. Basically, you use the 3-D accelleration to do 2-D. It's FAST! Damn FAST! And very easy to comprehend and program.

  40. Palm Pre by Ingenium13 · · Score: 1

    This would be really nice on a phone like the Palm Pre, which has the hardware to do OpenGL ES 2.0 (the same as the iPhone 3GS actually), but apps can't really use it. Its entire UI is basically a browser, right down to the phone and messaging apps. The biggest complaint for potential developers is that games aren't really possible since you don't have access to hardware acceleration. This would fix that problem.

  41. Re:We don't need yet another load of crap in brows by Goaway · · Score: 1

    There's a pretty easy solution to that one.

  42. Re:umm... by ciggieposeur · · Score: 1

    It would be, but people don't want to wait on the JVM to load, so they would rather cram all the already-existing Java applet functionality into Javascript.

    (Actually, the plugin doesn't work smoothly with everything else. If it was standard for Java applets to pass keystrokes back to the browser, integrating with the tab order and handling Ctrl-K/E/L/F / Alt-D/F / etc., then there wouldn't be much point to using Javascript for anything.)

  43. Re:umm... by guardia · · Score: 1

    You _can_ use native packages in applets.. https://jdk6.dev.java.net/plugin2/

  44. I've got a better idea... by sitarlo · · Score: 1

    Instead of presenting 3D content in a 2D browser, build a freaking 3D browser that is capable of rendering 2D content. Content providers could create sites that are as rich as an MMORPG, or as simple as a single html page. People could surf with the a,w,s, and d keys (and use their control buttons to duck under crappy sites!). The technology to do this is here, but the standards people need to embrace 3D as an important information exchange medium. I have a funny feeling this type of thing is going to happen eventually and it's going to be part of a paradigm shift that truly changes the way we approach computing online.