Hacker News Reader

Hacker News

Comment by venning | Hacker News Reader

Parent Full thread

venning

> Scroll like a native app without Safari's stupid rubber band scrolling the entire app at very erratic times

This is defeatable, either with `-webkit-overflow-scrolling: touch;` or other techniques.

> Background geolocation, background anything really

You mean, Service Workers?

> Display long lists of styled content and scroll without stalling

I could be wrong, but I think this is a Safari-specific concern. Android Chrome has never had this problem for me. In older versions of iOS, Safari was not able to execute Javascript while scrolling which could be perceived as "stalled" rendering. I'm not sure if that's what you mean, but Apple has been gradually working to allow JS execution during scroll. But they're so behind (in years) that I wonder if there are still some cases where the execution can't keep up with the scroll.

View on HN

The web is crap at long lists in general. Try to build something like Mail on iOS or OS X, which shows you all of your email in a big list: the best you can do is infinite-scroll solutions like Yahoo! Mail, which are horrible on every browser.

I've definitely had problems with this. There's a lot of bloat that comes with the DOM, especially if you use a framework like Polymer or Angular. Even something as simple as a material-design text entry field requires a horrific amount of CSS bloat to accomplish internally, and if you multiply that by, say, 1000, you're in for trouble.

Perspective is important :) Putting 1000 material design inputs on a page isn't something a sane web app would do. The same is true for a native app.

Re. "bloat" of components. I think it's important to remember everything something like paper-input is doing for _you_. As a developer, I no longer have to think about: validation, animations, a11y, keyboard, knowing all the MD spec configurations, labels, underlines, colors, fonts, typography, margins, composability, x-browser interop,... Sure, if you were implementing your own input, you could cut corners and/or leave out what you didn't need. However, if you were creating a highly reusable, highly configurable element, you'd be implementing the same amount of "bloat" yourself.

> Putting 1000 material design inputs on a page isn't something a sane web app would do.

Why not? What If I want to make a material design spreadsheet app? Just a random idea, but again, the people who make basic OS-style UI elements shouldn't be judging what a "sane" app should and shouldn't do. This limits creativity.

> However, if you were creating a highly reusable, highly configurable element, you'd be implementing the same amount of "bloat" yourself.

Sure, if I implemented it in JS. Implemented natively, a MD paper-input consumes very little resources because it isn't a nested div hell with CSS and a shadow DOM.

What would be more awesome is if there were a way to, using HTML and JS, "ask" the browser to call and insert a native element and be able to interact with it. On iOS, it should be an Apple-styled element, and on Android 5.x, it should be a MD element. They should be the genuine native element inserted right in place, not a DOM hell designed to "look" like the native thing.

I would conjecture that any app that's doing thousands of inputs will probably use virtualized lists so performance is predictable. And you can do that with JS too :D.

Polymer and Angular 1.x do come with a lot of bloat. I wouldn't call a MD text entry field "simple". Material Design was released ahead of web technologies really being able to manage it well, at least on mobile.

Polymer itself is 47KB. If you add the web component polyfills (16KB), that's 63KB minified and gzipped. I tend not to consider the polyfills because they're not Polymer and are a stop-gap that goes away over time.

Reply on news.ycombinator.com