Hacker News Reader

Comment by just2n | Hacker News Reader

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.

View on HN

So now we're going to say that in 2013 it is impressive that 160 rectangles can follow a mouse cursor? I see the advantages of client/server applications (as they used to be called), and presumably js/css apps will continue to get faster and asymptotically approach their client-only functional equivalents, but there is a thing about a hammer and all problems looking like nails that springs to mind when I see people claim that moving 160 rectangles in 16 ms / frame is 'scary fast'...

The parent's comment was that it is essentially infeasible to have a single div follow the cursor due to performance issues with the DOM. The fiddle includes 160 divs and opacity to demonstrate that that claim is false.

There's an awful lot of red herring going on in your post. It sounds like you have some problems with the web, but they most certainly aren't relevant to this discussion.

Oh I have no problems with the web, it has been providing me with a good living for well over a decade. Maybe that's my problem - that I remember the times when things that are being described now as 'great' or 'fast' were solved already, and my frustration is that instead of moving forward, we now have to repeat the last decade except with js/css before we can really start to innovate again.

Unreal engine in the browser? Seriously? Because of what - because it's easier to update people's clients when they download it again every time they visit your website? We had web launchers and auto-updating that solved everything the web brings as an advantage over desktop applications (in the use cases that require fast graphics, i.e. not CRUD line of business applications) years ago.

The elephant in the room here is that people want to push web applications because it's easier to make money from them, and you can make more of it, over a longer time. Look, I do it too, I know that the web beats the pants off client-only software from a business point of view. But let's call a spade a spade and not tip toe around it with bullshit pseudo-arguments like 'ease of deployability' and 'social sharing' and 'portability' and 'platform-agnosticity'.

If an app that had no sustainable future as a native app becomes possible as a web app, don't users also benefit? The fact is that many people are willing to pay for a service they continue to get value from month after month. And the recurring revenue also usually comes with recurring support because companies have to keep winning customer loyalty in a way they never have to with a one time sale. I think it is a net win for both customers and the companies selling the services.

And developers win because there are more viable businesses which need their skills over the long term.

Should it be possible to sell a native app as a service? Maybe, but supporting a native app professionally is much more difficult than you seem to be acknowledging. Have you ever supported a native app in the wild across a wide variety of generic PC hardware for novice users?

"If an app that had no sustainable future as a native app becomes possible as a web app, don't users also benefit?"

Of course they do, therefore charging for software (desktop & web alike) = good. Make no mistake on which side in that debate I'm on. But let's call it like that.

"And developers win because there are more viable businesses which need their skills over the long term."

Sure, and it's no more than fair, and the natural order to boot.

"Have you ever supported a native app in the wild across a wide variety of generic PC hardware for novice users?"

I'm glad you ask, because actually yes I do, and it's a pain in the ass for the most part. And for the parts where it makes sense, I have moved parts of the services we offer to web applications. Therefore I feel I'm experienced enough to compare the advantages and disadvantages of the two, and from that I criticize the developments of people wanting to shoehorn everything into the browser, either because of covered up ulterior motives, or because it's all they know and want to know. But again - then say so, and don't sugarcoat it under the fuzzy 'it's better for the user' rhetoric that is so prevalent.

I should add that another reason can be "because I can", which is a perfectly fine reason too, but then label it as such so that naive greenhorns don't start pushing production systems in this direction, requiring others to then deal with the fallout.

For me the movement is smooth but it still lags behind the mouse with 10-20 px. The Firefox version of the demo has a little less lag but still looks disconnected from the mouse when moved.

The problem is that the DOM is a hard upper limit on performance compared to what the performance of an unsafe language (asm.js) is. It is massively complex because it must perform every UI task in the browser and simply moving around DIVs doesn't give you a feel for its the performance in complex scenarios.

If you think about how native applications perform and then imagine every one having to go through a DOM interface and every button and UI interaction being composed of DOM elements and re-styling these elements on every interaction you get a sense of what the problem is. There is simply no way to get the DOM to do something it wasn't designed to do, which is to be a document display interface and not a general graphical user interface. You have to clobber together a lot of interactions to get the desired behavior and not only does this increase the overhead for both your program and the DOM you are going to hit cases where the DOM isn't optimized.

This doesn't mean that the DOM is inherently slow. If you tried to offload the UI work onto javascript you wouldn't get the performance benefit of doing that on Asm.js or NACL. You really need unsafe code to solve this problem. Asm.js and NACL are only useful if you are going to do this; targeting the Canvas and WebGL gives you the ability to do that.

asm.js is not an "unsafe language".

/be

What you describe -- "imagine every one having to go through a DOM interface and every button and UI interaction being composed of DOM elements and re-styling these elements on every interaction" -- is exactly how Firefox is built. The desktop Firefox UI is all DOM elements (not HTML, but still the same underlying DOM code).

Hovering over a toolbar button or a tab causes a CSS style rule for a :hover effect to be applied. Opening a new tab uses CSS animation for the transition. Moving tabs around manipulates the DOM and moves the tab elements (which are themselves composed of images, labels, etc.).

And yet, the Firefox UI is plenty snappy -- yes, you can argue that there are slowdowns and issues that need to be fixed, but no more or less than in many "native" apps.

That is very cool. I got quite bad rubber banding initially (with a reported 60fps), however after turning off v-sync in chrome://flags I got super smooth 120fps performance.

Would be great if Chrome had this option off by default.

> Would be great if Chrome had this option off by default.

Disabling Vsync causes page tearing artifacts (https://en.wikipedia.org/wiki/Page_tearing). It should always be enabled by default. Some new gpu drivers also have "adaptive vsync", where it's enabled by default but gets temporarily disabled when deadlines are not met.

isn't tearing preferable to input lag? As I mentioned, with v-sync on there is a very noticeable rubber-banding effect, with it off the result is (perceptually) far smoother.

>It [vsync] should always be enabled by default

Not sure about this. Surely the goal is to maximize perceived performance not 'correctness' (where correctness in this context is defined as each frame being fully drawn before the next one starts).

> isn't tearing preferable to input lag?

In a properly written app, vsync should not cause input lag despite gamer superstitions. But there are lots of not-properly written apps where this is a problem.

WebGL / Chrome should solve the problem in some other way, not disabling vsync. Or using adaptive vsync if available as a workaround.

The culprit here might be the ANGLE OpenGLES2-on-D3D9 wrapper that Chrome uses, which is notoriously slow on synchronous operations like vsync, glGetError or glFinish.

That was just caused by me not processing input properly. I've set up a proper rendering loop here and now only render the most recent mouse position on each frame:

http://jsfiddle.net/eymAS/84/

It's better, but still limited to 60fps, and since I render to the state at 0s, the worst delay we can see is ~16.6ms + rendering time.

Here's a version that's not Chrome-only: 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.

People generally mean their manipulation of DOM is effectively slow. That's a perfectly accurate statement, but the problem is calling the DOM slow as a result. The real culprit is often that doing stupid things with the DOM cause style recalcs, reflows, layouts, compositing, painting, etc. Those are all comparatively expensive.

The problem with the DOM is not that it's intrinsically slow, but that it's very easy to do slow things with it inadvertently. There are often N different ways to do things, due to the evolution of HTML. The newer approaches tend to be designed with things like GPU acceleration in mind (e.g. CSS transforms), whereas older methods often had lots of heavy interactions and computations because they weren't expected to be used dynamically.

Just like optimizing any software takes skill and knowledge, so too does writing HTML, whether dynamic or not. Tools for understanding what's going on with the DOM and with dynamic HTML are slowly becoming available as well, which will help with this.

Man, that is just scary fast :-)

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-trans...

Yep. Here's a version without using 3d (no layers generated for the followers): 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.

Reply on news.ycombinator.com