Skip to content

TodoMVC app built using Custom Elements and up-and-coming vanilla code in the browser and on the server.

Notifications You must be signed in to change notification settings

shannonmoeller/todomvc-custom-elements

Repository files navigation

Custom Elements TodoMVC Example

Custom Elements is a capability for creating your own custom HTML elements. They can have their own scripted behavior and CSS styling. They are a part of web components, but can also be used by themselves.

Custom Elements - developer.mozilla.org

Demo

https://todomvc-custom-elements.now.sh/

Learning Custom Elements

The Web Fundamentals website is a great resource for getting started.

Articles and guides from the community:

Philosophy

The guiding principle in this implementation of the TodoMVC is to use up-and-coming vanilla code in the browser and on the server. Right now, the code is transpiled and uglified, but the ultimate goal is to remove the toolchain and have things Just Work™.

The web platform has come a long way. It is no longer the hostile environment it used to be. Embracing the browser is key to long-term code stability. Frameworks and patterns will come and go, but the browser is here for the foreseeable future.

Dare to reacquaint yourself.

What about Shadow DOM?

Web components are comprised of many separate APIs. You don't need to use them all every time. The Shadow DOM is often a cannon used to kill a mosquito. Scoped CSS is a really great idea when an element is going to be dropped into a hostile environment, but this project is friendlier than that. Additionally, encapsulation can break the document outline, complicate accessibility, and lead to some nasty anti-patterns like attribute-proxying.

Why isn't every part of a component in the same directory?

This topic has been beaten to death elsewhere. Suffice it to say that I'm not ready to throw out over a decade of best practices regarding separation of concerns.

But, separation of concerns is different from separation of technologies.

I agree! But, it just so happens that in the browser we have separate technologies for separate concerns. Yay, browser! HTML defines what things are. CSS defines how things look. JS defines how things work. There may be overlap, but at the end of the day I don't want to fork a whole component or bloat its interface because I need to change a heading font in one particular use case (I wish that was a hypothetical example).


MIT © Shannon Moeller

Releases

No releases published

Packages

No packages published