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

31–40 of 151 posts

Re: Introduction to HTML Components

#31

Post by Yaggo »

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?

Most if not all major browsers let you style scrollbars, but the problem is that styling for built-in widgets is not standardized, i.e. it relies on vendor prefixes and worse, not all (sub) elements can be styled at all depending on browser. E.g. has poor support for styling.

Re: Introduction to HTML Components

#32

Post by Vinnl »

tiglionabbit wrote: post #30
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…

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.

That "sometimes" quickly breaks down when your application starts to grow beyond trivial. Some things that are rather application-specific like routing and dependency management don't quite compose well in the widget model. Or at least, Polymer at the moment doesn't have proper solutions to quite some edge cases that you'll be running into.

Re: Introduction to HTML Components

#33

Post by dheera »

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…

The main problems I have with Polymer:

* It's cumbersome to install. apt-get install npm && npm install bower && bower install ... this is about when I give up. Why not just include a 'polymer.js' file that just does all the work, no installs needed, no questions asked, CDN provided, batteries included, like every other client-side JavaScript library on the planet? Even the appropriate CSS can be loaded by the JavaScript itself, but it isn't.

* Bloated. You end up downloading several hundred kilobytes of JavaScript if your webapp uses more than a few different types of UI elements.

* Polymer components don't behave like native components. For example, you cannot swipe between tabs like a ViewPager does on Android. Implementing any kind of swipe-based feedback is hard, including pull-to-refresh. Back to native programming, I guess.

* For having so much marketing and PR and a camel-cased name "WebComponents", you would think it would be productized enough that it employ the appropriate native Android elements at least in Google Chrome on Android, and use the HTML5 substitutes on iOS and desktop. For example, you should replace the Polymer button with an actual styled Android button instead of a nested div hell. Chrome should have worked with the Polymer team on this. Not doing this has serious performance implications when you display thousands of items (e.g. lists of results, contact lists) each with their own nested div hell. Back to native programming, I guess.

* There is no framework to make apps look iOSish on iOS and Androidish on Android. Back to native programming, I guess.

Re: Introduction to HTML Components

#34

Post by drawkbox »

A great early site back in the DHTML/component days where IE4 was really pushing things was WebFX [1]. This was back when IE was actually a good browser as Netscape was fading due to DHTML/early AJAX (which was the XMLHttpRequest object originally from Exchange Server). DHTML at the time was mostly easier in IE because it didn't draw a new DOM for each layer i.e. document.layers (Netscape) each layer was a new full DOM and document.all (IE) was one DOM.

[1] http://webfx.eae.net/

Re: Introduction to HTML Components

#35

Post by fergie »

"Why did IE5’s HTML Components never quite catch on? Despite what you might think, it’s not because of a lack of open standards"

Actually thats precisely why it never caught on. Source: I was front end developer at one of the big dotcoms ca 2000.

Also, its remarkable how many people skimmed this article, and didn't understand that the first part was from 1999. That really says a lot about people's expectations when it comes to Microsoft and web technology.

Re: Introduction to HTML Components

#37

Post by nilliams »

dheera wrote: post #33
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…

The main problems I have with Polymer: * It's cumbersome to install. apt-get install npm && npm install bower && bower install ... this is about when I give up. Why not just include a 'polymer.js' file that just does all the work, no installs needed, no questions asked, CDN provided, batteries included, like every other client-side JavaScript library on the planet? Even the appropriate CSS can be loaded by the JavaSc…

Looks like they're working on moving away from bower: https://github.com/Polymer/polymer/issues/326#issuecomment-3...

A quick CDN get-started would be convenient I agree. There is Polymer-CDN for demos/code-pens: https://github.com/download/polymer-cdn

The 'native' stuff in your comment I don't agree with. You want browsers to start implementing native Android ListViews/Buttons etc? Browsers have a hard enough time implementing web standards.

Re: Introduction to HTML Components

#38

Post by em_te »

pjmlp wrote: post #20
jlebrech wrote: post #17

creating apps in html is like creating a spreadsheet in word. why didn't we stick to xml and use a language to transform it into ui.

I was a big fan of XHTML and all related XML Components, but then politics won.

Yeah but having to switch to createElement, appendChild, insertBefore, createTextNode just because innerHTML was not allowed was a pain in the butt.

Re: Introduction to HTML Components

#39

Post by shadowmint »

tiglionabbit wrote: post #30
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…

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.

I think you've misunderstood my point; I don't think that at all.

I'm specifically criticising the focus polymer has on creating user interaction elements.

My point is that this sort of low level functionality isn't the right place to focus; most low level components you need already exist. What people is a way to build robust application UIs (and yeah, that includes having a root level component).

For comparison, read:

https://www.polymer-project.org/2.0/start/

'build custom ui widgets' vs.

https://vuejs.org/v2/guide/#Composing-with-Components

'build your application from components' <-- right.

Re: Introduction to HTML Components

#40

Post by insin »

DaiPlusPlus wrote: post #14
urvader wrote: 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…

I still use them - IE9 being the highest available engine is just as bad as you remember, but being able to quickly whip up a few-hundred KB app HR can all use off a network drive to automate tedious tasks like recurring data-driven document generation, with a decent React UI, is worth some of the pain.
Post reply on HN