jhchen

IIRC they were random letters that do not occur naturally in English words, in order to serve as easily searchable annotation/footnote identifiers. He somewhat already knew they were extra details that would not make it to the main body. Later these get changed [1], [2], etc but you don't want to use these at the outset due to possible reordering/deleting.

Source: I was one of the founders of Stypi and we asked him when porting the data from Etherpad to Stypi.

https://techcrunch.com/2011/08/09/yc-funded-stypi-is-etherpa...

In a lot of situations, no additional time is spent (and thus wasted). This happens with advisors in the general case too: they become an advisor and never meet again.

Slab | Software Engineer | REMOTE (Worldwide) | Full-time

At Slab (https://slab.com), we believe that knowledge is the foundation of any organization's success. When a team's collective knowledge is more accessible, that team's potential is limitless.

Our product helps teams easily create, organize, and discover knowledge across the entire company, from non-technical to tech-savvy. Each day, thousands of customers rely on Slab across their entire workforces, including Asana, Benchling, and Fivetran.

You'd be joining a team of thoughtful and experienced engineers, distributed worldwide across North America, Europe, and Asia.

Stack: React, GraphQL, Elixir [1], Phoenix, Kubernetes

* Software Engineer: https://jobs.lever.co/slab/1c6fae7c-980e-4875-be9f-76ae1ebfa...

* Product Manager: https://jobs.lever.co/slab/002d52c5-adbf-49d0-ac7e-8ee4eb18b...

[1]: Why we use Elixir: https://elixir-lang.org/blog/2020/11/17/real-time-collaborat...

Slab | Software Engineer | REMOTE (Worldwide) | Full-time

At Slab (https://slab.com), we believe that knowledge is the foundation of any organization's success. When a team's collective knowledge is more accessible, that team's potential is limitless.

Our product helps teams easily create, organize, and discover knowledge across the entire company, from non-technical to tech-savvy. Each day, thousands of customers rely on Slab across their entire workforces, including Asana, Benchling, and Fivetran.

You'd be joining a team of thoughtful and experienced engineers, distributed worldwide across North America, Europe, and Asia.

Stack: React, GraphQL, Elixir [1], Phoenix, Kubernetes

Apply here for our Software Engineer role: https://jobs.lever.co/slab/1c6fae7c-980e-4875-be9f-76ae1ebfa...

[1]: Why we use Elixir: https://elixir-lang.org/blog/2020/11/17/real-time-collaborat...

Yes, Lyft not being YC is is mostly it but also from an early Stripe employee [1]: "Lyft was also not originally on Stripe. They were on Braintree and switched over to Stripe after both Stripe and Balanced (another YC-funded payments company) competed for their business." Balanced was definitely a payments company also backed by YC. I cannot verify the switching from Braintree as I'm mostly an observer in all this but the other details are easily verifiable.

https://twitter.com/cjc/status/1485803509110894596

At first https://twitter.com/theryanking/status/1485784882173255680 seemed pretty damning but if you hover over the dates of the HN posts, the title attribute shows the timestamp, and it would appear Stripe's came in a couple hours before Bolt's. Add in Lyft and the "facts" around this story really seem to fall apart.

Slab | Software Engineer | REMOTE (Worldwide) | Full-time

At Slab (https://slab.com), we believe that knowledge is the foundation of any organization's success. When a team's collective knowledge is more accessible, that team's potential is limitless.

Our product helps teams easily create, organize, and discover knowledge across the entire company, from non-technical to tech-savvy. Each day, thousands of customers rely on Slab across their entire workforces, including Asana, Benchling, and Fivetran.

You'd be joining a team of thoughtful and experienced engineers, distributed worldwide across North America, Europe, and Asia.

Stack: React, GraphQL, Elixir [1], Phoenix, Kubernetes

Take a look at our open roles:

* Software Engineer - https://jobs.lever.co/slab/1c6fae7c-980e-4875-be9f-76ae1ebfa...

* Support Engineer - https://jobs.lever.co/slab/3088ea25-df14-4692-b338-e18248f32...

[1]: Why we use Elixir: https://elixir-lang.org/blog/2020/11/17/real-time-collaborat...

Slab | Software Engineer | REMOTE (Worldwide) | Full-time

At Slab (https://slab.com), we believe that knowledge is the foundation of any organization's success. When a team's collective knowledge is more accessible, that team's potential is limitless.

Our product helps teams easily create, organize, and discover knowledge across the entire company, from non-technical to tech-savvy. Each day, thousands of customers rely on Slab across their entire workforces, including Asana, Benchling, and Fivetran.

You'd be joining a team of thoughtful and experienced engineers, distributed worldwide across North America, Europe, and Asia.

Stack: React, GraphQL, Elixir [1], Phoenix, Kubernetes

Take a look at our open roles:

* Software Engineer - https://jobs.lever.co/slab/1c6fae7c-980e-4875-be9f-76ae1ebfa...

* Support Engineer - https://jobs.lever.co/slab/3088ea25-df14-4692-b338-e18248f32...

[1]: Why we use Elixir: https://elixir-lang.org/blog/2020/11/17/real-time-collaborat...

Slab | Software Engineer | REMOTE (Worldwide) | Full-time

At Slab (https://slab.com), we're making the workplace a source of learning and purpose through knowledge-sharing. Our product helps teams easily create, organize, and discover knowledge across the entire company, from non-technical to tech-savvy. Our customers include Asana, Benchling, and Fivetran, who rely on Slab daily across their entire workforces.

You'd be joining a team of thoughtful and experienced engineers, currently distributed across North America, Europe, and Asia.

Stack: React, GraphQL, Elixir [1], Phoenix, Kubernetes

Take a look at our open roles:

* Software Engineer - https://jobs.lever.co/slab/1c6fae7c-980e-4875-be9f-76ae1ebfa...

* Infrastructure Engineer - https://jobs.lever.co/slab/1c7b4ed6-fdb1-4b8d-adff-85f3b02c0...

* Software Engineer, Support - https://jobs.lever.co/slab/3088ea25-df14-4692-b338-e18248f32...

If this piques your interest, email jason.chen@slab.com with your resume or LinkedIn with HN in the subject line!

[1]: Why we use Elixir: https://elixir-lang.org/blog/2020/11/17/real-time-collaborat...

This post makes some salient points about the challenges of team knowledge sharing:

- Tree structure is too strict for cross departmental content ex sales to customer success handoff - should that be under sales or customer success?

- The right answer can be found in multiple tools - companies are not going to ditch Google Sheets / Excel for Notion tables

- A common source of truth needs to take into account the variability in skill - some users are going to be heavier users or more technical than others

- Collaboration needs to be as good as Google Docs or else people will just use Google Docs

It looks like the author is envisioning a new solution with Dokkument but if you want an existing one, take a look at https://slab.com. It’s designed to focus on team knowledge sharing while recognizing that it will be part of the productivity stack. For example, there is have a Content Map feature that shows a bird’s eye view of the entire information topology (with filters and drill down possible) and even mass reorganize from there. Integrations are first class with search retrieving results from other tools and rich linking that will preview external content. Knowledge sharing used to be an afterthought for a lot of teams but with the world going remote it’s exciting to see the innovation and prioritization pick up in this space.

Disclosure: I am a co-founder of Slab

Normally I would not promote my own company to the HN community without contributing something of value, but from the looks of the UI decisions in the "juicy screenshots" I would venture to say we have already done so: https://share.slab.com/v1uy96K8

So if Confluence and internal knowledge sharing is problem for your team but you want to try out a ready and available product, please give https://slab.com a look.

I would add most companies do not have the product/engineering/ux talent to approach this problem. Stripe is in the unique position that its talent can execute on several internal “projects” that each individually could justify an entire company to build. Most founders / leaders care deeply about their enriching their teams’ camaraderie and collaboration -- even if only from a cynical rational perspective of onboarding, productivity and retention efficiency (though I would argue from talking to many of them there is also a benevolent side to that). It is an hard problem to get right and Home nails several important details.

Disclosure: I am a founder of https://slab.com that is also addressing this as a scalable SaaS solution.

We is much simpler and easy to use and plays well with the non-Atlasssian ecosystem (as well as with JIRA). In both these regards we like to think of ourselves to Confluence as Slack is to Hipchat.

The company is called Slab (somewhat of a double reference to a thing you can write on and slab serif fonts). It is current in private beta but if you would like to take an early look please find my email in my profile and I would be happy to share with HN.

Disclosure: I am the founder of a company that aims to solve this first documentation case you pose. But the process of validating this problem and get early feedback on our solution, I interviewed to dozens of companies to learn about their tools and processes, and hopefully some of that can be helpful here.

The information split is very much as you describe between canonical and ephemeral. For the first case, the defacto tool for medium size companies (25-1000) is Confluence (large companies lean towards a custom intranet). Confluence is accessible to the entire company, not just engineers with git and markdown knowhow, it is also well established, very reasonably priced and can be deployed on cloud or on premise. There are drawbacks such poor search and complex organization that makes it hard to find anything, but there is not a clearly better solution at the moment, though there are a few startups like mine trying to change that.

For the second case, companies have tried to deploy an internal StackOverflow / Quora, some homegrown or using open source tool but unless tied to a specific workflow (like all hands Q/A), they are eventually abandoned. The issue is a lot of duplication of content that also changes very often. So long term storage is not as valuable as just removing the initial friction and what seems to work best is an ephemeral solution like a dedicated Slack/Hipchat/Teams/Mattermost/Gitter/Zulip channel.

I’m the author of Quill and I will attribute my decision to David Greenspan of Etherpad. Not sure if they are the first but it certainly predates all the examples I know of.

Quill is now a very popular project on Github, in the top 250 of all projects. A lot of people want to add their two cents to popular project and unfortunately the volume is far too high for a) me to respond to every single attempt at adding said cents and b) Github Issues's linear commenting UI makes all attempts at adding two cents confusing and cluttering. With this I prioritize the question that was asked, and specifically the concerns the OP raises.

I have repeated many times that the removal of getHTML was because it was a passthrough function that added no additional value to Quill. You can look at the code history and the implementation of getHTML to confirm this fact. It has nothing to do with the desire to remove functionality as no functionality was removed.

I'm confused why Delta is a bad name, since the word delta means change, variation or difference and that's seems to describe what it is: a change to Quill's content. Data source on the other hand is unspecific and even misleading. Naming is hard though and other readers can find out what Deltas are here https://quilljs.com/docs/delta/ and decide for themselves.

Tables was reported as a feature request by me early in the project life because it is a known feature of Word but only years later did users indicated strong interest in it in Sept 2016. I believe in community contribution to open source so I decided to give the community a chance to build it so I wrote offered detailed implementation guidance: https://github.com/quilljs/quill/issues/117#issuecomment-244.... The fact that this user had seemingly urgent need for it and was employed by a large public company with resources also contributed to this decision. Valuable exchanges were had in the Issue and multiple users has fully implemented it for their companies to varying levels of feature richness depending on their requirements. An official canonical implementation is coming in 2.0: https://medium.com/@jhchen/the-state-of-quill-and-2-0-fb38db....

Author of Quill here. Interested in hearing Marjin’s thoughts but here are some of my main observation is at a high level Prosemirror is much more willing than Quill to sacrifice simplicity for power. This value difference manifests in the target audience, architecture and API design:

Quill can be used for the get going quickly drop in use case. Prosemirror specifically warns against this: “If you're looking for a simple drop-in rich text editor component, ProseMirror is probably not what you need. (We do hope that such components will be built on top of it.) The library is optimized for demanding, highly-integrated use cases, at the cost of simplicity.”

Prosemirror’s schema, as documented, is more flexible than Quill’s. Prosemirror appears to allow anything, whereas Quill imposes some constraints. For example Quill requires all nodes to either be a leaf and cannot have children or a container and must at least one child. There cannot be a node that can optionally have children as is allowed in Prosemirror. In my experience the constraints Quill imposes lead to a more consistent and bug free experience across browsers. I will be curious to try out the edge cases I have encountered at this new 1.0 Prosemirror to see if it handles them the way an end user typist would expect. If Quill can benefit from a shift in the flexibility in its schema, it will do so.

Quill is far more battle tested. Slack, Salesforce, LinkedIn, Intuit and many others are using Quill in their main user-facing production products, not an internal employee only tool. Prosemirror has a great start with the NY Times but there is a large difference in adoption at the moment.

Creativity and rationality are conventionally seen to be at odds than they actually are. But often something creative and innovative to one person is boring and logical to another, particularly when the former is not versed in the latter's domain.

For example, many people versed in networking were using the early internet to make voice communications circumventing long distance telecom bills. It just seems obvious to them then (and many more people now) that if you can send data through the internet, why not encode audio in that data?

To me setting up a server/installation and maintenance is in the chore category of work so 1hr setup and say 15/min/month maintenance ~= 3 hrs/yr. Good programmer contracts can command $500/hr and the work might actually be fulfilling. 4hrs*$500 = $2000 pays for years of hosting.

Also you are not going to hit the top of HN on a regular basis as a casual blogger. Look at real data like your blog's historical traffic in the last year to get an accurate picture of the costs.

As an open source maintainer I used to have the impulse of asking for tiny changes before merging such as what this post is suggesting. The alternative is just accepting the change and immediately "fixing" it for you.

The main reason I did this was to give contributors "credit" for their work. I wanted brilliant the lines of code you be attributed to you, not to me who accepted your PR but added a semicolon to the end to make it consistent with the coding style. But it seems people don't mind the core maintainers being janitors for them, and if they continue to contribute, following by example seems to work be better than being asked to on their first PR.

The "cost" of this is delay, but more importantly I believe it dampens the intrinsic rewards that go with contributing to open source through Pull Requests. Specifically a chore component is introduced and depending on communications you may also feel reprimanded for opening an unpolished PR in the first place.

What Danger does seem to do well is softening this communication portion for required steps. I believe the list is short (sign CLA, pass CI comes to mind) but I would caution and discourage other maintainers from using Danger to enforce an arbitrary rite of passage.

Why is optimizing for SSDs nonsense? Empirically this seems correct since RethinkDB themselves pivoted away from this but curious about the technical explanation.

In theory source maps is the answer but personally this has only worked some of the time. When it does work though it is magical and exactly answers your question of debugging in the browser at the source level.

The author is making an assumption but it is not uninformed. In the comparison list he wrote "I had printed games in China before, and have a good relationship with the company we used." I'm assuming things went reasonably well if relationships are still good.

This guide is heavy on the mechanical side and misses a lot of important substantive parts, if your goal is to add value to an open source project.

Don't just create a fork, branch, and submit a PR without context. First, make sure the intent of your change is actually desired. Just because someone opened an Issue does not mean that it belongs in the project. Anyone in the world can open a Github Issue for any reason. Instead engage and discuss the Issue first and make sure it's actually something the project wants.

Don't just start writing code. Familiarize yourself with the codebase. This comes naturally if you are a user of the project, as you will naturally run into bugs or learn the software's behaviors and as you discuss the Issue or features with maintainers. There are far fewer right ways to build a feature than possible ways.

Finally, understand that your contribution is not "free" for the project. It takes time and consideration to even look at your PR and even more to code review it. The more popular the project, the more true this is.

Atlassian, which just IPOd this year, was famously bootstrapped. There are two founders, each with 37.7% [1], so the table is misleading and the should really be 75.4%. Atlassian eventually took funding from Accel, 8 years after its founding.

It is also curious the table rounded Accel's ownership up (12.7 -> 13), but truncated the founders' (37.7 -> 37).

[1] https://www.sec.gov/Archives/edgar/data/1650372/000155837015...

You can use a container blot, which is how lists are implemented. A container blot represents <ol> and a block blot represents <li>.

Most editors nowadays maintain a parallel structure to the DOM. And since the DOM is a tree, that structure is also a tree. Quill's is Parchment[1] and goes a step further by also having an API and allow defining new nodes, which ProseMirror (and maybe Draft) also does.

Deltas are a simple, iterable output format for Quill. In practice it is much nicer to deal with this in many use cases than the Parchment tree.

[1] https://github.com/quilljs/parchment

What does this mean and how did you come to this conclusion? There are a lot of broad adjectives in the sentence but it doesn't sound right.

Quill definitely has users that are on React (and Angular, Ember, etc). In general you will want a React Component that is essentially a wrapper around Quill so they stay out of each other's way. You should make sure to understand React's component lifecycle and follow their best practices on working with third party libraries that modify the DOM.