Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introduction to HTML Components

blog.mecheye.net

Post reply on HN
Print view View original

101–110 of 151 posts

Re: Introduction to HTML Components

#101

Post by priolo »

shadowmint wrote: post #7

Personally, I think there's an important lesson here, and its the same lesson that polymer is learning as it stumbles around trying to convince people to use it. Most people don't actually derive much benefit from writing custom UI widget primitives. Certainly, that's a useful thing for a UI toolkit builder to be able to do, but tangibly, for most people, it's not actually useful. I don't have time to invest hours im…

"Web developers" do not know how to program, but they only know how to do "copyAndPaste". For this reason "the web" uses a shit technology. It's ONLY this: in other areas there are no such problems

Re: Introduction to HTML Components

#102

Post by dmitriid »

ehnto wrote: post #82
dmitriid wrote: post #49

Earlier quoted context omitted.

> I think that people that disregard Polymer fail to understand that Web Components are already here. No. Polymer is here. As Rob Dodson said, "Polymer is the jQuery of WebComponents". No one in their right mind would even think about writing and using WebComponents in vanilla JS. Hence we're coming back to the problem with WebComponents: they are a solution in search of a problem.

They are not a solution in search of a problem. They have a very clear problem statement, it's hard to orchestrate reusable front-end code. React's problem statement is roughly the same, but react seeks to provide more structure and functionality to the foundation of web components. The WebComponent spec is just trying to formalise that foundation.

> They have a very clear problem statement, it's hard to orchestrate reusable front-end code.

I'd love to see that problem statement written anywhere in any of the webcomponent-related specs or sites.

If it were true, they would not have such cumbersome APIs, for example.

On the contrary, WebComponents, as they turn out to be, realise next to none of their original goals: https://fronteers.nl/congres/2011/sessions/web-components-an...

> but react seeks to provide more structure and functionality to the foundation of web components.

React has nothing to do with web components. Until less than a year ago React team was set against WebComponents in any shape or form: https://docs.google.com/document/d/1QZxArgMwidgCrAbuSikcB2iB...

What React was, and is, is a library with a specific goal that solved a specific problem, and it's basically this: "Build encapsulated components that manage their own state, then compose them to make complex UIs."

No one really knows what WebComponents are, and what problems they solve. I know what Polymer is and what it attempts to solve though.

Re: Introduction to HTML Components

#103

Post by dmitriid »

ergo14 wrote: post #100
dmitriid wrote: post #95

Earlier quoted context omitted.

> it's just that many of the elements created use Polymer, and that is probably a good indicator of how popular the tooling is in the component ecosystem. That's exactly what I'm saying. There are no WebComponents. There is no x-tags or whatever. There is only Polymer. For many reasons. Chief among them: WebComponents suck. Polymer at least gives nice-ish APIs on top of that. Rob did say something like "Polymer is th…

I think web components are low level and non-opinionated to give you freedom of implementation for higher level things. Thats what Polymer, Stencil, Svelte, SkateJS are for. Indeed WC API is not the nicest to work with to say the least, but thats not the problem, I write in python instead of Assembly, just user higher level stuff.

> Indeed WC API is not the nicest to work with to say the least, but thats not the problem

How is it not a problem?

> I write in python instead of Assembly, just user higher level stuff.

As with any analogies, it's a wrong one. You compare a low-level PL with a high level PL. WebComponents is not a programming language. It's a set of APIs for the most popular platform in the world

I wonder how far along iOS would get if all it provided for its UI libraries was just the UIView, and never anything else (no collection views, no table views, no content views etc.) That's exactly what w3c does, times and again.

Re: Introduction to HTML Components

#104

Post by ergo14 »

dmitriid wrote: post #103
ergo14 wrote: post #100

Earlier quoted context omitted.

I think web components are low level and non-opinionated to give you freedom of implementation for higher level things. Thats what Polymer, Stencil, Svelte, SkateJS are for. Indeed WC API is not the nicest to work with to say the least, but thats not the problem, I write in python instead of Assembly, just user higher level stuff.

> Indeed WC API is not the nicest to work with to say the least, but thats not the problem How is it not a problem? > I write in python instead of Assembly, just user higher level stuff. As with any analogies, it's a wrong one. You compare a low-level PL with a high level PL. WebComponents is not a programming language. It's a set of APIs for the most popular platform in the world I wonder how far along iOS would get…

It is low level API to be non-opinionated. Or at least it makes sense for me to make it like that. Same as web assembly, service worksers and others - that is a step in right direction IMO.

Same as for example Python providing WSGI - you don't often use WSGI directly, you use a framework on top of it like Pyramid, Django or Flask.

Re: Introduction to HTML Components

#105

Post by ausjke »

Polymer will ditch 'html-import'(which is similar to the HTML component) as it is not widely implemented on browsers and such.

Polymer 3 will switch to ES6-loader and npm, probably one year away?

I spent quite some hours with Polymer, but finally give up for now, one reason is that I want Polymer 3 today, but it is not there yet, also big companies tends to make its stack for big players(look at Angular2).

I will use Vue.js for new projects at the moment, I read somewhere saying, Vue.js could be the next modern jQuery, and I kind of agree.

Re: Introduction to HTML Components

#106

Post by dmitriid »

ergo14 wrote: post #104
dmitriid wrote: post #103

Earlier quoted context omitted.

> Indeed WC API is not the nicest to work with to say the least, but thats not the problem How is it not a problem? > I write in python instead of Assembly, just user higher level stuff. As with any analogies, it's a wrong one. You compare a low-level PL with a high level PL. WebComponents is not a programming language. It's a set of APIs for the most popular platform in the world I wonder how far along iOS would get…

It is low level API to be non-opinionated. Or at least it makes sense for me to make it like that. Same as web assembly, service worksers and others - that is a step in right direction IMO. Same as for example Python providing WSGI - you don't often use WSGI directly, you use a framework on top of it like Pyramid, Django or Flask.

> It is low level API to be non-opinionated.

No API is non-opinionated. It's the opinion of its authors. And w3c's opinions invariably are to the detriment of developer experience.

For example, quote from [1]: "The things like property initializers for instances that were so nice in [a previous example] aren't here. And they've been stuck in committee for reasons that, frankly, just make me grumpy" (around 22:30 mark)

[1]: https://www.youtube.com/watch?v=y-8Lmg5Gobw

Around 12:50 mark: "What jumped out at us was how much infrastructure each library was bringing around to support creating widgets or components". Let's look at WCs: ooops, all the infrastructure is still there, nothing is done to make it easier.

Re: Introduction to HTML Components

#107

Post by frou_dh »

colejohnson66 wrote: post #23
Yaggo wrote: 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.

Didn’t IE use to let you style random components such as even the scroll bar?

Yep - I remember on vBulletin forums, the native vertical scrollbar often got the same vibrant colouring as the forum's theme.

Re: Introduction to HTML Components

#108

Post by allover »

dmitriid wrote: post #63
peterhunt wrote: post #58

Earlier quoted context omitted.

This isn't true https://facebook.github.io/react/docs/web-components.html

It's partly true, see https://custom-elements-everywhere.com and linked issues. The main problem: when the framework makes the developer decide whether to pass attributes or properties to Custom Elements, it's mostly ok. The framework should also allow binding any events (which cna be named as onEvent, or on-event or...) Frameworks that are trying to be clever and hide the complexities of DOM behind proper APIs, and…

The site you linked to is about frameworks 'playing well with' custom elements. It says nothing to the assertion about React moving to web components.

Also it is not helpful to call standards 'a pile of steaming crap' without backing that up with something substantive, examples/alternatives etc.

Re: Introduction to HTML Components

#109

Post by ehnto »

dmitriid wrote: post #102
ehnto wrote: post #82

Earlier quoted context omitted.

They are not a solution in search of a problem. They have a very clear problem statement, it's hard to orchestrate reusable front-end code. React's problem statement is roughly the same, but react seeks to provide more structure and functionality to the foundation of web components. The WebComponent spec is just trying to formalise that foundation.

> They have a very clear problem statement, it's hard to orchestrate reusable front-end code. I'd love to see that problem statement written anywhere in any of the webcomponent-related specs or sites. If it were true, they would not have such cumbersome APIs, for example. On the contrary, WebComponents, as they turn out to be, realise next to none of their original goals: https://fronteers.nl/congres/2011/sessions/we…

> No one really knows what WebComponents are

That is ridiculous. They've come from some impetus, derived by some individuals, and they obviously had a goal in mind. They are in a spec, they're being implemented into browsers, they're emulated or polyfilled by various JS libraries, and they're being used by individuals around the web.

> I know what Polymer is and what it attempts to solve though.

The WebComponents spec is admittedly lacking a full feature set to truly enable "Encapsulated Components" but with really not very much work ( https://bitbucket.org/polylab/polyblocks ) you can get pretty close.

I guess I'm simply not understanding what all the fuss is about. I think those busy building with React and friends might see no point to it, because why not just build it in React right? But not everything needs to be a highly orchestrated complex UI, and in those circumstances I still want to be able to re-use my frontend code.

Re: Introduction to HTML Components

#110

Post by coldtea »

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.

React/JSX got the good parts of it, and added even more useful things. If we could add the missing parts on top of that (like encapsulation from the external DOM), it would be perfect, and the rest of their horrible API/design can vanish.

Post reply on HN