9 ms·

It's funny when you contrast it to web applications. It just shows the layers and layers of bad, inefficient abstractions we've built over the years. For exampl

by Siyo 11y ago

It's funny when you contrast it to web applications. It just shows the layers and layers of bad, inefficient abstractions we've built over the years. For example, re-drawing when resizing the Slack chat window can take up to a second. In that time I could have rendered the Deus Ex scene at 1080p at the highest settings 60+ times.

angersock 11y ago
I really, really hate it when people point at a web browser and a modern game engine and then say "Look how sloppy and horrible and inefficient the web is!" Seriously, just stop for a second and use your head. First, that game? Probably using precompiled logic--especially as games in the last decade have gotten objectively harder to mod. The browser must deal with any arbitrary code shoved at it, and handle modifications to its scene graph (the DOM) at any time. These modifications may include creating more script code, pulling in networked resources, or any other damn fool thing. Second, that game is only going to run on a narrow selection of hardware. It's not going to run on a machine from ten years ago, probably. It's not going to run on a machine ten years from now, probably. Third, that game is built to use files and formats specifically made for itself. It's not dealing with old goofy image formats. It's not dealing with potentially malformed XML documents. It's not dealing with any number of things, because those have been trimmed away and pre-verified. Fourth, that game is never going to have to scale from a multiple-socket workstation all the way down to a handheld phone or shell script. It's really silly to point at a hyperoptimized purpose-built tool and claim it is somehow massively better than a platform for distributing massively-varied media and documents. EDIT: Downvote away--but first, write a purpose-built pipeline for deferred rendering, and then a real-time app in Angular, for example. If you haven't done both of these things, you probably don't know what you're raging about.
- charliefg 11y ago
  I think many would agree with you, that most modern browsers with the expected features are pretty bloody efficient pieces of software. I believe what OP was saying was that the layers of abstraction used in building web application on top of the foundation the browser provides -- while really useful -- are also inefficient. This is to be expected since they do not usually have access to the full capabilities of the operating system and hardware.
- reitzensteinm 11y ago
  I have done both of those things (though my real time web app is written in React/cljs), and I agree entirely with the grandparent. The difference isn't in the technical details, the difference is that a chat app with a 1 second redraw can succeed in the marketplace, whereas a game with a 1 second redraw will never be played. The bloat and inefficient abstractions grow to the limit of our tolerance. If CPUs had hit the wall at 66mhz single core, that chat app would somehow still take the same 1s to redraw. Of course, it would probably be written in something like NaCL and have significantly more engineering effort put into optimization, with a browser stack engineered for high performance.
  - sliverstorm 11y ago
    The bloat and inefficient abstractions grow to the limit of our tolerance. Which is tragic in some ways IMO. It means every system is always optimized to the level of misery where you are just barely not willing to do something about it. Which when you think about it sounds kind of like what you would expect from a lesser circle of hell.
  - robmcm 11y ago
    Apparently in the early days of HDTV, cable/satellite companies would slowly reduce the quality of broadcasts until people started complaining. At which point they stopped. When BBC HD was a channel, its quanily was black and white to everything else, now even they are in on the reduced bandwidth game :(
- WolfeReader 11y ago
  If, in 10 years, I'm unable to play Deus Ex HR but all of these bloated, insecure, backdoored, "social" web sites are still supported, I might just quit this industry for good.
  - voltagex_ 11y ago
    Vote at http://www.gog.com/wishlist/games/deus_ex_human_revolution http://www.gog.com/wishlist/games/deus_ex_human_revolution, buy the DRM-free version if it eventually comes out, then store it on good quality archival media.
  - robmcm 11y ago
    Dont worry, you will be able to emulate it through a browser in your watch in 10 years :)
- simoncion 11y ago
  Here's the thing. You're replying to "...re-drawing when resizing the Slack chat window can take up to a second." 0) I agree that working with the DOM can get very complicated, and that layout can also be a hard problem[0]. Keep this in mind while you read the rest of my response. 1) When a browser goes to render a page, it does so from assets that have already been loaded and validated. All the fiddling with goofy image formats and malformed inputs is over and done with. All of those resources should have been processed by the browser into a format that's specifically made for the browser. So, when you resize the browser window, all[1] you're asking the browser to do is to reflow the page using the resources that some other code has specially prepared for rendering. 2) I bet you ten dollars that -if it had been compiled for a 64-bit machine- Deus Ex: HR would run on a machine manufactured in August, 2021. (Indeed, look at how well Starcraft 1 runs on machines built in 2008 and later. :) ) (Oh, BTW. Deus Ex: HR runs on the XBox 360; a machine that was released in November 2005... just about ten years ago. :) ) 3) Have you used Mobile Chrome or Mobile Firefox on a Nexus S (a phone released in December 2010)? I have and -when I have no other choice- do. They are slow as balls for web pages of any appreciable complexity. Hell, for rather complicated pages, they consistently get reaped by the Android OOM killer. 4) I assume that by "That game is never going to have to scale .. down ... to a ... shell script" you mean something like "The web is browsable through lynx. You will never have a text-mode version of Deus Ex: HR.". If the game dev was willing to let folks make Deus Ex: HR look like a game from the early 2000's (and run on machines from the mid-to-late 2000's), they could have inserted a checkbox that switched to pre-computed lighting and turned off (or greatly reduced the complexity of) all shaders. However, I bet you fifty dollars that a wide section of The Web is completely unusable on lynx (or even links, for that matter). Edit: Know that I've built soft-realtime networked GUI software with both OpenGL (using FLTK as the base) and a modern browser (with JQuery as the base). :) [0] However, TeX has been doing complicated page layout since the late 1970's. :) [1] Yes, I'm quite aware that browsers can do all sorts of things -including loading and processing new resources- when the viewport size changes. If you've written a web page that does so much work on viewport size change that redraw takes 1000ms or more, guess what? You've written a slow web page. :) If you build a game that requires 1000ms to render a single frame, guess what? You've built a slow game. :)
- jlarocco 11y ago
  I suspect you're being down voted because most of your claims are false. It's not hard to find counter examples for all all of them. And also because web developers made their own bed. It was web developers who decided it was a good idea to cram everything into the browser and make web pages into "web apps." They could have said, "Hey, this is dumb, doing this will be slow and inefficient, and here are the other technical reasons why it's a bad idea," but they never did that. Instead it's always, "Hey, look how I can make a low quality Doom clone in a browser that runs slower than original Doom did 22 years ago!" and hack after hack to get things running at a speed comparable to regular applications.
  - jacquesm 11y ago
    The reason for that is not 'web developers' but rather the fact that a single delivery device for a huge variety of content without intermediaries is a thing no corporation will be able to ignore. That's what caused the envelope to be pushed as far and as fast as it did, and we all both enjoy the fruits of that and suffer because of it. It's like forcing a kid to grow from age 3 to age 30 in a few weeks time, it's bound to give trouble, no matter how impressive the feat may be technologically speaking.
    - Retric 11y ago
      There is a ton of unbelievably bad web code out there. jQuery is a great example of a 'huge' and popular slowdown for a minor gain. Sure, it's 'worth it' because nobody cares if a web app takes 1/2 second to render, but as soon as you trade speed for anything else you quickly end up with code that's as slow as your willing to live with. Having said that there are a few modern web-apps that really got 10x faster while sticking with HTML, CSS, and java-script so it's possible. The trick is stick with competent people and reasonable designs.
      - hhandoko 11y ago
        I believe it's been discussed many times before. Developers who use jQuery do so because it provides a good API / abstraction layer, as dealing with browser specific issues could be non-trivial.
- jacquesm 11y ago
  Have an upvote, dissenting opinions should at least be legible. That said, I really can't agree with you. Browsers can re-compile their input into whatever intermediary format they desire subject to the usual space/speed trade-offs. By the looks of it (judging by the space they need) they use that trade-off rather liberally in the 'speed' direction and they still run quite slow. I just can't imagine that laying out some text and images in 2d (which I've done for limited contexts) is that much harder than rendering a 3D scene (in software, not using a bunch of GPU power to do the heavy lifting) (which I've done, but not recently and definitely not with this kind of detail, roughly at the level of the original 'Doom' with a slightly better lighting model and right around the time it came out). Games may not have security issues in the input data that they consume when it comes to graphics and such, so that's a valid point but games do have to run on a wide variety of hardware and they typically adjust really gracefully. The one thing I think that really differentiates game rendering engines from browsers is that game engines tend to model some physical process whereas browsers attempt to implement a massive spec to allow any server it chooses to contact to send it a bunch of bytes the rendering result of which is not known ahead of time so arguably the games people have a relatively limited possible space of outputs they can generate whereas browsers theoretically can display anything including that game. That still doesn't excuse them for the crappy performance they deliver, that simply means we've moved too fast in adding layers before getting lower layers to perform adequately. The original web did not seem sluggish to me, it seemed about as fast as what you could expect from the hardware of the day, whereas the 'modern' web seems to be (to me) terribly slow and inefficient. The ratio of content:markup+eye candy has deteriorated and I suspect that that is part of the answer here (and of course that would not be the browsers fault per-se).
  - angersock 11y ago
    The web doesn't deliver crappy performance, though--apps written by bad developers deliver crappy performance. The complaints about the abstractions and everything honestly remind me of the complaints about Java, and look how that turned out over the same time period. As for the engine vs. browser thing--you can totally render a DOM super efficiently if you are sure that it remains relatively static. That's very much, in fact, how the game engines do so well. They have the task of "throw as much as we can in triangle buffers onto the card, and occasionally draw with uniforms set to our desired transform matrices, and let the Z-buffer and pixel shaders sort it out." By contrast, the DOM may have any number of properties twiddled at any time, and the layout engine is forced to deal with that. A random float or something could cause hundreds and thousands of nodes to reflow. There is a cost to such flexibility, to be sure, but it's not inefficient for no good reason--the tradeoff was made to lower the entry to program it and to allow maximum malleability.
- deleted 11y ago
  [deleted]
- banachtarski 11y ago
  Written both. Not sure why it needs to be deferred rendering specifically lol. A forward renderer (or a light deferred, or tiled deferred, or forward plus, etc) would easily prove the same point. The precompiled logic thing is nonsense. This happens on the fly in games too. Shaders get compiled on the device, assets streamed in from disk or the network. Game behavior is typically scripted and patched, etc. Narrow selection of hardware? 10 years ago? Wrong. I work on a game engine that fully supports a 10 year old machine, and most state of the art engines can degrade to that level too. Goofy image formats? Please. DXT1-6, BC1-7, crunched assets, raw DDS, etc. We deal with tons of different formats, lossy and otherwise. Texture arrays, cubemaps, etc too. Malformed XML documents are trivial with a good lexer and we need tons of validation too on our side. Many games patch themselves. The game can scale to a mobile device believe or not. It just doesn't make sense to. Throttling draw calls or streaming only the lowest mip levels is trivial for a good engine. The web is absolutely 100% less efficient than a commercial game engine and does far far less. The flip side is that the barrier to entry is way lower as well. It takes less experience to write a web app than it takes to author a game. I would argue that authoring a web renderer is easier than authoring a state of the art game renderer too, although there are certainly complexities there. The DOM scene graph compared to a game scene graph? Come on, is there even a comparison? I could dump a scene graph for you which is totally dynamically generated in real time that dwarfs the most complicated web page you could find. I mean, heck, we use BVHs, KD trees, octrees, and more to represent our scene graphs. You think the DOM has even a fraction of that complexity? Too quote you, "seriously, just stop for a second and use your head."
  - angersock 11y ago
    I'll stick with my precompiled logic assertion. How many AAA games ship with a fully dynamic language like JS? Of those, how many then expose low-level APIs to those languages instead of just an operating environment suitable only for scripting? At any point, do those games allow trivial fetching of new code from the network from an unspecified source, parsing and executing that code in or out of a sandbox? As for "goofy image formats"--I'm going to be somewhat surprised if you aren't doing a preprocessing step to normalize your textures and images into either an atlas or at least some standard format (with texture compression or whatnot). I know that across the entire space of game engines there are bajillions of formats, but again, when you're building a custom engine for a game, I'm willing to bet that you can pick your battles in ways that browsers simply can't. The "malformed XML" isn't a simple matter of just "Oh, a missing closing tag!". It's "quirks" mode. It's supporting weird old behavior, bug-for-bug, across browser versions (thank you Microsoft). "The web is absolutely 100% less efficient than a commercial game engine and does far far less." See, from a performance standpoint, I wouldn't hesitate to agree that the web engines are less efficient. Similarly, I wouldn't claim that a gas turbine is less efficient than piston engine. However, piston engines are a lot more common because they're more flexible, easier to make, and can put up with a lot more nonsense. You lost me, though, when you said that the web does "far far less" than the specialized work a game engine does. "Come on, is there even a comparison?" Look at the spec: http://www.w3.org/TR/html5/rendering.html#rendering http://www.w3.org/TR/html5/rendering.html#rendering You're absolutely right--there's no comparison. Show me a modern game engine whose rendering pipeline is one tenth as complicated or well-specified! Sure, bang around about your scene-management structures for visibility tests. I'm sure that'll impress your friend at GDC who similarly rediscovering techniques already mined out twenty years ago--better than thirty in the case of octress. At the end of the day, game engines (from a display standpoint), are just rendering lots of triangles, with optional intermediary targets clever shading tricks. There may be some animation, there may be some physics, but all of that is relatively straightforward in implementation compared with the downright byzantine rules for, say, CSS: http://www.w3.org/TR/css-2010/ http://www.w3.org/TR/css-2010/ I'm not saying that game engines aren't impressive feats of engineering--they are in no way, however, near as complicated from anything other than a technical perspective when compared with a modern web browser.
- fsloth 11y ago
  I think your intuition, that game engines are a poor comparison to a virtual machine and GUI targeting general purpose computing, is fundamentally correct, since they have mostly different design and technological constraints. Your detailed rationales are a bit off though. The parsing and image processing bit should involve only preprocessing of data and not runtime performance, and should not take that long anyhow. The visible stuff a web browser does should not take exhaustive resources to get running nice and smooth. Also, since web is now most of all a UI tech in a sane world it should have the explicit design constraint of helping developers write fluid interfaces. I'm not sure what the root cause of the slowness of web tech in general but I'm guessing there is a megaton of accidental complexity in the standards and implementing them is probably a small hell in itself. From purely user facing side, and estimating intuitively the intrinsic complexity of the stuff a browser does, I would compare the experience just to the experience one gets on a modern desktop.
  - angersock 11y ago
    The thing about the parsing and image processing is this. Browser JS is completely allowed to, say every few frames in a setTimeout() or whatever, dynamically generate a pile of bytes, create an image from that pile, attach it to the DOM, randomly remove some other node from the DOM, and finally change the position property on a third node and cause everything to be reflowed. This all being done from substrings that it randomly selects together and then eval's. That level of pathological douchebaggery is rare (well, sorta, kinda) and yet browser vendors still have to write code that supports it as well as it can. I'm not sure what the root cause of the slowness of web tech in general but I'm guessing there is a megaton of accidental complexity in the standards and implementing them is probably a small hell in itself. Quite right! The problem with "slowness in web tech" is that there are just so many things that can be going wrong--slow CDNs, bad Angular code, whatever--that simply aren't the fault of the web, just the fault of sloppy developers. If the game engine bro who I've been going back-and-forth with wanted to claim that web developers were, in general, rather shit, I wouldn't disagree at all. I think that having design constraints might help with this, but honestly we've all gotten so much from the sheer flexibility of these janky sandboxes that every time I see people pining for native apps I die a little inside.
- marrs 11y ago
  Certainly, getting to market early, being stable, compatible, secure, accessible etc. is way more important than performance, but I think the hate is justified. Browsers are super-performant these days: JS and CSS engines are highly optimised, internet connections are very fast, server-side caching makes for an instant response, and yet web apps are slower and less compatible than they've ever been. You mention Angular, which is a big, slow, complex, and horrible framework. It's a fine example of the nonsense that is perpetuated all the time in the web dev world (I'd call it an extreme example if it wasn't used everywhere). I often say on here that all you need for most applications (that are currently adopting Angular) is a bit of jQuery, and I get pointed and laughed at every single time, but my jQuery app would be smaller, simpler, faster, and easier to maintain than its Angular equivalent for just about every use-case going. P.S. It makes me angry that you got down-voted for having an opinion - it seems that we've all got to think the same these days. Thanks for making a valuable contribution to this discussion.
andrepd 11y ago
Makes me wonder, as a non-web developer, would it be possible in principle to develop for the web in a low-level language like C/C++? What I mean is, is it only impractical and inconvenient for the developer, or is it fundamentally impossible?
- corysama 11y ago
  It's certainly possible today with emscripten. And, for an old C++ fart like me, it's rather tempting. I'm not saying it's advisable though...
- bentcorner 11y ago
  Definitely possible, but it's up to you whether or not you're willing to take the time to do it. Modern web apps "deploy" nicely and play well with modern OSs, but at the end of the day you're downloading a bunch of code and running it. Nothing says you couldn't have an OS that downloads compiled binaries and executes them for your web app. A browser just makes it easier to design a page with clicky buttons and text boxes.
- golergka 11y ago
  Javascript as an abstraction allows developer to have a significantly lower skill level. Remember designer that was upset that she was presented with a FizzBuzz on an interview, which she couldn't solve? She can write websites in Javascript, and actually provide value for people. And this is not only about the beginner developers. I'm a game developer myself, and I use garbage-collected C# with Unity engine instead of pure C++. This means that my games won't have performance or graphics of Human Revolution, but I'm able to prototype and change game logic much faster.
- pjc50 11y ago
  Your javascript is JIT-compiled and can be extremely fast (see asm.js). Conversely you can have extremely percieved-slow C++ applications (giant office suites etc.). It's not the speed of the language. This is like rookies swapping out multiplications for logical shifts and thinking it should make a big difference. It's the computational complexity. What would "develop for the web in a low-level language" even mean? An assembler interface to the DOM isn't going to help. The problem is the computational complexity of the task. Every CSS rule has potentially to be re-applied to every DOM object every time you change anything. Especially the sizing and layout ones. Because they're all interdependent, paralellism won't save you here. By comparison, games are so fast because pixels can be parallelised. You could build an alt-web if you had a suitably sealed VM running code in any language with access to the rendering portal and a security-enforcing network abstraction. This was what Java applets were supposed to be, and Flash is somewhat, but they had three problems: - fixed size: ability to cope with resize or different devices not built in - not as secure as hoped (javascript-to-local-user exploits have been very rare by comparison) - too slow to start up and too willing to hog resources when they did.
jim_greco 11y ago
What slack are you running? Slack or any web app doesn't take a second to redraw on resize.
xaduha 11y ago
Many games use Scaleform to create UI, which uses Adobe Flash. And I think it's possible to create UI using WebGL for example. Your comparison is just plain stupid. If you don't want to use these abstractions you can opt out, for the most part.
sebastianconcpt 11y ago
That's why I found fundamentally interesting the approach of famo.us It uses powerful rendering for mundane widgets (plus uses physics lo layout objects) so your JavaScrip programmed web apps and smartphone apps can do +60fps.
warfangle 11y ago
Games have to optimize for performance - if your game doesn't run smoothly on typical market hardware, it's a market failure (generally). Web applications have to optimize for flexibility of development. Performance is certainly important, but at a very different level (usually network and data retrieval) compared to games (massive SIMD operations).

by Siyo 11y ago

angersock 11y ago

I really, really hate it when people point at a web browser and a modern game engine and then say "Look how sloppy and horrible and inefficient the web is!" Seriously, just stop for a second and use your head. First, that game? Probably using precompiled logic--especially as games in the last decade have gotten objectively harder to mod. The browser must deal with any arbitrary code shoved at it, and handle modifications to its scene graph (the DOM) at any time. These modifications may include creating more script code, pulling in networked resources, or any other damn fool thing. Second, that game is only going to run on a narrow selection of hardware. It's not going to run on a machine from ten years ago, probably. It's not going to run on a machine ten years from now, probably. Third, that game is built to use files and formats specifically made for itself. It's not dealing with old goofy image formats. It's not dealing with potentially malformed XML documents. It's not dealing with any number of things, because those have been trimmed away and pre-verified. Fourth, that game is never going to have to scale from a multiple-socket workstation all the way down to a handheld phone or shell script. It's really silly to point at a hyperoptimized purpose-built tool and claim it is somehow massively better than a platform for distributing massively-varied media and documents. EDIT: Downvote away--but first, write a purpose-built pipeline for deferred rendering, and then a real-time app in Angular, for example. If you haven't done both of these things, you probably don't know what you're raging about.

charliefg 11y ago
I think many would agree with you, that most modern browsers with the expected features are pretty bloody efficient pieces of software. I believe what OP was saying was that the layers of abstraction used in building web application on top of the foundation the browser provides -- while really useful -- are also inefficient. This is to be expected since they do not usually have access to the full capabilities of the operating system and hardware.
reitzensteinm 11y ago
I have done both of those things (though my real time web app is written in React/cljs), and I agree entirely with the grandparent. The difference isn't in the technical details, the difference is that a chat app with a 1 second redraw can succeed in the marketplace, whereas a game with a 1 second redraw will never be played. The bloat and inefficient abstractions grow to the limit of our tolerance. If CPUs had hit the wall at 66mhz single core, that chat app would somehow still take the same 1s to redraw. Of course, it would probably be written in something like NaCL and have significantly more engineering effort put into optimization, with a browser stack engineered for high performance.
- sliverstorm 11y ago
  The bloat and inefficient abstractions grow to the limit of our tolerance. Which is tragic in some ways IMO. It means every system is always optimized to the level of misery where you are just barely not willing to do something about it. Which when you think about it sounds kind of like what you would expect from a lesser circle of hell.
- robmcm 11y ago
  Apparently in the early days of HDTV, cable/satellite companies would slowly reduce the quality of broadcasts until people started complaining. At which point they stopped. When BBC HD was a channel, its quanily was black and white to everything else, now even they are in on the reduced bandwidth game :(
WolfeReader 11y ago
If, in 10 years, I'm unable to play Deus Ex HR but all of these bloated, insecure, backdoored, "social" web sites are still supported, I might just quit this industry for good.
- voltagex_ 11y ago
  Vote at http://www.gog.com/wishlist/games/deus_ex_human_revolution http://www.gog.com/wishlist/games/deus_ex_human_revolution, buy the DRM-free version if it eventually comes out, then store it on good quality archival media.
- robmcm 11y ago
  Dont worry, you will be able to emulate it through a browser in your watch in 10 years :)
simoncion 11y ago
Here's the thing. You're replying to "...re-drawing when resizing the Slack chat window can take up to a second." 0) I agree that working with the DOM can get very complicated, and that layout can also be a hard problem[0]. Keep this in mind while you read the rest of my response. 1) When a browser goes to render a page, it does so from assets that have already been loaded and validated. All the fiddling with goofy image formats and malformed inputs is over and done with. All of those resources should have been processed by the browser into a format that's specifically made for the browser. So, when you resize the browser window, all[1] you're asking the browser to do is to reflow the page using the resources that some other code has specially prepared for rendering. 2) I bet you ten dollars that -if it had been compiled for a 64-bit machine- Deus Ex: HR would run on a machine manufactured in August, 2021. (Indeed, look at how well Starcraft 1 runs on machines built in 2008 and later. :) ) (Oh, BTW. Deus Ex: HR runs on the XBox 360; a machine that was released in November 2005... just about ten years ago. :) ) 3) Have you used Mobile Chrome or Mobile Firefox on a Nexus S (a phone released in December 2010)? I have and -when I have no other choice- do. They are slow as balls for web pages of any appreciable complexity. Hell, for rather complicated pages, they consistently get reaped by the Android OOM killer. 4) I assume that by "That game is never going to have to scale .. down ... to a ... shell script" you mean something like "The web is browsable through lynx. You will never have a text-mode version of Deus Ex: HR.". If the game dev was willing to let folks make Deus Ex: HR look like a game from the early 2000's (and run on machines from the mid-to-late 2000's), they could have inserted a checkbox that switched to pre-computed lighting and turned off (or greatly reduced the complexity of) all shaders. However, I bet you fifty dollars that a wide section of The Web is completely unusable on lynx (or even links, for that matter). Edit: Know that I've built soft-realtime networked GUI software with both OpenGL (using FLTK as the base) and a modern browser (with JQuery as the base). :) [0] However, TeX has been doing complicated page layout since the late 1970's. :) [1] Yes, I'm quite aware that browsers can do all sorts of things -including loading and processing new resources- when the viewport size changes. If you've written a web page that does so much work on viewport size change that redraw takes 1000ms or more, guess what? You've written a slow web page. :) If you build a game that requires 1000ms to render a single frame, guess what? You've built a slow game. :)
jlarocco 11y ago
I suspect you're being down voted because most of your claims are false. It's not hard to find counter examples for all all of them. And also because web developers made their own bed. It was web developers who decided it was a good idea to cram everything into the browser and make web pages into "web apps." They could have said, "Hey, this is dumb, doing this will be slow and inefficient, and here are the other technical reasons why it's a bad idea," but they never did that. Instead it's always, "Hey, look how I can make a low quality Doom clone in a browser that runs slower than original Doom did 22 years ago!" and hack after hack to get things running at a speed comparable to regular applications.
- jacquesm 11y ago
  The reason for that is not 'web developers' but rather the fact that a single delivery device for a huge variety of content without intermediaries is a thing no corporation will be able to ignore. That's what caused the envelope to be pushed as far and as fast as it did, and we all both enjoy the fruits of that and suffer because of it. It's like forcing a kid to grow from age 3 to age 30 in a few weeks time, it's bound to give trouble, no matter how impressive the feat may be technologically speaking.
  - Retric 11y ago
    There is a ton of unbelievably bad web code out there. jQuery is a great example of a 'huge' and popular slowdown for a minor gain. Sure, it's 'worth it' because nobody cares if a web app takes 1/2 second to render, but as soon as you trade speed for anything else you quickly end up with code that's as slow as your willing to live with. Having said that there are a few modern web-apps that really got 10x faster while sticking with HTML, CSS, and java-script so it's possible. The trick is stick with competent people and reasonable designs.
    - hhandoko 11y ago
      I believe it's been discussed many times before. Developers who use jQuery do so because it provides a good API / abstraction layer, as dealing with browser specific issues could be non-trivial.
jacquesm 11y ago
Have an upvote, dissenting opinions should at least be legible. That said, I really can't agree with you. Browsers can re-compile their input into whatever intermediary format they desire subject to the usual space/speed trade-offs. By the looks of it (judging by the space they need) they use that trade-off rather liberally in the 'speed' direction and they still run quite slow. I just can't imagine that laying out some text and images in 2d (which I've done for limited contexts) is that much harder than rendering a 3D scene (in software, not using a bunch of GPU power to do the heavy lifting) (which I've done, but not recently and definitely not with this kind of detail, roughly at the level of the original 'Doom' with a slightly better lighting model and right around the time it came out). Games may not have security issues in the input data that they consume when it comes to graphics and such, so that's a valid point but games do have to run on a wide variety of hardware and they typically adjust really gracefully. The one thing I think that really differentiates game rendering engines from browsers is that game engines tend to model some physical process whereas browsers attempt to implement a massive spec to allow any server it chooses to contact to send it a bunch of bytes the rendering result of which is not known ahead of time so arguably the games people have a relatively limited possible space of outputs they can generate whereas browsers theoretically can display anything including that game. That still doesn't excuse them for the crappy performance they deliver, that simply means we've moved too fast in adding layers before getting lower layers to perform adequately. The original web did not seem sluggish to me, it seemed about as fast as what you could expect from the hardware of the day, whereas the 'modern' web seems to be (to me) terribly slow and inefficient. The ratio of content:markup+eye candy has deteriorated and I suspect that that is part of the answer here (and of course that would not be the browsers fault per-se).
- angersock 11y ago
  The web doesn't deliver crappy performance, though--apps written by bad developers deliver crappy performance. The complaints about the abstractions and everything honestly remind me of the complaints about Java, and look how that turned out over the same time period. As for the engine vs. browser thing--you can totally render a DOM super efficiently if you are sure that it remains relatively static. That's very much, in fact, how the game engines do so well. They have the task of "throw as much as we can in triangle buffers onto the card, and occasionally draw with uniforms set to our desired transform matrices, and let the Z-buffer and pixel shaders sort it out." By contrast, the DOM may have any number of properties twiddled at any time, and the layout engine is forced to deal with that. A random float or something could cause hundreds and thousands of nodes to reflow. There is a cost to such flexibility, to be sure, but it's not inefficient for no good reason--the tradeoff was made to lower the entry to program it and to allow maximum malleability.
deleted 11y ago
[deleted]
banachtarski 11y ago
Written both. Not sure why it needs to be deferred rendering specifically lol. A forward renderer (or a light deferred, or tiled deferred, or forward plus, etc) would easily prove the same point. The precompiled logic thing is nonsense. This happens on the fly in games too. Shaders get compiled on the device, assets streamed in from disk or the network. Game behavior is typically scripted and patched, etc. Narrow selection of hardware? 10 years ago? Wrong. I work on a game engine that fully supports a 10 year old machine, and most state of the art engines can degrade to that level too. Goofy image formats? Please. DXT1-6, BC1-7, crunched assets, raw DDS, etc. We deal with tons of different formats, lossy and otherwise. Texture arrays, cubemaps, etc too. Malformed XML documents are trivial with a good lexer and we need tons of validation too on our side. Many games patch themselves. The game can scale to a mobile device believe or not. It just doesn't make sense to. Throttling draw calls or streaming only the lowest mip levels is trivial for a good engine. The web is absolutely 100% less efficient than a commercial game engine and does far far less. The flip side is that the barrier to entry is way lower as well. It takes less experience to write a web app than it takes to author a game. I would argue that authoring a web renderer is easier than authoring a state of the art game renderer too, although there are certainly complexities there. The DOM scene graph compared to a game scene graph? Come on, is there even a comparison? I could dump a scene graph for you which is totally dynamically generated in real time that dwarfs the most complicated web page you could find. I mean, heck, we use BVHs, KD trees, octrees, and more to represent our scene graphs. You think the DOM has even a fraction of that complexity? Too quote you, "seriously, just stop for a second and use your head."
- angersock 11y ago
  I'll stick with my precompiled logic assertion. How many AAA games ship with a fully dynamic language like JS? Of those, how many then expose low-level APIs to those languages instead of just an operating environment suitable only for scripting? At any point, do those games allow trivial fetching of new code from the network from an unspecified source, parsing and executing that code in or out of a sandbox? As for "goofy image formats"--I'm going to be somewhat surprised if you aren't doing a preprocessing step to normalize your textures and images into either an atlas or at least some standard format (with texture compression or whatnot). I know that across the entire space of game engines there are bajillions of formats, but again, when you're building a custom engine for a game, I'm willing to bet that you can pick your battles in ways that browsers simply can't. The "malformed XML" isn't a simple matter of just "Oh, a missing closing tag!". It's "quirks" mode. It's supporting weird old behavior, bug-for-bug, across browser versions (thank you Microsoft). "The web is absolutely 100% less efficient than a commercial game engine and does far far less." See, from a performance standpoint, I wouldn't hesitate to agree that the web engines are less efficient. Similarly, I wouldn't claim that a gas turbine is less efficient than piston engine. However, piston engines are a lot more common because they're more flexible, easier to make, and can put up with a lot more nonsense. You lost me, though, when you said that the web does "far far less" than the specialized work a game engine does. "Come on, is there even a comparison?" Look at the spec: http://www.w3.org/TR/html5/rendering.html#rendering http://www.w3.org/TR/html5/rendering.html#rendering You're absolutely right--there's no comparison. Show me a modern game engine whose rendering pipeline is one tenth as complicated or well-specified! Sure, bang around about your scene-management structures for visibility tests. I'm sure that'll impress your friend at GDC who similarly rediscovering techniques already mined out twenty years ago--better than thirty in the case of octress. At the end of the day, game engines (from a display standpoint), are just rendering lots of triangles, with optional intermediary targets clever shading tricks. There may be some animation, there may be some physics, but all of that is relatively straightforward in implementation compared with the downright byzantine rules for, say, CSS: http://www.w3.org/TR/css-2010/ http://www.w3.org/TR/css-2010/ I'm not saying that game engines aren't impressive feats of engineering--they are in no way, however, near as complicated from anything other than a technical perspective when compared with a modern web browser.
fsloth 11y ago
I think your intuition, that game engines are a poor comparison to a virtual machine and GUI targeting general purpose computing, is fundamentally correct, since they have mostly different design and technological constraints. Your detailed rationales are a bit off though. The parsing and image processing bit should involve only preprocessing of data and not runtime performance, and should not take that long anyhow. The visible stuff a web browser does should not take exhaustive resources to get running nice and smooth. Also, since web is now most of all a UI tech in a sane world it should have the explicit design constraint of helping developers write fluid interfaces. I'm not sure what the root cause of the slowness of web tech in general but I'm guessing there is a megaton of accidental complexity in the standards and implementing them is probably a small hell in itself. From purely user facing side, and estimating intuitively the intrinsic complexity of the stuff a browser does, I would compare the experience just to the experience one gets on a modern desktop.
- angersock 11y ago
  The thing about the parsing and image processing is this. Browser JS is completely allowed to, say every few frames in a setTimeout() or whatever, dynamically generate a pile of bytes, create an image from that pile, attach it to the DOM, randomly remove some other node from the DOM, and finally change the position property on a third node and cause everything to be reflowed. This all being done from substrings that it randomly selects together and then eval's. That level of pathological douchebaggery is rare (well, sorta, kinda) and yet browser vendors still have to write code that supports it as well as it can. I'm not sure what the root cause of the slowness of web tech in general but I'm guessing there is a megaton of accidental complexity in the standards and implementing them is probably a small hell in itself. Quite right! The problem with "slowness in web tech" is that there are just so many things that can be going wrong--slow CDNs, bad Angular code, whatever--that simply aren't the fault of the web, just the fault of sloppy developers. If the game engine bro who I've been going back-and-forth with wanted to claim that web developers were, in general, rather shit, I wouldn't disagree at all. I think that having design constraints might help with this, but honestly we've all gotten so much from the sheer flexibility of these janky sandboxes that every time I see people pining for native apps I die a little inside.
marrs 11y ago
Certainly, getting to market early, being stable, compatible, secure, accessible etc. is way more important than performance, but I think the hate is justified. Browsers are super-performant these days: JS and CSS engines are highly optimised, internet connections are very fast, server-side caching makes for an instant response, and yet web apps are slower and less compatible than they've ever been. You mention Angular, which is a big, slow, complex, and horrible framework. It's a fine example of the nonsense that is perpetuated all the time in the web dev world (I'd call it an extreme example if it wasn't used everywhere). I often say on here that all you need for most applications (that are currently adopting Angular) is a bit of jQuery, and I get pointed and laughed at every single time, but my jQuery app would be smaller, simpler, faster, and easier to maintain than its Angular equivalent for just about every use-case going. P.S. It makes me angry that you got down-voted for having an opinion - it seems that we've all got to think the same these days. Thanks for making a valuable contribution to this discussion.

andrepd 11y ago

Makes me wonder, as a non-web developer, would it be possible in principle to develop for the web in a low-level language like C/C++? What I mean is, is it only impractical and inconvenient for the developer, or is it fundamentally impossible?

corysama 11y ago
It's certainly possible today with emscripten. And, for an old C++ fart like me, it's rather tempting. I'm not saying it's advisable though...
bentcorner 11y ago
Definitely possible, but it's up to you whether or not you're willing to take the time to do it. Modern web apps "deploy" nicely and play well with modern OSs, but at the end of the day you're downloading a bunch of code and running it. Nothing says you couldn't have an OS that downloads compiled binaries and executes them for your web app. A browser just makes it easier to design a page with clicky buttons and text boxes.
golergka 11y ago
Javascript as an abstraction allows developer to have a significantly lower skill level. Remember designer that was upset that she was presented with a FizzBuzz on an interview, which she couldn't solve? She can write websites in Javascript, and actually provide value for people. And this is not only about the beginner developers. I'm a game developer myself, and I use garbage-collected C# with Unity engine instead of pure C++. This means that my games won't have performance or graphics of Human Revolution, but I'm able to prototype and change game logic much faster.
pjc50 11y ago
Your javascript is JIT-compiled and can be extremely fast (see asm.js). Conversely you can have extremely percieved-slow C++ applications (giant office suites etc.). It's not the speed of the language. This is like rookies swapping out multiplications for logical shifts and thinking it should make a big difference. It's the computational complexity. What would "develop for the web in a low-level language" even mean? An assembler interface to the DOM isn't going to help. The problem is the computational complexity of the task. Every CSS rule has potentially to be re-applied to every DOM object every time you change anything. Especially the sizing and layout ones. Because they're all interdependent, paralellism won't save you here. By comparison, games are so fast because pixels can be parallelised. You could build an alt-web if you had a suitably sealed VM running code in any language with access to the rendering portal and a security-enforcing network abstraction. This was what Java applets were supposed to be, and Flash is somewhat, but they had three problems: - fixed size: ability to cope with resize or different devices not built in - not as secure as hoped (javascript-to-local-user exploits have been very rare by comparison) - too slow to start up and too willing to hog resources when they did.

jim_greco 11y ago

What slack are you running? Slack or any web app doesn't take a second to redraw on resize.

xaduha 11y ago

Many games use Scaleform to create UI, which uses Adobe Flash. And I think it's possible to create UI using WebGL for example. Your comparison is just plain stupid. If you don't want to use these abstractions you can opt out, for the most part.

sebastianconcpt 11y ago

That's why I found fundamentally interesting the approach of famo.us It uses powerful rendering for mundane widgets (plus uses physics lo layout objects) so your JavaScrip programmed web apps and smartphone apps can do +60fps.

warfangle 11y ago

Games have to optimize for performance - if your game doesn't run smoothly on typical market hardware, it's a market failure (generally). Web applications have to optimize for flexibility of development. Performance is certainly important, but at a very different level (usually network and data retrieval) compared to games (massive SIMD operations).