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

71–80 of 151 posts

Re: Introduction to HTML Components

#71

Post by byte1918 »

JepZ wrote: post #50

I think the main problem with IE technology was the way Microsoft pushed it down our throats. The tech wasn't necessarily bad, but when the giant corporation pushes new features while not respecting/implementing the existing standards very few people support their efforts. So as a result 96% hated the IE and the other 4% were using other browsers. No wonder nobody wanted to use the newest Microsoft only features.

I was young in 1999 so not very experienced with technology but I really doubt people were hating on Microsoft back then. Sure, every company will have a hate camp but I doubt it was as spread as it was in the past few years.

Re: Introduction to HTML Components

#72

Post by chenster »

allover wrote: post #61
chenster wrote: post #57

Earlier quoted context omitted.

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 patheticall…

> It's like visiting a store called "phone" that sells iPhone exclusively Not really a fair analogy as anyone can submit elements to webcomponents.org: https://www.webcomponents.org/publish

Sure, but they could also add x-tag to their resource list.

Re: Introduction to HTML Components

#73

Post by alwillis »

chenster wrote: post #51
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.

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

x-tag is mentioned on the WebComponents site--and it works with the same underlying technologies as Polymer: shadow dom, HTML imports, custom elements and templates: https://www.webcomponents.org/libraries

Re: Introduction to HTML Components

#74

Post by TazeTSchnitzel »

colordrops wrote: post #16
enb wrote: post #3

Earlier quoted context omitted.

FTA: cough OK, obviously it’s 2017 and Internet Explorer 5.5 isn’t relevant anymore. But if you’re a Web developer, this should have given you some pause for thought. The modern Web Components pillars: Templates, Custom Elements, Shadow DOM, and Imports, were all features originally in IE5, released in 1999.

Is that really true? IE 5.5 had shadow Dom?

Yes, it's described by the article.

Re: Introduction to HTML Components

#75

Post by detritus »

abritinthebay wrote: post #5
enb wrote: post #3

Earlier quoted context omitted.

FTA: cough OK, obviously it’s 2017 and Internet Explorer 5.5 isn’t relevant anymore. But if you’re a Web developer, this should have given you some pause for thought. The modern Web Components pillars: Templates, Custom Elements, Shadow DOM, and Imports, were all features originally in IE5, released in 1999.

It was a truly great release.

haha, it really was too, no hint of sarcasm! Young'uns these days probably can't believe what a saviour Microsoft from the clusterfudge that Navigator represented back then.

.

Typed on Firefox :)

Re: Introduction to HTML Components

#76

Post by jlebrech »

girvo wrote: post #67
jlebrech wrote: post #41

Earlier quoted context omitted.

at this point i'm considering creating a backend framework that sends a grid of images and uses imagemaps for clicks. with fast internet raster images shouldn't be a big issue.

Adobe ImageReady... now that is giving me some flashbacks. Pun sort of intended.

we could send 60fps image diffs now, we have the bandwidth.

and all the browser does is send the window size and cursor position.

Re: Introduction to HTML Components

#77

Post by stevedonovan »

Fifer82 wrote: post #10
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…

I really tried with Polymer (for the last few months) but it was particularly verbose. I remember implementing an " " tag, and thinking that this is so wild and "Out There" that I may simply never understand. Annoyingly, there is a whole "Hybrid" mode as well. So there is no distinction between V1 and V2. If you are confused,you go to the docs, they aren't giving you what you need, so you go to one of the sample elem…

For my sins, I look after a Polymer 0.8 based site left to me by a Chrome enthusiast. It is starting to break in mysterious ways. Not looking forward to the upgrade path...

Re: Introduction to HTML Components

#78

Post by kinlan »

dmitriid wrote: post #62
chenster wrote: post #57

Earlier quoted context omitted.

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 patheticall…

While this is true, it's also true that x-tags and whatever else that's not Polymer is entirely irrelevant in the context of WebComponents. There's only Polymer. It's gotten so bad that even the main proponents of WebComponents (working for Google, of course) cannot build proper WebComponents (and no one can): https://www.youtube.com/watch?v=sK1ODp0nDbM

> main proponents of WebComponents cannot build proper WebComponents (and no one can):

I've a vested interest as I run the team that Rob is on, I feel like there is a lot being misconstrued here in this thread, x-tags is be on the list of supported resources on webcomponents.org. If there are only two elements on the list it's not because it's "polymer only" and run by the Chrome team. I've launched a couple of elements using plain JS and there are others on there too, 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.

Rob didn't say no one can build proper web components, he was saying that to build great web components there is a lot of work that you have to do especially to make them accessible and good actors in the life-cycle of a page and that many of the spec authors hadn't seen them being built as a canonical reference set. Of course people can build proper web components, but it is on us to explain it clearly now that the browser support is mostly there.

Re: Introduction to HTML Components

#79

Post by kinlan »

chenster wrote: post #72
allover wrote: post #61

Earlier quoted context omitted.

> It's like visiting a store called "phone" that sells iPhone exclusively Not really a fair analogy as anyone can submit elements to webcomponents.org: https://www.webcomponents.org/publish

Sure, but they could also add x-tag to their resource list.

It is in the resource list.

https://www.webcomponents.org/resources

Re: Introduction to HTML Components

#80

Post by mlsarecmg »

jarek-foksa wrote: post #70
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.

> No one in their right mind would even think about writing and using WebComponents in vanilla JS. Why not? I have written a complete widget toolkit [1] this way. With vanilla APIs the code is a bit more verbose and repetitive, but in turn you get more options for speed optimization and fine-tuning. [1] https://github.com/jarek-foksa/xel

You get a small set of APIs that allow you to encapsulate, so what, encapsulation never was the problem. Now how do you bind, how does the UI react to store changes, how do you bring state managers into this, etc. We'd be in 2010 fighting the naked dom all over again.

As for optimization, vanilla won't be faster than a framework unless you write one from scratch. That means having a scheduler in place that orders dom read/writes, pooled events listening from a single source (the main document), a prioritizer that can cull, something that diffs state in order to render the minimal set of components, etc. Many don't realize the effort that goes into these libs to render as efficient as possible. Even if some stuff is baked into the browser, the field is moving so fast that we get higher benefits from community driven optimizations. And that is an understatement if you look at things like React Fiber.

Post reply on HN