Write up suggestions on dealing with performance

[beriberikix]

There are attempts to address performant architecture with projects like Yeoman & require.js but we as a community don't have definitive answers yet. The FAQ addresses some of these questions, though without a lot definitive answers.

Some concerns I have and other's have asked me:

• The web component model suggests inlining JS & CSS in your components, which seems to go against current best practices for performance, namely:
  • Minimize HTTP Requests
  • Put StyleSheets at the Top
  • Put Scripts at the Bottom
  • Make JavaScript and CSS External
  • Minify JavaScript and CSS
• There is support for external JS, though it does not seem to be the recommended method.
• How can we solve the duping problem, aka dependency management of includes? Should there be an element for that?

Understandably these are early days but at some point it would be great to have an article addressing performance.

[DavidPesta]

Since it is the early days of the framework, it stands to reason that as the framework matures it will be met by explosive internet speeds in the not so distant future. Optimizing a little HTML/CSS/JS here and there will be extremely negligible compared to other resources that will be much more demanding of bandwidth by then. It is a common trend in the history of software that as hardware gets better, a sacrifice to computing speed is made in exchange for ease of development. It's why we use things like PHP/Symfony or Ruby on Rails instead of assembly. Things like Polymer will replace old ways as the practice of minimizing bits and bytes matter less.

[sjmiles]

There is a natural tension between development time and production time.

The current recommended approaches for defining custom elements are heavily skewed toward the development phase of a project. This is when the most work is being done to the source files and when it's valuable for developers to focus on innovation and creativity instead of overcoming technical obstacles.

At production time the suggested tack is to use tooling (e.g. vulcanizer) to construct a network efficient version of your application dependencies (aka to adhere to your bullet points for current best practices).

This way you get the best of both worlds, and as DavidPesta points out, as the current best practices evolve due to changing externalities, we don't have to change our developer experience, just the output of our production tooling (or we get to eliminate that last bit altogether).

How can we solve the duping problem

Likely this is still a problem for tooling, although note that HTMLImports has a built-in de-duping feature.

[beriberikix]

@sjmiles looks like the beginnings of a write up :)

[addyosmani]

In the past month I've been exploring how tools like Yeoman, Grunt and Bower can be used with Polymer in order to solve some of the points you brought up (with and without Vulcanizer). As @DavidPesta mentioned, it's still early days for WCs and the best practices around production tooling still need to be figured out. I do hope to speak to Mozilla about how they're planning on addressing some of these challenges for Brick soon..

@sjmiles I'm unsure of whether it would be helpful, but I'd be happy to expose some of my tooling work around Polymer as part of an experimental repo in the Polymer org if that would give folks a central place to collaborate on solving more of these problems.

[tjsavage]

This is a critical part of the project, under constant scrutiny and development. Reluctantly closing this issue for repo cleanliness, given its age.