Profile cover photo
Profile photo
Component Kitchen
53 followers -
The best ingredients for your web apps
The best ingredients for your web apps

53 followers
About
Component Kitchen's posts

Post has attachment
We believe in progressive web applications as a strong alternative to native mobile applications. Along with small experimental projects we conduct on the side, we intend to improve our web site over time with new techniques and patterns, both to educate ourselves as well as to demonstrate the worth of these browser improvements. Our latest improvement makes use of Service Workers. You can now view most of the Component Kitchen website offline, courtesy of the power of Service Workers.

Post has attachment
We’ve rewritten the component.kitchen backend server to rip out a popular templating language and replace it with plain JavaScript functions. Recent language improvements in ES2015 have, in our opinion, made it a sufficiently capable general-purpose language that we’ve dropped use of a special-purpose template language. As we began a rewrite of our site, we were inspired by our recent work using plain JavaScript functions to create web components and decided to apply the same philosophy to our backend as well.

Post has attachment
The rising interest in React inspired us to try implementing web components that use a reactive approach to rendering. As an experiment, we’ve redone a React tutorial in web components, using Redux for predictive state management, JSX for rendering state, and virtual-dom for comparative DOM updating. Essentially, we treat each web component as if it were a reactive application in its own right.

Post has attachment
What if you want to create #webcomponents that extends the behavior of standard HTML elements? An early draft of the Custom Elements specification allowed you to do this with a special syntax, but the fate of that syntax is in doubt. We've been trying to create custom variations of standard elements without that support, and wanted to share our progress. Our results are mixed: more positive than we expected, but with some downsides.

Post has attachment

Post has attachment

Post has attachment
We like the idea of defining a mixin as a function that takes a base class and returns a subclass with the desired functionality. We like this so much, in fact, we've changed our nascent core-component-mixin project to use mixin functions.

Post has attachment
We think it’s generally necessary to use some sort of framework to develop web components, but that framework may not have to be monolithic in nature. Instead, the framework might be built entirely as mixins on top of a kernel that enables mixin composition. Rather than invoking a framework’s class constructor, one would simply compose the desired mixins together to create an instantiable web component.

Post has attachment
Web components are a great way to package user interface behavior, but they may not be the most interesting fundamental unit of behavior. There are certain aspects of behavior which you'd like to be able to share across components: accessibility, touch gestures, selection effects, and so on. Those things aren't top-level components in their own right; they're abstract aspects of behavior.

If we imagine a web component as a molecule, what's the equivalent of an atom? That is, can we decompose a web component into a more fundamental coding unit?


Post has attachment
Wait while more posts are being loaded