Closed AlphaWong closed 6 years ago
I completely agree - 3.0 from our point of view moves in the wrong direction. We have a dynamic application, depending a lot on importHref. Being required to use a build step is nothing we can consider.
Please keep HTML imports and importHref.
@IntranetFactory there is no chance that HTML imports get implemented natively by Firefox and Safari, therefore ES modules are the only platform package loading system for now.
Personally, I like the new approach as long as I can get proper syntax highlighting. To browsers, HTML document is just a big chunk of string anyway.
Please see HTML modules for some context about the real direction. It is not about Polymer, it is about platform and such things have to reach cross-browser agreement which can take a lot of time. But when that new proposal become a spec, which I hope for, we will get much more.
The move is disheartening 😞 . The Polymer team spoiled us with all these good looking components in HTML. I hope HTML import will be reintroduced in one form or another. Using JS Modules for web components just feel unnatural.
Otherwise, yarn, npm and JS modules for JS look great.
Have you guys watched the HTML templates video?
Guys, you can still use HTML templates as always, It will be transformed in the build step for you. There is nothing forcing you to do things differently Polymer 3.0 will still support hybrid elements.
@ergo Which build step? We don't have a build step, and with http/2 I also see no need for a build step. The whole concept of having a build step I think should be eliminated and not become the only way to build components.
I kind of put my rambling thoughts here. I do look forward to using lit-html, at least for some use cases, especially if it doesn't sacrifice performance. So this is not a knock on that work, nor of Polymer's understandable decision.
But making that seemingly subtle decision, without any other adjustments, makes Polymer code-centric, rather than markup centric, IMHO. I find that disheartening. If I wanted code-centric, I would have gravitated more towards SkateJS (another very fine solution). Or maybe Stencil. Or HyperHTML.
But as Monica Dinculescu pointed out, it's nice, on many levels, to break down development between crafting (coding) and assembling (designing / configuring with markup). That's what attracted me Angular 1, and what seems to be making Vue so popular (and Polymer and Aurelia). Clearly, it's not everyone's cup of tea.
Looking back at how Angular 1 stayed markup-centric, I think it would only require two simple adjustments for Polymer to preserve its Markup-centric niche:
Robust support for a Polymer-supported client-side include custom element. Ideally, this custom element would be relatively dependency-free (i.e. no need for the full suite of Polymer mixin's) It would be similar to Angular 1's ng-include. Include the ability to activate scripts in a performant , de-duplicating way. But maybe not much more than that, to keep it small and simple.
Tie the routing components to the client-side include, rather than using HTML Imports and having to load the full Polymer before the content inside the shell can load.
I suspect (or hope?) this would also have the side effect of reducing time to first paint for the first view beyond the shell for PWA's (due to not having wait for Polymer to load before rendering the content view).
@IntranetFactory with polymer 2.0 you don't have a build step for es5?
@IntranetFactory with polymer 2.0 you don't have a build step for es5? - @ergo
Definitely not the norm but there are exceptions. Worked on an app circled around WebRTC which is non-existent in IE11 but is in Edge. Due to Microsoft basically EOL'ing Internet Explorer and with the advent of HTTP/2 I believe many others will make the leap to no build step in the near future. Seeing more companies willing to cut IE11 all together (more tech forward firms at least). Definitely expect this on the horizon.
@snuggs Don't forget about minification though, which is still quite relevant regardless.
Open a text editor, write my custom element, import Polymer using a native import from a CDN and it should just work. Well that is the beauty of it at least for me. No build tools, abomination frameworks, compilers and not even a package manager.
Optimization build steps are nice but optional. Optimization could even move to a plugin or flag on your web server. Push your code to a CDN and let the it minify JS/CSS + compress and cache the optimized version.
Question: off topic sort of, but in spirit matches below:
Based on your below, and my +++++ agreement with sentiment:
Is the future just html input of some type on user focus/click/touch, etc. everything else is just a bit stream which you can “steal” from a current “box model” site. Canvas Polymer app from 2 years ago can trace a live screen view
On Aug 24, 2017, at 3:26 AM, Tanbouz notifications@github.com wrote:
Open a text editor, write my custom element, import Polymer using a native import from a CDN and it should just work. Well that is the beauty of it at least for me. No build tools, abomination frameworks, compilers and not even a package manager.
Optimization build steps are nice but optional. Optimization could even move to a plugin or flag on your web server. Push your code to a CDN and let the it minify JS/CSS + compress and cache the optimized version.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Polymer/polymer/issues/4806#issuecomment-324555710, or mute the thread https://github.com/notifications/unsubscribe-auth/AHxnvu_ytFFMLndQai3Ye3kJCtWouK2pks5sbSWLgaJpZM4O_2ZJ.
Which build step? We don't have a build step, and with http/2 I also see no need for a build step. The whole concept of having a build step I think should be eliminated and not become the only way to build components. - @IntranetFactory
Are you really writing JavaScript without ESNext and CSS without SASS/PostCSS?
Open a text editor, write my custom element, import Polymer using a native import from a CDN and it should just work. Well that is the beauty of it at least for me. No build tools, abomination frameworks, compilers and not even a package manager. - @Tanbouz
You can still use jQuery (just kill me for saying this) for this kinda of projects. I think this is not a work for a Web Components library like Polymer.
I'm starting to think that all this malcontent is related just to developers' procrastination...
I'm starting to think that all this malcontent is related just to developers' procrastination...
I think that's an inacceptable allegation...
It's not about this issue, nor you. It's about the whole context. Don't misunderstand me. @IntranetFactory
Heh, its always wrong :) , when they wanted to do the HTML imports people complained. Now they want to provide another option and adopt the solutions the rest of JS community adopted, to be compatible with the rest of the ecosystem. People still complain, jeez.
Why don't consider give the better syntax for developer, and do translate with polymer serve
& polymer build
?
I don't care of any browser support for the syntax, this can do at the build time
This is the polymer 3.x i wanted:
<link rel="import" href="../the-element/the-element.html">
<!-- css.css
/* import shared.css or */
/* import shared.less or */
/* import shared.scss */
:host {
@apply --some-property;
color var(--some-variable);
display: block;
}
-->
<dom-module id="app-shell">
<!-- <link rel="stylesheet" href="path/to/css.css"> or -->
<!-- <link rel="stylesheet" href="path/to/less.less"> or -->
<!-- <link rel="stylesheet" href="path/to/scss.scss"> or -->
<style>
:host {
display: block;
}
</style>
<!-- <template src="template.html"></template> or -->
<template>
<h1>Content</h1>
<the-element></the-element>
</template>
<!-- <script src="app-shell.js"></script> or -->
<script type="module">
import thelib from 'thelib';
import Polymer from '@polymer/polymer';
class AppShell extends Polymer.Element {
// constructor() {
// super();
// thelib.doSomeThing();
// }
created() {
super.created();
thelib.doSomeThing();
}
ready() {
super.ready();
}
attached() {
super.attached();
}
detached() {
super.detached();
}
attributeChanged(name, oldValue, newValue) {
super.attributeChanged(name, oldValue, newValue);
}
}
</script>
</dom-module>
I think this is a not necessary abstraction. We had this kind of abstraction with Polymer 1. Why come back and not go forward? We are building Web Components with the help of Polymer, not Polymer components.
OK @LasaleFamine, drop the abstraction lifecycle callbacks:
@web-padawan @AlphaWong
I make the script goes the esmodule way, templates goes the HTMLImport way.
While browser not supported, we can transform script to es5, html template into index.html or load it by custom loader.
/* file: app-shell/app-shell.js */
import Polymer from '@polymer/polymer';
class AppShell extends Polymer.Element {
static get observedAttributes() {
// ...
}
constructor() {
super();
}
attributeChangedCallback(name, oldValue, newValue) {
super.attributeChangedCallback(name, oldValue, newValue);
}
connectedCallback() {
super.connectedCallback();
}
disconnectedCallback() {
super.disconnectedCallback();
}
}
customElements.define('app-shell', AppShell);
Then I needs import other custom element & define the template:
<!-- file: app-shell/app-shell.html -->
<link rel="import" href="../the-element/the-element.html">
<template id="app-shell">
<link rel="stylesheet" href="app-shell.css">
<h1>AppShell</h1>
<the-element></the-element>
</template>
<!-- or -->
<dom-module id="app-shell">
<template>
<!-- style can written inlined or inlined by polymer-cli -->
<link rel="stylesheet" href="app-shell.css">
<h1>AppShell</h1>
<the-element></the-element>
</template>
</dom-module>
Use AppShell in index.html:
<!-- file: index.html -->
<!doctype html>
<html>
<head>
<meta charseet="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Demo of Polymer</title>
<link rel="stylesheet" href="assets/shared.css">
<link rel="import" href="app-shell/app-shell.html">
<script src="app-shell/app-shell.js"></script>
<!-- or some cli bundled as script: <script src="bundled.js"></script>-->
</head>
<body>
<app-shell></app-shell>
</body>
</html>
There is the-element.js
:
/* file: the-element/the-element.js */
import Polymer from '@polymer/polymer';
class TheElement extends Polymer.Element {
}
customElements.define('the-element', TheElement);
And the-element.html
<!-- file: the-element/the-element.html -->
<!-- define template -->
<template id="the-element">
<!-- style can written inlined or inlined by polymer-cli -->
<link rel="stylesheet" href="app-shell.css">
<h1>AppShell</h1>
<the-element></the-element>
</template>
<!-- or -->
<dom-module id="the-element">
<template>
<!-- style can written inlined or inlined by polymer-cli -->
<link rel="stylesheet" href="app-shell.css">
<h1>AppShell</h1>
<the-element></the-element>
</template>
</dom-module>
Here is my take on the current situation: https://github.com/ruphin/gluonjs/tree/es6-modules It is a working solution for HTML templates imported from .html sources, in ES6 modules. If you have a browser with ES6 module support, you can see it working in action here
I am pretty confident that it is possible to leverage the HTML Imports polyfill combined with minimal changes to the current syntax (we need to wrap customElements.define
), to get very close to the behaviour we want. No compile-time requirements, HTML in .html files.
Sorry guys, but what about using Webpack? Please check out my test: https://github.com/LasaleFamine/polymer-3.
I'm using the text-loader
to load the template html
from another file. There is no readme, but I think you can get easily what I have done.
UPDATE: and then I made up the Polymer Skeleton -> https://github.com/PolymerX/polymer-skeleton
I really want to keeping the current HTML syntax. The implementation of the modules import can under the shadow or leave it as a magic.
However, please consider following case that I need to resolve. I can easily propose HTML to UX designer teams as they just need to care about the HTML code which is their daily. (Even a fresh graduate designer can use HTML)
PS: The true is many UX designer only have HTML and CSS background but not JS background.
I really don't think there are many UX designers have JS background.
Power of designers: I am truly believe that the main reasons that jQuery still alive after 15 years is that many designers contribute a lot of projects or themes insides.
If polymer aims to encourage developer / designers to contribute more and more reusable web component. I truely believe that a nice syntax can breakdown the gap between designers and front developer. Keeping designers in polymer community should be considered in this time.
Sent from my Htc HTC U11 using FastHub
@AlphaWong great input about UX designers. As an example, our designer also can serve project locally (he only needs Git and Docker) to tweak markup and styles once he needs.
BTW in our team we always place styles in separate style modules although it results in more dom-module
definitions.
Another reason is that most of our backend developers take part in prototyping and they are able to cope with HTML but obviously they would be unhappy to see all that CSS stuff.
Writing CSS in JS is bad idea, even though it became a maistream. @sorvell on his slides collapsed that part, and to be honest not only due to its size but also to its poor readability.
Anyway, I totally understand the impossibility of placement of CSS in separate stylesheets due to polyfilling limitations.
@AlphaWong @web-padawan I totally agree with your. I think the reason most people choice Polymer, Not the React or AngularJS is The Polymer most standard and friendly for UI/UX design. Although it is not stable as React or AngularJS. And in our project, always UI/UX goes first. Is the polymer 3 leave the web standard or the standard away for the UI/UX designer?
when they wanted to do the HTML imports people complained. @ergo
Who is "they"? In my experience (and I deal with over 10,000 devs daily) i've heard nothing but joy from imports for the ones that understand the intent. The only "they" i've seen is Firefox having a heavily negative stance. And truth be told much due to fact they are internally in a bit of a pickle with implementation vs. not breaking existing. Other vendors like IE -> Edge and Chrome have moved on from internal implementations. Which I believe helped them have less pain in implementation.
We have also learned from Gaia and others, that lack of HTML Imports is not a problem as the functionality can easily be provided for with a polyfill if desired - Anne
That's the part i believe is a tad oversimplified because...cyclical dependency trees and "easily polyfilled" is a bit of a loaded statement when placed within the same sentence.
🎉 🎉 🎉 @AlphaWong @web-padawan @baocang I've been screaming developer ergonomics for UX folk for years! Glad someone else is picking up on and having empathy for them. I am running out of excuses of why they should keep the mental gymnastics of build steps in their head when they continually run to HTML and CSS which then creates a dependency on the dev to piecemeal mockups/code. That's one thing that will take many a while to realize. React is great when you're the only one working in the front end and a little code dev heavy. But that very feature leaves many front end folk with their hands tied behind their back waiting for us. I know tons of great UX folk who build amazing UIs and could care less about the JS side. A harmonious balance can be achieved. Empathy is the key. And Polymer is flexible enough to have this be a thought as is far more flexible to adhering to the platform (thus less build steps) IMHO. /cc @brandondees
I'm there also has some questions, that i can't understand why HTMLElementElement dead, https://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0152.html
If this works, UI/UX can do likes below, they just needs to know put things into template
tag inside element
, and give the name, the syntax of :host
, :slotted
..., it can works for they.
<element name="contact-card">
<template>
<style>
:host { }
:host(sizing="cover") { }
:host(sizing="contain") { }
</style>
<img src="avatar.png" />
</template>
</element>
<contact-card sizing="cover"></contact-card>
<contact-card sizing="contain"></contact-card>
when coder changed it to likes below, UI/UX still can continue it's work, we just tell him ignore the script
and managed
attribute, and what's the binding means:
<!-- managed attribute tell browser this element will be registered by code -->
<element name="contact-card" managed>
<template>
<style>
:host { }
:host(sizing="cover") { }
:host(sizing="contain") { }
</style>
<img src="{{avatar}}" />
</template>
<script src="contact-card.js"></script>
</element>
<contact-card sizing="cover" avatar="avatar.png"></contact-card>
<contact-card sizing="contain" avatar="avatar.png"></contact-card>
Then talk about such as dom-repeat
and dom-if
, UX written some code likes this
<table>
<colgroup><!-- ... --></colgroup>
<thead><!-- ... --></thead>
<tbody>
<tr><td>The Content</td></tr>
</tbody>
<tfoot><!-- ... --></tfoot>
</table>
A javascript coder changed it to, we only needs told they don't care about any template
element:
<table>
<colgroup><!-- ... --></colgroup>
<thead><!-- ... --></thead>
<tbody>
<template is="dom-repeat" items="{{theItems}}">
<tr><td>{{item.content}}</td></tr>
</template>
</tbody>
<tfoot><!-- ... --></tfoot>
</table>
And works with another custom element, they only needs to know just put html import likes stylesheet
into html file
<link rel="import" href="path/to/custom-element.html">
What a wonderful and friendly Web! @dglazkov but why it's dead?
As far as I understand the reason to remove html imports is because the other browser makers don't want to support it. Fair enough.
But then why not leave the current polymer 2 architecture and support transpiling to esmodules !
Why ? Polymer 2 is very easy to understand, build designers / IDE systems via reflection and so is quite powerful. Transpiling allows an easy way to reduce the size as well as support esmodules.
Also it's not that the transpiler aspect is a daunting task as we already have it in the github tree.
Also be sticking with the polymer 2 DSL it will make it easy to transpiled to web assembly later.
Another upside is that it insulates developers from the constant flux going on in the web technology world.
It also makes it easy to upgrade polymer as the architecture changes.
I funny comparison is to see how Microsoft evolved c# to be multi ISA. .net core 2 can do JIT and AOT and the c sharp language has had only small changes over the years.
Another similar example is XAML and QML. They are DSL"s of a GUI system and are compiled at compile time.
Polymer 2 using html imports is a DSL also to a degree.
Moving to NPM / yarn is good. The new html patching / fake vdom technique being worked on is also good.
Downsides of polymer 2 DSL ?
Integrating with esmodules is not direct and so reusing existing he libraries out there is harder. But we have seen that many well used he libraries have been wrapped as polymer libraries
I don't really mind if polymer does move to esmodules in reakity. It's a small bit of learning for me. But I do mind the lost long term opportunity of tooling, code gen and code maintainability that will be lost imho.
I wish the polymer team would be move brazen / bold and keep polymer with its own unique approach rather then follow the sheep. It's really a fantastic system and the team has done a great job and also been very honest all the way through about what the architecture can and can't do , which is more than I can say for other complex projects
Anyways... Happy to discuss this further. Sorry to be complaining about this and in many levels I think my perspective is likely ignorant of many insider facts that the polymer team has that has influenced their decision. It's always more complex on the inside of a project. Maybe a more thorough article needs to be written by the polymer team to calm the users and things that we don't know that we don't know - a common problem in complex projects
Can we have sources that substantiate this stance ?
See this comment on w3c.
And please also see HTML modules issue and read it thouroughly before getting angry.
As it was said, 3.0 is a very early preview and it is likely that we only should expect for release once browser vendors reach an agreement.
I have been following this series of messages with interest. So far it looks like the greater share of messages are from people already inside the polymer community, disappointed by the move away from HTML imports. But I'm looking in from the outside, primarily developing with the (ridiculously) numerous SPA platforms out there, occasionally touching polymer as project needs require. From out here, the HTML import idea looks interesting, but from a bygone era, an alternative shape of the world that didn't get traction. I am excited to see a future polymer fitting in enormously more easily with the rest of the tool stack on the typical big, complicated, polyglot things I work on.
So notwithstanding the question of which is better, I think it's important to see there is at least some merit to the upcoming new way. Hopefully it will turn out that some well-designed tooling can make things pleasant for everyone.
(Incidentally, the SPA technology I work with most often is Angular - which supports both single file components, and spreading components across TS + HTML + CSS files. There is variation of opinion on the relative merit of combined versus separate files there also.)
If this help some body, you do not need to have the html in the js, this may be tru in react, but polymer 3.0 only ask to have a method to return the string of the template.
in old backbone days, we create templates like this
<script type="template" id="my-app-template.html">
<div>This is my [[name]] app.</div>
</script>
each of them in his separate files, and UX guys just remove the script tag to see them as normal html.
and then we use undercore to read those templates, in polymer 3.0 you can do something like this
static get template() {
var content = document.getElementById('my-app-template.html').innerHTML;
return content;
}
to get the contents, you can see an example here with dom-repeat and dom-if pen with an example
hope it helps to get the concept
It seems to me the real issue is the build system. If the build system made it easier to keep two files, it would be super nice. Once HTML file that has the template and the other has the javascript or typescript.
For example:
import * as view from './Element.template.html';
export class Element extends PolymerElement {
static get template() {
return view;
}
}
Thoughts?
On a side note, I think the build tool should include some common word setups like using typescript files (*.ts). By build system, I mean polymer build
.
@atishpatel have read the HTML modules issue? Polymer team tends to standardize something similar to what you drafted, instead of relying on Webpack etc.
Polymer 3 work both with HTMLImports & ES Modules looks good.
<dom-module id="custom-element">
<template><h1>Hello [[prop]]</h1></template>
<script type="module" src="./custom-element.js"></script>
<!-- or -->
<!--<script type="module">import './custom-element.js';</script>-->
</dom-module>
import { Element } from '/node_modules/@polymer/polymer/polymer-element.js';
export class CustomElement extends Element {
static get is() { return 'custom-element'; }
static get properties() {
return {
prop: {
type: String,
value: () => 'Polymer 3',
},
};
}
}
customElements.define('custom-element', CustomElement);
@web-padawan I hadn't seen that. Thanks for linking it!
seems "build step" fraction has seized polymer and push away "no build required" minority. that is evolution isn't.
@s-trooper The problem is that native solutions is not coming. Simple as that. So its either isolation or adoption ecosystem practices.
The problem is that native solutions is not coming. Simple as that. @ergo
As someone that works on native platform daily please elaborate? Genuinely curious as this was a vague statement.
@snuggs Well HTML Imports are not coming to other browsers, thats what I meant.
Safari likes something such as HTMLImports
, but they have more to think about web components
as Ryosuke Niwa(rniwa@webkit.org) says:
Our primary objection to HTML imports was that it had a completely different dependency resolution mechanism. We're interested in exploring declarative syntax for web components, and that includes importation of externally defined components without writing an explicit Fetch, XHR, etc... So we think something akin to HTML imports is needed. We just didn't agree with the particular proposal being made at the time.
The problem is that there is no declarative syntax for custom elements or shadow DOM. We need to fist solve that problem in order to discuss how something like HTML import should work.
So I think polymer 3.0 work both declarative syntax & ES modules is right.
I think in the future, Web Components should works such likes below: (These not be mentioned in the standard,Just my imaging about) And I can't wait Polymer 3.0 released that works both HTMLImports & ES6 Modules (decorator for behaviors) with tooling support. 😉
<!-- case 1: work without javascript -->
<!-- custom-element.html -->
<element name="custom-element">
<template>
<style>
span {
color: red;
}
</style>
<!-- Maybe that can support binding in template to make web most powerful and easily to use -->
<span>{{prop1}}</span>
<slot name="slot1"></slot>
</template>
</element>
<!-- case 2: work with javascript -->
<!--
this can not work without javascript, because a script element
inside element or allow work both with/without javascript?
-->
<!-- custom-element.html -->
<element name="custom-element">
<template>
<!-- same as above -->
</template>
<!-- content in custom-element.js, not inside script tag -->
<script type="module">
import BaseElement from 'base-element.js'
class CustomElement extends BaseElement { /* ... */ }
customElements.define('custom-element', CustomElement);
</script>
<!-- or work with external javascript -->
<script type="module" src="custom-element.js"></script>
</element>
<!-- custom-element.js -->
<script>
import BaseElement from 'base-element.js';
export default class CustomElement extends BaseElement { /* ... */ }
customElements.define('custom-element', CustomElement);
</script>
<!--
case 3: no script tag inside `element`, add managed attribute
to tell browser this will register later
-->
<element name="custom-element" managed>
<template>
<!-- same as above -->
</template>
</element>
<!-- custom-element.js -->
<script>
import BaseElement from 'base-element.js';
export default class CustomElement extends BaseElement { /* ... */ }
customElements.define('custom-element', CustomElement);
</script>
<!-- index.html -->
<link rel="import" href="custom-element.html">
<!-- while no script within `element` tag, import script with script tag -->
<!-- <script type="module" src="custom-element.js"></script> -->
<custom-element prop1="prop">
#shadow-root
<span>prop</span>
<!--<span slot="slot1"></span>-->
<span slot="slot1"></span>
</custom-element>
<!-- after bundled -->
<!-- index.html -->
<link rel="import" href="bundled.html">
<!-- while no script within `element` tag, import script with script tag -->
<!-- <script type="module" src="bundled.js"></script> -->
<!-- bundled.html -->
<element name="custom-element">
<template>
<!-- same as above -->
</template>
<script type="module">
/* Code of BaseElement and CustomElement */
/* customElements.define('custom-element', CustomElement); */
</script>
</element>
<!-- bundled.js -->
<script>
/* Code of BaseElement and CustomElement */
/* customElements.define('custom-element', CustomElement); */
</script>
@ergo not sure what you mean with "The problem", the native solution for WC load in now JS Import, any discussion about is Pointless, for the non w3c member. The Google WC Proposal years ago was quite like Polymer 1.0/2.0, even Databinding was part of it, in the early stage! Now the People that like to use html/css without build step have to avoid WC/Polymer, that is important to spread around because ... The Ideas of "html/css" transpiler to WC has nothing to do with WC Spec nor Polymer = WC polyfill + UI Elements. I am sure Polymer Team or others will write such a Thing but IMHO its not polymer framework aim to be webpack module ;)
The reality of w3c is that Polymer 3.0 will be standardized competitor to React, that is not bad thing per se, but for html/css no build fraction.
edit: P.S i am impressed of polymer team professionalism and dedication, and would like to add they are for nothing to blame ... the development of WC Spec was not under their control and they have done all possible to stay with initial goals "proposal" in some sort they continue so
@s-trooper I agree it's pointless to talk about the what could be if w3c standards were different. The polymer team is dedicated and I really appreciate that as well.
I think the issue was poor communication and lack of options. Many people - including me - love that polymer allows HTML, CSS, and Javascript to be separate like it has been on the platform from the beginning. When the announcement was made to go to switch to HTML and CSS being in .js files in order to use modules, it made those people upset. So, really the issue for me is not that HTML imports are going away, it's that the layout of HTML, CSS, and JS being separate seems to be broken/unimportant. It's semi-arbitrary that stuffing everything into a .js file is better than not having a build step or polyfill.
This has been mentioned above, but I'm summarizing here. A potential solution I would really appreciate:
Comply or die of irrelevancy aside, the simple fact is that front-end development is getting harder, not easier. It is bit absurd that modern platforms/frameworks are evolving toward more convoluted build and compilation steps in order to use markup languages like html/css and a dynamic language like javascript. It's almost as if best practices are being driven by maximization of the tech evangelist conferences.
I don't mind the change, but I'm interested in the question raised by @bahrus about how this will compare to Stencil/HyperHTML. Going by HNPWA, HyperHTML (there represented by ViperHTML) seems performant yet somehow more low-level, while Stencil seems a bit like how Polymer 3.0 would be.
Activity on Polymer 3 seems to be very low, along with a lack of development transparency. Would be helpful if we got any news about the current status and near-future plans.
Polymer 3 is auto-converted by the Polymer-modulizer (https://github.com/polymer/polymer-modulizer) which is actively being worked on. If you want to follow the progress on Polymer 3 you can watch that repository.
I am trying to pick a path at the momemt for a hobby piece & i am not a programmer. However, in trying to determine to go the Polymer (which attracted me because of the html first apperance) or Angular. I was disapointed with Polymer 3 direction but lit-html & this blog http://blog.scottlogic.com/2017/11/10/first-look-at-polymer-3.0.html seems to address for both single file & seperate file approaches (beyond the super technical performance / toolset aspects) Is this not right? Thr question I still have - As a long run option, am I better to invest my time into Polymer or an alternative (Angular)?
@cywalker Polymer and Angular address different use-cases. Angular is a full-fletched framework, usually a good option for enterprises and big teams. Polymer is a small layer on top of webcomponents, usually a good option for smaller websites or performance-critical systems.
With the move to ES modules, there are multiple options for structuring files, which the blog points out as well. We are still gathering all options and trying to figure out best practices. lit-html
is one of them, which we are experimenting with.
Dear Community,
Polymer direction: https://www.youtube.com/watch?v=JH6jEcLxJEI
So sad. The main reason I select polymer to develop the webapp is that It keeps the html part without js. The front end developer can keep their logic in the js side and the designer can continue html design section but now the rendering part mix with js again. Might be I should move back to react as the only uniqueness of polymer is gone.
Personally, I don't think polymer 3.0 following react style can earning users as react already have the majority of the front-end market and it is true. Polymer should keep the HTML native concepts in order to survive in the front-end world.
Finally, I always think Polymer is based on two concepts
As customize Dom is following the iframe that developer can packaging the HTML code and import it anywhere.
Reference : https://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-301/
Polymer 2016 : https://youtu.be/Ihdp63FaRKA?t=25m39s
However, I don't think Polymer will listen my opinion as I remember it has a debate about golang direction. The final response from Google is that "If you do not agree, you can fork your own". Therefore, I just want to leave a record for my view about Polymer 3.0.
Thanks Alpha