5 ms·

For most applications JS doesn't need to get any quicker. What makes web apps feel like swimming through molasses is the DOM. Even something as simple as getti

by ux-app 13y ago

For most applications JS doesn't need to get any quicker. What makes web apps feel like swimming through molasses is the DOM. Even something as simple as getting a Div to follow the mouse on anything but the simplest of pages is impossible to do without incurring ridiculous lag. I don't know enough about them, but it seems that maybe Web Components may offer some answers by encapsulating mini Document trees which presumably exist in isolation from other components thereby reducing the penalties of dynamic CSS.

ihsw 13y ago
> What makes web apps feel like swimming through molasses is the DOM. I would contend that network latency and the plethora of domains queried to be a greater impediment to a speedy web. DOM manipulation may be absurdly slow however it cannot hold a candle to latency hold-ups. Most readers on HN live in a quiet and peaceful bubble of high-quality network connections, but the majority of the world is beginning to wake up to the web and they'll have to endure latency issues that we haven't experienced since "broadband" was a new concept.
- carbocation 13y ago
  Quite a few HNers have probably experienced lossy connections such as Amtrak or busy coffee shops. I would think that those high-loss situations would feel somewhat like a high latency experience.
  - wslh 13y ago
    Lossy mobile connections are very common in the world.
- derleth 13y ago
  But we do know how to handle bad latency, don't we? Speculative loading, which got a bad name because it makes wallhacks on FPSes work but really has almost no downside once the client can't do anything malicious with a little information the human isn't using yet. If the real problem isn't latency but bandwidth or bandwidth caps, that will require other solutions.
- pyre 13y ago
  | DOM manipulation may be absurdly slow however | it cannot hold a candle to latency hold-ups. Just an anecdote, but jQueryUI + IE8 took 8 seconds to style all of the buttons[1] we had on a page during one call. Granted, we had a ton of buttons (most were hidden), but that's a lot of time. The same call on Firefox and Chrome were fractions of a second (can't remember the exact numbers, but Chrome was faster at the time), and this was a couple of years ago. DOM manipulation can be a real drag. [1] http://jqueryui.com/button/ http://jqueryui.com/button/
untog 13y ago
What makes web apps feel like swimming through molasses is the DOM. In my experience, it's the lack of threading. Or any way to perform an operation without affecting the UI. Web Workers go a long way to solving this, but they're limited in what they can do.
- ux-app 13y ago
  Not sure I agree with this. Very few web applications are CPU bound to the point of locking the UI. Web Workers are extremely useful, however very few current web apps benefit from them. Given they cannot interact with the DOM they are limited to pure number crunching. Great if you're ray tracing or encoding/decoding sound or video, not much use to the other 99% of web apps. My understanding is that parsing CSS rules and updating the DOM are incredibly costly operations which none of the browser vendors have yet decided to optimise.
  - daeken 13y ago
    > My understanding is that parsing CSS rules and updating the DOM are incredibly costly operations which none of the browser vendors have yet decided to optimise. These operations are extremely well-optimized. The reason they're slow is that they're also extremely complex and slow operations. It's not something you can hack around.
    - ux-app 13y ago
      > The reason they're slow is that they're also extremely complex and slow operations. In that case it seems that we need something new to replace CSS for layout. Or maybe a 'strict mode' equivalent for CSS where styling is separated from layout. In this mode rules that affect style (bold, font etc) cannot affect container dimensions. This mode would include a subset of rules that affect only layout (position, width, height etc). This would presumably greatly reduce the impact of the parse/dom traversal/paint cycle of CSS.
      - untog 13y ago
notatoad 13y ago
For most applications, the Dom is the weak point because manipulating the Dom is as ambitious as the apps get. The exciting part of asm.js is not that it can speed up existing apps, it's all the cool new things you can do on the client side now that were simply to slow to be possible before.
- ux-app 13y ago
  Yeah that's a fair point. What kinds of new apps do you think this will enable (besides games)? It seems that the DOM will continue to be the major bottleneck since presumably the GUI for these new apps will still be DOM based.
  - chii 13y ago
    i see porting over existing codebases and rendering not via DOM but webgl as the path this takes on.
  - Yoric 13y ago
    I expect Virtual Machines for domain-specific languages. I also expect (de)compression, cryptography, number-crunching, graphics algorithms, etc.
just2n 13y ago
Like this? http://jsfiddle.net/eymAS/2/ http://jsfiddle.net/eymAS/2/ The DOM is faster than almost everyone believes. It's not 2001 anymore, guys. Web components solve a lot of major problems, but it has little to do with DOM/CSS performance and more to do with encapsulation (ie, so your CSS/HTML/JS don't break a component). DocumentFragments and insertAdjacentHTML solved more performance problems for the DOM than most other API changes have, and smarter compositing/painting algorithms in browsers (along with hardware acceleration) have made it possible to do some pretty ridiculous stuff.
- ChuckMcM 13y ago
  Man, that is just scary fast :-)
  - krebby 13y ago
    It should be, it's hardware-accelerated (take a look at the translate3d hack) Paul Irish did a good writeup here: http://www.paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/ http://www.paulirish.com/2012/why-moving-elements-with-trans...
    - just2n 13y ago
      Yep. Here's a version without using 3d (no layers generated for the followers): http://jsfiddle.net/eymAS/29/ http://jsfiddle.net/eymAS/29/ The layout/composition/painting etc is taking roughly 5x longer now. Chrome is smart enough to do it all just once, though, so it's still relatively performant.
- fhd2 13y ago
  Here's a version that's not Chrome-only: http://jsfiddle.net/eymAS/21/ http://jsfiddle.net/eymAS/21/ I've been wondering why I keep hearing that the DOM is supposed to be slow. Don't people mean to say that rendering (i.e. mostly CSS) is slow? This fiddle is certainly not doing much with the DOM except setting style attributes.
  - 13y ago

by ux-app 13y ago

ihsw 13y ago

> What makes web apps feel like swimming through molasses is the DOM. I would contend that network latency and the plethora of domains queried to be a greater impediment to a speedy web. DOM manipulation may be absurdly slow however it cannot hold a candle to latency hold-ups. Most readers on HN live in a quiet and peaceful bubble of high-quality network connections, but the majority of the world is beginning to wake up to the web and they'll have to endure latency issues that we haven't experienced since "broadband" was a new concept.

carbocation 13y ago
Quite a few HNers have probably experienced lossy connections such as Amtrak or busy coffee shops. I would think that those high-loss situations would feel somewhat like a high latency experience.
- wslh 13y ago
  Lossy mobile connections are very common in the world.
derleth 13y ago
But we do know how to handle bad latency, don't we? Speculative loading, which got a bad name because it makes wallhacks on FPSes work but really has almost no downside once the client can't do anything malicious with a little information the human isn't using yet. If the real problem isn't latency but bandwidth or bandwidth caps, that will require other solutions.
pyre 13y ago
| DOM manipulation may be absurdly slow however | it cannot hold a candle to latency hold-ups. Just an anecdote, but jQueryUI + IE8 took 8 seconds to style all of the buttons[1] we had on a page during one call. Granted, we had a ton of buttons (most were hidden), but that's a lot of time. The same call on Firefox and Chrome were fractions of a second (can't remember the exact numbers, but Chrome was faster at the time), and this was a couple of years ago. DOM manipulation can be a real drag. [1] http://jqueryui.com/button/ http://jqueryui.com/button/

untog 13y ago

What makes web apps feel like swimming through molasses is the DOM. In my experience, it's the lack of threading. Or any way to perform an operation without affecting the UI. Web Workers go a long way to solving this, but they're limited in what they can do.

ux-app 13y ago
Not sure I agree with this. Very few web applications are CPU bound to the point of locking the UI. Web Workers are extremely useful, however very few current web apps benefit from them. Given they cannot interact with the DOM they are limited to pure number crunching. Great if you're ray tracing or encoding/decoding sound or video, not much use to the other 99% of web apps. My understanding is that parsing CSS rules and updating the DOM are incredibly costly operations which none of the browser vendors have yet decided to optimise.
- daeken 13y ago
  > My understanding is that parsing CSS rules and updating the DOM are incredibly costly operations which none of the browser vendors have yet decided to optimise. These operations are extremely well-optimized. The reason they're slow is that they're also extremely complex and slow operations. It's not something you can hack around.
  - ux-app 13y ago
    > The reason they're slow is that they're also extremely complex and slow operations. In that case it seems that we need something new to replace CSS for layout. Or maybe a 'strict mode' equivalent for CSS where styling is separated from layout. In this mode rules that affect style (bold, font etc) cannot affect container dimensions. This mode would include a subset of rules that affect only layout (position, width, height etc). This would presumably greatly reduce the impact of the parse/dom traversal/paint cycle of CSS.
    - untog 13y ago

notatoad 13y ago

For most applications, the Dom is the weak point because manipulating the Dom is as ambitious as the apps get. The exciting part of asm.js is not that it can speed up existing apps, it's all the cool new things you can do on the client side now that were simply to slow to be possible before.

ux-app 13y ago
Yeah that's a fair point. What kinds of new apps do you think this will enable (besides games)? It seems that the DOM will continue to be the major bottleneck since presumably the GUI for these new apps will still be DOM based.
- chii 13y ago
  i see porting over existing codebases and rendering not via DOM but webgl as the path this takes on.
- Yoric 13y ago
  I expect Virtual Machines for domain-specific languages. I also expect (de)compression, cryptography, number-crunching, graphics algorithms, etc.

just2n 13y ago

Like this? http://jsfiddle.net/eymAS/2/ http://jsfiddle.net/eymAS/2/ The DOM is faster than almost everyone believes. It's not 2001 anymore, guys. Web components solve a lot of major problems, but it has little to do with DOM/CSS performance and more to do with encapsulation (ie, so your CSS/HTML/JS don't break a component). DocumentFragments and insertAdjacentHTML solved more performance problems for the DOM than most other API changes have, and smarter compositing/painting algorithms in browsers (along with hardware acceleration) have made it possible to do some pretty ridiculous stuff.

ChuckMcM 13y ago
Man, that is just scary fast :-)
- krebby 13y ago
  It should be, it's hardware-accelerated (take a look at the translate3d hack) Paul Irish did a good writeup here: http://www.paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/ http://www.paulirish.com/2012/why-moving-elements-with-trans...
  - just2n 13y ago
    Yep. Here's a version without using 3d (no layers generated for the followers): http://jsfiddle.net/eymAS/29/ http://jsfiddle.net/eymAS/29/ The layout/composition/painting etc is taking roughly 5x longer now. Chrome is smart enough to do it all just once, though, so it's still relatively performant.
fhd2 13y ago
Here's a version that's not Chrome-only: http://jsfiddle.net/eymAS/21/ http://jsfiddle.net/eymAS/21/ I've been wondering why I keep hearing that the DOM is supposed to be slow. Don't people mean to say that rendering (i.e. mostly CSS) is slow? This fiddle is certainly not doing much with the DOM except setting style attributes.
- 13y ago