catapart

Ah, I see! Very cool! Yeah, this is the kind of thing I was looking for, so this should give me what I need to test some proof of concepts. Thanks for the links! I do wish there were something a little more ergonomic, but I'm way too far into the begging to be choosing, here, so I'm quite happy to take what I can get.

In any case, I really do appreciate the dual links. It's so much harder to suss out the boundaries of a library with only one implementation. This was really helpful.

Great recc! Unfortunately, raylib doesn't quite go as far as I would need. raylib does all of the text rendering in a very clean way, so I love it for that. But as far as actual editing, it doesn't have anything for that (last I checked, at least). It can render the text in way more ways than I need it to, but it can't actually do the editing work that prevents the common text-editing traps like line-based editing.

It's kind of an odd thing, I think. There are a bunch of articles on how you can write your own AST and use all kinds of data ranges (instead of heap allocation) to do deep technical performance optimization, but very few libraries that actually do any of that which aren't also bundled into an inseparable implementation of the library as a control/editor. Feels like there has been enough ink spilled over the "how" that someone would have packaged it up together into a referenceable library. Yet nothing I can find quite fits.

I appreciate this, but I'm not concerned with the capabilities of the terminal or the GUI. What would be unhelpful, to me, would be to build a TUI because then if I wanted to send the actual app state to - for instance, a web browser which runs the library in WASM - the only way would be to pipe the terminal output across the shared buffer, instead of just blitting the app/editor state into it (or the relevant messages, like CRDTs).

Contrast that with a library: I could capture the inputs from any source - browser, native app, network, etc - work with the data using the single library, and then render the result in whatever client (or as many clients) as I wanted.

I guess I might be misunderstanding what Scintilla is? Everything I've seen with it has it coupled with native controls, like a winform control or a Qt control. Are you saying that the library can be used, on its own, without a graphical component? If so, that might fit the bill!

Any chance people in this thread have some recommendations for text-editing libraries? I would love to build my own text editor, to do some things in my own way that no one else seems to have an interest in doing, but one of the big things for me is that it must be a GUI. I won't bore people with the reasons, but that requirement forces me to bring along a lot of stuff, like a font renderer (at least one) and a graphics context.

To do all of that and write a text editing library at the same time is a little more than my nights and weekends can handle. If I start on just the text editor, it'll only work in a terminal console, so I won't actually use it for my own projects. If I start on just the GUI, I won't actually use it because it won't actually work. So, even if I'm going to replace the text editing library at the heart of the project with custom code, eventually, it's pretty much a non-starter if I don't have something to use to get started.

To be honest, I'm kind of surprised to have so much trouble finding a solution here. Everything I find is either a self-contained text editor, or a full-on "mission statement" GUI (development can be easier/better by using our editor's features). I've had a very hard time finding something that is just an API that I can feed input and have it return me reasonable state updates about the text content. CRDTs or whatever.

I'm assuming people just figure you're either going to write a toy text editor, in which case simple text editing will work, or you're going to write a full-blown showcase product, in which case your advanced structural design with performance-focused editing, language servers, multi-cursor support, etc, will be your selling point and functional focus. But that seems to leave this surprising hole where a developer who wanted to "rebuild windows' Notepad app, except that it can handle text files with massive lines without slowing way down" would have to actually implement the advanced text editing line management rather than just use a library for this well-solved problem.

Big time +1, here. Would love to hear something - anything - from the bsky team that takes some accountability.

This looks really useful! I'm having a hard time understanding how it might be used by each specific user, using their own LLM instance, though. Is that because it does not support that type of bring-your-own-llm scheme, or am I just not putting two and two together with some kind of chain of user authentication, then token exchange?

Yeah, I think there's a lot of juice left in the "newstand" model. We just have to figure out how to translate the efficiency of "drop in quarter, get news" with digital currency and content. Like you said: a micro-transactional framework. That would be a hell of a thing to get started, but if you could my money's on it working like a charm.

I'm not suggesting monetization without ads or subscriptions. I'm suggesting monetization without obnoxious bullshit like full page, scroll arresting ads, or news content locked behind a paywall, rather than editorial content locked behind a paywall.

If I go to your website where you purport to cover the news of the tech industry, it is always in your best interest to actually give me that news. I'd prefer it if they gave a dry, sometimes even bullet-pointed list of bare news facts. What they know, how they know it, and the basic ways it affects the site's topic/hobby, as soon as they possibly know it. From there, link to your subscription content that goes into detail about the news and provides attractive insight or framing or whatever, along with reasoned updates when the news stops breaking and we have some better or more reliable information. People who just want the news can hit the site, light up the in-page and side gutter banner ads, and then bounce. People curious for more or appreciative of the talent can subscribe and get more, and more informed, detail.

Basically, just the same old suggestions for any enterprise: figure out what people, right now, today, want; stop relying on what worked in the past or what is most convenient for your team. Break it down in to how people actually function, and then place monetization where you would purchase, for a price that you would purchase for. I'll always be able to find the news without you, so you don't have any leverage to hold it hostage. Use it as a lead for your content, which can be the kind of reporting (different than news in subtle but meaningful ways) that people will be happy to pay for.

honestly: good. all of them jumped up their own asses for the sake of SEO and minimum required regulation compliance, which stopped me from even going to the ones that aren't low-quality, content mills, which many of them are.

cut the cookies and tracking, so you don't have to have a ridiculous compliance banner. cut the paywall that tells me what you had to say wasn't important enough for public consumption. cut the full screen ad breaks and page takeover nonsense.

these outlets have had years (decades?) to figure out how to monetize content that didn't drive users away. they have failed over and over and over again, so why should I care that they are failing now? if it wasn't AI, it would be something else that came for them. if you rely on the captiveness of your audience, rather than the quality of your product, I'm always happy to see you destroyed. whatever comes next will be different, at the very least. and I'm an optimist - I'll always hope that it's a better way. if it's not, let that shit die, too.

regardless, I have every faith that the good will that buoyed these sites in their respective heydays will continue on to provide some other resources for the same kind of media.

It's developer fantasy because no one was putting any money into this kind of project. Presumably, because the data showed there wouldn't be enough return from it. Which then implies that the data has updated to show that there is at least enough for a company like Motorola to put at least this much money in to it.

The whole point is that a company is going to try to market this developer fantasy to non-developers, assuming that what excites developers about it enough to discuss it will resonate with non-developers when they hear developers talk about their new phones.

It's not a guarantee of success or anything, but a lot of stuff works like this. Mozilla didn't gain market dominance (for a hot second in the early 2000's) because they marketed to non-devs. They just provided a superior product in every way to everything else at the time, and devs couldn't ignore that, so non-devs always dealt with non-microsoft browsers whenever the devs came around. That kind of "grass is greener" non-marketing is a real winner when the product is solid.

So here's hoping Motorola takes a great idea and builds a product so solid on it that people can't ignore it.

For anyone still using Windows' notepad app, I strongly recommend Notepad2[0].

It's a drop-in replacement for Notepad that does add a few extra features, but does not have even the minimal suite of features that something like Notepad++ has. Where Notepad++ is great for code editing and extensible functionality via plugins, Notepad2 is more suited for people who just want Notepad, without the Windows/Microsoft. It has line numbers and (limited) syntax highlighting and a dark mode - bits and bobs like that - but it does not have tabs and ftp-on-save and the more complex stuff that requires a larger binary size.

It's free, it works like Notepad, and it acts like a bare bones text editor. In many, many cases, it's exactly what I want, and it's always exactly what I want in cases where my original intention would have been to use Windows' Notepad.

[0] https://notepad2.com/

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.

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.

Anyway, great job on this!

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.

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?).

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'.

[0] https://github.com/catapart/magnit-ceapp-taskboard-manager

(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];)

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!

Awesome! TIL.

Thanks for the quick feedback! Makes sense, to me.

nice call. (unfortunately)

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!

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.

based on this users comments in a similar story from earlier, this seems like a bot.

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!

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.

Right on. The only problem with M-DISC is that it's industrial only and most certainly not free for public use.

I know that isn't relevant to the question I asked, as stated, but the focus was on 3D printing because it is something any person could do, rather than something that has to be manufactured by specialized equipment.

I think vinyl would, but as others have noted, it probably wouldn't satisfy the "3D printed" condition.

I know this wasn't in the original ask, but my focus was on what I would be able to do, as far as archival storage, if I had a 3D printer. The assumption being that it's easier for me to have, maintain, and use a 3D printer than it would be for me to have a vinyl press.

Yeah. I kind of lumped in engraving with 3D printing because the difference is really just a toolhead (simplified; motors, tolerances, etc, but still). But that's part of what the 'specialized tool' part of the question was meant to cover. Like, if you can store data in an additive way, you can obviously store it in a subtractive way. But... is anyone doing that with a 3D printer? Or a CNC machine, for that matter?

I think some of the other answered showed that people are, it's just pretty niche. Not something a hobbyist can (currently) do, but definitely the same idea at a production scale.

Oh, very cool! Thanks for chiming in! Lots of good responses, but few that seem to have literal experience with the production. I appreciate the hard numbers. I think that was near the capacity I was assuming.

One or the more interesting things about asking this was seeing all of the types of "storage" that I hadn't even really considered. Braille didn't enter my mind, but of course it's a great analogy!

Right on. Simple text/encoded strings weren't really on my mind while imagining the more complicated solution, but you're right that data is probably best preserved with just "printing" rather than 3d printing.

I didn't have an amount in mind, I was just kind of wondering about the hobbyist aspect. Like if I woke up one day and realized I need to archive something and my most readily available tool was a 3d printer, would I have to come up with my own scheme, or has someone already done it?