3 ms·

> 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

by venning 11y ago

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

dheera 11y ago
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.
- venning 11y ago
  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.
  - ebidel 11y ago
    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.
- ebidel 11y ago
  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.
  - dheera 11y ago
    > 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.
    - TheAceOfHearts 11y ago
      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.
millstone 11y ago
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.

by venning 11y ago

dheera 11y ago

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.

venning 11y ago
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.
- ebidel 11y ago
  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.
ebidel 11y ago
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.
- dheera 11y ago
  > 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.
  - TheAceOfHearts 11y ago
    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.

millstone 11y ago

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.