Does Polymer have a JavaScript-first API?

[trusktr]

Out of the box, Polymer offers an HTML-first API, meaning that we write HTML first (in .html files) then we can add JavaScript behavior as needed inside <script> tags. On the other hand, Skate.js and X-Tag offer a JavaScript-first API meaning we can write JavaScript first (in .js files) then we can add HTML as needed (in the .js files, via React, Handlebars, etc).

The advantage of JS-first API:

• it can be easily shipped onto NPM
• it can be used with Webpack, Browserify, JSPM, and other JS workflows (with ES6 module support) very easily. With Polymer, we're stuck with the outdated Bower. (I think switch from bower to npm? #2578 is a high priority if acquisition of polymer users is high priority)
• <script> tags (as with Polymer) are not very friendly for build systems. To use ES6 Classes and other new language features (or custom features like JSX, CSSX, or glslify), we'd have to compile many bundles, one per component, and that would be additional to managing the Bower workflow.

The getting-started docs for Polymer show the HTML-first approach, so I'm not sure if I may have missed the JS-first method of using Polymer, if any. Does one exist?

[Pablo-Ivan]

Hi @trusktr. You may want to checkout the Polymer Docs for that.

[trusktr]

@Pablo-Ivan I read that, but it doesn't show how to add markup to the element. Do we still need to use dom-module for that in a separate HTML file?

[dfreedm]

You can absolutely make an element exist only inside of a .js file if you want to. Here's an example: http://jsbin.com/xelagaquze/edit?html,js,output. We don't have an easy way to build your template in JS other than using DOM APIs to create it manually. This isn't really a use case we consider very important because it is our opinion that HTML is the most expressive way to write a web component.

You can always make two files, HTML for the dom-module and template, and JS for the definition, and that is well supported.

As for code loaders and bundlers, we think the available solutions are far from perfect. JS-only tools rely on either a non-standard CommonJS syntax and API, or an as-of-yet-unimplemented-in-browsers ES6 syntax and API. Neither approach is using the platform idiomatically and comes with a dependency on tooling in the short term (and perhaps medium to long term for CommonJS).

Polymer uses HTMLImports to encode dependencies from one HTML file to another, and that serves our needs admirably. We have tools for bundling like vulcanize that behave similarly to the JS-focused tools, and it seems to work pretty well for our users. Other tools like crisper can split the <script> tags out of the HTML files into JS files to run minifiers, transpilers, etc, and we're working on a friendlier all-in-one CLI tool polymer-cli that will have hooks for all your customization needs.

I hope that answers your questions 😄

[trusktr]

It does. Thanks! I was overlooking that we can simply call HTMLElement methods on this. Thanks! :]

The "Get set up" section of the "Get started" guide doesn't mention the NPM package at https://www.npmjs.com/package/@polymer/polymer. That would be nice.

[ebidel]

@trusktr I think one reason it's not listed on our getting started docs is that we're not doing a good job of keeping the lib up to date on npm.

@arthurevans, should we add info on the package to the docs?

@justinfagnani, can we get the latest release up on npm?

[justinfagnani]

We shouldn't mention npm on the docs until it's actually supported.

[arthurevans]

@ebidel @justinfagnani +1 to what Justin said. I don't want to document it until we have a reliable process for 1) updating the packages in NPM, and 2) using those packages in a project.

[ebidel]

Which begs the question, when will we support it? :) Many many many devs want it!

[trusktr]

@justinfagnani @azakus It may be a good idea to convert the v1 Custom Elements polyfill to ES6 modules at the same time.

[TimvdLippe]

Closing this issue in favor of #326 Also note that in Polymer 2, you can now also pass a template as String