3 ms·
This is just an indicator that we need a proper native development environment. Devs who embrace new web technologies like WebGL, <audio> or <video> forget that
by kombine 14y ago
This is just an indicator that we need a proper native development environment. Devs who embrace new web technologies like WebGL, <audio> or <video> forget that those are just Javascript bindings to the technologies developed in C/C++. Can we please have native code instead, so developer controls the underlying system without having to rely on the wits of browser makers? Google Native Client is a step in the right direction.
- UnFleshedOne 14y agoWhat, wasn't the whole point of all web technologies to pile abstraction layers on top of abstraction layers so you never have to think about pointers ever again? :) Native platforms and architectures were replaced by browser platforms, trading power and control for deployment headaches. And now you want to write for multiple browsers, multiple OSes and multiple architectures all at the same time while still battling heaps of restrictions any decent OS/antivirus would impose on binary blobs that can be run by a browser directly? (disclaimer: I'm obviously biased towards native development :))
- azakai 14y ago> This is just an indicator that we need a proper native development environment. Devs who embrace new web technologies like WebGL, <audio> or <video> forget that those are just Javascript bindings to the technologies developed in C/C++. That is technically true, but what is the point? The bindings can make things better, or they can make things worse. WebGL, for example, covers over a lot of issues with OpenGL (security and convenience), making the web version very nice to use. > Can we please have native code instead, so developer controls the underlying system without having to rely on the wits of browser makers? Google Native Client is a step in the right direction. Native code is by definition non-portable. NaCl in a partial attempt at portability adds bindings of its own to native APIs. Ask people developing for it, like any environment it has bugs and issues. There is no simple solution here.
- kombine 14y ago> That is technically true, but what is the point? The bindings can make things better, or they can make things worse. WebGL, for example, covers over a lot of issues with OpenGL (security and convenience), making the web version very nice to use. Last time I tried WebGL version of Quake3 on my machine which had the hi-end AMD graphics card at that time, it ran at less than 100FPS. For a game that's 10 years old that is a very poor result. The reason why I said bindings is because I want a language powerful enough to implement any technology I want in that language. > There is no simple solution here. Of course it's not simple. It doesn't mean it's not possible. Microsoft's WinRT is another example of coming closer to the native code apps.
- azakai 14y ago> Last time I tried WebGL version of Quake3 on my machine which had the hi-end AMD graphics card at that time, it ran at less than 100FPS. For a game that's 10 years old that is a very poor result. The Quake II port was extremely unoptimized in how it was performed. It's not a good benchmark of anything. > Microsoft's WinRT is another example of coming closer to the native code apps. What about just actual Android C++ apps, as an example of native code apps..?