I’m building something in this space and I’m curious what’s the appeal of the former vs the latter?

It's not the same as acreom (leaning more towards a CMS-like platform with API, real-time collab, etc.), but is well-suited for e.g. creating knowledge bases.

I'm also working on a WYSIWYG editor and using TipTap. It's great, but on its own, it's not a ready editor, but a great framework.

There's a lot you can do with TipTap (and ProseMirror) to make your editor stand out and fit your use case better than others.

Currently supports custom block elements and JSON-serializable attributes. Now looking into inline content and building an extension system to render custom previews for the nodes.

Check it out if you're interested - it's also open-source.

Comments URL: https://news.ycombinator.com/item?id=37955747

Points: 2

# Comments: 0

The idea is to provide a great "hybrid" editing experience (combining code and WYSIWYG approach) to create an editing environment that's extensible and can be used for various technical needs, by people of varying technical proficiency.

Since the last time I posted this project here (https://news.ycombinator.com/item?id=36324281) I followed on the recieved feedback, adding:

- GitHub synchronization (for existing projects using docs-as-code approach);

- Self-hosting support via Docker Compose;

- Command palette with semantic search (also accessible via API);

- Variants (for i18n support);

- New "Element" block in the editor, allowing for custom markup (via XML-like syntax) that's then transformed to structured JSON;

- Other features, like more customization, better commenting support and new dashboard view (list)

Check it out and let me know what you think.

For basic look, use the following credentials:

- Email: hello@vrite.io

- Password: Hello_2023

This account will be reset every few hours.

Comments URL: https://news.ycombinator.com/item?id=37870036

Points: 4

# Comments: 0

What's described above really doesn't fit into this view, but is definitely how I've seen people "play the game". ChatGPT-generated fluff, copied content, and the same tips & tricks, inspirational stories, etc. you see repurposed all the time on different platforms - especially LinkedIn.

I hope marketing can be good and value-adding but, the way it's going right now, we're due for a change.

So, I've been building Vrite as an open-source project for a while now, but only now - with v0.2.0 - I'm happy to finally provide official self-hosting support.

The best way to describe Vrite is a "developer content platform" - something between a CMS and a knowledge base - a versatile tool to create, manage, and publish your technical content.

You can use it in various ways:

- as a headless CMS for your technical blog (with Kanban management dashboard and API + JS SDK)

- as a great WYSIWYG editor for product docs in your GitHub repo (kind-of like GitBook)

- as an internal tool to manage, search through, and chat with all your content with AI (so a knowledge base like Confluence, Notion, etc.)

Currently, Vrite is still in Beta, but I hope that in time, it can become a solid tool for various use cases, helping all kinds of software developers and technical writers maintain high-quality docs, share knowledge, and build their blogs.

Either way, if you're interested in something like this, let me know what you think. And how I can make Vrite even better.

For some other links:

- Today's Product Hunt launch (if you like the product, support it there): https://www.producthunt.com/products/vrite

- Self-hosting guide: https://docs.vrite.io/self-hosting/docker/

- Landing page: https://vrite.io

Comments URL: https://news.ycombinator.com/item?id=37496093

Points: 3

# Comments: 0

This also enables easier installation and setup for basically any carrier. Just download the app, configure eSIM and you're good. Maybe the easier switching is why adoption is kind-of slow on the carrier side? Easier to keep you locked-in with more obstacles in place.

Seen some comments mention potential issues with it vs physical SIM, but I hope these get resolved with time or standard solutions are developed. Personally I had no issues with it, using it for over 2 years now.

That said, I'd consider switching for type-safety (or more specifically auto-completion) if there was an ability to e.g. import existing OpenAPI schema and automatically pick up the types.

I haven't really explored WASM hands-on (I'll give this guide a try) but, given that it's already been a few years, I think it's been hugely beneficial for web development.

Not the "JavaScript killer" some where hoping for, though it was never meant to be one. Instead it integrates pretty nicely within the existing ecosystem, optimizing existing use-cases and allowing new ones when heavy computations are required. Net benefit for all web devs - faster libraries, impressive dev tools and more portable node binaries.

The fact that it’s available on mobile and that it allows for “embedding” a good-enough dev tools into your web app, does enable interesting use-cases.

Of course, it’s not the go-to for complex or extended debugging sessions but still impressive.

I think it all depends on the project’s scale, type (is it part of your infrastructure like a database or all-in-one solution like a CMS, etc.), goals and other factors.

It’s difficult to make the right choice at the very start, as something that might have worked then might not work when you’re at a scale of competing with AWS.

You are correct that under AGPL-3.0 people still can provide the software as a service, but they’ll have to disclose any changes to the source code they’ve made.

This, in my mind, effectively discourages doing so as, if all you do is change the branding, people will eventually know and, depending on their ethics and the provided offering, they might choose not to use the “official” service.

In theory people still could distribute the product as-is or just be fine with the open-sourcing and actually add something of value to their fork. However, as I’ve seen in practice, this doesn’t seem to happen at a meaningful scale and people usually prefer to contribute directly to the original project.

Like you’ve said, there are other licenses that aren’t really open-source, prohibiting this from happening at all.

Most interesting options from these, for me, were SSPL (which puts the open-sourcing requirement on other elements of your stack, like hosting provider, making it a non-starter), or ELv2 (which just prohibits SaaS use entirely).

But again, not being recognized as official open-source licenses, using these puts the project more in the camp of source-available software rather than open-source.

I've certainly seen many different licenses used in COSS projects, including different mixes of them. E.g.: for my latest project I've decided to use mainly AGPL-3.0 (a pretty strong copyleft license) with specific parts licensed under MIT.

That said, my goal wasn't to limit the usage, but to be open-source, and provide self-hosting option (the 2 fundamental advantages you can provide to your users by being open-source, IMHO), while making sure nobody just runs the product on their servers, rebrands it, and sells it to others as a service (which, while possible with other licenses, is simply unethical in my book).

Essentially it’s a toolkit intended primarily for technical content (like programming blogs or docs), with multiple features in one:

- WYSIWYG editor focused on good UI/UX (including good support for code), and collaboration;

- Kanban dashboard (and other views in the future) for managing the content and its production process; Especially useful for larger teams;

- The “headless CMS” part for hosting and delivering content and related assets; This includes API and Extension system; (in the future planned additions are asset optimization and Git integration)

So, tl;dr; it’s a lot more than the mention tools and I’m still looking for a way to categorize it clearly.