ZjsComponent

> One fun thing I did once is use the custom elements API to make a custom tag <element-template>. When the page sees <element-template tag=what-name></element-template>, it looks inside, finds any <template></template> <script></script> and <style></style> tags, and builds a new custom element with that tag name and all the powers. Cool but not incredibly simple. I went a similar way: https://github.com/lelanthran/ZjsComponent Not using it in anger in any prod system right now (finding the past, prior to AI, though), but all my side projects use it. Need to check and close any security issues this may have (not that I know of any yet. Should probably ask an LLM at some point about the danger of this).

> Who would ever want this? Your lack of imagination is disturbing :-) https://github.com/lelanthran/ZjsComponent

> Web components are the way out of this trap. Every single framework that isn't React should be wholeheartedly supporting web components to make sure that they have access to a viable ecosystem of components and utilities without having to bootstrap an entire competitor to React and it's ecosystem. I've been using web components using a wrapper to avoid all boilerplate. It gets me 80% of web component functionality with very little effort: https://github.com/lelanthran/ZjsComponent Discussed on HN previously: https://news.ycombinator.com/item?id=44290315 Now this is not perfect, but there is, for me, no easier way to create and use new html components.

> On one hand I agree, one should approach issues as they come, but there's solutions that are hard to ignore such as the need for reusable fragments/components on different pages which already make a cry for dependencies. I side-stepped that completely, even on actual production web apps for clients, with this: https://github.com/lelanthran/ZjsComponent Now, you may argue that that is a dependency, but it doesn't have any of its own, you can make a copy of it, serve it from your primary domain, and you're done.

> Something that can go from a backend handlers straight to terse markup for reactive UI would be a massive simplification to all this, and a big productivity boost. I do this for custom software I build for clients, mostly on the backend though[1]. Started it two years ago, have rapid velocity and, without AI generally take 30 to 60 minutes to implement a new feature that touches backend persistence and front end UI. ‐---------- [1] I did a show HN on a tiny front end component that gets the most use, recently, I think. ISTR most people in the comments said they they preferred React, a few said it was not novel enough to be a paper (they are correct. It isn't). You can see it here: https://github.com/lelanthran/ZjsComponent/ I'm not really in the mood to open up the whole stack I use yet, I still make money bu having a low effort way to

> 1. Making it possible to do something like <template src="..."> and being able to load them from an external source I've done that, requires no build step/npm/whatever. It was posted on HN for discussion a week ago: https://github.com/lelanthran/ZjsComponent

Thanks to the availability of ChatGPT and Claude, I have actually checked all those links prior to creating my own. The ZjsComponent thing I use is unlike those things; while the goal of those (and other similar projects) is primarily to perform client-side includes, the goal of zjs-component is to provide client-side object instantiation using a remote object definition. The paper itself may be a bit arcane and obscure, but as a quick example of what zjs-component was intended to do, see the GH page: https://github.com/lelanthran/ZjsComponent/tree/master?tab=r... As you'll see from the above link, the goal was not to simply include remote fragments (with some execution behaviour), but to instantiate a local instance of an object defined in a remote file fragment and support instance-scoped code and HTML. IOW, it's the scoping to a speci

For anyone curious, the source code: https://github.com/lelanthran/ZjsComponent/