Polymer: Entirely broken workflow with Polymer 3.0

[nazar-pc]

WIth 3.0 a lot of changes are expected to happen that will make my workflow broken entirely.
I don't like writing plain CSS or HTML or JavaScript. Instead I'm writing everything in SCSS, Jade and LiveScript. My IDE compiles files to native formats on change with files watchers using default settings and everything works wonderfully.

With Polymer 3.0 I wouldn't be able to write LiveScript, since JavaScript imports are not supported there (also imports only support relative paths, while I need named aliases sometimes, TL;DR: they don't work for me). I can't write Jade, since HTML imports are gone and I have to put everything into JavaScript (which is why I subconsciously don't like React and love Polymer). And the last piece - I can't write SCSS, since CSS should be within HTML within JavaScript now and referencing external styles is not yet supported and will be very tricky when there is no dedicated HTML file.

So all of my tooling is now no-op.

I've being with Polymer since 0.5 and contributed a lot, but now I refuse to accept that I'm forced to use only plain JavaScript and write all of the markup and styling inside of it.

I could write the tooling that will bring old-looking Polymer elements into new 3.0-like ones, but that it a lot of effort to make and maintain as well as complicates everything too much.

So the question becomes: how do you suggest me to approach this now?

In my opinion this is too big question to ask on Slack channel or somewhere else, which is why it is opened here.

[moebiusmania]

@nazar-pc you don't have to write HTML and CSS exclusively in the Javascript class, it is important that they are there in build time. You can use Webpack with different loaders to write SCSS and HTML in different files to keep separation and have it build them for you in a single js file.

Don't have complete example right now (I do not use LiveScript and SCSS) but for external HTML and as workflow example you can watch this https://github.com/LasaleFamine/polymer-3

[moebiusmania]

another thing, by joining NPM, Yarn and Webpack, Polymer now enters in wider community of developers using these tools regarding the frontend library/framework they use, so you can borrow ideas and workflows from React or Vue users.

[nazar-pc]

@moebiusmania, what if I don't have build step? I love Polymer for the ability to use it without any build step - just include source files and it works.

I don't like workflows that REQUIRE build steps just to show something on screen. Optionally - great, and I do have some build step, but it is not based on Webpack or something like that. And I need a way to have separate files and run them as is in browser. This is very fast and easy, there is no need for source maps and so on.

My whole dev environment works perfectly without build steps with Polymer 2.0 (I don't consider files watchers as real build step here).

[moebiusmania]

Polymer tools had lots of build steps, just because they don't show them to you it doesn't mean that they aren't there.

Sass is a build step.
Transpilation is a build step.
PostCSS is a build step.
Typescript is a build step.

Today's frontend development requires build step.

I'm sorry guys but you have to face reality, it's mainly polymer's fault because until 2 days ago they intoxicated you with tons of wrong concepts. Polymer's community is the only one in the entire frontend/JavaScript landscape that was outside and 3 years behind the real world.

I know it's hard to change mind but it's more the gain than the pain.

[nazar-pc]

The only build step I had was files watchers. It worked since Polymer 0.5 till 2.0. And suddenly, we have React-like JS file with everything in it.

I know why the build tools exist and I do use them, but for optimizations and performance improvements, I should be able to use stuff without it.

I suspect Polymer is not going to support SCSS within Jade/Pug within JS. Which means I have to build a lot of tooling myself. Placing everything in JS doesn't play nicely with already existing tools.

[moebiusmania]

You are looping the same argument without adding nothing to the discussion, and in the last example you are talking of something never supported natively by Polymer.

This is not an issue, but a pointless rant.

You have solutions for everything you mentioned with little effort, if you don't want to use them it's your choice and can't blame V3 or the polymer team.

At least be kind and close this issue.

[brian-cruickshank]

This is not a _pointless_ rant - I think unless the Polymer team comes up with a decent migration strategy and build flow for existing Polymer developers that there will be a lot of developers leaving Polymer for something less painful.

I'm really getting tired of being told "we've got your back" and then finding out that they've punted on it and being told it's all my problem. Are they truly going to convert existing behavior code as part of the polymer-modulizer? What about converting Polymer 1.x components? Oh yeah, they decided that it wasn't possible and that it was so "easy" for people to do themselves that they didn't even bother implementing what they promised to do at last year's conference.

I've never been a fan of writing html in javascript, and Polymer 3 makes this even uglier. I'm really wondering why I don't truly 'use the platform' and just write plain web components instead of going through hell with another big-bang conversion.

Re: _Don't have complete example right now (I do not use LiveScript and SCSS) but for external HTML and as workflow example you can watch this https://github.com/LasaleFamine/polymer-3_
<cough> There's _nothing_ there. Why bother linking to it?

[moebiusmania]

@brian-cruickshank React, Angular, Preact , Vue, Inferno, Cycle are not less painful and all works with NPM + ES Modules + Webpack, so what alternatives to Polymer are you talking about?

it's pointless since its not bringing something useful to help and its clearly subjective

again with that "dont want to write HTML in JS", when is already demonstrated that YOU DONT HAVE TO, there are other ways, but you just want to ignore them.

that repository is not empty, it has an example of a Polymer 3 component with external template

manners please, ranting and being rude will not help you

[nazar-pc]

@moebiusmania, this was initially opened as a question, not an issue, to Polymer team. And the only person that is rude right now is you, telling everyone what to do, while you don't even seem to contribute anything to the project yet, which in turn tells us a bit about how familiar with the project you are.

Also import template from './template.html'; is not a ES Module as far I understand it. Which means it wouldn't run even in the bleeding edge nightly browsers without compilation (which makes me dependent on particular tool that supports this non-standard syntax). Which is contrary to what I've initially requested. And "everyone does this" is not a good argument to do something on its own, there should be a reasoning behind regardless.

@brian-cruickshank, don't take @moebiusmania's words as representation of Polymer's team vision. Let's wait what they have to answer. And let's discuss only this particular issue here.

[arthurevans]

Hey folks, I know people have a lot of strong feelings on this issue, and I'm going to ask everyone to be patient with each other. Questions about the roadmap are perfectly reasonable.

I'm also going to ask folks to be patient with _us_, because this is a very, very early preview and we've tried to be crystal clear how early it is, and encourage people to stay on their current versions of Polymer for any kind of real-world use.

@nazar-pc I feel your frustration. As far as writing HTML in HTML goes, I don't think that transform is going to be any more complicated than the SCSS, Jade, and Livescript transforms you're currently using.

The Livescript/imports question is trickier. ES6 modules are the only native module system we have for the web. A major reason Polymer is moving to ES6 modules is that they won't require a build step or polyfill for browsers with native support.

I'd never heard of Livescript until today, but looking at the repo, it looks like they've had a series of open issues to support ES6 modules since 2014. With module support shipping in Chrome and Safari, hopefully there is some increased interest in supporting web-compatible imports.

[moebiusmania]

@nazar-pc by now I'm the only one who has given you an advice / help to your request, never ordered you to do anything. I never said "because everyone do it", that's word of yours. Trying to turn the "rude" to me is not fair and confirm how pointless are your statements.

Thanks to v3 my workflow has got even better and I'm enjoying the new Polymer DX.

Have fun

[nazar-pc]

@arthurevans, Modules do not concern me much, since I'm not going to use them anyway (until they support imperative way of loading, aliases and features like that, they are not a viable alternative to Alameda and RequireJS for me, since in my context I can't predict all of the paths and I need to be able to control what is where). I'll be also using legacy syntax as I find it much shorter and easier to use than verbose ES6 classes that also require compilation depending on environment.

But I can't agree that compilation is not going to be easy. It'll be 2-step compilation, once from source to CSS/JS/HTML and second time to single JS, which is cumbersome and doesn't fit well in trivial files watchers approach.

I hope there will be still a way to optionally use HTML imports, since they make life so much easier and more straightforward.

[HitkoDev]

Polymer 3 is currently no more than a proof of concept, with "the concept" being ES6 module imports. HTML imports are being deprecated, as most browsers don't plan to implement them. Currently it looks like W3C is pulling the plug, and switching over to ES6 modules. The debate is open for public, though, and if you don't like HTML imports being removed, you can tell it there. Again, this has nothing to do with Polymer, and everything to do with the platform.

While Polymer isn't intentionally making it hard to integrate SASS (or other tools for generating CSS / HTML), you have to understand that these things aren't the platform, and therefore don't have a very high priority, especially when it comes to proof of concept work.

The way platform is currently developing, it looks like we'll have to either inject generated HTML and CSS content into .js components at build time, or get a JS loader to fetch HTML & CSS when a component is imported (not that hard to implement, however it will probably break if the files are bundled). The third option, as demonstrated here, is to bundle the code before running it, but I _really_ don't like that approach, as it doesn't let you create independent components.

That being said, I've made a simple example demonstrating the first approach. It uses a TypeScript watcher to compile components, and a Gulp watcher to compile, minify, and inject SASS & HTML into the component. It's available here.

[nachoab]

Having just one html file per element combining everything was a great win for Polymer in my opinion, it was very intuitive. Build steps are not necessary with Polymer 2, you don't need transpilation, postcss, sass or typescript to write an element.
Bundling everything is not a good approach since we need independent components, using a JS loader to fetch HTML and CSS is worse than using a link import polyfill and you have to have separated files, and a build step is making things more complicated.

Link imports are a big loss. Polymer 3 looks more like a step back (aside from moving to npm)

[TimvdLippe]

With HTML imports proposal not being accepted by various browser vendors, a future that included HTML imports without a polyfill was no longer feasible. As a result of the non-acceptance, we had to look for a different loading mechanism that is supported by browsers and does not require a polyfill. To that end, we moved to ES modules, which has been standardized and has shipped in almost every browser (at the moment of writing this comment).

The move to ES modules gives a future without polyfills, however does mean we are moving to a JS-centric world. As I explained in https://github.com/Polymer/polymer/issues/4806#issuecomment-388653999 , we are actively experimenting and investigating being able to develop with HTML in a JS-centric world. To that end, we are involved in the HTML modules proposal and have an active experiment that shows the potential: https://github.com/PolymerLabs/html-modules-toolkit (You can watch our latest IO talk with more details: https://www.youtube.com/watch?v=7CUO7PyD5zA&feature=youtu.be&t=32m37s )

Once the proposals are succesful, the platform can give you more options that allow you to develop given the dialects (like SASS, Jade and LiveScript like you are using) you prefer. Given these commitments to address your use-case, I am closing this issue. Please join the standards discussions to explain your point-of-view, as well as experiment with the toolkit to give your opinion on the developer ergonomics.

[masonlouchart]

I guess we have to accept that Polymer became one of those countless JS Frameworks. It's not because everyone is going in a direction that this direction is the good one. It's time to give a chance to Elm.