[dheera]

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

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.