Hacker News new | ask | show | jobs
by _bxg1 2403 days ago
Rich text editors are a nightmare to implement, especially on the web, mainly because formatting a substring requires creating a new nested element, so you have to constantly synchronize a flat string with a tree structure. It's possible that they dodged this problem by storing the in-progress message as a tree and just intercepting keyboard events to directly manipulate that. If so, the core data structure would've changed and it might not be a clean swap between two different widgets that both just operate on a string.

That's just a guess though; I don't work at Slack.
1 comments
capableweb 2403 days ago
Sure, I understand the complexity of implement rich text editors / WYSIWYG. However, when implementing and deploying something like this, you usually put it behind a feature toggle (so, if you have a "text editor" component, you start by extracting old text editor into something like "raw text editor" which "text editor" uses by default. Now you can add "rich text editor" to the "text editor" component, but only if the feature flag is activated) so you can toggle it back/forth as needed.
link
_bxg1 2403 days ago
My point is that abstracting things that way may have carried deceptively significant overhead, and if they intended to move everyone to the new editor without a toggle (which they clearly did), they may just gone forward with deep, incompatible changes instead. So now they'd have to go back and re-structure everything to make it modular in that way so that the two versions can coexist.
link
capableweb 2403 days ago
> may just gone forward with deep, incompatible changes

Yeah, this would be my assumption as well, which is why this is so unreasonable. Any serious company will deploy changes that are easy to rollback (especially when it comes to UI changes) and that Slack can't do that, speaks a lot about their engineering talent. But then again, they never been famous for their software engineering exactly.

link