Re: [w3c/webcomponents] idea: easy way to specify attributes (and optionally enable getters/setters). (#517)

@rniwa 

> because no builtin elements add attributes during construction.

It may be true now, but the spec can be modified. That's not what the element's currently do, but that *could* be what they do in the future, as part of what explains how things work (following the Extensible Web Manifesto)...

@treshugart 

> ...I don't think allowing non-string values to go to, or come back from `setAttribute()` / `getAttribute()` is the best idea considering eventually they'd have to be serialised anyways...
> Skate offers an API to [`serialize`](https://github.com/skatejs/skatejs#serialize) to and [`deserialize`](https://github.com/skatejs/skatejs#deserialize) from attributes.

That seems like a performance bottle neck when it comes to passing data from outer component to inner component, and so on. It'd be nice for anything that is passed via attributes to remain exactly as it is until it gets to where it needs to be (the thing being passed might flow into some inner, inner tree).

What I'm imagining is that component layers might go deep in a big application (layers of nested Shadow DOM trees, and possibly with encapsulated component registration as in #488). Imagine this horrible performance scenario:

- An app has 3 layers of ShadowDOM trees, each layer is the ShadowDOM of a Custom Element. The elements are A, B, and C.
- The app developer only uses element A directly, and passes a string into an attribute, where the attribute is called `array` (to be generic) and accepts an array of numbers:
  ```html
  <A array="1,2,3"></A>
  ```
- Suppose that element B, used internally inside of A's shadow DOM, will also accept an array of numbers in some attribute after A has modified the values. Element A will need to deserialize the array, modify the values, then convert it back into a string to pass to element B.
- Element C is used in element B's shadow tree and also needs to accept an array of numbers. Element B will deserialize the array, do some modifications, then finally serialize it to pass it to C.

### Doesn't that sound bad?

---

In general, I think what we should aim for is not using serialization/deserialization until the very last moment, or not at all. For example, nothing should need to be serialized until necessary (f.e. DevTools may need to show the values in the element inspector, but if DevTools are never used, serialization/deserialization may never even need to happen). Serialization/deserialization could also be good for server-side rendering or saving state, but should be completely avoided until the last minute when it is needed.

Right now, serialization/deserialization is the default, no matter what, and in my opinion that's awful because it require unnecessary performance costs.

I'd like to see HTML interfaces being used to create immersive 3D experiences (f.e. games or 3D UIs). This is beginning to happen, and as an author of 3D content I would highly appreciate this performance improvement.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/517#issuecomment-224763625