jhchen

I do not believe it is a fine control vs out of the box tradeoff. Draft gives you one. Quill gives you both. Previously Quill was limited in what content it could understand but this is the major change in 1.0. I'd encourage you to take another look.

Regarding the third point on markup, everything you say is true, except the first part about misrepresentation. When I said markup I am precisely talking about the HTML markup used to render the contents of the editor. Some people do care about the HTML markup being semantic during the edit session. Sounds like you don't or are okay with computing this yourself, and that's fine, but again this is extra work for the end user. Quill also has an internal state[1] that is easy to iterate over and convert into whatever output/markup.

[1] http://quilljs.com/guides/working-with-deltas/

Quill does let you define Embed blots which essentially hand back complete control over the corresponding DOM node container. For example the formula module uses KaTeX to render formulas and it does not care what KaTeX does to descendant DOM nodes. You could attach listeners and add editing UIs within this if desired. I believe this approach should allow you to implement what you are describing.

The playground favors very short code for experimentation, given the limited screen real estate for the split view.

Quill could do better in the accessibility front though and autofill titles and aria attributes for you. However at the moment you would have to create an HTML element with the aria attributes and pass that into the toolbar[1]. Please feel free to open a feature request for tracking.

You can also use Quill without either of its themes or any of its UI by just using quill.core.js and quill.core.css[2]. The Cloning Medium with Parchment guide[3] in fact starts with this and builds custom UI on top of quill.core.js/quill.core.css.

[1] http://quilljs.com/docs/modules/toolbar/#container [2] http://quilljs.com/docs/download/ [3] http://quilljs.com/guides/cloning-medium-with-parchment/

(Quill maintainer here)

There was a separate comment about Draft, so I answered that one there and will just comment on ProseMirror here.

ProseMirror's main is insight is the need to maintain a document model in parallel with the actual DOM. While most modern editors also do this, ProseMirror also allows their document model to be extended and customized, which only Quill and possibly Draft[1] is also capable of. I think this is the right idea and foundation to build on top of (Quill also made this choice).

I don't think it's fair to judge implementation or specifics beyond its ideas just yet since it is still in the development stages and things can change and improve, as stated on its README:

"NOTE: This project is in BETA stage. It isn't thoroughly tested, and the API might still change across 0.x releases. You are welcome to use it, but don't expect it to be very stable yet."

[1] "Possibly" because Draft uses inline styles and only two levels of content (block and inline) so it's far more limiting.

(Quill maintainer here)

Draft’s own description of itself is "Rich Text Editor Framework for React" and is more comparable with Parchment[1], both being a foundation in which you can build a rich text editor. But there are many pieces missing for it to be a full fledged editor like Quill.

* UI Draft only has buttons you can toggle for formats. There are no dropdowns to select which header size—just six h1, h2, h3, h4, h5, h6 buttons. There are no tooltips or link, video, or image UIs to assist with editing.

* API - Quill’s API is designed for the editing use case. Draft is built on React and inherits many primitives and ideas that are more appropriate for websites, rather than linear content like text. Which APIs is nicer for which use case may be subjective so I will just link Quill’s API’s [2] and Draft’s API [3] and ask the reader to think of some common tasks, like making a range of text bold, and try to figure out how to accomplish these tasks from reading through the respective APIs.

* Markup - With the exception of nested lists, Quill’s markup is clean and semantically correct. Draft uses <span> tags with inline styles with lots of attributes for bookkeeping.

[1] https://github.com/quilljs/parchment [2] http://quilljs.com/docs/api/ [3] https://facebook.github.io/draft-js/docs/overview.html

Not sure which version you were using, but it would be difficult to add this in pre-1.0, and one of the reasons 1.0 was built. There were definitely documentation gaps during the 1.0 beta and release candidacy as well so I'd encourage you to give Quill and its docs another look. Cloning Medium with Parchment[1] might be a relevant guide.

[1] http://quilljs.com/guides/cloning-medium-with-parchment/

Quill just uses KaTeX [1] (which an excellent project) for rendering formulas. Not sure how it determines vertical vs horizontal fractions.

[1] https://khan.github.io/KaTeX/

Disclosure: As the maintainer of Quill, I am much more aware if its strengths and have worked hard to limit its weaknesses.

The main idea behind Trix as stated in their README[1]:

"Most WYSIWYG editors are wrappers around HTML’s contenteditable and execCommand APIs... Trix sidesteps these inconsistencies by treating contenteditable as an I/O device: when input makes its way to the editor, Trix converts that input into an editing operation on its internal document model, then re-renders that document back into the editor. This gives Trix complete control over what happens after every keystroke, and avoids the need to use execCommand at all."

I think the first portion is only historically true. Everyone has figured out contenteditable/execCommand alone is a problem and all notable editors I have seen released in the past few years have reasonable solutions--Trix's solution included. Quill is slightly different in that it prevents problematic operations in the first place and reimplements them itself, such as enter and backspace, but the main idea is the same: maintain a document model as the source of truth, define operations to mutate it, and build an editing experience on top of this.

Some strengths unique to Quill:

* API Quill has the most powerful API of any editor I have seen. You can make any text or formatting change in any part of the editor at any time. Trix by contrast only allows changes to the current selection.

* Modules Quill's internals are broken into modules[2] that themselves can be configured or even swapped out. Many modules also include their own APIs. Trix does not have documentation in this regard, but looking at its codebase, it does not appear designed to support major modification of its internals.

* Formats/Content Quill's document model itself is customizable, which allows users to define their own formats or customize existing ones. This capability is what kicked of 1.0 development, now being released today. This gives Quill extensive coverage of well known formats (tables to my knowledge is the only missing one), but more exotic formats/content like formulas, tweets or syntax highlighted code is also supported. Some editor frameworks have this same idea, but lack the actual editor and UI on top of this so you have to build a big portion of functionality to realize the full benefits.

One main idea I'd like to highlight is this: Text is no longer written to be printed. It is written to be rendered on the web—a much richer canvas than paper. Quill 1.0 was designed and built to support this next generation canvas.

[1] https://github.com/basecamp/trix#different-by-design [2] http://quilljs.com/docs/modules/

I'm sorry you are experiencing problems on your device/browser but I don't think it's fair to say Quill does not take mobile browsers into account.

I personally have a Nexus 7 running Android 5.1, which I use to test Chrome and Firefox. I also have an iPad and iPhone that I use to test Safari. Quill works great in all of these platforms. Quill also uses SauceLabs to automate testing of every push. I have filed browser bugs in the past on mobile Firefox, but have been told sometimes the issue is from the keyboard driver itself, which is two layers from the browser. With the distribution of Android versions and the differences between devices, it is cost prohibitive for an open source project to test and catch all Android issues.

Of course none of this explanation helps your particular situation. What you can do to help your particular situation is:

1. File a bug report so others can reproduce, identify, and fix the issue: https://github.com/quilljs/quill/issues/new

2. Encourage SauceLabs to support Firefox on Android as a testing platform.

Did you try the demo on the homepage? I would have thought a demo of the actual product would make it clear what the actual product is.

Sure, the Playground default now has code blocks in the toolbar.

Thanks and fixed!

Hey HN - Quill maintainer here. The 1.0 release has been a huge effort with spanning almost a year, over a thousand commits, and hundreds of issues closed, since it's announcement[1].

Feel free to AMA.

[1] http://quilljs.com/blog/the-road-to-1-0/

Is there a study you can point to? I'd be curious to know the severity of the vulnerabilities. In the past companies have also been able to successfully cover up breaches. The media attention as you point out makes this more challenging, but in the post-Snowden era people are more aware and and concerned about security and privacy and researchers are getting better at explaining/marketing their discoveries (ex. Heartbleed). I can see breaches continue enjoying heightened attention across industries.

Why is their execution poor? They've broken every record in usage and growth. Designing a back-end to expect and support that level of usage out the gate would have been poor execution.

Servers crashing and people still tolerating it is strong evidence they made something people want, which in my mind is excellent execution. I guarantee if they made a crappy game they will not have server problems or loud bug complaints.

I think what the OP means by winning is keeping control of the gym, to your point exactly.

I am also at level 23 and can take out pretty much any gym. But right when I walk out of range, someone half my level using either a full six roster or type advantage or both will boot me out. When the game came out I could maybe stay in control of a gym for a day but now it has not exceeded half an hour so I no longer try.

Driving a car is a complex and potentially dangerous activity, hence the license. A license to rent a place to sleep makes no sense.

Edit: Instead of responding to every single sub comment I will just add that car accidents kill 30,000 people a year. Whether or not you think AirBnB should be regulated, the analogy pairing their activity to the commonly fatal activity of driving is unambiguously on a different level. A more appropriate analogy is perhaps a fishing license.

It was not long ago that Computer Science degrees itself faced a similar challenge, against more well-rounded liberal arts programs, championed and prided by the Ivy Leagues. Today MIT and Stanford are ahead by the strength of their more “practical” engineering degrees. The data from Triplebyte supports the same narrative, just in greater granularity: businesses value practical skills.

There is value in being balanced and diversity, but this applies to teams, not necessarily individuals. Not everyone on your engineering team needs to be an architect. After your globally distributed, fault tolerant, realtime, highly available system is designed, somebody’s got to build it. And most startups or software teams have no business even trying to design such a system in the first place.

In the US, my generation was told we all needed four year degrees. We don’t. Some jobs and some roles certainly but the entire population of future adults?

There is an engineering shortage in the US because everyone was too busy getting four year degrees in more well rounded fields. Meanwhile Apple needs tens of thousands of engineers that could have been trained by two year vocational programs that the US was apparently above for our children, and thus cannot meet their business needs.

And yet this data from Triplebyte is incredibly encouraging because while we screwed up the educational policy, it may not be so difficult to fix.

So HN itself does the merging and the raw dataset still includes the numerous duplicate submissions then? If this is the case it's not just sources with a lot of content like medium.com, github.com, nytimes.com being dragged down, it's any popular source.

How is paulgraham.com not on this list?

It's a fork of App Inventor[1] so it's essentially a new version, built by people that built the original version[2].

Honestly it would not have been disingenuous to exclude that tiny link clause altogether, but now they're being punished for transparency, because people are too lazy to click on the the "About" link for the page they provided.

[1] http://techcrunch.com/2016/03/05/mit-spin-out-thunkable-hope... [2] http://appinventor.mit.edu/explore/our-team.html

(Biased Quill author here)

Most modern rich text editors have or are moving towards having a document model that maps to the DOM, ideally also producing compact and canonical output. Quill's new document model Parchment takes this approach as well though I admit I borrowed the idea from the Etherpad guys, and some design ideas from React as well [1]. I have not had the time to dig into Draft.js in depth but Facebook has made many high quality contributions to open source and looking forward to borrowing more ideas.

[1] http://quilljs.com/blog/the-road-to-1-0/

You are still very early in your career and very far away from realization of your regret. Find someone you want to work with or a problem you want to solve, ideally both. You can accelerate the process by working on interesting side projects with different people. When you do start a company, people will think it's shitty. But do not intentionally start one you think is shitty too.

Promises about the future about Github’s roadmap is understandably difficult to make, besides by a very small number of people at the top. I don’t think this is the expectation. But visibility into past failure to address these concerns and the current status is long overdue. I assume when these maintainers reached out in private channels, they were equally detailed, and have waited years.

At present, I’m not sure how this response is different from the "empty response" that motivated the publication of this document in the first place, except that this response is also public. Comments like "happy to take a look into these issues", "considered in how future work is planned" and "ensure the right eyeballs are on this" uses a lot of words to say nothing. If the community department is not the right place, maybe it’s time to walk over to where the the product group sits and ask. They probably read Hacker New too.

I’ll also highlight a possible theory: the right people at Github have already looked at these requests and decided that is not what Github Issues is for. Perhaps Issues is prioritized for the masses, not the small minority of very popular projects (but not resourceful enough that they have staff). Each of these feature requests do add friction (if only in complexity) and the majority of projects that do not need and should not utilize them. Hopefully someone at Github will quash this theory but it is consistent with events so far.

Sense of purpose is a real sources of satisfaction and happiness. If you work on something that you believe will impact the world, you will be happier, regardless of the actual odds.

What's wrong with a CLA? It's incredibly common for projects open sourced by companies.

"With the newly obtained AWS key... I queued up several buckets to download, and went to bed for the night."

He definitely took data off of Facebook's server.

Also you misunderstand his access being denied was a firewall change earlier in his story. This was merely to speculate other systems he could have penetrated--completely separate from the S3 buckets he took data from.

From Facebook's perspective it could very well have seemed like he went back for the goods since he submitted three separate reports, the last of which triggered the response. But this is also irrelevant, the question is whether he took data off or not and this is unambiguously yes, by Wes's own admission.

Downloading data is where he crossed the line and what I meant by hostage:

"Wes was not happy with the amount we offered him, and responded with a message explaining that he had downloaded data from S3 using the AWS key..."

Guy discloses vulnerability. Facebook is not as impressed as guy would have hoped. Maybe it's because he's one of several people to disclose the same vulnerability. Maybe there are just a lot of vulnerabilities (they've paid out 4.3m in bounties).

Guy's reaction to rejection: take hostages and threaten Facebook. Facebook moves to defense and cuts guy off.

You are not a good neighbor for kidnapping someone's family to prove to someone their busted lock is a big deal. You show them their lock is busted and trust they can figure out what harm that could lead to. The alternative is companies being hostile to people just looking around their locks, which is the world in the 1990's and 2000's that responsible researchers are trying to avoid going back to.

Uh right below the video...

"We first added Private Browsing to Firefox to give you control over your privacy locally by not saving your browser history and cookies when you close a private window. However, when you browse the Web, you can unknowingly share information about yourself with third parties that are separate from the site you’re actually visiting, even in Private Browsing mode on any browser. Until today.

Private Browsing with Tracking Protection in Firefox for Windows, Mac, Android and Linux actively blocks content like ads, analytics trackers and social share buttons that may record your behavior without your knowledge across sites."