Live data from Hacker News

Introduction to HTML Components

blog.mecheye.net

141–150 of 151 posts

Re: Introduction to HTML Components

#141

I think Web Components will have/already had the same fate. To paraphrase the meme: "Stop trying to get Web Components/Polymer to happen. They aren't gonna happen". At least not in this version of them. It's like XHTML that went about for years before it was taken out of its misery. We needed something like Web Components for a long time -- but the current implementation is exactly how it should not have been done. R…

It's happening, slowly: https://platform-status.mozilla.org/#shadow-dom

And "XHTML experience" is now built in to browsers, no developer effort needed (implementation consistency, the ACID tests, strict mode for JS, and WASM for speed)

And see also http://ishoudinireadyyet.com/

Re: Introduction to HTML Components

#142

Earlier quoted context omitted.

> I think that people that disregard Polymer fail to understand that Web Components are already here. XHTML was "already there" too. > They are fully supported on Chrome and Safari, and hopefully Firefox and EDGE will eventually catch up with them. With React, Vue etc going strong, I don't see them going anywhere even after that. They solve less problems in a messier way.

The big benefit (once Firefox and EDGE support them) is in not needing to download 132K of Javascript for basic platform functionality. It's much like JQuery. It was very much necessary when it came out in 2006. But then browsers got querySelectorAll, classList, uniform event handling, uniform dimensions, fetch, animations, transitions, data-attributes, and basically all the other functionality in JQuery. The JQuery…

I don't think I've ever seen a Polymer-powered page of any substance use less than 132kb of JavaScript. File size is really not a good reason to choose web components, especially when you consider the things you need to do to actually work efficiently with web components once you have them.

Re: Introduction to HTML Components

#143
post #141

I think Web Components will have/already had the same fate. To paraphrase the meme: "Stop trying to get Web Components/Polymer to happen. They aren't gonna happen". At least not in this version of them. It's like XHTML that went about for years before it was taken out of its misery. We needed something like Web Components for a long time -- but the current implementation is exactly how it should not have been done. R…

It's happening, slowly: https://platform-status.mozilla.org/#shadow-dom And "XHTML experience" is now built in to browsers, no developer effort needed (implementation consistency, the ACID tests, strict mode for JS, and WASM for speed) And see also http://ishoudinireadyyet.com/

>It's happening, slowly

That's browser adoption. XHTML was also adopted by all browsers.

I'm talking about developer adoption.

Re: Introduction to HTML Components

#144

Earlier quoted context omitted.

In what messier way exactly? Do you have any specifics? The component models are largely analogous. React and Vue could use custom elements if they chose to.

Developer usability: the fact that they're largely analogous is literally why the implementations that stick to one language, taking advantage of new language features as they pop up, and abstract away all the bindings, win out over something like Polymer, which sticks to the separation of HTML, CSS, and JS. React, for instance, has changed a lot since its first release, mostly to do what devs need it to do with a ba…

It seems as if you are a bit misguided about Polymer. I recommend that you take a look at a Polymer 2 element instead of a Polymer 1 element:

https://www.polymer-project.org/2.0/start/first-element/step...

The reason you have to define what an element 'is' is for backwards-compat reasons. Additionally, the properties definition block is there simply for attribute -> property serialization so that you can set properties declaratively in the HTML as attributes. The property declaration is also used for tooling schema enforcement just as you suggested it should really be there for. You do not need a properties block at all since Polymer uses webcomponents, and as you said, elements can handle arbitrary attributes (and attributes set in JS with the exception of the data- attributes [1]).

In Polymer 2, you simply set the function hook just like you wanted. Polymer 3 which is essentially just a refactoring of Polymer 2 introduces JS Modules. An example would be:

  import {Polymer} from 'pathToPolymer';

  export class IconToggle extends Polymer.Element {
    static get is() { return 'icon-toggle' }
    observedAttributes() { return ['toggleIcon'] }
    attributeChangedCallback(name, old, new) { if(name === 'toggleIcon') {...} }
    connectedCallback() { super.connectedCallback(); this.addEventListener('pressed', this.onPressed.bind(this)); }
    onPressed(evt) { this.pressed = !this.pressed; }
  }

  customElements.define(IconToggle.is, IconToggle);
This example, does not use the properties but the native attributeChangedCallback [2], it does not explicitly define properties and it can still set this.pressed, and you can easily add a 'cats' attribute if you want which can then be accessed via this.getAttribute('cats') like any other native element. Polymer is written so that all the code is executable in the browser even with the JSX-like template syntax [3]. But with the move to JS modules, a webpack configuration can easily add extra functionality like not even having to define the event listeners or the observed attributes.

[1] https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement...

[2] https://developer.mozilla.org/en-US/docs/Web/Web_Components/...

[3] https://www.youtube.com/watch?v=ruql541T7gc

Re: Introduction to HTML Components

#145
post #65
post #33

Earlier quoted context omitted.

The main problems I have with Polymer: * It's cumbersome to install. apt-get install npm && npm install bower && bower install ... this is about when I give up. Why not just include a 'polymer.js' file that just does all the work, no installs needed, no questions asked, CDN provided, batteries included, like every other client-side JavaScript library on the planet? Even the appropriate CSS can be loaded by the JavaSc…

> It's cumbersome to install. apt-get install npm && npm install bower && bower install ... this is about when I give up Half the things I've ever installed were far more complicated than that.

Honestly I never understand why they need to be so complicated. If you want people to use your product, why not make it easy to use it? This goes for developers too -- who should be spending their time coding their product, not dealing with how to install stuff.

Re: Introduction to HTML Components

#146

Earlier quoted context omitted.

> I think that people that disregard Polymer fail to understand that Web Components are already here. XHTML was "already there" too. > They are fully supported on Chrome and Safari, and hopefully Firefox and EDGE will eventually catch up with them. With React, Vue etc going strong, I don't see them going anywhere even after that. They solve less problems in a messier way.

The big benefit (once Firefox and EDGE support them) is in not needing to download 132K of Javascript for basic platform functionality. It's much like JQuery. It was very much necessary when it came out in 2006. But then browsers got querySelectorAll, classList, uniform event handling, uniform dimensions, fetch, animations, transitions, data-attributes, and basically all the other functionality in JQuery. The JQuery…

>The big benefit (once Firefox and EDGE support them) is in not needing to download 132K of Javascript for basic platform functionality.

If that's the big benefit, then it will be increasingly irrelevant (assuming its not already), including on the mobile space.

Especially since those 132K (for React, Angular, and the like) are not "basic platform functionality" but give tons of things that Web Components do not.

Re: Introduction to HTML Components

#147
post #22

Earlier quoted context omitted.

> is good enough for me, [...] If it just was fully styleable. Browsers really should implement better selection of customizable standard widgets. Currently it requires too many hacks to re-style the built-in input elements. Web components feel a bit overkill for most cases.

Or maybe designers should learn to respect the platform's widgets' look and feel, which the user is familiar with and has possibly customized according to their preferences and accessibility needs.

Unfortunately the industry just doesn't work that way.

Accessibility is one reason why css-themeable native widgets would be a win for everyone, their look will match with the branding (customer happy) and behaviour will be consistent (end user happy), and standardization would make developers happy.

Re: Introduction to HTML Components

#148

Earlier quoted context omitted.

Both are basic front end frameworks. Polymer just happens to use a minor spec to encapsulate and expose, the smallest part of what it actually does. Polymer of all the frameworks i've had to use has had the most breaking changes. That they're turning the ship for each and every major forcing you to rewrite the entire application is kind of ironic given that their motto is "use the platform" as if suggesting stability…

Big corps like Google tend to over-engineer stuff. It's the very reason why Vue.js is so kicking ass due to its low learning curse and progressive approach. Why can't we do the same for WC standards?

I think the problem is more or less that we're at a breaking point where it's getting quite obvious that we should move away from higher-up standards. The browser should worry about low-level interfaces only, high level abstractions should never be cast in any standard and that is exactly what the extensible web manifesto said.

WC break this in half again and all of the sudden they're again trying to shovel more UI stuff into the dom. What they're trying to fix hasn't been a problem for years. Their entire spec was thought out in a meeting room maybe 10 years ago, but almost nothing of it has relevance today. It would simply make it harder again and block applications from leaving the browser behind.

Re: Introduction to HTML Components

#149

Earlier quoted context omitted.

> I think that people that disregard Polymer fail to understand that Web Components are already here. XHTML was "already there" too. > They are fully supported on Chrome and Safari, and hopefully Firefox and EDGE will eventually catch up with them. With React, Vue etc going strong, I don't see them going anywhere even after that. They solve less problems in a messier way.

The big benefit (once Firefox and EDGE support them) is in not needing to download 132K of Javascript for basic platform functionality. It's much like JQuery. It was very much necessary when it came out in 2006. But then browsers got querySelectorAll, classList, uniform event handling, uniform dimensions, fetch, animations, transitions, data-attributes, and basically all the other functionality in JQuery. The JQuery…

>> for the same functionality, their sites are slower, take longer to load, and have more things that can go wrong

I would like to see sources supporting these claims, please.

Re: Introduction to HTML Components

#150

Earlier quoted context omitted.

Developer usability: the fact that they're largely analogous is literally why the implementations that stick to one language, taking advantage of new language features as they pop up, and abstract away all the bindings, win out over something like Polymer, which sticks to the separation of HTML, CSS, and JS. React, for instance, has changed a lot since its first release, mostly to do what devs need it to do with a ba…

It seems as if you are a bit misguided about Polymer. I recommend that you take a look at a Polymer 2 element instead of a Polymer 1 element: https://www.polymer-project.org/2.0/start/first-element/step... The reason you have to define what an element 'is' is for backwards-compat reasons. Additionally, the properties definition block is there simply for attribute -> property serialization so that you can set properti…

As a dev, comparing technologies given that I've already used Vue and React, I still see lots of code that I've become accustomed to not needing to specify, making even Polymer 2 still feel clunky and bloated: there is still no reason for that "is()" or "observedAttributes()" (tooling should take care of that), and the fact that you manually need to initiate the super chain in connectedCallback instead of having a side call to a function with a name that indicates what it's actually for, with the chain taken care of by the super class (if your callback function has the word "callback" in it, that's already a wasted 8 characters that could have been used to actually name the function after what it does) still makes me go "this is silly, why would I go back to such a verbose technology?".

Polymer 2 looks better than polymer 1 for sure, but if I'm comparing what I need to write in React vs. Polymer 2, the former still beats out the latter in terms of low effort, high productivity.

And to be clear: the reason I think (and the numbers bear out that) React and Vue etc. beat out Polymer still is because they can do the same things as polymer: the on-page result is identical. Except React and Vue offer a better dev experience... provided you buy into the development model, of course. But this is also true for people who first start with Polymer: they have to buy into the idea that the classic web stack is the best solution to the problem of needing custom components.

And that reveals the major difference, in turn revealing another reason why Polymer is not as popular as one might hope: Polymer is a web presentation and interaction technology, whereas for instance React is a universal UI technology. They're not even remotely the same thing: the latter is effectively a superclass of the former. For example, as long as you call the functions that React tells you need to be used to effect UI updates, you will never have to think about "where this code runs". Web? Mobile? Desktop? Someone's GTK+ application on embedded hardware with JS support? It literally doesn't matter: call the functions, and it will work. The fact that the DOM is used in the browser is pretty much irrelevant to React - it's only relevant to devs who want to explicitly tie their UI to APIs that are only available in a browser. Polymer takes an approach that is diametrically opposite to this: it keeps things as "webby" as possible, making you write DOM, and only DOM, elements.

So that is another reason for the difference in dev experience: React has abstracted as much as possible so as to only expose what you need because it wouldn't be able to do its job as UI technology if it kept exposing platform-specific construct, whereas Polymer can keep things explicitly tied to the browser stack, and thus never got pushed to be as self-contained as possible, with as high a productivity:effort ratio.

(and whether that's a good or bad decision is irrelevant when discussing 'why is one of these more/less popular than the other', even if I certainly have opinions there. I'd love for React to be more webby, like polymer, but if it was, it would be much clunkier)

Post reply on HN