lol! no surer sign of a junior/naive/ignorant developer or manager than the sentiment "okay, well, let's start from scratch and do it right this time."
big projects generate cruft. there are ways to minimize it, but as you go along there will always be some stuff that doesn't quite mesh with whatever else you've got going on. if you insist on ironing out every single wrinkle (admirable!) you'll never actually deliver a result.
I'm not saying this will fail. green field projects can certainly be a godsend when they produce something better than what they attempt to replace. but they are always a sign of failure. of not being able to work your way out of the mess you made with the first attempt. so that just begs the question: what are you going to do when this attempt gets hard to work with? going to give up and start over again - do it right that time? or...?
This is far too general of a philosophy to be applied in the dark. You can't say, without any familiarity with what the actual software looks like whether a rewrite is the best way to proceed. There are plenty of projects that get bogged down in the inertia of a system that wasn't built right in the first place.
Also, modern AI is only a few years old at this point. Whatever has been built so far is hardly load bearing.
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.
A thing that shocked me as I was working on the text editor was how capable modern terminal emulators are when you account for ANSI extensions. First-class clipboard access, mouse events, precise text styling, focus tracking, system notifications, key press/release events, etc. are all possible with a modern terminal emulator. There's not really anything else you need to build a very competent, ergonomic editor UI.
You can even use tools like trolley to wrap the entire application up in a ghostty-powered shim that presents the application as a native UI application: https://github.com/weedonandscott/trolley
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.
Several of the lean GUI text editors are built on Scintilla (https://scintilla.org/), which provides a cross-platform editing component that can be integrated in GTK, Windows or Mac GUI apps. Maybe that has too much bells and whistles for you, since it's both about editing and presentation.
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!
Yes, Scintilla is a text editor engine library. It's not tied to any particular UI or technology. Out of the box it's not a text editor yet; you provide the frontend. You get all the "table stakes" right away if you build your editor on this library.
Same engine, different frontends. The engine has a series of hooks that you implement in whichever way you please for your particular interface. It's definitely the presumptive choice here.
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.
I would mention stb_textedit.h, but I would not recommend it. It was an interesting thing to study. but the library has many shortcomings and is pain to integrate and use. It is used in ImGui, but somewhat modified. Just to illustrate the flaws - it can't be used with utf-8 bytes easily, there is a large switch on keyboard shortcuts to trigger actions so you have to fake keyboard input to script things, the default word boundary detection is pretty bad, and there is no way to nicely provide double or triple click selection.
The two notable functions are stb_text_locate_coord() and stb_textedit_find_charpos(), which connect the physical x,y coordinates with position in text buffer. They both iterate lines of text - accumulating y position; and the chars of last line - accumulating x position.
For windowing, drawing and OS integration, SDL with SDL_ttf is actually pretty good. SDL3_ttf API got an improvement and no longer requires zero-terminated strings so you don't need to relocate every chunk.
It's hard to give you a recommendation without knowing the platform details, but if GUI rendering is not the goal, something like raylib might be a great choice to have a cross-platform GUI API, including text rendering.
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.
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?
This library does not include a LLM services. The one on the homepage is only for demonstration and testing. The npm package and extension requires your own LLM api config. Doc here https://alibaba.github.io/page-agent/docs/features/models
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.
What would be your suggestion for monetization without ads or subscription? Or are you thinking some type of privacy-respecting ad system? Because those have definitely been tried.
Subscription used to work. They can work again, even better than before now that we have the facility for micro-transactions. A micro-transactional framework would have the added benefit of making it expensive for scrapers to steal content.
This is hard for me, an "information wants to be free" kinda guy, to espouse. But there are softer ways to do it, such as how The Guardian does it, or how public media does it.
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.
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.
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.
big projects generate cruft. there are ways to minimize it, but as you go along there will always be some stuff that doesn't quite mesh with whatever else you've got going on. if you insist on ironing out every single wrinkle (admirable!) you'll never actually deliver a result.
I'm not saying this will fail. green field projects can certainly be a godsend when they produce something better than what they attempt to replace. but they are always a sign of failure. of not being able to work your way out of the mess you made with the first attempt. so that just begs the question: what are you going to do when this attempt gets hard to work with? going to give up and start over again - do it right that time? or...?
reply