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

91–100 of 151 posts

Re: Introduction to HTML Components

#91

Post by alwillis »

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.

If you call web browser vendors mutinying against the W3C who was pushing XHTML 2 down their throats "politics", which lead to Apple, Mozilla and Opera creating the Web Hypertext Application Technology Working Group (WHATWG) and to HTML5--then I'm okay with the politics.

Yeah, I could close my tags and validate my code with the best of them back when XHTML was a thing--but that's no way to live. I'm glad WHATWG stepped in and literally saved the web from itself. OMG! XHTML 2 would have sucked so much!

Re: Introduction to HTML Components

#92

Post by dmitriid »

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

> With vanilla APIs the code is a bit more verbose and repetitive

Exactly. Just the code for syncing attributes and properties is enough to never ever use vanilla JS for WCs

Re: Introduction to HTML Components

#93

Post by ourcat »

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

Angular and React also have plans to eventually move into Web Components.

Aren't Angular directives more or less Web Components?

Re: Introduction to HTML Components

#94

Post by cageface »

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 was a little bit disappointed to see that the plan for Polymer 3.0 is to leverage ES modules to handle all the asset loading. Maybe their hand has been forced here since browser vendors refused to implement http imports but if Polymer requires a fair bit of Javascript to do anything interesting then its advantage over something like React becomes a bit less clear-cut, IMO.

Re: Introduction to HTML Components

#95

Post by dmitriid »

kinlan wrote: post #78
dmitriid wrote: post #62

Earlier quoted context omitted.

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

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

That's exactly what I'm saying. There are no WebComponents. There is no x-tags or whatever. There is only Polymer. For many reasons. Chief among them: WebComponents suck. Polymer at least gives nice-ish APIs on top of that.

Rob did say something like "Polymer is the jQuery of WebComponents". And it's true.

One could argue that you can write your stuff in pure DOM APIs. Yet hardly enyone ever did that, because there was jQuery. All the handlebars and mustaches and other things of this world were largely irrelevant because of jQuery.

Now, jQuery solved a very pressing problem: it gave an easy, simple, extensible API that made working with the DOM a joy. It would be very nice if jQuery's approach was adopted by w3c, but that is really too much to ask for.

In 11 years since jQuery's original release w3c managed — barely! — to standardize on querySelector/querySelectorAll (already a much more cumbersome combination of APIs than jQuery's $).

Enter WebComponents. 6 years in development. Quite a few years of saying that they are the future. Let's do a reality check, shall we?

The APIs are horrible. None of the original promises are fulfilled. As Polymer 3 approaches someone suddenly starts asking "erm, guys, what are the best ways of creating WebComponents without Polymer".

- It turns out even people who implement the spec in the browser don't have reference components.

- It turns out the API is so bad, you have to use pseudocode in your presentation to sell people the idea[1].

- It turns out WebComponents are so effing great and can really be used to reimplement stuff in the browser, ... that you can't even implement a checkbox without reimplementing the checkbox label [2]

- It turns out people don't even know how WCs should work. Quote from [1]: "If we can generally agree on how Custom Elements should behave..."

- It turns out that actually implementing WCs in anything but Polymer is a royal pain in basically everywhere because w3c's goal was never to create a sane API for anything.

etc. etc. etc.

Therefore, forget selling people the idea of WebComponents. For all intents and purposes they do not exist. Only Polymer exists. Masochists can go and check out the underlying DOM APIs, of course.

[1] https://www.youtube.com/watch?v=sK1ODp0nDbM

[2] https://github.com/GoogleChrome/howto-components/issues/112

Re: Introduction to HTML Components

#96

Post by ergo14 »

shadowmint wrote: post #39
tiglionabbit wrote: post #30

Earlier quoted context omitted.

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, r…

Actually - the process of creating both is exactly the same, I created components in angular, react and polymer. No difference IMO (apart implementation details).

Re: Introduction to HTML Components

#97

Post by ergo14 »

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…

From index page "Polymer is a JavaScript library that helps you create custom reusable HTML elements". I'm using Polymer components same as as react's controller/view components. You don't need to reimplement custom select's or whatever. You can use exact patters as other frameworks use.

Re: Introduction to HTML Components

#98

Post by JepZ »

byte1918 wrote: post #71
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.

Actually, it was much worse back then. Nowadays Apple Macs are affordable and alternative PC operating systems are quite usable too. In 1999 there was a usable but limited/old Win 95 and Win 98 which was crashing on a daily basis. So you can imagine how frustarating it was to work with such a machine.

Furthermore, microsoft was fighting open source software which didn't make them more popular: https://en.wikipedia.org/wiki/Halloween_documents

Compared to those times the data collection on modern Win 10 systems and forced updates are small sins ;-)

Re: Introduction to HTML Components

#99

Post by ergo14 »

Vinnl wrote: post #32
tiglionabbit wrote: post #30

Earlier quoted context omitted.

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.

I actually implemented React's UI Router in polymer, works the same as in Angular 1/2. The biggest issue with web components in general are problems with Shadow DOM support. Which means you need to do elements without shadow components up to top level - that is indeed annoying and reduces the pros of components.

Re: Introduction to HTML Components

#100

Post by ergo14 »

dmitriid wrote: post #95
kinlan wrote: post #78

Earlier quoted context omitted.

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

> 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. That's exactly what I'm saying. There are no WebComponents. There is no x-tags or whatever. There is only Polymer. For many reasons. Chief among them: WebComponents suck. Polymer at least gives nice-ish APIs on top of that. Rob did say something like "Polymer is th…

I think web components are low level and non-opinionated to give you freedom of implementation for higher level things. Thats what Polymer, Stencil, Svelte, SkateJS are for. Indeed WC API is not the nicest to work with to say the least, but thats not the problem, I write in python instead of Assembly, just user higher level stuff.
Post reply on HN