Thanks for posting the new documentation on HN! Co-creator here.
tiptap v1 was pretty popular (more than 6M downloads) and an amazing community formed around it. It’s used in GitLab, Nextcloud, Statamic … and tons of other popular apps. But it was built 3 years ago, coupled to Vue, and had an awful documentation.
We couldn’t help but work on a new version over the last months and basically incorporated all the feedback that came up over the last years. We’ve been in a private beta for 4 months now, with sponsors and regular contributors. Now, we’re in public beta and can’t would like to hear what you think!
Here are a few things you can do with tiptap v2:
- Use with Vanilla JS, React, Vue, Alpine, Svelte …
- Bring your own markup and CSS
- Use Markdown shortcuts
- Render Vue or React components inside the editor content
- Use Vanilla JavaScript to render interactive things inside the editor
- Add collaborative editing capabilities
- Build offline-first apps
- Add autocompletes, for example for @mentions
- Use it with Tailwind CSS
- Automatically fix typographic mistakes (optional, as everything else)
Can I build a Typora-like editing experience? Specifically, I want nodes where the visibility depends on the caret position. This requires mutating the DOM of the editable area in response to cursor movement, which wreaks havoc on a lot of the existing WYSIWYG editors.
Was wondering what makes this different form prosemirror but it looks like it uses it, why would I use this instead? For sure pm is hard at first but once you get the system it's like a new superpower.
How Tiptap does HTML cleaning and sanitizing from different browsers? E.g. edit rich text tables in IE and after this editing them in Safari could be broken. This has been an acute pain for all WYSIWYG editors for the last 20 years. Especially ProseMirror shines to solve this problem as it encodes everything to Markdown.
The default way to persist a ProseMirror doc is JSON. There is a way to serialize that to Markdown via the prosemirror-markdown package, but not every node can be represented as plain text. You can also use html without a non core package since each node has to define a toDOM and parseDOM method.
It’s really something I don’t understand that the web browsers haven’t come out yet with a decent API to implement a WYSIWYG editor in a website.
And browsers have taken the completely opposite way actually, with the recent deprecation of execCommand.
WYSIWYG is really the basic of tons of app, I would say as much as showing an <input> or using a <select>. And contenteditable hasn’t been of any help, it’s worse in fact.
Where I work, we decided to use Google Closure editor, which is really powerful, but is undocumented and adds like dozens of kbs to our app.
I really hope some day we wouldn’t have to rely on a third party dependency to implement an <input>. With how things have gone with WYSIWYG editor, I wouldn’t be so surprised though.
execCommand was used to add rich text to web mail clients, it's fine for writing once but not exchanging documents between browsers because of different interpretations at to what the commands do and how they handle nested tags ala <i><b></b></i> or <b><i></i></b>. Anyway prosemirror has a schema that provides extra info to how the tags should be handled: https://prosemirror.net/docs/guide/#doc
Also this is a much bigger design area then you might think.
all this griping about 'headless'. Look around, the term is very common these days pertaining to static website development, Jamstack, headless CMSes etc.
It just means this editor is decoupled from any particular backend or presentation output -- it's just the editor that can be implemented/used regardless of the greater system you're developing for.
Headless doesn't mean no stylesheets. It means no gui at all. This project is not headless at all. It is not possible to make this thing headless. It's head is sticking right there.
It's trying to create a new definition of what the word means.
Just say "no stylesheets included". That's 100x more clear what's going on.
Happy sponsor here. Started exploring the (previously closed) beta a number of weeks ago, and its really a pleasure to work with.
Have worked with Slate and Prosemirror before, and it feels like tiptap2 hits a better balance; easier API and better documentation. All built on top of the proven prosemirror, so if you need to its still possible to dive into the underlying tech. Great job guys!
Not sure if this is a known issue but I tried to load the site 3x in Firefox. Caused the tab to stop responding with a "Script is slowing down Firefox" error. Each time I had to close the tab. Opened the site in Chrome with no issue.
Yeah, the document loaded in the editor is nearly 1 MB by now. This document has grown over the last months. Over the last days there were 100 users concurrently typing in the document, some times pasting in 20k words, deleting it, pasting it in again … And Y.js (what we use) stores the whole history, and currently is blocking the main thread until the first state is downloaded and applied.
The collaborative editor seems seems to be struggling with the load test of visitors, combined with some people putting a lot of content into the editor--it looked like the entire Bee Movie script was in there.
Some people pasted whole books into the editor. In combination with more than 100 people using it concurrently, that’s not working that well. I limited the character count, it should be way more performant now.
This looks really nice, especially collaborative editing. I've been playing around with draft.js and also looked at other libs.
How does this handle maintaining text selection while interacting with a drop down list (ex. font size drop down, link editor with pop over)? Google docs handle this really well. It would be nice to see this in the docs.
We don’t provide any controls, you can use a native select or whatever you need and I don’t see a reason why that shouldn’t work. tiptap just gives you an API to apply styles, check for styles and so on.
Good point though, we should put together an example that showcases that.
I would love to see the open source community get together to create a web based open source version of Microsoft Word rather than hundreds of basic text editors.
Even adding something as basic as "Pages" would help move this in that directions as it would open up the ability to export to actual document types like PDF and DOCX.
Where they offer a downloadable on-premise applicance (Docker) you can use. They also have a hosted version, if you'd rather just use their infrastructure.
Yes, it’s a wrapper around ProseMirror, but a fairly popular one. tiptap 1 has more downloads than ProseMirror and all other ProseMirror based npm packages together. [1]
Even with nearly 300 sponsors our hourly rate is $8 before taxes and from what I know Marijn is doing just fine already. I think it’s in his and our interest to make our work financially sustainable too.
That said, we’re sponsoring other related open source projects, for example Y.js already.
Why not just ask users to also sponsor the ProseMirror project directly? Actually, this is what they are doing on their "Sponsor" page: https://www.tiptap.dev/sponsor/
I appreciate these free WYSIWYG editor projects but 'headless' is just another way of saying you need to build all of the tricky stuff yourself. Where's the out-of-the-box anchor functionality? How often do you not need to link text?
Using v1, and custom nodes with vue components are very powerful and gives even more flexibility. Glad they are more than advertised in v2 and got more care. Can’t wait to migrate. Well done !
I work on a game that runs in a browser on mobile and synchronizes a physics simulation with orders of magnitude more relevant data. That's the benchmark upon which I scoff.
Google Docs has a limit of 50 collaborators. I think that with 100 collaborators it’s doing pretty well considering that we’re not a billion-dollar company.
Collaborative editing is one of the hardest problems in that field, I think it’s cool to show that one on the frontpage.
And the demo shows how you can customize the styling, the power of extensions and how that all can be put together in a custom way. But maybe it doesn’t communicate all that very well.
Keep in mind it’s an MIT-licensed open source project, we just launched two days ago and we didn’t even post it here.
Most things should work fine. I do not have Word installed right now but if you want to do a test, try to paste some content in a basic editor like this one: https://www.tiptap.dev/examples/default/
How does this relate to [Slate.js][0]? Why would I use this over Slate? The most important part is the data model. Slate gives you the ability to edit not only HTML but anything you can come up with. How does tiptap relate to this?
ProseMirror (used by tiptap) is way more stable and comes with different types of collaboration support (OT & CRDT). Data is stored as JSON as well. But you can import/export good old HTML too.
This doesn't answer my question: how does the model differ? Does tiptap use a similar "can write an editor for anything since everything is abstract" concept?
Everything you can do with Slate.js, you can do with tiptap, too.
Some things are even easier in tiptap, some are better supported (collaborative editing), and Slate.js is only available for React, but tiptap is framework-agnostic.
If you’re happy with Slate: That’s fine, it’s an amazing editor. For some use cases, tiptap is probably better suited, though, but that highly depends on your use case.
This sounds like a parody. What does "headless" mean in this context? It clearly has an interface, so it's not like a headless browser. Edit: I got the styling link to load now. They just mean no CSS.
And what distinguishes a "web artisan" from a person who types? Edit: oh I think the web artisan is just the web developer who uses this on their page, not the person who uses the editor.
For a headline it doesn't seem to communicate well.
Hi, co-creator of tiptap here and the one who wrote the heading:
We went with “renderless” for tiptap v1, but this is not really correct and a lot of people switched to “headless”.
Give me a better word that’s know to more people, I’d love to change it!
With web artisans I wanted to point out it’s for people who really care about every detail.
If you just want to slap in an editor and that’s it: tiptap is not for you. If you want to really customize every aspect of the editor: You should definitely consider using tiptap.
> Give me a better word that’s know to more people, I’d love to change it!
Thank you for being flexible :-)
Headless literally means "gui-less" (without a gui) and has had the same meaning since 1998 or so so it's probably not a good idea to reuse the word to mean something else in the same context.
I would go with either "style-less" (which is a bit awkward to say") or "effortless", which is better even if not totally accurate.
With "effortless" you fully capture how easy it is to use.
> With web artisans I wanted to point out it’s for people who really care about every detail.
You can keep artisan - it looks correct in this context.
Yes, I'm confident it's wrong because it re-use a word in a way that will confuse. It implies it'll be used without a GUI and the first thought is not to think "oh, they must mean it doesn't come with its own GUI". Lots of others things that have an API do not get called headless - presumably as they're aware of the existing use of headless and thus don't want to confuse people.
Maybe you could explain it's a backend for an editor.
> tiptap comes without a graphical user interface. It’s an API and you have to build the gui. Are you sure headless is so wrong?
Unless I misunderstood the example, all you have to do is instantiate it to make it work with a default look.
If "using the API" is headless, then everything is headless because they all have an API, including things like Qt, WxWidgets, etc. This is obviously not the case.
I saw the title of this story and assumed that tiptap was going to be a component that somehow backed up various WYSIWIG editor-clients. That would be headless. (It's even useful -- the transaction system + collaboration server is theoretically a thing that could back up other clients, after all, though in practice it's going to force enough design decisions onto the clients that it's not really worth it.)
Tiptap does come with a graphical user interface, insofar as it looks like the most minimal possible use of it (from your "Minimal setup" example) will create a contenteditable surface to write in. Said surface is the "head".
I'd consider "flexible", "customizable", or "unopinionated". "Unstyled" was suggested, but although it's true I think it's misleading -- the need to construct your own toolbar goes beyond what that implies.
effortless sounds good, but is it really true here? If I have to style the complete editor myself that sounds like a lot of effort.
I would go in the direction of "The fully customizable editor" or something similar.
Back in my day, "headless" meant a computer without a monitor, for example a server or a PC that had been repurposed to server duty.
We also had the opposite: before Xrandr or Xinerama, there was an older X feature called "Zaphod Mode" that allowed you to drive a graphics card's multiple outputs (on cards that supported such) mapping each to a different X "screen", Zaphod Beeblebrox, of The Hitchhiker's Guide to the Galaxy, had two heads, you see.
Yeah I think the Jamstack folks have decided to use headless in an entirely different way. For example search for headless CMS you'll find loads of CMSs that just run on a server and use an API to talk to the client, but they're just web pages.
It just means not WordPress I think in this context.
Well I'm probably not really in the target audience, so take my confusion with a grain of salt if those are widely used terms among those who are. The list of features in your other comment does sound pretty appealing though. Maybe the site should have something like that as a column down the side or something - I would have immediately understood instead of coming here and complaining about headlines!
I'd call it "stylable", "freely stylable", "add your own CSS", "DIY CSS" or similar, as they seem like they mean what you're talking about even to people who haven't run into them before.
Artisanal to me suggests obviously handmade and deliberately unpolished (as a stylistic choice, not a negative). The immediate image that sprang to mind was pottery with finger marks in it, so I was a bit lost with "web artisan". The strengths of tiptap seem to be the flexibility and customisability, and realtime collaboration, so a word that got that sort of thing across would communicate more.
Instead of "headless", which I agree is confusing, perhaps instead: bare-bones; unstyled; fully customisable; extensible; unopinionated (maybe).
"Artisan" seems fine, although it's slightly obscure. Perhaps instead: control-freak; obsessive; perfectionist. They are somewhat negative, but they're also points of pride for some.
So for example: tiptap, the fully customisable editor for website perfectionists.
headless instantly made sense to me, I was thinking of it like contentful/headless shopify even if there is a little bit of a gui. I interpreted it as something I'd have maximum control over in just one word.
Makes sense to me too. Given all the attempts at alternatives that don't quite work, I'd fully support an evolution of what headless means and hope to see other libraries about it. The context makes it pretty obvious.
In the context of UI components it has taken on the connotation that it mainly handles interactivity, state, performance, accessibility, cross-platform support and similar functional aspects, while leaving decisions about the visual design to you.
EDIT: And it does allow you to customize both styling and markup, as far as I understand.
It's a cliché and it's meaningless - it's not like you see "Made with hate" or "Made with indifference (but at least it covered my mortgage payments)".
The term "headless" is widely known in the React world for
components where I have full control over markup and styling.
In the Vue world, this is usually called "renderless". We have then decided to use the term "headless".
"problem" is that you have a live editor shared across everyone on the homepage, and the editor is main thread blocking so it slows down the entire page
tiptap v1 was pretty popular (more than 6M downloads) and an amazing community formed around it. It’s used in GitLab, Nextcloud, Statamic … and tons of other popular apps. But it was built 3 years ago, coupled to Vue, and had an awful documentation.
We couldn’t help but work on a new version over the last months and basically incorporated all the feedback that came up over the last years. We’ve been in a private beta for 4 months now, with sponsors and regular contributors. Now, we’re in public beta and can’t would like to hear what you think!
Here are a few things you can do with tiptap v2:
- Use with Vanilla JS, React, Vue, Alpine, Svelte …
- Bring your own markup and CSS
- Use Markdown shortcuts
- Render Vue or React components inside the editor content
- Use Vanilla JavaScript to render interactive things inside the editor
- Add collaborative editing capabilities
- Build offline-first apps
- Add autocompletes, for example for @mentions
- Use it with Tailwind CSS
- Automatically fix typographic mistakes (optional, as everything else)
- Add resizable tables
- …
Here are a few links to get started:
- Repository: https://github.com/ueberdosis/tiptap
- What’s tiptap/why it’s special: https://blog.ueber.io/post/tiptap-public-beta/
- Discord: https://discord.gg/WtJ49jGshW