We do have news employees in bureaus around the world but I'm not sure what the the exact policy is for tech employees. I'll see if I can find someone with the answer for you
I'm an engineer on our CMS team and as Albert mentioned we're currently seeking both back-end and front-end team members. We're not opposed to hiring skilled developers that don't have deep experience the specific language or frameworks we use. There's also always the option of joining the back-end and transitioning over time to a more front-end role. If you're interested, I'm happy to answer any questions or connect you to the hiring manager.
At the time we started revamping our editing interface many of the options were still in early/incomplete places. I think ProseMirror had an funding campaign at the time that didn't meet its goal initially, although did later on in a second attempt. Ultimately we decided to venture down the path of building our own editor, which was based on a combination of our own learnings in text editing and a collaborative system some folks in our graphics department had put together.
About 6 months in, near the start of 2016, when moving on from the exploration/demo stage of the project to actually building out the real deal we took another look at the landscape and decided to move to ProseMirror. I don't remember the exact points that went into the decision but transitioning from our in house solution to ProseMirror felt pretty natural as they followed similar design philosophies.
Hello, from The New York Times CMS team. We have been working with ProseMirror for the last year and a half or so. Congratulations, it's great to see this finally reach 1.0!
Some of the things we've found really great about working with ProseMirror:
- Separation of the data model from the rendered display has allowed us to extract things like tracked changes and comments which we traditionally embedded as HTML tags in TinyMCE. This leads to less cleaning and prevents inadvertent publishing of metadata.
- Unidirectional data flow makes it work well with applications that use this type of data architecture.
- Separation of modules (prosemirror-state, prosemirror-model, etc) has allowed us to quickly write better tests around our editor code.
- Decorations have been great for implementing the previously mentioned metadata aspects of our editor like comments and change tracking. They're useful for features like our custom spell checking implementation, which checks for Times style in addition to normal spelling/grammar.
- Node views allow us to implement rendering in our own way. We've been rendering React components into them which will eventually allow us to share code between our editing environment and our user facing web stack. They also allow use to render the same editor schema in different ways depending on the context/view they are being used in.
- The step/transaction model has allowed us to move from what was previously a set of additions and deletions persisted within the document to a calculated change tracking implementation. This allows both for a cleaner document but also allows for a wider range of tracking (i.e. show the differences between versions 10 and 15) rather than a static current vs the last "accepted" version comparison.
- Prosemirror’s plugin system is really simple and flexible and has allowed us to add new features to our editor rapidly in a modular way without interfering with other features (comments, custom spell checking, custom find/replace, etc).