Etherpad-lite: RFC: Thinking about a rewrite (I know)

[Pita]

It's been a while since I wrote the first code for this project. Back then it was all more of a proof of concept and node.js was a super new technology. I knew little about working with bigger code bases and how to keep code clean. It was never really meant to scale and I copied lots of code from the old Etherpad that I didn't understand much myself. When I then left the project, it seems a lot of code activity has gone down. Although, it seems like user demand for this project is still high.

All this made me think how I would write it today. I would make sure it uses new technologies that make it more stable. We had to reinvent the wheel here lots of times, just because there were no established frameworks yet to solve our problems. I would use typescript on the server and client side to avoid type errors. Build everything with a very test driven approach and make it more object oriented. These things should make it easier for people to contribute as pull requests can be type and test verified. On the client side we could start a new editor with react that doesn't use content editable, maybe there is even one we could reuse out there. This should help us to avoid so many browser specific content editable bugs. A rewrite would probably break 3rd party code which uses the rest api or the plugin api. I feel that would be ok as ultimately it would be easier to build more features.

These are all just thoughts so far and I'm curios to what you guys think. I'm not sure if thats just the dev in me speaking who wants to make everything new and pretty and that there is really no big use case. Or maybe I'm wrong and I'm not the only one thinking this way. I'm a contractor these days and if you agree with me here and would like to sponsor such efforts, please get in touch.

[lpagliari]

@Pita for sure a re-written Etherpad would be much better than the current one, although I suspect that would take A LOT of time to complete. Things that would improve, with the ideas you've mentioned above:

• by using a React editor without content editable, we would get rid of the iframe waterfall we have, which sometimes is a nightmare to handle. On the other hand that might break lots of things inside Etherpad-core and its plugins, but that's a cost we might have to end up with cleaner and simpler code bases;
• by using a more TDD approach, we would be able to increase the test coverage we currently have. Currently some parts of the code do not have a very good coverage (if they have any at all), which I understandable, as no one had a very good knowledge about the original Etherpad code when Etherpad-lite was being re-written. But by having a good test coverage we will be able to change parts of the core of the editor without being afraid of breaking things. I'm personally always afraid of breaking something when I need to change anything on ace2_inner.js, for example;
• by using other tools & frameworks to do stuff that Etherpad doesn't need to handle, the codebase would be much simpler and less error-prone. And I'm pretty sure those guys know how to handle these other stuff much better than we do; :-)

So, yes, I agree this would be a great idea, and Etherpad would be much better after that. I'm not sure how long that would take, but would be awesome to have it. Let me know if you need a pair of extra hands to work on it, I would be glad to help.

[fnetX]

What about a rewrite (or parts of it) in Rust? It appears to be a hype and it has a lot of advantages for systems that have to be safe and fast ...

[rhelmer]

What about a rewrite (or parts of it) in Rust? It appears to be a hype and it has a lot of advantages for systems that have to be safe and fast ...

I'm a big Rust fan, but I think it's a little too soon to do a pure Rust server or a wasm front-end.

One approach I believe is very viable though is to write native modules in Rust instead of C/C++ ... for instance the Neon Rust/Node bindings works pretty well today: https://github.com/neon-bindings/neon

[rhelmer]

I agree that it's worth seriously considering React for the front-end, or if not React proper then at least considering components and think about data flow etc. React has the tooling and developer awareness though that would probably help attract contributors.

I agree with @lpagliari that this will require re-thinking and probably breaking existing Etherpad plugins, however the goal of having plugins might be better served with React-style components rather than the current approach that most plugins take.

One thing I hear from folks when I ask what problems they have with Etherpad is mobile support, having a single responsive front-end probably makes the most sense, which this would be a good opportunity to do.

It's worth looking into the full set of Progressive Web App guidelines too.

[Pita]

Thank you all for your feedback on this. It seems like most people agree with a frontend rewrite in React. I'll start thinking about how to do that and then we can go to the backend maybe later.

@fralix I played a bit with Rust myself and I like the ideas behind it. But I had to realize that the eco system is still way smaller than the one of JS. So I think it would be too hard to find dev support.

@rhelmer What are the current issues with mobile? I guess if we would make this a priority for a frontend rewrite it would be easier to justify

[bennidi]

Hi guys,
I just stumbled upon this thread while staring the repo (I have a running installation of etherlite and love it). Many thanks for creating this awesome tool.

If you consider a rewrite with a modern web framework, specifically react, I encourage you to look at preact instead (much faster vdom diffing/rendering) and absolutely compatible with entire react ecosystem. See https://github.com/Rich-Harris/js-framework-benchmark for some numbers.

Also have a look at common component libraries like react-material-ui, react-bootstrap or the like. You get responsiveness for free then and don't have to meet and mingle to much with SASS,LESS whatever.

Definitely use web-pack for bundling (currently best dev xperience with hot-reloading and debugging with sourcemaps and babel support).

Also, before using REDUX or similar tool: Check out mobx for state management. With ES7 decorators in place (very commonly used babel plugin) it gets rid of a lot of state management boilerplate. You get back to coding your models, define observables and all your ui is reactively update on state changes by mobx.

[rpmansion]

@Pita any update on this?