4 ms·

Because the API is really ugly. I can't see them ever taking off except maybe as an implementation of another library with a cleaner API.

by ng12 7y ago

cmpolis 7y ago
This is one of the goals of Polymer- a cleaner API/abstraction layer on top of web components, right?
- floatboth 7y ago
  Well, forget about "Polymer the library", it served us well but it's very legacy at this point. The successor is https://lit-element.polymer-project.org https://lit-element.polymer-project.org and it's awesome.
  - interlocutor 7y ago
    Why on earth do you need something that heavy? How about this 200-line lib instead: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder It lets you TSX format (same to React) to implement as well as to use web components.
    - spankalee 7y ago
      > Unlike React.js UIBuilder does not do incremental screen updates LitElement + lit-html give you very efficient updates, and don't require non-standard JS like JSX.
      - interlocutor 7y ago
        lit-html is no more of a standard than JSX. In fact JSX is better because tools like VSCode is able to validate both HTML and embedded JavaScript.
        spankalee 7y ago
        Huh? lit-html uses standard JavaScript. That's it. JSX is a non-standard extension. So yes it is more standard than a non-standard, and lit-html runs directly in browsers without any transpilation while JSX very much doesn't. VS Code is as able to analyze lit-html templates as well as JSX via the lit-plugin extensions. It gives you type-checking, code completion, hover-over docs, and linting.
        interlocutor 7y ago
        lit-html needs a 1600 line library where as UIBuilder is a 200-line library: https://github.com/wisercoder/uibuilder/blob/master/UIBuilder/UIBuilder.ts https://github.com/wisercoder/uibuilder/blob/master/UIBuilde... Yes, JSX needs transpilation but that happens at compile-time. Which is better, pre-processing at compile-time, or "transpilation" (i.e., string processing) at run-time?
        spankalee 7y ago
        UIBuilder doesn't do incremental updates at all. You might as well use innerHTML and template literals. That's a 0-line library :)
        deleted 7y ago
        [deleted]
        interlocutor 7y ago
        Updates offered by lit-html appear to be very limited. If you change value of expressions it updates the DOM. What about larger changes, such as list items changing? What about child elements being replaced with new ones?
        spankalee 7y ago
        It handles all of that.
- nothis 7y ago
  So we finally got a goddamn proper standard and we're already cheering for the next API to throw in front of it to make it "cleaner"?
  - floatboth 7y ago
    Actually, no. There's no need or possibility to make it "cleaner", but there's always the direction of making it more "high level". These are very different things. If you look at https://lit-element.polymer-project.org https://lit-element.polymer-project.org — it's just a base class that integrates declarative DOM templates. The platform APIs are not opinionated about templating, they just provide proper mechanisms for declaring elements and having isolated DOM subtrees. It makes sense to leave templating to libraries, because… well, good luck on getting even just two people to agree about how templating should be done :)
ergo14 7y ago
You are correct, they are pretty low level. You want something like lit-element or stencil (or vue, svelte... etc) on top of them for a pleasant experience.
jlengrand 7y ago
Which is exactly the point :). So good news!
interlocutor 7y ago
What are you talking about? There is hardly any API. https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements https://developer.mozilla.org/en-US/docs/Web/Web_Components/... It is extremely simple.
- Crinus 7y ago
  First time reading this. On one hand it looks neat. This is something i expected browsers to be able to do since i noticed that Mozilla (pre-Firefox) implemented <blink> (or <marquee>?) in JavaScript. On the other hand it looks like it'll become much harder for JavaScript-less environments to extract data from web-pages as now an article on a news site could be something like <news-article id="23848923"> and the JavaScript side will do the rest. But being able to do something like <my-fancy-button caption="Go To Google" target="http://google.com/"> http://google.com/"> that in the background creates all the canvases and such needed will be neat.
  - madmulita 7y ago
    Oh, wait for webassembly, that's gonna be fun.
  - Asooka 7y ago
    >On the other hand it looks like it'll become much harder for JavaScript-less environments to extract data from web-pages as now an article on a news site could be something like <news-article id="23848923"> and the JavaScript side will do the rest. This is already the case on a lot of sites, just not standardized. With the standard you could sandbox the javascript or maybe implement specific parsing for the most common web components.

Because the API is really ugly. I can't see them ever taking off except maybe as an implementation of another library with a cleaner API.

by ng12 7y ago

Because the API is really ugly. I can't see them ever taking off except maybe as an implementation of another library with a cleaner API.

cmpolis 7y ago

This is one of the goals of Polymer- a cleaner API/abstraction layer on top of web components, right?

floatboth 7y ago
Well, forget about "Polymer the library", it served us well but it's very legacy at this point. The successor is https://lit-element.polymer-project.org https://lit-element.polymer-project.org and it's awesome.
- interlocutor 7y ago
  Why on earth do you need something that heavy? How about this 200-line lib instead: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder It lets you TSX format (same to React) to implement as well as to use web components.
  - spankalee 7y ago
    > Unlike React.js UIBuilder does not do incremental screen updates LitElement + lit-html give you very efficient updates, and don't require non-standard JS like JSX.
    - interlocutor 7y ago
      lit-html is no more of a standard than JSX. In fact JSX is better because tools like VSCode is able to validate both HTML and embedded JavaScript.
      - spankalee 7y ago
        Huh? lit-html uses standard JavaScript. That's it. JSX is a non-standard extension. So yes it is more standard than a non-standard, and lit-html runs directly in browsers without any transpilation while JSX very much doesn't. VS Code is as able to analyze lit-html templates as well as JSX via the lit-plugin extensions. It gives you type-checking, code completion, hover-over docs, and linting.
        interlocutor 7y ago
        lit-html needs a 1600 line library where as UIBuilder is a 200-line library: https://github.com/wisercoder/uibuilder/blob/master/UIBuilder/UIBuilder.ts https://github.com/wisercoder/uibuilder/blob/master/UIBuilde... Yes, JSX needs transpilation but that happens at compile-time. Which is better, pre-processing at compile-time, or "transpilation" (i.e., string processing) at run-time?
        spankalee 7y ago
        UIBuilder doesn't do incremental updates at all. You might as well use innerHTML and template literals. That's a 0-line library :)
        deleted 7y ago
        [deleted]
        interlocutor 7y ago
        Updates offered by lit-html appear to be very limited. If you change value of expressions it updates the DOM. What about larger changes, such as list items changing? What about child elements being replaced with new ones?
        spankalee 7y ago
        It handles all of that.
nothis 7y ago
So we finally got a goddamn proper standard and we're already cheering for the next API to throw in front of it to make it "cleaner"?
- floatboth 7y ago
  Actually, no. There's no need or possibility to make it "cleaner", but there's always the direction of making it more "high level". These are very different things. If you look at https://lit-element.polymer-project.org https://lit-element.polymer-project.org — it's just a base class that integrates declarative DOM templates. The platform APIs are not opinionated about templating, they just provide proper mechanisms for declaring elements and having isolated DOM subtrees. It makes sense to leave templating to libraries, because… well, good luck on getting even just two people to agree about how templating should be done :)

ergo14 7y ago

You are correct, they are pretty low level. You want something like lit-element or stencil (or vue, svelte... etc) on top of them for a pleasant experience.

jlengrand 7y ago

Which is exactly the point :). So good news!

interlocutor 7y ago

What are you talking about? There is hardly any API. https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements https://developer.mozilla.org/en-US/docs/Web/Web_Components/... It is extremely simple.

Crinus 7y ago
First time reading this. On one hand it looks neat. This is something i expected browsers to be able to do since i noticed that Mozilla (pre-Firefox) implemented <blink> (or <marquee>?) in JavaScript. On the other hand it looks like it'll become much harder for JavaScript-less environments to extract data from web-pages as now an article on a news site could be something like <news-article id="23848923"> and the JavaScript side will do the rest. But being able to do something like <my-fancy-button caption="Go To Google" target="http://google.com/"> http://google.com/"> that in the background creates all the canvases and such needed will be neat.
- madmulita 7y ago
  Oh, wait for webassembly, that's gonna be fun.
- Asooka 7y ago
  >On the other hand it looks like it'll become much harder for JavaScript-less environments to extract data from web-pages as now an article on a news site could be something like <news-article id="23848923"> and the JavaScript side will do the rest. This is already the case on a lot of sites, just not standardized. With the standard you could sandbox the javascript or maybe implement specific parsing for the most common web components.