Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've been on the Polymer team, making web component libraries, for a long time. And while we used to promote "single file" style authoring in HTML files, we've come around (me very strongly) to the idea that it's better to do single-file components in JavaScript.

This has resulted in our newer lit-html and LitElement libraries, where the DOM rendering is done in JavaScript, but it's still possible to do single-file style:

    import {LitElement, css, html} from 'lit-element';

    export class MyElement {
      static styles = `
        :host {
          display: block;
          background: red;
        }
      `;

      static properties = {
        name: {},
      };

      render() {
        return html`
          <h1>Hello ${this.name}</h1>
        `;
      }
    }
    customElements.define('my-element', MyElement);
There are a number of reasons why this is better, IMO. Not requiring any builds and utilizing the JS module graph are big ones.

The most important though is that the essential job of templates is to interpolate data into DOM. It's much easier this by building DOM in JS, than by trying to access and transform data in HTML.

Templates need some kind of expression language. If the template is in HTML then you need to invent expression delimiters, the expression syntax and semantics, and a way to get data into HTML: HTML doesn't natively have a way to refer to JavaScript objects. This is all custom, needs code to implement, and you need to train developers on it.

On the other hand if you write templates in JS you can take advantage of full JavaScript expressions, imports, and natural lexical scoping... and the data is typically already in JavaScript.



> On the other hand if you write templates in JS

As a non-programmer (UX), I used to watch Polymer with so much interest, since it had HTML tag-like syntax. I copy paste component codes & construct an UI. There was simplicity in <googlemaps lat="89.2" long="123.2" draggable="false"></googlemaps>

Now with lit-html, it went from unique HTML/WebComponent for non-coders, to another one of the JS frameworks out there.


I'm only talking about the _implemention_ of web components. You can still use any custom element from HTML.

If <google-maps> was rewritten in LitElement, you'd still be able to write:

    <google-maps lat="89.2" long="123.2" draggable="false"></google-maps>


I used to like the idea of (originally zope's) metal/tal templates. In theory the templates where valid html, complete with example values - and could be edited directly.

Unfortunately this breaks down as soon as you start to break up the page into sections (you end up with a component that needs a "layout" to provide surrounding <html><body>(...) etc).

Ironically, now with html5 being rather loose and fast, you might actually get a decent preview of such a widget again... But it's still not right for "web applications" as opposed to "hypertext applications".

Full applications need full gui widgets - and html isn't a good fit.


You can absolutely still use React/Polymer/other JS frameworks in that same manner, but you have to learn a little bit of coding boilerplate.

I think one difference between lit-html and React/other JS frameworks is that lit-html knows which portions of its template are static, and can avoid reconciling static portions. This is the same optimization as what Svelte can do, but without the need to change your toolchain.

Disclaimer: I work at Google, but on a completely unrelated team.


Somehow, I don't know why especially, I've come to enjoy JSX/TSX syntax with styled components. It just is simpler for my brains, I guess. To think of all just as custom components, with their logic included as a single component. Nice to see though that also people working at Polymer do see the benefits of only JS.

But having separate style-sheets, I don't know. I have done Vue with SASS etc, but the abstraction I felt was a bit too vague. At least our team got a little lazy and wrote massive style sheets with nested classes, and similarly we then ended up fitting too much HTML to the template.

With JSX/TSX I can keep myself from doing those mistakes, and just make small simple components, that do not go overboard with logic. Although I have to say performance-wise React is still very much pain in the ass to debug, and I can't say how many working days I have wasted on some dumb rendering bug, where the components would rerender constantly.

And it's way, way too hard to find those problems and I think this is the weak point of React. No one likes figuring out how to performance optimize a simple list. It should work straight out-of-the-box! I hope that Polymer team will try to make their framework a little better than React on this part.


If you think it's bad in React (and I agree that this can be a pain point at times - although actually long lists are a weak point of the web platform in general), definitely don't try Polymer!

A colleague of mine went with Polymer for a prototype (against my advice), and switched to Angular within 2 weeks because the performance of Polymer was so bad. I think the web-component approach is inherently inefficient for large apps, because you can't batch DOM reads and write like the other frameworks do.

Were you using CSS modules with your SASS? I've found a few base styles in global SASS along with scoped styles in CSS (SASS) modules works pretty well for keeping things simple.


Polymer has generally been as fast or faster than Angular and React. We've seen that pretty consistently in Todo MVC, Hacker News, etc., shootouts.

But Polymer isn't our current generation library anymore. LitElement, which is based on the lit-html template library, is. LitElement measures clearly faster than Angular and React on shootouts.

There's nothing inherently inefficient about web components, and we do batching of DOM updates much like frameworks. LitElement is even able to yield between different component renders naturally, like React concurrent mode, to not jank the page.


Huh, well it figures that it isn't an easy problem to solve.

EDIT: I was looking at the wrong. I see, it seems like a nifty way to combine styles. But hmm, I guess this one of those things that what works for you, is good enough.

Somehow keeping the styles in the same file, inside the styled components, just makes everything easier to me. Granted the string interpolation is bit annoying at times for accessing the theme variables but ehh.


Remove a couple special characters and it's starting to look pretty much like QML (http://qmlbook.github.io/ch04-qmlstart/qmlstart.html) :p


With JS being the better way, why would people chose that over, say, Vue ? For a few ko you can do that and more. And transition to a full scale infra if needed later.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: