Hacker News Reader

Comment by shawndumas | Hacker News Reader

"The DOM is slow": with all the advancement of the JS engines we'll hit a wall if the DOM does not start improving by an order of magnitude.

Is this a fundamental problem or is this a case of JS being so bad that now that it's faster it is exposing a need to focus on the DOM?

View on HN

I write a lot of mobile web apps and find that the DOM is blazing fast. I wish I knew some examples of why people think that it is slow, but I have a few guesses.

1. Your mobile web framework is slow, not the browser DOM. Ditch your bloated frameworks - writing JavaScript without external libraries is not rocket science.

2. There are deliberate pauses in the DOM. The onclick event is very slow and unresponsive. I get very fast UIs by replacing it with ontouchstart

3. You are using too many animations. Smooth animations can work in mobile web, to a degree. But honestly, if the big reason nobody wants to do mobile web is because it doesn't support copious animations, I see that as a positive. I'd rather have a UI that just does what it should without having to wait through all the fanciness.

>I'd rather have a UI that just does what it should without having to wait through all the fanciness.

Well, you would rather have it, just like some would rather have a Lynx-like interface. This doesn't address the point, which is users go to native because web just can't bring native-like experience.

Why is native-like better? Explain.

> But honestly, if the big reason nobody wants to do mobile web is because it doesn't support copious animations, I see that as a positive. I'd rather have a UI that just does what it should without having to wait through all the fanciness.

Well, except native apps let you have those animations without waiting, is the thing.

I'd love to see some examples of non-trivial apps written in pure JavaScript which:

a) has decent browser compatibility b) is not a rat's nest of shims and polyfills c) could be maintained by more than one person

Why browser compatibility? Why polyfills?

I don't understand the logic that goes from "Modern browsers with fast JS engines make fancy web apps practical" to "let's make sure our fancy web apps run in old browsers with slow JS engines."

The original commenter asserts the DOM feels slow because we use bloated frameworks rather than pure JS. Sure, you certainly can use pure JS to target a select few modern browsers, but I've yet to see a practical story on how to build apps for the rest of the web at large this way.

Are we saying in order to go fast, we should eschew the progress we've made in compatibility to accomplish it?

In some cases, yes.

If you are committed to doing everything in JS, then you have two choices:

1. Deliver a degraded experience to modern browsers and a terrible experience to older browsers.

2. Deliver a good experience to modern browsers and no experience at all to older browsers.

Depending on your business model, #1 may be the best choice. But if you're trying to compete with native apps then #2 is the only thing that makes sense.

Luckily browser compat is not really an issue any more. If you have customers on ie8, the new fastness does not apply to them.

Good point. But I doubt any of my recent cross-browser web apps you would consider non-trival. I have recently only been doing simple wireframed prototypes for UI experimentation (like this: http://chrisbroski.github.io/sketchpad-calculator/) I did write a fancy web app with graphics and animations a few years ago but it was an intranet app targeted to iPhone only.

I know it is possible because I have done it. Sadly, few others have done it probably more because of the FUD surrounding mobile web than for any real reason (the best one I have heard is that mobile web can't handle animations well.) The truth is mobile browsers are better at handling JavaScript and DOM today more than ever, and continue to improve. Maybe today mobile web isn't ready for prime time, but tomorrow will be here soon.

So really you did not do it? You had one complex app which was not cross-platform and then several experiments, but somehow you extrapolate what is possible and what is not?

>with all the advancement of the JS engines we'll hit a wall if the DOM does not start improving by an order of magnitude

We already hit that wall a long time ago. DOM is the bottleneck in any non-trivial app (unless your app mines bitcoins or something).

Agreed! Further, things like DOM diffing help but are an optimisation and can only take us so far. The answer is in the layout engine, no?

DOM implementations have had vast improvements over the past years, vendors these days are working on nanosecond improvements to DOM operations. "The DOM is slow" usually refers to design problems that can't be optimized away, like being 99% synchronous, exposing APIs that invalidate layout at arbitrary times, etc. So yes, a fundamental problem that was exacerbated by the incredible advancement of JS engines over the last few years, causing developers to build more and more complicated web apps.

To be honest, the fact that the DOM is as good as it is today is very impressive to me, considering how old it is and how much the landscape has changed.

I often see native, iOS app being sluggish and I don't blame it on Objective-C or Swift. I blame it on the application. I don't understand how it's different when it comes to web apps.

I don't know how fundamental the problem is in terms of fixing it, but it is fundamental in making mobile webapps. I remember making an auto-complete friend selector a while ago (the kind that filters as you type) - I had the JS filtering through names in less than 10ms, but the resulting DOM updates immediately brought every keypress to around 400ms, which is visibly slow, and worse, laggy.

I started work on a canvas-powered alternative before giving up - but I'm glad to see the React Canvas has gone with it. When I have some free time I'll be playing around with it to see if it lives up to the hype.

It depends entirely on what your app does – but yes, I'd paint this as a fundamental problem for any app that needs to render a large amount of content (and keep it updated).

JavaScript is slow. DOM is really slow, but JavaScript is fundamentally slow. It's slower than Java and way slower than Obj-C and always will be. Excellent writeup here: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow...

Reply on news.ycombinator.com