Live data from Hacker News

Introduction to HTML Components

blog.mecheye.net

51–60 of 151 posts

Re: Introduction to HTML Components

#51
post #19

Earlier quoted context omitted.

I think that people that disregard Polymer fail to understand that Web Components are already here. They are fully supported on Chrome and Safari, and hopefully Firefox and EDGE will eventually catch up with them. And they have to, because Chrome and Safari own the mobile web. Polymer is transitioning to being a thin layer on top of what the browsers support, which basically means a Polyfill for Firefox and Edge, and…

> 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.

> As Rob Dodson said, "Polymer is the jQuery of WebComponents".

How about x-tag, a competing WP framework from Mozilla/Microsoft? I don't see any any mention of that.

Re: Introduction to HTML Components

#52

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…

> Most people don't actually derive much benefit from writing custom UI widget primitives.

Bingo. Most won't and shouldn't. There's a different between building casual widgets for personal vs for business production use. jQuery UI got some widely popular components such as Select2 and jqGrid, Datatables etc. They will never be developed by non-developers or business users. The tool should be really reserved for code crafters.

Imagining those crafters started creating tools with WP that are modular and self-cotained, work across whatever browsers threw at them.

Re: Introduction to HTML Components

#53

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.

> As Rob Dodson said, "Polymer is the jQuery of WebComponents". How about x-tag, a competing WP framework from Mozilla/Microsoft? I don't see any any mention of that.

Because for all intents and purposes it's absolutely irrelevant.

If you go to webcomponents.org, you'll see that the overwhelming majority of components there are Polymer components.

Re: Introduction to HTML Components

#54
post #19

Earlier quoted context omitted.

I think that people that disregard Polymer fail to understand that Web Components are already here. They are fully supported on Chrome and Safari, and hopefully Firefox and EDGE will eventually catch up with them. And they have to, because Chrome and Safari own the mobile web. Polymer is transitioning to being a thin layer on top of what the browsers support, which basically means a Polyfill for Firefox and Edge, and…

> 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.

Angular and React also have plans to eventually move into Web Components.

Re: Introduction to HTML Components

#55

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…

It's really interesting to see these comments when I feel the struggle of not having this on a daily basis.

I guess it's ultimately about how web development is actually two things: web pages (posters) and web apps ("software")

Maybe when you're working on some one-off pages you don't feel much need for encapsulation, and in the end it's more trouble than it's worth.

Let's say you are working on a social network though. You'll need to display a "person widget" a bunch, in different contexts. Of course you want to have it be consistent throughout your app. Of course you want it to look the same. Of course you want encapsulation!

When you're writing a web app, your HTML isn't just layout but the entire interface. You're usually working with a huge team and need consistency. You want to be DRY.

If you have a style guide, you probably could benefit some from this. The proof is that things like JQuery UI exist, even if it's activated more through JS.

HTML is basically unreadable in so many cases because you can't encapsulate layout code into widgets. Having these tools lets you stay a bit sane when you need to build out a lot of workflows in a consistent manner.

Re: Introduction to HTML Components

#56

As far I remember that time, I would say IE Components didn't succeeded, because at that time server side rendering was far more popular. I personally was doing sites in PHP and tried to avoid JS at all costs. Strange that today I'm doing exactly opposite.

Exactly this!

Re: Introduction to HTML Components

#57

Earlier quoted context omitted.

> As Rob Dodson said, "Polymer is the jQuery of WebComponents". How about x-tag, a competing WP framework from Mozilla/Microsoft? I don't see any any mention of that.

Because for all intents and purposes it's absolutely irrelevant. If you go to webcomponents.org, you'll see that the overwhelming majority of components there are Polymer components.

Well, I think mainly it's because Google is behind webcomponents.org. It has ZERO mentioning on x-tag and other competing frameworks. Ironically, it is called "webcomponents.org".

It's like visiting a store called "phone" that sells iPhone exclusively. Google has definitely got own its down agenda with the so-called standards in this regard.

Unsurprisingly, a searching "x-tag" on webcomponents.org returns pathetically two components.

Re: Introduction to HTML Components

#58
post #54

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.

Angular and React also have plans to eventually move into Web Components.

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

Re: Introduction to HTML Components

#59
post #55

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…

It's really interesting to see these comments when I feel the struggle of not having this on a daily basis. I guess it's ultimately about how web development is actually two things: web pages (posters) and web apps ("software") Maybe when you're working on some one-off pages you don't feel much need for encapsulation, and in the end it's more trouble than it's worth. Let's say you are working on a social network thou…

> I guess it's ultimately about how web development is actually two things: web pages (posters) and web apps ("software")

This is what Progress Web Application tries[0](PWA https://en.wikipedia.org/wiki/Progressive_web_app), a fairly new spec, attempts to bridge the gap. Basically a normally web page will virtually be indistinguishable from a web app.

Post reply on HN