Your visualizer looks great! I really like that it queues up tasks to run instead of only operating on the code during runtime attachment. I haven't seen that kind of thing before.
I built my own node graph utility to do this for my code, after using Unreal's blueprints for the first time. Once it clicked for me that the two are different views of the same codebase, I was in love. It's so much easier for me to reason about node graphs, and so much easier for me to write code as plain text (with an IDE/language server). I share your wish that there were a more general utility for it, so I could use it for languages other than js/ts.
Not to nag, but this seems like a design error? WC font settings should be inherited and relative, rather than any specific pixel size. Designs should be robust enough to support overflowing text, should the user increase scale/zoom/etc.
Admittedly, I might not be understanding your problem well enough, so sorry in advance if I've mischaracterized the issue.
I love web components and, for the past few years, I've been building a simple demo app that is, itself, a web component[0]. The main problem I've found with web components is the ecosystem. The reason 1000 different devs can make react/svelte/vue components that all work together (obviously with some exceptions) is because they have the framework as a basis. If you want to use pure web components, you can't rely on a framework for any kind of architectural certainty. You're at the whim of what the other dev needed when they built the component.
And I don't find that bad for web components, as a whole, but if you wanted to build an app, you would most likely just use a web component framework (something that uses a base component and extends the rest from it), in which case you're limited to what that framework provides (and it won't be as robust as any non-wc framework). But if you're just looking to quickly slap in a component that "just works", you would have to do some real diligence to make sure it would fit which just is not a problem for any defined framework.
My approach has been to make a complete suite of CC0 components (which also meant no dependencies that I didn't write myself, so that I could make each dependency CC0, too), and let each component be an entirely standalone library, so that you could treat them like drop-in new html elements, rather than libraries to ingest and work with (in effect, the component should be as self-sufficient as an <input> or a <select> and require no js interaction from the consumer to work; just add the script and use the new tag). Of course, the major downside of that is that each component has to be it's own library which needs competent documentation (at least, I'm not going to remember how 15-20 different components all work in fine detail. I want some docs and examples!), and no other dev has any way of knowing that these components won't require an additional "base" script or component to work.
Overall, though, I'm happy with the results I've got (just finishing up all that documentation, at this point). And I definitely don't mind things like web components "not having reactivity" or "state", because I, personally, don't like being forced to push every piece of data through the rube-goldbergian plinko machine of reactive state. Different paradigms for different purposes and all that. So between not being forced to use it and having the events and attribute observation to be able to use it when I want it, I'm pretty satisfied with the state of web components on that front.
Honestly, the biggest issue I have with web components is how they work with "parts". I had to write a whole little library to make working with parts reliably comfortable for both library dev and consumer devs. I'd love a way to query on the "part" attributes, while within the component's shadow dom. As it stands, the best you can do is `[part="my-part"]`, which has obvious shortcomings if you're trying to use it like a class. Multi-classed elements are easy to select; doing anything complicated with part selectors would quickly spiral into a lot of `[part*="red"]:not([part*="redorange"])`, instead of `.red`, or whatever. The light dom is better because the ::part() selector treats parts like classes, so you can write selectors like class selectors. But, of course, you're limited to the part itself, so every single thing that should be stylable (in a lot of components, every single element; implementing devs should control style and display layout, just not functional layout) needs to have a part. And that's still a fairly superficial problem compared to the issue of not being able to automatically convert all "part" attributes into an "exportparts" value for the parent element. Again, not something that most libraries will need, but when you do need it, it's crazy that I would have to make a porting solution, myself. That's just begging for errors.
In any case, I generally agree with most of what the article has to say. As others have pointed out, some of the examples aren't really "best practices", but the overall point that web components are perfectly capable of building with is a solid one. I do still think that the old adage holds true, though: 'if you don't use a framework, you'll build one'.
(Notes for the demo pages: not production ready; the component will write to an indexedDB instance in your browser; the pages will add to your browser history [an option that is currently on, but is not the default config of the component];)
> in which case you're limited to what that framework provides (and it won't be as robust as any non-wc framework).
Is there something inherently wrong with wc that stops robust frameworks being built on top of it? Have you tried actual framworks built on wc like Lit for example.
No, I'm saying that if you use a non-wc framework, it will be more robust than any wc framework. Not because it's non-wc, but because it's more mature. Lit is mature, but it's not more mature than React, and it definitely has less contribution to it than react.
It's definitely possible to make a comprehensive web component library. Something that could compete with React. But, as far as I know, it doesn't currently exist (and would be a huge task to achieve with... no discernible reason to do it?).
Sorry but you're mixing up terms. A "web component library" would be something not compete with React, because React is a web component framework. The frameworks is whats used to build the component libraries e.g I think material design has one built on top of React.
I'm sorry you're having a hard time understanding. "library" just means "package of code". A framework - of any kind - is a library. Not all libraries are frameworks, but a web component framework would absolutely be a library. And since it is a library of web components, it can be called a "web component library", correctly. A library of react web components is also a web component library, for the same reasons.
I'm not mixing anything up, and I'm not being unclear. I could have used the same terms, but that I didn't does not make me incorrect. You're just splitting hairs. I'm sorry that seemed like it was worth your time.
You make great points! I appreciate the detail of the comment, and I don't particularly disagree with any of it. I think someone else mentioned gravestones that are etched and filled with black, so your suggestion of just doing that with sensible scales and fonts seems like a slam dunk, to me.
Bummer that it doesn't really seem feasible for a hobbyist, though. I take your meaning with the wax and such, but I think my solution would just be to go bigger and store less data. And I mean bigger like, 20 characters per print bed, or something. But then, at that scale, maybe a QR code would hold up well enough in plastic, too?
Overall, I think I've mostly learned that "archiving format" is a broad term that really needs to be collapsed by describing how the archive will be stored (and what extremes/complications to expect). In any case, thanks for the links and again for the detailed discussion!
> I take your meaning with the wax and such, but I think my solution would just be to go bigger and store less data. And I mean bigger like, 20 characters per print bed, or something. But then, at that scale, maybe a QR code would hold up well enough in plastic, too?
Only way to know is to try it! I think you might be surprised. QR codes (with high redundancy settings) are very resistant to corruption.
The idea with the wax is to transfer the data into a more durable final product... Lost wax casting, you print wax, cover the wax in plaster, melt the wax, pour a metal (or epoxy) into the plaster mold.
Hey all! Wild to see my silly question pop up on the front page, but very cool! I hope it was because of a spike in interest for some reason, but...
Please forgive me, this is the first time I've ever been on the front page, but I'm seeing something odd? I posted this topic days ago and it was well received and then kind of done. But now it is showing both on the front page and on the ask page as having been posted only 8 hours ago. Is that normal?
I did see a topic the other day about HN being flooded with content, where some mods responded that they were doing work in that area. If I hadn't seen that, I probably would have just assumed that any ask that gets bumped up to the front page might get re-zeroed for posting time on all the existing comments. But given the other topic, I thought I'd pop back in and ask!
That aside, I do appreciate everyone's comments! I can't respond to them all, but hopefully I've hit all the main suggestions so far. Thanks again for the breadth of consideration!
Sometimes the PTB will give a post another chance at the front page when they feel it was a good post that deserved more attention that it got when originally submitted, and it behaves exactly like this - the time resets on the post and comments, and new discussion ensues.
Asking the wrong question, friend. What should the penalty be for failing to process an immigrant through your system for ~7 years? Where does the fucking buck stop? The US immigration system is broken, and has been, so where are the penalties for this mismanagement? I'd love to see Republicans propose a punitive approach here, but all I seem to hear is though terminating cliches like "should we just have open borders?"
But, absolutely - after we fix the broken system and start processing immigration in a reasonable and timely manner, then we can start asking what the penalties should be for people who abuse our immigration system. But I don't have an ounce of energy to spare on that deflection until the former is done.
Wow! Now that's some outside the box thinking. That even seems to suggest that "watermarking" a print (or a small, hard to notice part of a print) would be possible.
I also think you could get denser storage that way? I guess depending upon how thick the "wire" is? But it's an interesting idea for both just printing the wire, and for the driver-teeth imprinting, separately. Very cool!
Not sure how it will survive extrusion. But yeah, the wire is a cylinder so you can ‘imprint’ multple ‘sides’. Another idea, some form of anti temper encryption like little particles (flock) inside the filament (like those colored rice anti temper methods)
I completely hadn't considered the idea that QR codes could be made 3D (in fact, now I'm curious how much denser they can get, if you can both read and write them in 3D), but now that people have said it, it seems so obvious! I really like your follow up about using the error-correcting properties of it. A great feature that would be very unlikely to be realized in amateur 3d data implementation.
I built my own node graph utility to do this for my code, after using Unreal's blueprints for the first time. Once it clicked for me that the two are different views of the same codebase, I was in love. It's so much easier for me to reason about node graphs, and so much easier for me to write code as plain text (with an IDE/language server). I share your wish that there were a more general utility for it, so I could use it for languages other than js/ts.
Anyway, great job on this!
reply