Live data from Hacker News

Introduction to HTML Components

blog.mecheye.net

11–20 of 151 posts

Re: Introduction to HTML Components

#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 super stable. But there was an attitude that frontend was for designers and "real programmers" were backend-only.

So the real programmer found a backend component for ASP.NET or GWT and wasn't interested in the frontend sausage.

(This article reminded me of the DHTML Dude column[1], and yeah some of us unreal programmers were doing this bleeding edge IE-specific front-end stuff for clients. Then we spent many years atoning for our sins. However, I think 90% of "IE-only" apps never used this stuff, they just had the wrong box model or some dopey ActiveX upload component or something.)

[1] https://msdn.microsoft.com/en-us/library/bb263969(v=vs.85).a...

Re: Introduction to HTML Components

#12
Nice; I used these "back in the day" while at Google to implement the illusion of native SVG support in Internet Explorer 6-8; I used hidden Flash for the rendering and Microsoft Behaviors wrapping it all so that the fake SVG would look like it was part of the DOM for full JS scripting. Fun times. Check it out here: https://github.com/BradNeuberg/svgweb

Re: Introduction to HTML Components

#13

I'm slightly confused by the combination of "introduced in Internet Explorer 5.5" and "offers a powerful new way" being written in an article posted on August 28, 2017

To a great degree, "modern web standards" are an exercise in reinventing proprietary Microsoft stuff from the 1990s.

(Or replacing some thing that Java or Flash had done for years.)

Re: Introduction to HTML Components

#14
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 Scripting.FileSystemObject, for example.

Some built-in Windows components were/are built as HTAs, like the previous versions of the Microsoft AntiMalware / Windows Defender UI.

I tried to use it for a project in 2013 but couldn't because HTAs are forced to run in Quirks-mode, so you can't use IE11's Edge mode, unfortunately.

Best of all: they ran while needing only a few megabytes of RAM. Compare with Electron-based apps and it makes me weep because this, right here, is evidence that a Web-View can be used as the basis for an application, using a platform that was available since 1998/1999, without it dragging my PC down.

Re: Introduction to HTML Components

#15

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 think the API actually does matter a lot.

I think jQuery's massive success was precisely because it was a simple and concise API on top of the verbose and confusing DOM API.

Re: Introduction to HTML Components

#16
post #3

I'm slightly confused by the combination of "introduced in Internet Explorer 5.5" and "offers a powerful new way" being written in an article posted on August 28, 2017

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?

Re: Introduction to HTML Components

#18
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 is a front-end framework for general purpose. Polymer is the library specifically to facilitate Web Component development only. So I think you are comparing apple and orange here.

Re: Introduction to HTML Components

#19

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 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 utility classes to make writing components easier.

Web Components is what is making me finally get to love web development again.

If it is to make an application platform out of browsers, then give me a platform, not an application for doing hypertext documents that we try to bend for something else.

Chrome settings panel, the new You Tube, all new EA gaming portals are already using Web Components.

I look forward to have something like Blend for Web Components.

https://www.youtube.com/watch?v=otcmcNY-3pk&t=17s

EDIT: fixed a few grammar issues

Post reply on HN