Live data from Hacker News

Introduction to HTML Components

blog.mecheye.net

21–30 of 151 posts

Re: Introduction to HTML Components

#21
post #9

I am not sure it is not a coincidence that the same idea keeps resurfacing. I remember reading pretty early on that HTML/XML/XHTML would eventually lead to a world where "chemists would have their own tags to represent chemical formulas" and similarly each discipline would develop their own tag language. Browsers would just know how to render them! People have tried to materialize this idea in multiple ways over time…

> Browsers would just know how to render them!

They wouldn't "just know," there were supposed to be DTDs published that would tell the browser how to render that specific kind of markup.

Re: Introduction to HTML Components

#22

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…

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

Re: Introduction to HTML Components

#23
post #22

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…

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

Re: Introduction to HTML Components

#24
post #6

I used HTC a lot and waited for the other browsers to implement it. XBL came around but waited many years until it became web components. Great post!

All this talk of HTCs reminds me of HTAs: HTML Applications. https://msdn.microsoft.com/en-us/library/bb250409(v=vs.85).a... They behaved like a native app, with control over their native chrome, and without any browser sandboxing: their JavaScript (JScript) or VBScript could use COM components to access to the file-system and other features, including loading other binaries in-process. File-system access was through…

This! I love simplicity of electron but it is absurdly resource hungry.

Re: Introduction to HTML Components

#26
post #11

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…

"Third party widgets" was the use case. The idea was to build a marketplace for frontend components, much like existed for Visual Basic, eg. the average web developer would buy/download BobsTreeView.htc and bind an XML file and that would be it. The actual issue was that very few people was doing any serious frontend development back then. Netscape and IE had completely different DOMs and the environments were not su…

That frontend vs backend attitude exists to this day, although somewhat less so. To be fair, apps were basically just forms in the early days of the web with very little dynamic activity.

Re: Introduction to HTML Components

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

Re: Introduction to HTML Components

#28
I remember discovering these in the mid-2000s, and thinking along the same lines as the author: why hadn't they caught on and been standardised like XMLHttpRequest, etc. had been?

I think the reality is, Microsoft introduced these technologies at the tail-end of initial "dot com boom". Shortly afterward, most of the companies who might have built ambitious web apps using them went bust. Microsoft stopped investing in IE, and for quite a while afterwards, web development regressed to people building document and brochure-style sites. People were too busy trying to figure out complex CSS, and what `hasLayout` meant in IE to build component-based apps.

A few years later, web development crept out of the doldrums: JavaScript's reputation began to be rehabilitated, the term "AJAX" was coined, and companies like Google began building more ambitious web apps. But by now Firefox was the browser of choice for most developers, and had gained enough market share that you couldn't build IE-specific sites.

Mozilla teamed up with Opera and Apple, and later Google, to create what became HTML5, and that included reverse engineering and standardising a number of proprietary IE APIs. However, they chose to ignore element behaviours. Presumably because they had their own component technology, XBL, and wanted to make that the basis of web apps. And, since element behaviours never made it into Firefox, developers never started using them.

My guess is, had Firefox adopted them, they'd now be a standard part of the web platform, and we wouldn't have web components as they currently stand. There are a lot of similar "what ifs" in the history of the web. For example, what if Microsoft had adopted XBL? What if flexbox and grid had been implemented in early 2000s when they were originally designed, instead of fifteen years later? What if ES4 had been accepted and implemented? What if Cassowary had been built into CSS when it was proposed, instead of being ignored (and later used by Apple as the basis for auto layout)?

Re: Introduction to HTML Components

#29
post #10

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…

Angular v1 or v2 though? :P

Re: Introduction to HTML Components

#30

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…

Why shouldn't your entire application be a widget? Sometimes it's nice to embed one application into another, multiple times. I find your reasoning here short-sighted, since there's often no clear point at which components should bottom out. You can always add another layer.
Post reply on HN