3 ms·

You can create reusable UI widgets that are usable without the user knowing how they were written. e.g. with today's frameworks you need to know how to create w

by rictic 10y ago

You can create reusable UI widgets that are usable without the user knowing how they were written. e.g. with today's frameworks you need to know how to create widget, and that may involve rolling up your sleeves and diving into a bunch of framework-specific concepts. With custom elements you could just have your server emit an <image-carousel> element, or do document.createElement('image-carousel'). This is good for ease of use, but it's also great for interop. Custom elements work with every way of writing a web site because every way of writing a web site can deal with elements.

jessedhillon 10y ago
But in reality, the server would have to emit <image-carousel delay="10" images="['...', '...']" end-behavior="cycle"> Thus making us no more free from the details of the component than we were before.
- abiox 10y ago
  > no more free from the details i suppose it depends on what you mean by "the details." details can be just the inputs required by "the interface" or it can be specifics of "the implementation". the purpose of an interface is often to distance (perhaps even "free", depending) the user from the implementation.
- rictic 10y ago
  Parameters aren't implementation details. Implementation details are stuff like "It's written in framework X so you need to call that framework's init method after document load, then do frameworkX.initCarousel(document.querySelectorAll('.image-carousel')).onEnd((carousel) => carousel.cycle())".
bryanrasmussen 10y ago
I suppose the ship has sailed a while ago on this, considering various projects I've had over the last couple years but: You can create reusable UI widgets that are usable without the user knowing how they were written with an element like <div class="FrameworkName_imageCarousel" ...> also, and your client library handles FrameworkName_imageCarousel without you needing to know how that is done. I guess where document.createElement is concerned you might need to do framework.create('image-carousel'); or something similar, but I suspect if you are programmatically creating your custom elements you are probably also going to have to do more with them than just create them, and at that point you are going to need to know what code you are expected to call to do whatever things you want to do. When you say it's also great for interop I worry we have a different definition of interop - I don't call it interop when my way of writing a web site can deal with elements, I call it interop when other people's ways of consuming websites can deal with elements and I have a hard time to understand how interop is going to be great for consumption of non-standardized elements (robots etc. included under other people's ways of consuming websites) My feeling is really that a benefit to this that does not seem to get discussed is the ability to limit 'interop' that the solution builder does not explicitly control with its implementation (except where the big players are concerned, who have the resources to overcome piddling limits like these). So no more easy crawler solutions, you want to deal with crawling our site and you're not google? Well you will have to reverse engineer our <asio-link> element and figure out how it works to crawl it. Even if you automate a browser you still have to have code to click on asio-links to get the script implementing that element to run! But like I say that ship has pretty much sailed anyway, this kind of thing just officially validates the direction the ship is headed. (and I'm not happy about the direction)
- om2 10y ago
  > You can create reusable UI widgets that are usable without the user knowing how they were written with an element like > <div class="FrameworkName_imageCarousel" ...> also, and your > client library handles FrameworkName_imageCarousel without you needing to know how that is done. With all frameworks I know of, this won't work for elements dynamically added to the DOM after the start of your application. Not only document.createElement, but even if you insert chunks of markup using innerHTML or the like. Sometimes there is a framework-specific call to do the right thing, but then you're back to needing to know how an element is implemented. For Custom Elements, it really is as simple as just inserting them. You don't have to run any script code to make them do what they do.
  - bryanrasmussen 10y ago
    Ok thanks, now I see a benefit - not sure if I consider it enough of a benefit for creating what I would consider to be awful interop problems but I can see a benefit.

by rictic 10y ago

jessedhillon 10y ago

But in reality, the server would have to emit <image-carousel delay="10" images="['...', '...']" end-behavior="cycle"> Thus making us no more free from the details of the component than we were before.

abiox 10y ago
> no more free from the details i suppose it depends on what you mean by "the details." details can be just the inputs required by "the interface" or it can be specifics of "the implementation". the purpose of an interface is often to distance (perhaps even "free", depending) the user from the implementation.
rictic 10y ago
Parameters aren't implementation details. Implementation details are stuff like "It's written in framework X so you need to call that framework's init method after document load, then do frameworkX.initCarousel(document.querySelectorAll('.image-carousel')).onEnd((carousel) => carousel.cycle())".

bryanrasmussen 10y ago

I suppose the ship has sailed a while ago on this, considering various projects I've had over the last couple years but: You can create reusable UI widgets that are usable without the user knowing how they were written with an element like <div class="FrameworkName_imageCarousel" ...> also, and your client library handles FrameworkName_imageCarousel without you needing to know how that is done. I guess where document.createElement is concerned you might need to do framework.create('image-carousel'); or something similar, but I suspect if you are programmatically creating your custom elements you are probably also going to have to do more with them than just create them, and at that point you are going to need to know what code you are expected to call to do whatever things you want to do. When you say it's also great for interop I worry we have a different definition of interop - I don't call it interop when my way of writing a web site can deal with elements, I call it interop when other people's ways of consuming websites can deal with elements and I have a hard time to understand how interop is going to be great for consumption of non-standardized elements (robots etc. included under other people's ways of consuming websites) My feeling is really that a benefit to this that does not seem to get discussed is the ability to limit 'interop' that the solution builder does not explicitly control with its implementation (except where the big players are concerned, who have the resources to overcome piddling limits like these). So no more easy crawler solutions, you want to deal with crawling our site and you're not google? Well you will have to reverse engineer our <asio-link> element and figure out how it works to crawl it. Even if you automate a browser you still have to have code to click on asio-links to get the script implementing that element to run! But like I say that ship has pretty much sailed anyway, this kind of thing just officially validates the direction the ship is headed. (and I'm not happy about the direction)

om2 10y ago
> You can create reusable UI widgets that are usable without the user knowing how they were written with an element like > <div class="FrameworkName_imageCarousel" ...> also, and your > client library handles FrameworkName_imageCarousel without you needing to know how that is done. With all frameworks I know of, this won't work for elements dynamically added to the DOM after the start of your application. Not only document.createElement, but even if you insert chunks of markup using innerHTML or the like. Sometimes there is a framework-specific call to do the right thing, but then you're back to needing to know how an element is implemented. For Custom Elements, it really is as simple as just inserting them. You don't have to run any script code to make them do what they do.
- bryanrasmussen 10y ago
  Ok thanks, now I see a benefit - not sure if I consider it enough of a benefit for creating what I would consider to be awful interop problems but I can see a benefit.