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

61–70 of 151 posts

Re: Introduction to HTML Components

#61

Post by allover »

chenster wrote: post #57
dmitriid wrote: post #53

Earlier quoted context omitted.

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

Re: Introduction to HTML Components

#62

Post by dmitriid »

chenster wrote: post #57
dmitriid wrote: post #53

Earlier quoted context omitted.

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

Re: Introduction to HTML Components

#63

Post by dmitriid »

peterhunt wrote: post #58
pjmlp wrote: post #54

Earlier quoted context omitted.

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

It's partly true, see https://custom-elements-everywhere.com and linked issues.

The main problem: when the framework makes the developer decide whether to pass attributes or properties to Custom Elements, it's mostly ok. The framework should also allow binding any events (which cna be named as onEvent, or on-event or...)

Frameworks that are trying to be clever and hide the complexities of DOM behind proper APIs, and that implement their own event systems suffer greatly because DOM APIs and WebComponent APIs are a pile of steaming crap.

Re: Introduction to HTML Components

#64

Post by mattacular »

pjmlp wrote: post #19
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 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 wish people would stop saying "feature X is already here" when it is missing Edge and Firefox support. What projects are people working on where they can happily overlook the fact that something simply won't work in 2 out of 4 major browsers in use today?

Re: Introduction to HTML Components

#65

Post by Can_Not »

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…

> It's cumbersome to install. apt-get install npm && npm install bower && bower install ... this is about when I give up

Half the things I've ever installed were far more complicated than that.

Re: Introduction to HTML Components

#66

Post by noisem4ker »

Yaggo wrote: post #22
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…

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

Or maybe designers should learn to respect the platform's widgets' look and feel, which the user is familiar with and has possibly customized according to their preferences and accessibility needs.

Re: Introduction to HTML Components

#67

Post by girvo »

jlebrech wrote: post #41
em_te wrote: post #38

Earlier quoted context omitted.

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

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.

Re: Introduction to HTML Components

#69

Post by alwillis »

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…

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

Google's Flutter certainly creates apps (using mostly web technologies) that have the correct look and feel for Android and iOS from the same codebase.

Keynote: Flutter (Dart Developer Summit 2016)»https://www.youtube.com/watch?v=Mx-AllVZ1VY

Re: Introduction to HTML Components

#70

Post by jarek-foksa »

dmitriid wrote: post #49
pjmlp wrote: 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.

> 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

Post reply on HN