有多大比例的前端工程師，能在合理的時間內獨立開發出一個足以供商業網站使用的文本編輯器？

01-11

就是知乎現在用的這種，latex 支持和代碼高亮可以暫時忽略。
所謂工業標準嘛，一方面是功能，兼容性，界面，穩定性等；另一方面是代碼要比較規範，設計比較合理（比如支持有限的擴展能力）。
鑒於IE系瀏覽器實在是太坑，降低一下難度好了——不考慮IE678。

其實還有一個前提，問題里放不下了——不學新知識，只依賴最基本的html，js，css文檔。
統計結果恐怕是沒有，只能估計一個數（我個人覺得是千分之一）。
如果想回答「這個都做不了怎麼能叫前端工程師」之類的話，可以直接回答「100%」。
PS：這個「工業標準」被吐槽的不清，我改改吧。

我是wangEditor - 輕量級web富文本編輯器的作者。

作為一個在web富文本編輯器貢獻了1年半時間的非菜鳥人員，我來談談我的感受。說到這個話題，我感受特別多，也特別亂。因此，想到哪裡就寫到哪裡吧。

2014年11月開始，我是想著練練手，就綳著一股勁寫了1000多行的代碼，提交到github，就有了最初的wangEditor編輯器，那時候的樣子，完全不符合上述的『工業化』這個標準，無論你對『工業化』這個詞的要求有多低。說白了，就是一個簡單的div增加contenteditable屬性，然後用瀏覽器原生的execCommand執行命令，要不然代碼怎麼會那麼少呢？現在想起來，那時候談什麼穩定性、兼容性，那就是妄想了。

後來，經過了大約兩次代碼重構，直到2015年夏天那會兒，總算是有了好轉——只是『好轉』啊，離著『工業化』的要求還是有一段距離。此時的編輯器，在代碼上比較清晰，結構也比較穩定，我可以自己去靈活的擴展一些用戶提出來的功能。但是那時候在功能層級和用戶自定義擴展層級上，還是遠遠不夠。第一，用戶無法自定義菜單和插件，有啥問題只能我來加。第二，現在的功能穩定級別，緊緊是在於用戶完全沒有特殊操作和特殊需求的時候穩定，例如，用戶要是ctrl+a全選內容然後刪除，這時再寫入內容就會有問題，再例如，用戶粘貼一段文字也會有各種問題，再例如，用戶引用了一段內容之後無法通過兩次enter跳出……再多了我就不說了

但是，到那時候通過我一年多的努力，QQ群里有了幾百個關注著，也有人真正的開始嘗試用我的這款產品。然後吸引大家來的，不是功能多麼多麼強大，而是靠漂亮的UI——不要見笑！

到2015年的冬天，將近春節一個多月的時候，我蓄勢待發，重構代碼，開發2.0版本。因此此時，我已經在編輯器這個領域混了1年多了，見過了各種各樣用戶的需求，研究了網路上所有看得見的競品，我現在已經知道了用戶到底需要一款什麼樣子的編輯器，用戶的需求在哪裡、問題在哪裡、痛點在哪裡。

大約2周的事件來開發，春節前發布了基礎版本，直到現在春節後剛上班沒幾天，這段時間裡，我又做了5次小版本升級，基礎版基本穩定。接下來，我還要繼續升級，做一些更加符合用戶需求的功能，例如集成七牛雲存儲的圖片上傳、國際化、標準的表情包、集成第三方上傳插件等等。

另外，我今年還會將移動端集成進來，做成響應式、支持手機pad的編輯器。

總結來說，web富文本編輯器——沒進來的人覺得沒啥大不了的，開源插件那麼多，何必重做輪子。真正進來的人，會發現這東西真的可做的東西特別多。

共勉！

剛好最近在做涉及富文本編輯的項目，我的答案是沒有。理由簡單說一句話就夠了：獨立開發、「合理」時間和商業級質量，三個條件最多滿足兩個。

這個話題下的不少答主雖然造過編輯器的輪子，但多半只滿足獨立開發的條件。至於達到獨立開發與商業級質量兩個條件的開源編輯器項目，目前接觸到的例子主要也只有這幾個（別拿某個內部系統說事，這裡說的使用都是對外產品上的使用）。按照開源時間排序：

Quill 編輯器，不太了解但使用很廣泛，至少見到過鵝廠在用。
ProseMirror 編輯器，有 Atlassian 和衛報等公司在用。
Slate 編輯器，有 Gitbook 等公司在用。

後兩者答主都合了若干 PR 進去，應該還算比較熟悉吧。這裡要注意的是，其它答案下提到的 TinyMCE、Draft.js、UEditor 等輪子，都是團隊的作品，甚至像 TinyMCE 這樣已經構成了一家公司的核心業務，已經不能用來衡量單人的開發能力了。那麼，單人開發一個富文本編輯器到「穩定」質量，需要多長時間呢？幾天？幾周？幾個月？

Quill 從 2012 年收到第一個 Issue 到 2016 年發布 1.0 版本，已經過去了四年；ProseMirror 作者在 2015 年正式開源前籌款維護時已經開發了半年，而到前兩個月發布 1.0 版本時，已經過去了接近三年。至於 Slate 雖然理念先進（它能讓你用 React 編寫編輯器中的表格等組件且支持嵌套，這個 Draft.js 做不到），但開源至今接近兩年，仍然有一堆邊邊角角的 bug 會讓你用起來莫名其妙，實時協作的支持也還只是停留在紙面上（別相信開源項目里 Leave it to you to decide 的說法，這意思就是這個地方坑太大，你急你來填）。總之，上面這幾個單人主導的編輯器項目要達到穩定質量，時間是以年為單位來計算的。考慮到目前互聯網「下周上線」的節奏，動輒幾年的時間算「合理」嗎？

如果他們的項目都沒有辦法在「合理」的時間內完成，那麼是富文本的坑太大，還是這兩位作者太菜了呢？ProseMirror 的作者 Marijn 是 CodeMirror 編輯器和 acorn 解釋器的作者，前者已經在 Chrome 和 Firefox 自帶的調試工具里使用了，後者則是 babel 的依賴。而 Slate 的作者 Ian 則是 Metalsmith 生成器、Myth 預處理器、Superstruct 類型校驗等數千 star 項目的作者（這裡順便給答主的 Bumpover 打個廣告，一個基於 Superstruct 的數據遷移工具）。當然了，他們跟各位知乎大牛肯定還是沒得比，畢竟人家都沒開過 C++ 的 Live 嘛。不過以答主的粗鄙見聞，在前端富文本編輯的這個細分領域裡，已經很難找到比他們更靠譜的人了。

所以這裡面到底有什麼坑呢？其它答案里對於多語言、RTL、排版等從 Word 出發的概念已經有有很完善的介紹了，對於一個在瀏覽器里從頭打造的富文本編輯器，我能想到這麼一些除了 contenteditable 兼容性之外，還必須填的坑：

必須有自己的一套文檔模型和 Schema 校驗規則。ProseMirror 自己造了個 Immutable 輪子，而 Slate 更是直接拿了 Immutable.js 當依賴。而粘貼、拖拽等事件會以完全不可控的方式魔改掉編輯內容，這時候需要類似 DTD 的 Schema 規則去做校驗和相應的 normalize 去過濾標籤，比如 inline 里不能套 block，table 里必須是 tr 套 td 之類。
必須維護自己的一套撤銷棧。聽起來好像就是 push 和 pop 一下的事情，不過考慮到輸入事件的去重和協同編輯支持，這會涉及對文檔 rebase 操作合併的問題。
必須維護自己的一套 Selection 和 Range 模型。這個靠扁平下標去索引樹形結構的 API 十分反直覺，也是各種詭異 bug 的高發地帶。
必須有自己的一套視圖層。ProseMirror 定義了一個比較難用的 View class，而 Slate 直接拿了 React 當視圖層：聽起來不錯，但是很容易破壞掉 React 的 reconciliation，讓整個編輯器崩潰掉（知乎用的 Draft.js 也有這個問題，我有穩定的復現步驟）。
必須提供一套可拓展的文檔變換 API 和插件機制。簡單地把編輯器當做純粹的應用來開發在架構上是行不通的，需要一個提供上述能力的基礎庫再加上根據業務需求去定製的 UI 組件層。

這些坑每一個單獨拿出來都能算一個獨立的輪子。比如 Superstruct 就是從 Slate 衍生出來的數據校驗庫，不到一個月就收穫了近 3k star。可以說，有能力維護某個獨立編輯器模塊的前端開發者，都已經鳳毛麟角了。

回到問題，題主問的是多大比例，那麼我們可以做個合理的估算：去掉對開發時間的限制，這個級別的開發者在整個社區也只有個位數，考慮上寫 Medium 這樣閉源編輯器的作者，按百級來估算應當足夠了。而使用 JavaScript 的開發者總量，是百萬級。

所以這是最後的結論：滿足時間、質量和人數限制的沒有，去掉時間限制，也是萬分之一以內的水平。（已經準備退坑保平安了，想跳坑的請多保重啊 XD

工業標準，這個太厲害了。開發一個符合工業標準的文本編輯器到哪都是一件相當困難的事情。什麼是工業標準？所見即所得算吧，渲染各種自然語言算吧，撤銷重做算吧。雖然你說用戶只有中國人，但是知乎上出了一條討論泰國語和阿拉伯語之間的關係的問題怎麼辦。就別說Web程序員這種大部分都是沒有經過良好訓練的群體了，就算是客戶端程序員，我看連1‰都不到。

現在知乎的編輯器連「引用」按了都經常沒效果，選擇了「&<&>」上下的空行編輯的時候各種bug，選擇編程語言的那個下拉框還經常失效，這簡直就是玩具嘛。

如果有程序員覺得不難的，我就問你們三個小問題好了。給你一個雙擊的坐標你怎麼計算出遊標的位置？給一個游標位置你怎麼計算出那條豎線的坐標？已知游標的位置按一下←或者→你怎麼知道下一個游標的位置在哪？

我們5個人，做了快半年，才勉強上線，還參考了許多別人寫的東西，最後還一屁股bug。。

說句題外話，你們難道真的覺得這個編輯器達到工業標準了嗎？

功能？引用按鈕的奇怪行為就不說了，從別的地方複製過來會帶上字體大小和顏色，一提交就沒了，這就是工業標準？

兼容性？Windows Phone上怎麼變成個文本框了？

界面，那個選擇語法著色的下拉框真是蛋疼的存在。

穩定性，一點編輯按鈕出來的東西和你提交的完全不一樣是大概率事件，還有自動搞出換行符的問題是最近才修好的吧。。。

別拿這個東西來侮辱工業標準和前端了好么，2333

萬分之一。別不信，光一個 bidi 處理就能搞死你們。

這只是純文字而已哦~

你沒有定義「合理的時間」是什麼

千分之一這個數字肯定高了，前端的基數是非常大的

editor本身是一個邊緣技術，所以沒有太多現成掌握相關能力的人很正常。但如果是「再進行自主學習後能達到開發editor能力」的，可能還是有不少的，而這樣的人會更有泛用性華潤價值

不要過於樂觀，或許是千分之一/萬分之一，甚至更少

80%我是後端程序員，獨立完成了簡書的富文本編輯器(兼容ie8 除了css部分是設計師完成)，時間花了大概兩個月半吧。剛開始先參考一些開源editor(同時看了蝴蝶書) github有仿medium的項目還有網紅sofish的一個editor 後來發現這些實現在ie下是行不通的，而且各個瀏覽器體驗差異較大，然後發現了wysihtml5 editor可以在ie下使用，遂參考其實現方式並改進了用起來會一頓一頓的體驗，完成後發現同時選中有不同樣式的文字再處理會有問題，當時的目標是editor要能生成清晰可解析的html，於是重新設計了相關邏輯的實現，處理文字圖片等選擇時可以保證html的完整與嵌套正常，之後上線修復了一些小bug 總代碼大概2500行吧(editor沒實現很複雜的列表功能，用的coffeescript) 應該在線上至少運行過一年，後來離開簡書不知道現在有沒有重寫了

感想就是看看開源項目來啟發實現原理，然後看看蝴蝶書來掌握js，最後就是遇到任何問題立刻去翻mozilla。實現編輯器是挺難，但沒大多數人想想的難，想做的話用下心還是搞得定的

反對排名第一的答案，content editable 的行為很不一致，比如說插入各種奇怪的標籤，比如說拷貝其它網站的內容，比如說 em 和 strong 標籤的排序規則。可以參考 Medium 很久以前的一篇文章：Why ContentEditable is Terrible。

當然，如果你們滿足於在伺服器端直接存一段 HTML 字元串，而不是保存成一個 well formed 樹結構，我也只能攤手咯。

PS: 我最近打算寫個玩玩，過段時間彙報一下。

足以供商業網站使用的編輯器，這方面目前比較權威的大概是以Tiny MCE為代表的WYSIWYG編輯器，抱歉，不到0.01%的前端可以單槍匹馬在「合理時間」內完成，否則就沒必要形成一個開源項目了；

而工業規範或商用規範，很遺憾前端這個行業太新，沒有這類的規範；功能與體驗這些都非常主觀，而代碼規範這些就更主觀了——雖然有一些編碼規範，但語法層面的規範我覺得體現不出設計層面的問題。

而如果只是基本可用，或是直接利用開源方案，那我覺得應該大多數兩年以上經驗的前端開發都可以在幾天內學會並且在兩天內開發出一個基本DEMO。

比較贊同百分之1的那個答案，單從功能實現上其實不難，但是如果想保證沒有問題的話，可能能做好的也就百分之1了（說不定還不到）

主要原因是日常需要寫文本編輯器的項目很少，大多都是偷懶用插件（管他好不好用放上去不報錯就行了←_←）其他情況下文本處理的程序寫的也不多，相關聯繫真的很少，寫出來的BUG肯定多

好在是之前看百度貼吧改版，那個發帖的功能BUG多的要死，簡直是各種心靈雞湯「百度都做成這樣，我水平低錯的一定是世界！」（開個玩笑，度娘的人不要拍我）

咦？互聯網啥時候開始搞工業標準了？大家做事不都是能用就行了嗎？

想想當初，寶寶也寫過一個 wfEditor ，可惜的是就玩了不到一個月就不玩了

最近剛好在做編輯器，給tinymce寫插件。所以剛好可以回答下。

可惜現在是在android客戶端下，所以不能參照編輯器當前的樣子，我憑印象寫下吧。

考慮到知乎的編輯器也不是很強大。。。所以，答案分兩種:

1 可以用開源庫。比如我們最近用tinymce，那麼答案是五分鐘(下，再加個和後端集成的時間。這個無法估算，而且目測題主也不關心這個。

2不準用任何庫。

這個難度略高，不過以知乎這個水準也不是很難，一小時學api然後用半天調試即可。難的是樣式，費時間。而且有些偽前端，比如我，毫無美感，只會調size，目測會卡在這很久。

有人說太小看這個問題了，我說那是你太高看它了。小技巧，把body的contentEditable改為true，整個網頁就是個編輯器。現代流覽器div就支持此屬性，還能省個iframe。

當然寫到這我就知道會有人拿一些很邊角的問題來顯示自己的逼格了。很抱歉，題主沒有要求實現一個無bug的編輯器，否則答案應該是永遠做不完。即使是tinymce這樣成熟的庫，我最近也經常被它的一些小bug搞的很煩。

然後我估計會有人拿IE兼容性來難為我。很開心，題主極為貼心的為我排除了某些IE。

開源社區有不計其數的簡單編輯器，基本都是外國人寫的。有的也就幾百行，純練手項目，但是完全符合樓主要求。如果這也算難，那就太侮辱國內程序員水準了。

題外話，來知乎問問題是求答案，不是求鄙視，樓上好多冷嘲熱諷秀逼格的答案算是怎麼回事。。。。

如果只需要支持chromium，Firefox nightly，IE11，不管移動端的話應該兩天可以寫出來。而且應該是個前端都能做到。。

要兼容其他的我就布吉島辣。反正我不是前端也才不管兼容性。

而且，如果打一開始就用markdown語法的話，應該上個世紀初學HTML的人就能做到辣！無限兼容喲。

PS，contenteditable雖然坑比但是相比起textarea+div的兼容性還是要更好的，反正filter清楚就沒啥問題啦。

當知乎選擇富文本編輯器的時候，知乎已經掉進坑裡了

我覺得，題主有些小看編輯器的難度了。

最簡單的notepad，不依靠任何庫，國內重本畢業生能搞定的都只有精英。

Office算不算編輯器？你看看微軟多少人花了多少年，至今也才能做到這樣。

基於draft-js,十天搞了個仿知乎、medium的編輯器框架（上傳圖片、代碼....功能都具備了），然後再過去的2個月時間，一直在優化編輯器，估計還要優化很久。富文本編輯器最噁心的地方應該就是游標的問題。

你可以參考下,discuz!的編輯器,百度百科編輯器,這些都是開源的。