DEV Community

loading...

Discussion on: Why I coded a micro library for Web Components

Collapse
maxart2501 profile image
Massimo Artizzu

Heavy inspiration from Angular, I see.

It looks definitely nice, but there are some things that makes me wonder.

ECMAScript Decorators for Web Components

Those look like TypeScript decorators, and as such they're not ECMAScript. The specs are now on completely different paths. Maybe clarify that?

update attributes and innerText discretely.

Using innerText instead of textContent or changing the data property of the text node is a peculiar choice. innerText rearranges whitespaces under the hood and it's generally slower, but it can serve a purpose. Is this the case?

Emitter defines an EventEmitter pattern that can use BroadcastChannel API

There's another possible source of confusion here, as there's a stage 1 proposal called - you guessed - Emitter. It could be take a couple of years, sure, but still a possible name conflict.

All in all, it's a nice approach. There are several problems with Web Components, and you got to the point in targeting them. Boilerplate code, verbosity, non-intuitive interfaces... you name it. I think it's a step on the right direction.

Also, I like the choice of TypeScript.

Collapse
steveblue profile image
Steve Belovarich Author

innerText was a typo. It is textContent for sure ๐Ÿ˜œ. Edited for clarity.

Ugh different spec paths for Decorators. I should read up on this more. From what I understand the stage 2 proposal is basically what TypeScript currently implements.

Didnโ€™t know about Emitter, thatโ€™s cool ๐Ÿ˜Ž.

Glad you like the direction. I definitely wanted to take some of the pain points away from developing Web Components.