Show HN: ORY Editor – A rich editor for the browser, built with React and Redux | Hacker News Reader

Show HN: ORY Editor – A rich editor for the browser, built with React and Redux

github.com

369 pointsjswizzard98 comments

The high CPU and memory usage was due to a large gif which was included two times. This gif accidentally was 1280p with 20fps and was about 40mb large. For some reason, the resizer did not properly work.

Anyways, the gif is now removed. I hope the performance gets much better now. The CPU fans on macbooks going up where probably due to a lack of a dedicated graphics card. This happened to me with my macbook and large gifs too.

If the problems don't go away, please create an issue in the repo so we can work on improving this! It would be important to include your steps so we are able to reproduce these issues.

edit://

Since this comment is on the top, I'll address a few more questions here too. If you missed the demo, it's here: http://editor.ory.am/

First, this is a layout editor first- and foremost. Behind the scenes, React, Redux and slate.js ( http://slatejs.org/ ) is being used. Each cell is a React component that you can implement yourself. In fact, the text component itself is a plugin that wraps slate.js.

Second, we're integrating this editor in Germany's largest e-learning platform (wiki-esque) with ~1 million MAUs: https://de.serlo.org

And lastly we're working on a business model behind it, with our ory sites product (early access): http://ory.am/sites/

If you want to check out our other open source products, feel free to do so: https://github.com/ory

> First, this is a layout editor first- and foremost. Behind the scenes, React, Redux and slate.js ( http://slatejs.org/ ) is being used.

Would it make sense to have a separate repo for layout editor ?

Not sure what you mean? This is already the case, all cells that you can use in the demo are actually plugins. Check this directory: https://github.com/ory/editor/tree/master/packages/plugins/c...

This does not appear to work at all with my screen reader.

Accessibility as afterthought, as always.

I used to look forward to trying to help people fix their stuff to be accessible, but now I'm just tired of every single fucking thing somebody creates being broken for me because everything is a complete heaping pile of inaccessible garbage and nobody even thinks about accessibility. It's not like there aren't thousands of pages of documentation on how to make stuff accessible... but the libraries keep getting released without accessibility, and then people build components using several of these libraries and they're useless, and then people build entire apps out of these components... And the web that I used to know and love and get around just find goes dark.

And this is going to get integrated into some big educational site? So I guess it sucks to be a blind student in Germany.

What a mess.

Sorry for the negativity, but this just really, really gets old.

It must really suck, and when I work on small(but large) personal projects I feel bad that someone might not be able to use it. What are some good resources to start thinking accessibility first? I remember in the past it was .. a project and a half in and of itself.

I really like the A11ycasts show by Google Chrome Developers https://www.youtube.com/playlist?list=PLNYkxOF6rcICWx0C9LVWW...

The nice thing is it's very easy to get started, and no matter what you're working on, be it a web project, a mobile app, or even something for desktop there are loads of resources out there, as well as people who care.

For web stuff, over the last month or so I've been pointing people to the relatively new but still pretty nice A11y Style Guide[0] This is obviously for just getting started. When we get into more complicated markup, I often find fantastic resources, articles, and examples from companies like SSB BART or Deque (no affiliation with either)

When mobile accessibility comes up, few people do it better than the BBC, and they have a great resource on it[1]

I'm also working on a playbook for mobile accessibility, but that's still under development.

The really important and kind of awesome thing is that it's extremely easier to test the accessibility of whatever you're building as you build it. Unlike the bad old days where screen readers costs $1,000 and no developers had access to them, on mobile or Mac screen readers are built directly into your device, and on Windows NVDA is completely free from [2]

Hope this gives you a starting point, and if you have more questions feel free to reach out, email in profile.

[0]: https://a11y-style-guide.com [1]http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mo... [2]https://NVAccess.org

I guess something I have trouble wrapping my head around is when is it acceptable to give up on a11y? I mean, it seems improbable to get a11y into an expansive CLI application. Or a 3D game. When does it become OK to give up?

> it seems improbable to get a11y into an expansive CLI application

Why? I used to use make menuconfig back in 2000--why should it not work now?

3d game? This I'll grant you. Some experiences are just not replicatable for the blind, though if you're interested in this at all check out the weird and wonderful world of audiogames and 3d audio with HRTF.

An editor? Even a visual editor? Is not one of these experiences. I used to use Visual Basic 6 just fine, dragging and dropping controls out of the toolbox, lining things up, and editing the code behind the widgets all the way back in 2002.

I see that this project apparently took 8 years by 150 people, according to the OP. With this much human effort behind it, it's remarkable that no one once said, hey, I wonder if anybody with a visual disability might want to use the app that this will be a part of?

How would you mark it up? If I have multiple panes with different data, and say a graph, how does a screen reader know that? As far as I know that kind of data can't be conveyed yet?

I don't really understand your question. Mark what up, a command line interface? They don't really have markup.

If I'm trying to read a lot of data in a CLI, the output of top, for instance, I need to read by line with the screen reader fixed to a given column offset but it works fine even if it's a little awkward.

I guess I meant that in the case of HTML you usually mark things up with aria tags and what have you. Not that there was anything like that in CLI land.

This is only one small facet of the problem, but a11y[0] is a helpful tool to automate accessibility testing. It of course doesn't cover everything you should be concerned about, but as someone who's far from an expert, it feels like a good starting point.

[0] https://github.com/addyosmani/a11y

It doesn't work with your screen reader because the site is rendered after the initial page load. The content is not prerendered. However, the technology allows prerendering, so it actually works with screen readers. Some pieces might need improvement (e.g. missing alt tag on images at the moment).

By the way, blind students use the education platform, and they are really happy that such an amazing, ad-free platform exists.

As far as I know screenreaders can handle dynamic rendering just fine. Perhaps you just need to mark it as a live region? https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

> Accessibility as afterthought, as always.

You are in a minority. Minorities are always an afterthought. It's hard meeting the needs of every single minority - there are so many with many diverse needs.

Yes, being in the small group that wants people to actually use proper accessible markup as WCAG indicates does put me in a minority, it's true.

However, this concept that there are a lot of minorities so obviously we can't cover all the bases seems a little silly. Do people of color need different markup? Do women require somebody adds special javascript libraries so they can access the content? Making content accessible to a screen reader is part of our job as web developers. Just like the site isn't done until it renders in IE 11, it's not done until it reads with NVDA. In fact, often times people can install an alternative browser, whereas it is currently impossible to install an alternative pair of eyeballs, so I would go so far as to advocate accessibility before heroic browser compatibility battles but obviously I'm biased here ;-)

Well, I wasn't referring to just websites. Any software you make is probably going to have some kind of accessibility issues. For example, does your app have color cues for anything? Colorblind people may have an issue with that and so you need to take that into consideration and make the app colorblind friendly as well. It's virtually impossible de-conflicting all the types of colorblindness, so usually people just use icons to tag things instead of colors. This is even more important for things like games where colors indicate critical functions (hence why games sometimes have "colorblind mode")

>Just like the site isn't done until it renders in IE 11, it's not done until it reads with NVDA.

Interesting opinion. I'd argue that it's not at all a web developer's job to comply with every single accessibility guideline or support outdated browsers, unless required by their contract and paid for by whoever commissioned the work. These requirements are part of the reason that most governmental contracts are overpriced by a factor of 10 (the other reason being corruption).

It is unfortunate that the effort spent to accommodate screen readers is easy to see as less rewarding than the effort invested into all of the other users... Truthfully, it seems like the only really good solution would be to make screen readers much better at understanding the content than to make the content much better at being understood by screen readers. Pool the expertise where the need is. This kind of thing is why I feel that good AI is so important. We can make information far more accessible, especially when you consider that the AI doesn't actually have eyes either.

So I take it you've never shipped an MVP?

A lot of us did and those worked perfectly with screen readers. It's not hard or even additional work, you just need to give a crap while doing basic design.

This is similar to the responsive/mobile design - if you care about it from the start, you'll structure the site/component in a way that it really won't take you much more time to support accessibility features. If you don't care at all, retrofitting accessibility will require severe refactoring and probably won't ever be done.

So not caring about it in "MVP" is about the worst thing you can do.

Not having something in the 'forefront' of one's mind isn't equivalent to "not caring".

You should also keep in mind that you're (implicitly) asking people to do more work – which is fine, but there are real costs and people aren't bad because they haven't already borne them.

No that is exactly my point - it's not "more work" if you think about it from the start. Just like it isn't more work to make a site responsive if you start correctly - but it's significantly more work when you have to rewrite a lot of components later because you didn't take accessibility (or responsiveness) in consideration at the start.

>it's not "more work" if you think about it from the start

Most of my job as a developer is thinking. So yes, it is more work. Accessibility / Responsiveness isn't always done first because it takes more time (either thinking or "working").

This was something I really wish would be featured at every conference by device / OS manufacturers every year.

I was surprised there was no discussion of Android accessibility this year at IO.

Sorry for the late reply, but this condemning tone just really, really gets old.

This is a frigging open source project. Take it or leave it. If you want something, you send a frigging patch. Or you ask nicely.

When literally the first sentence of the project description mentions an "accessible web", I think it's perfectly acceptable to have a condemning tone.

> ORY is a company building and maintaining developer tools for a safer, more accessible web.

It also says "Please Note: ORY Editor is pre-release" and while we're commited to improve the experience for everyone, this tone definitely doesn't motivate us.

The definition of "accessible" could be pretty broad. It doesn't have to mean what you have in mind. As I see it, is this WYSIWYG editor making the web more accessible to laypeople who don't know HTML, CSS, etc.? Definitely.

> The definition of "accessible" could be pretty broad.

Only if you are trying to play word games. Try googling that exact phrase - accessible web - and see if there are any results that support your point.

The tag line did not contain that exact phrase. It said "make the web accessible". Try googling "accessible definition"? Also, they seem to have since changed it to "easy to use", so the intention is clear. If you want to be offended by their use of the original meaning of "accessible", by all means.

EDIT: Okay I retract the "did not contain that exact phrase" part; I thought you were talking about their company's tag line. Anyway, feel free to be mad at the word choice.

I read my comment again and realized that I could have been mistaken for being affiliated to the project. To be clear, I am not. I'm just one open source maintainer and contributor who gets upset when I (or other amazing people) put out work for free and then am somehow blamed for not doing this or that.

Edit: Ahh I see you mentioned A11y or Ally, thought it was someone's user name.

Aside from using tab indexes to jump around on a page, what else helps?

Is Hacker News really good with accessibility?

Oh Screen Reader has that voice right? So proper use of Header tags... man how do you follow a chain of comments? control find and look for your user name? Oh maybe the threads part of Hacker News.

Aria tags...

Well probably good news for you with the move towards voice-interfaces with the Amazon Echo products and what not, maybe there will be API's or something to present data with voice-first in mind so no visual.

I think this looks great for CMS websites: where a user wishes to build an entire page in a web GUI.

For composing text in blocks on existing pages, like comments or posts, you would need a lighter-weight solution.

SlateJS (https://github.com/ianstormtaylor/slate) fits that purpose for me exceedingly well, more than DraftJS, Quill and others, since it doesn't treat XML/HTML as a second-class citizen.

The levels of complexity with text representation are:

Document -> Post -> Text

which corresponds roughly to the data sources:

JSON/Data Structure -> XML/HTML -> Plaintext / Markdown

Markdown can "upscale" to documents, but JSON data structures, by virtue of their complexity, do not "downscale" well at all to Markdown.

HTML is the simple middle for me: it shouldn't be used for documents, but it is totally intuitive for posts where a users simply wants to adjust the color of one's text. The blocks wrapping this text should own the data structure, e.g. a flag for "NSFW Content" shouldn't be in the text editor but an option on the post itself.

This is actually using slate js! We've been contributing to slate too :)

Ha, then I should read more carefully before I comment :-)

Excellent work! Do you think it may make more sense to market Ory as a Page Editor or Page Maker? Content in my mind can mean anything from a block to an entire page, though I recognize that CMS's have popularized the idea of content being equivalent to a page.

Right now, I see "Layout Editor" and "Content Editor" being used to describe it, so maybe it would make sense to standardize that.

Just a thought!

Yes, we've been banging our heads to finde the right terminology to describe it. We'll put page editor / maker to our list of keywords :)

Agreed. I like the simplicity of http://megadraft.io/ (built on draft.js).

I'm curious, what does this offer over something like https://draftjs.org/, https://github.com/ianstormtaylor/slate, or http://prosemirror.net/ which also use normalized JSON (or ImmutableJS) objects for editor state and are backed by much larger and more established companies/communities.

We just launched https://ridewithgps.com/ride_reports which is built with draft, and I found it to be very flexible. I'd love to see the industry start to focus on using two or three best-in-class editors and contributing bugfixes to those rather than slugging it out with contentEditable again and again in smaller one-off projects.

Hey, the ORY Editor is actually built on top of slate - it simply adds drag and drop layout capabilities and a cool plugin system!

You might want to make that more clear in your documentation. Your current README doesn't mention Slate at all, I'd be much more inclined to go 'oh, this makes a lot of sense' if you were pitching 'Slate.js with the batteries included' instead of 'we built another WYSIWYG editor!'

That's a good point!

Just checked out ridewithgps.com - the implementation is very nice!

It's a clean and simple look where the underlying tech stays out of the way.

> Promising libraries potentially solving the above where abandoned by their maintainers, because it started as a special use case, or a free-time project.

> It is built by a company, reducing the likelihood of abandonment.

Even projects "built by a company" suffer the same fate. The only way to reduce the likelihood of abandonment is to tie a revenue stream directly to it, like customers paying for support or a pro version with additional features

That's what we're doing: http://www.ory.am/sites/ - although there's obviously never the guarantee that a project is maintained. However, all of our other projects have been maintained for over two years.

Anyways, you're now one library richer, that solves a hard problem and we're committed to making it awesome.

Oh, and I almost forgot to say that. The editor is also used at serlo ( http://en.serlo.org/serlo ) which is the largest educational platform for germany with 1 million MAUs. So there's really little chance of this being discontinued over the next 4 years.

Yeah, I've gotten this response for my framework vs. a competing one from Mozilla. I usually reply "Mine came out a year before theirs and I still work on it all the time, and how 'bout that Shumway?"

I've come to the conclusion that "All software is ultimately abandoned". Ours is a fast-changing industry. If software isn't abandoned, it probably should be. Its the oldest frameworks and languages that get the most criticism.

Big parts of the toolset I use every day are several decades old; if done correctly, software can be iterated and refined until it's of a very high quality. In my experience, it tends to stand a much greater chance the smaller it is (the best examples I'm thinking of are small unix command-line tools like find, grep).

Yet I resent every time I have to use grep, instead of a tool integrated with my IDE. Certainly those baroque old tools have their detractors too. That they survive so long (like vi and emacs) due to cults, not objective evaluation?

I use sublime text as my main editor, but I still need to use vi from time-to-time - e.g. when ssh'ing to a remote server. That's definitely an objective need, unless you can offer an alternative that is just as widely available.

De gustibus non disputandem.

I like grep... It does not do the same thing as Ctrl+F in my editor, but that's fine.

The Chrome worker for the demo site accumulated about 600mb of ram. Is the editor really that heavy or is the demo page abnormally heavy?

See this comment: https://news.ycombinator.com/item?id=14417601 - the memory heap should now be around 20 megabytes.

Didn't fix it for me, I just hit it at 11:55 EDT - still getting 500MB on initial load of the editor.

Could you share the profile file and some additional screenshots in the github repo as an issue? That would help a lot identifying the issue.

There is definitely a memory issue. Chrome's task manage shows me your tab at 900MB.

Some other issues:

- create_content.png takes 37 seconds to load - sea_bg.jpg takes 20 seconds to load

Was this on the blank page, or did you edit some things?

Looks and works great, but there are 2 limitations I think would prevent it from using it in our stack:

1) It cannot be easily embedded, ie. as a field in a form. Apparently it's meant (UI-wise at least) as a full-screen editor and has lots of dependencies of its own, including React.

2) AGPLv3 license is a killer. Means that any work that links to the library should be opensourced. Despite some people interpreting it differently, it would be risky for a consumer product to ship making use of this library.

We are working on (1), and make it possible to include it in non-react environments. However, there are still some dependencies required (such as react). So yes, this is not perfect at the moment.

We're actually not confident with AGPLv3. We might change it to a more permissive license if it prevents people from adopting the technology. Feel free to create an issue on GitHub and we'll discuss it!

Actually, I would be more confident working with a GPL- or AGPL-licensed product, because enhancements are more likely to go back upstream.

That is right. I just know, that many companies flee from GPL licenses (and more so AGPL). They omit any product involving GPL just to be sure not to get any juristic hassles (if rational or not).

Here is the culprit: When no other people invest in enhancements, there is also nothing that can go back upstream.

I like free software very much, but I also don't want to be forced to give things free, that I make. Problem is not the small enhancements I make to an OSS product, but when I link or use some OSS part in a bigger software that I made -- should I always be forced to give everything for free?

Particularly for companies, that is a difficult thing.

To be clear: Of course I would give away my contributions to an OSS product, but I also want to be free, to use OSS in commercial products without need to fear that I loose my own rights.

GPL here is just difficult and when lawyers have to decide about software, anything can happen (as in the patent-wars).

Any company that arbitrary limit themselves will be at an disadvantage to their competitors. LAMP for example include GPL products and avoiding it can be more costly and time consuming than the alternative (hosting solutions with LAMP for example).

A great example of such competitive environment is game development where you can't let religious fear of licenses get in the way. If a license is compatible with the business model then use it, and if not then try to get the developer to give you an exception. Development time is precious in getting the product released in the right time window and in a stable state. Studios can't afford skipping GPL development tools (which would not be part of the end product) or LGPL libraries (unless constrained by aspects shared by the competition), as the risk to the company from delayed release is significant higher than the cost of having a lawyer go through a license and confirm if it will impact the model for releasing the game. As a result many AAA games are released with a huge list of free and open source libraries.

But if you are an incumbent holder in a market with very little competition, then you can have policy against licenses and do well. What would an extra month of development for iphone cost Apple as a company?

> many companies flee from GPL licenses

That's a feature, not a bug. If I release free software and you are unable or unwilling to play fair, I don't __want__ you to use my software.

+1 for keeping the [A]GPL. As I understand it, the CRUD service that backs this would be separate software, which only communicates with this editor through an API, so it would not be affected by ORY's license.

If ORY was a full stack content editing service, rather than just a client with a demo server, then you could still run it unmodified, making it easy to share the source (just link to the official repo). Your other services could either operate on the data being saved by ORY-service, or communicate with it via an HTTP API (whose implementation would be an open component of the ORY-service). But once again, your own software would not fall under the AGPL, because they do not extend, or trivially wrap, ORY.

The only way an AGPL license would force a user of ORY to share their own code, would be if they forked ORY and extended its own codebase, or wrapped it in a trivial adaptor for some framework or platform, e.g. a Wordpress plugin.

IANAL, and the AGPL is a long read, but I do feel like I understood it, and could use this alongside closed-source services.

Some of your assumptions may not hold in this case: see my thoughts at https://github.com/ory/editor/issues/392

I did create an issue about the AGPL: https://github.com/ory/editor/issues/392 Quoting some of my thoughts from that thread here:

> I am not a lawyer, and this is not legal advice, but the choice of AGPL makes this utterly unusable as part of a commercial web application.

> Not only would it require all frontend code to be open sourced, but if it's used in-process in the application server as recommended for server-side rendering (for accessibility or SEO), all backend code for that application process would need to be open sourced as well.

...

> If you want the largest usage (and, by extension, upstream contributions), I'd encourage a license like Apache, BSD, or MIT. React itself is licensed under the BSD 3-clause license to sidestep many of these issues! The ecosystem nowadays is such that the default is to fork on Github anyways and send pull requests upstream, so that the application can benefit from continuous upstream bugfixes and just use the mainline NPM version without needing to maintain a fork. There are so many incentives to contribute that I think many open source projects lose more than they gain by trying to formalize contractual obligations.

I get the cutting edge part, but what has happened to the good old distributed, built, minified version?

What if I just want to play with it, install it in a second and I don't want to download 50% of NPM?

Looks pretty good and I didn't see performance issues. From a usability perspective it's simple to use. I would suggest a couple of usability improvements.

1. The right side buttons for edit, layout, etc. have tooltips (that's great) but they should be like on/off buttons e.g. clicking layout once puts the editor in layout mode, clicking it again should bring editor out of layout mode back into preview.

2. In Edit mode the buttons on the bottom work like on/off buttons (that's great) those buttons should have tooltips.

3. Editing an image I can't put an alt value or title? How accessible is the content created by the editor?

Keep up the good work. I would use this for quick website/blog setup.

Hey, thanks for the feedback! I tracked this in the repo, see: https://github.com/ory/editor/issues/389

But I will briefly address these issues here:

> 1. The right side buttons for edit, layout, etc. have tooltips (that's great) but they should be like on/off buttons e.g. clicking layout once puts the editor in layout mode, clicking it again should bring editor out of layout mode back into preview.

This was actually implemented at one point, but we removed it because some people found it confusing. We might add it though.

Also keep in mind that the UI is just a component, you could simply provide your own!

> those buttons should have tooltips.

Great idea!

> 3. Editing an image I can't put an alt value or title? How accessible is the content created by the editor?

Noted, we forgot about that. You can, by the way, write your own image plugin that has an alt tag. But of course we will add this capability to the image plugin. :)

I wanted to walk you through my thought process regarding the right side buttons if you'll indulge me:

1. I clicked the edit button on the right to get in to edit mode. Edit button was highlighted in pink.

2. Saw the buttons on the bottom appear when I clicked a Text section.

3. Bolded some selected text by clicking the B button. B button got highlighted.

4. Clicked the B button again and text went back to normal and the highlight on the B got turned off. (At this point I'm thinking cool buttons are on/off. On state is indicated by a highlight, Off state is indicated as normal style)

5. Performed some other edits then clicked the Edit button the right since it was highlighted and based on my experience with the bottom buttons I expected clicking it again would turn off edit mode.

You don't have to make the change. I just wanted to walk through the thought process of one user.

Thanks for indulging me :)

Thank you for your feedback, I added it to the issue as well :)

I enjoyed messing around with it but, like others have noted, it seems to be resource intensive - both CPU and memory. My CPU fans kicked into turbo-jet mode after playing around with the editor for a while. Maybe it's less resource intensive on the user (non-editor) side?

Optimizations will go a long way to swaying adoption. Clients like easy-to-use editing capabilities, and it doesn't get much easier than this.

Almost broken on mobile, and my iphone gets really hot...

Which iphone do you use? Also is it safari? It's currently absolutely not optimized for mobile, as most content creation happens on the desktop. We might though at some point.

When you say not optimized for mobile, does that include use on laptops?

My Macbook gets really hot as well. It seems to be quite cpu intensive, and the editing is not very smooth. Otherwise, the product looks interesting

We're trying to improve the experience. One possible issue could also be a large gifs in the content: https://storage.googleapis.com/ory.am/inline-edit-lg.gif

I'll resize that, and let you know - could you test again then?

I'd love to switch to a modern, React editor, but sadly they're all for 'rich text', but not full HTML, so I'm stuck with TinyMCE.

I realize my use case is uncommon, which is users tweaking HTML emails before they are sent.

You should take a look at the Monaco Editor[1], which is used in VS Code. It is available as a javascript component, and there is also a React wrapper around it [2]

[1] https://github.com/Microsoft/monaco-editor

[2] https://github.com/superRaytin/react-monaco-editor

I went here: http://www.ory.am/sites/

They have a signup page. The premium option is $9/mo. I tried to signup, it brought me to a Google form. I completed the form.

OP: I will pay you $8/mo for this. It is beautiful and interesting, and is worth looking in to. I want to try to create some sites with this, I am happy to pay for it and self-host it. Hopefully it's easy to deploy.

Or better yet, I can let you host it for me. With the option of self-hosting anytime in the future. The key to adoption is making it as easy to install as Wordpress.

This could be big! Good luck.

But this is built with React so its not really reusable outside of its ecosystem. Is there a version that would run on preact instead? Maybe QuillJS would be a better option for general purpose editor.

If you use preact without preact-compat then you seal yourself into the preact ecosystem. That's why preact-compat exists.

I was thinking more about using the editor with our polymer and vuejs applications.

Isn't a lot of the "Others don't do this" addressed by Prosemirror? http://prosemirror.net/

One of their requirements is "Based on reusable React Components, it gives developers, authors and designers new ways of working together and creating better and richer experiences more easily."

So basically Prosemirror is not buzzword-compatible enough for them.

And also, "It is built by a company, reducing the likelihood of abandonment." Because Marijn Haverbeke's reputation for abandoning projects is so prominant </sarcasm>

(Full disclosure: I supported the Prosemirror Kickstarter and contributed to CodeMirror.)

Nevermind your sarcasm, but if you'd actually checked out both editors in detail, you would have seen the apparent differences. Anyways, you can replace the standard text editor, which is slate, with prosemirror, as all content is just a plugin.

Ory makes some really cool stuff for OAuth / Authorization that we are considering using in our stack.

https://github.com/ory/hydra

https://github.com/ory/ladon

https://github.com/ory/fosite

Demo here: http://editor.ory.am/

Looks similar to Draft (https://draftjs.org) at least in how they think about maintaining editable content outside of the DOM. Glad to see some editors finally put this theory to practice.

I like it because it looks complete and clean, however in safari for iPad the readme page in github already breaks and says the typical:

"A problem has ocurred, so the page has been reloaded"

I hope they fix it because it looks perfect for fast mockups

Edit: it seems to sadly happen with all ORY pages including the documentation

How performant is this?

I don't have it on me right now, but if I were to dump a 400-kW document into the editor, would it still be snappy? That's one of the major weaknesses of Google Docs right now, and I'd consider switching if I found anything that lacks it.

Man... everytime I think about building something... on this Chromebook I'm just like "Why did I buy this?" And it's ARM! ahhhhhhhh

I did like Cloud9, but still not used to it versus a local dev environment... hypderdev yo! Heard about that

Built studiously.co website with this. Highly recommend the sites editor!

Also using Hydra by the same author for OAuth2. Truly amazing work.

line-height of the title does not look good on my screen http://i.imgur.com/SpxLfUD.jpg (and the white text in front of the blackbord as not very readable either)

I like it! If there was an online journaling web-app using this, I would definitely use it. hint hint

> You are a web agency and are lookin for tailerd solutions?

From the pricing page. Is this a typo or a joke I am missing?

Yeah i prefer word for windows 3.11

Reply on news.ycombinator.com