You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When nearly four years ago we started talking about implementing CKEditor 5, the successor of CKEditor 4, we understood that it is not going to be a quick job. From the beginning we knew that we need to start with a clean slate and do a full rewrite. A new data model, completely new architecture, modular codebase and demanding requirements (such as support for collaborative editing through Operational Transformation) meant that iterative approach was not an option. We knew that our experience with CKEditor 4 will influence it, but we also knew that it will be a completely new product.
From the beginning we tried not to make promises regarding when CKEditor 5 will be ready. Working on such innovative features as Operational Transformation for tree structures meant that with every next step we felt like Alice in Wonderland — a bit lost but also more and more excited. Just to give you an idea what it meant: back in 2015 we were aware of just one proven implementation of OT for trees (but details of which were not public) and some failure stories. We needed two complete overhauls, countless refactorings and over 1600 closed tickets to get to a point where we can say — it works!
At the same time, we value quality above all and we would never release an unproven and unstable implementation to the world. It is ready when it is ready.
Therefore, we are extremely excited and proud today to announce that we have just tagged the first alpha release of CKEditor 5. It follows 11 developer previews and it means that we reached a state where we think that it is ready for you to play with it. The first CKEditor 5 alpha is also a part of the new CKEditor Ecosystem which is going public today as well!
Let us go through the state of the project to see what it means.
CKEditor 5 Builds
CKEditor 5 Builds are the fastest and easiest way to use CKEditor 5 in your application. They are available on npm, CDN and as ZIPs.
There are three ready-to-use builds available so far:
When implementing features we took the chance to revisit every one of them. The existing builds may resemble CKEditor 4 editor types, but the difference lays inside. Let us see a few examples.
Inserting images into the content is now very intuitive, with all technical aspects (uploading, resizing) hidden from the user experience. No more complex dialogs!
Also, when integrated with Easy Image, uploading, resizing and producing different image sizes for responsive design is all automated.
Linking got much simpler:
Formatting (bold, italic, lists) can be applied by typing:
And even the classic editor is not that classic anymore. It got a new sticky toolbar:
It also automatically grows with content:
You can read more about the most important changes in the "What's new?" guide.
See it yourself!
To play with the editors see the examples. You can also learn more about even more features (such as Markdown output, keyboard support, changing the UI language or setting the editor to read-only) and see more examples in the Features section. And if you want to run the editor yourself, refer to the Quick start guide.
CKEditor 5 Framework
Since the beginning, extensibility and flexibility were our main goals. CKEditor 3 and then CKEditor 4 had plugin-based architecture — but that was not enough. What if someone wants to implement a completely different editor? With a different, React-based UI, some new features and some official features (but customized, rendering different output and new UI). Every use case is different and the user experience depends on the quality of integration, so the editor needs to be flexible.
This is why we created CKEditor 5 Framework. Its design allows for infinite possibilities for creating new types of editors and implementing features that were not possible in the past. It also ensures that when needed, the behavior of the existing features can be adjusted to your needs and use cases or reused to create brand new, custom-tailored ones.
NOTE: While CKEditor 5 Builds API should be quite stable, the framework API will still change a lot. We are at a point where the code works, the architecture is in place but in many places the API needs refinement. Also, we try to respond to new use cases that the community brings, which lets us review our assumptions even before the final 1.0.0 version.
Documentation
It may be surprising how much documentation a project like CKEditor 5 requires. The API surface of CKEditor 5 is vast. To give you an example: CKEditor 5 API documentation consists of over 600 modules and classes. You do not need to know all of them to start developing features, but they all need to be documented. Besides that, even at such an early stage we already have over 50 guide pages with examples and code samples — and we expect this number to grow fast.
To accommodate that, we needed to create a custom documentation generator which we called Umberto. Thanks to it, we managed to organize the documentation in a, hopefully, digestible format. We are very pleased with the results and we use the documentation ourselves already. We also plan to improve both the contents (in terms of quality and completeness) and packaging with time. You can, of course, see the documentation live here.
What’s next?
We would like to hear as much feedback as we can. We are very grateful for all the kind words and ideas that we got from you so far. They allowed us to spot some issues early and kept our spirits up during these busy and tough days (a thousand of them, in fact :D). We would love to hear from you more about how CKEditor 5 and its architecture fits your use cases, which pieces are cumbersome when implementing new features and which work great. You can report issues and ideas on the main issue tracker.
With that feedback we will get back to the code. There is still a lot to do in terms of stability, browser compatibility, API design and documentation. You can see the Roadmap to 1.0.0 and beyond but please keep in mind that it is fluent and we will definitely do a lot more than stated there before releasing 1.0.0.
NOTE: We are aware that the introduction to architecture and the Quick start guide are not enough to start writing plugins for CKEditor 5. This guide will be followed with a more code-oriented guides, but in the meantime you can browse the existing features’ code and tests on GitHub.
For a detailed list of changes go to ckeditor5@v1.0.0-alpha.1 where you can check each package's changelog.
Thanks!
I would like to use this occasion to thank all of you — those who got involved, those who supported us and those who followed us. Thank you.
Also, I would like to thank the wonderful CKSource team which grew to over 40 people in the meantime. I won’t lie if I write that there would be no CKEditor 5 without you ;)!
The text was updated successfully, but these errors were encountered:
When nearly four years ago we started talking about implementing CKEditor 5, the successor of CKEditor 4, we understood that it is not going to be a quick job. From the beginning we knew that we need to start with a clean slate and do a full rewrite. A new data model, completely new architecture, modular codebase and demanding requirements (such as support for collaborative editing through Operational Transformation) meant that iterative approach was not an option. We knew that our experience with CKEditor 4 will influence it, but we also knew that it will be a completely new product.
From the beginning we tried not to make promises regarding when CKEditor 5 will be ready. Working on such innovative features as Operational Transformation for tree structures meant that with every next step we felt like Alice in Wonderland — a bit lost but also more and more excited. Just to give you an idea what it meant: back in 2015 we were aware of just one proven implementation of OT for trees (but details of which were not public) and some failure stories. We needed two complete overhauls, countless refactorings and over 1600 closed tickets to get to a point where we can say — it works!
At the same time, we value quality above all and we would never release an unproven and unstable implementation to the world. It is ready when it is ready.
Therefore, we are extremely excited and proud today to announce that we have just tagged the first alpha release of CKEditor 5. It follows 11 developer previews and it means that we reached a state where we think that it is ready for you to play with it. The first CKEditor 5 alpha is also a part of the new CKEditor Ecosystem which is going public today as well!
Let us go through the state of the project to see what it means.
CKEditor 5 Builds
CKEditor 5 Builds are the fastest and easiest way to use CKEditor 5 in your application. They are available on npm, CDN and as ZIPs.
There are three ready-to-use builds available so far:
What's new?
When implementing features we took the chance to revisit every one of them. The existing builds may resemble CKEditor 4 editor types, but the difference lays inside. Let us see a few examples.
Inserting images into the content is now very intuitive, with all technical aspects (uploading, resizing) hidden from the user experience. No more complex dialogs!
Also, when integrated with Easy Image, uploading, resizing and producing different image sizes for responsive design is all automated.
Linking got much simpler:
Formatting (bold, italic, lists) can be applied by typing:
And even the classic editor is not that classic anymore. It got a new sticky toolbar:
It also automatically grows with content:
You can read more about the most important changes in the "What's new?" guide.
See it yourself!
To play with the editors see the examples. You can also learn more about even more features (such as Markdown output, keyboard support, changing the UI language or setting the editor to read-only) and see more examples in the Features section. And if you want to run the editor yourself, refer to the Quick start guide.
CKEditor 5 Framework
Since the beginning, extensibility and flexibility were our main goals. CKEditor 3 and then CKEditor 4 had plugin-based architecture — but that was not enough. What if someone wants to implement a completely different editor? With a different, React-based UI, some new features and some official features (but customized, rendering different output and new UI). Every use case is different and the user experience depends on the quality of integration, so the editor needs to be flexible.
This is why we created CKEditor 5 Framework. Its design allows for infinite possibilities for creating new types of editors and implementing features that were not possible in the past. It also ensures that when needed, the behavior of the existing features can be adjusted to your needs and use cases or reused to create brand new, custom-tailored ones.
The framework is made of a few groups of npm packages: core libraries, editors, features, themes and builds. The most important part of it are the core libraries. You can learn more about them in the Architecture introduction guide.
NOTE: While CKEditor 5 Builds API should be quite stable, the framework API will still change a lot. We are at a point where the code works, the architecture is in place but in many places the API needs refinement. Also, we try to respond to new use cases that the community brings, which lets us review our assumptions even before the final 1.0.0 version.
Documentation
It may be surprising how much documentation a project like CKEditor 5 requires. The API surface of CKEditor 5 is vast. To give you an example: CKEditor 5 API documentation consists of over 600 modules and classes. You do not need to know all of them to start developing features, but they all need to be documented. Besides that, even at such an early stage we already have over 50 guide pages with examples and code samples — and we expect this number to grow fast.
To accommodate that, we needed to create a custom documentation generator which we called Umberto. Thanks to it, we managed to organize the documentation in a, hopefully, digestible format. We are very pleased with the results and we use the documentation ourselves already. We also plan to improve both the contents (in terms of quality and completeness) and packaging with time. You can, of course, see the documentation live here.
What’s next?
We would like to hear as much feedback as we can. We are very grateful for all the kind words and ideas that we got from you so far. They allowed us to spot some issues early and kept our spirits up during these busy and tough days (a thousand of them, in fact :D). We would love to hear from you more about how CKEditor 5 and its architecture fits your use cases, which pieces are cumbersome when implementing new features and which work great. You can report issues and ideas on the main issue tracker.
With that feedback we will get back to the code. There is still a lot to do in terms of stability, browser compatibility, API design and documentation. You can see the Roadmap to 1.0.0 and beyond but please keep in mind that it is fluent and we will definitely do a lot more than stated there before releasing 1.0.0.
NOTE: We are aware that the introduction to architecture and the Quick start guide are not enough to start writing plugins for CKEditor 5. This guide will be followed with a more code-oriented guides, but in the meantime you can browse the existing features’ code and tests on GitHub.
Samples
Check out the Examples section in the documentation. You can also find some more examples in the Features section.
Changelogs
For a detailed list of changes go to
ckeditor5@v1.0.0-alpha.1where you can check each package's changelog.Thanks!
I would like to use this occasion to thank all of you — those who got involved, those who supported us and those who followed us. Thank you.
Also, I would like to thank the wonderful CKSource team which grew to over 40 people in the meantime. I won’t lie if I write that there would be no CKEditor 5 without you ;)!
The text was updated successfully, but these errors were encountered: