4 ms·

Show HN: A web component framework with templating

1 points by graderjs 4y ago

graderjs 4y ago
I wanted a way to combine the ease of templating of a previous framework I made (brutal.js) with web components (mainly because web components let me work faster, and I think a big part of that is because of the benefits of easier styling when you have style isolation because of the shadow tree), so I came up with something where you structure a components files into a directory (the below assumes a component called sg-frame): components/sg-counter/markup.html: <sg-frame state=${_self}> <button id=counter onclick=Increment>Count</button> <label for=counter>${count}</label> </sg-frame> components/sg-counter/script.js: class Counter extends Base { Increment() { const {state} = this; state.count++; this.state = state; } } components/sg-counter/style.css label { min-width: 4.5ch; display: inline-block; text-align: right; } Which you then use by dropping: import {use} from 'good.html'; use('sg-frame'); use('sg-counter'); in your client-side JS. I did this (added this organizing principle) even tho I don't like the templating syntax as much as brutal.js's effortlessly simple: F`<ul>${items.map(async item => F` <li> <span class=name>${item.name}</span> <img src=${img.imgSrc}</span> <span class=price>${await item.getLatestPrice()}</span> ${itemDetails(item)} </li>`)} </ul>`; because I found the benefits of having things organized into directories, and having all the functions needing to be on the class allowed me to move faster. Conceptually, I don't think you need to have trade-off between "organization overhead" and "effortless syntax" but in the current iteration of my framework explorations, this is all I could come up with. It's a tradeoff I'm willing to make in my own work, because the ability to move faster overall, and especially over complex sections, and move faster when the overall project becomes more complex, trumps, for me, the ability to move faster in a single isolated view function case. Because I value the minute-by-minute developer experience for myself, what it's actually like coding, I need the syntax to be as easy and simple as possible, the lowest cognitive overhead, so even tho I've traded some of that, for a greater overall speed as a result of enforcing some organization, I've still optimized for that as much as I'm able to here.

1 points by graderjs 4y ago

I wanted a way to combine the ease of templating of a previous framework I made (brutal.js) with web components (mainly because web components let me work faster, and I think a big part of that is because of the benefits of easier styling when you have style isolation because of the shadow tree), so I came up with something where you structure a components files into a directory (the below assumes a component called sg-frame): components/sg-counter/markup.html: <sg-frame state=${_self}> <button id=counter onclick=Increment>Count</button> <label for=counter>${count}</label> </sg-frame> components/sg-counter/script.js: class Counter extends Base { Increment() { const {state} = this; state.count++; this.state = state; } } components/sg-counter/style.css label { min-width: 4.5ch; display: inline-block; text-align: right; } Which you then use by dropping: import {use} from 'good.html'; use('sg-frame'); use('sg-counter'); in your client-side JS. I did this (added this organizing principle) even tho I don't like the templating syntax as much as brutal.js's effortlessly simple: F`<ul>${items.map(async item => F` <li> <span class=name>${item.name}</span> <img src=${img.imgSrc}</span> <span class=price>${await item.getLatestPrice()}</span> ${itemDetails(item)} </li>`)} </ul>`; because I found the benefits of having things organized into directories, and having all the functions needing to be on the class allowed me to move faster. Conceptually, I don't think you need to have trade-off between "organization overhead" and "effortless syntax" but in the current iteration of my framework explorations, this is all I could come up with. It's a tradeoff I'm willing to make in my own work, because the ability to move faster overall, and especially over complex sections, and move faster when the overall project becomes more complex, trumps, for me, the ability to move faster in a single isolated view function case. Because I value the minute-by-minute developer experience for myself, what it's actually like coding, I need the syntax to be as easy and simple as possible, the lowest cognitive overhead, so even tho I've traded some of that, for a greater overall speed as a result of enforcing some organization, I've still optimized for that as much as I'm able to here.