Hacker News Reader

Comment by protonfish | Hacker News Reader

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.

View on HN

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

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?

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

Reply on news.ycombinator.com