Skip to content

Instantly share code, notes, and snippets.

What would you like to do?

Reasons why it doesn't make sense to make jQuery CKEditor's dependency

  1. CKEditor would use very limited part of jQuery - only basic DOM methods, some tools maybe.
  2. CKEditor needs very specific DOM methods. The vast majority of features implemented in CKEDITOR.dom.* are not available in jQuery. Huge range API, walker, iterator, editing-specific DOM traversal methods, etc. (really - >75% of dom.*) - all of that would have to be implemented.
  3. I don't know how jQuery's API can be extended, but I guess that CKEditor's extensions would look ridiculous. Overall effect could not be good.
  4. CKEditor deals with extreme browser bugs (contenteditable FTW!) and very uncommon DOM operations and algorithms, so even existing jQuery's features may not be suitable in some cases. Currently we have full control over methods' implementation, so we may introduce necessary tweaks.
  5. CKEditor rarely works on collections of elements - jQuery API's biggest feature would not be consumed. Moreover - it would be a performance and memory cost.
  6. jQuery would become dependency - CKEditor hasn't got any dependency at the moment.
  7. Mirrored CKEDITOR.htmlParser.* implementation of pseudo-DOM would have to be reimplemented and would become unnecessarily more complex.
  8. Surprisingly, CKEditor rewritten with jQuery as a dependency could grow in terms of code size. I mean - it would definitely grow combining CKEditor + jQuery size. But even without it, its size could be bigger. Why? Because lost control over every piece of code would result in less optimum solutions.
  9. It would be an enormous effort to rewrite CKEditor with jQuery.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment