yoga VS sourcegraph

We still wanted to leverage a layout engine that could be performant and easy-to-use. After doing some performance testing with native UIKit, Autolayout, and a few other third-party options, we ended up bringing FlexLayout into the mix, which is a Swift implementation of Facebook’s Yoga layout engine. All RPL components utilize FlexLayout in order to lay out content fast and efficiently. While we’ve enjoyed using it, we’ve found a few touch points to be mindful of. There are some rough edges we’ve found, such as utilizing stack views with subviews that use FlexLayout, that often come at odds with both UIKit and FlexLayout’s layout engines.

We have our own test suite (orginally derived from the test suite of Meta's Yoga layout library [0]) which consists of text fixtures that are small HTML snippets [1] and a test harness [2] that turns those into runnable tests, utilising headless chrome both to parse the HTML and to generate the assertions based on the layout that Chrome renders (so we are effectively comparing our implementation against Chrome). We currently have 686 generated tests (covering both Flexbox and CSS Grid).

We would like to utilise the Web Platform Test suite [3], however these are not in a standard format and many of the tests require JavaScript so we are not currently able to do that.

[0]: https://github.com/facebook/yoga

[1]: https://github.com/DioxusLabs/taffy/tree/main/test_fixtures

[2]: https://github.com/DioxusLabs/taffy/tree/main/scripts/gentes...

[3]: https://github.com/web-platform-tests/wpt/tree/master/css/cs...

The "engine" is built on top of amazing https://www.lwjgl.org/ and https://github.com/bkaradzic/bgfx/, and UI system is baked by https://github.com/memononen/nanovg and https://github.com/facebook/yoga

React Native uses the Yoga engine under the hood, which allows you to use CSS properties to layout your React Native UI in a way that translates really well. Layout in Yoga is limited to Flexbox and absolute/relative positioning, however; there is no CSS grid and no display attribute. This keeps things simpler and more performant, but if developers are accustomed to using other layout techniques on the web, they’ll need to adjust to this new limitation.

PR #246 is super interesting to check out: by fixing the caching strategy, we were able to eliminate an exponential time (with respect to tree depth) performance penalty, and get comparable speeds for flat and deeply nested layouts (something I'd never expected to be possible). Preliminary benchmarks shows us significantly faster than yoga, Meta's C++ library for the same thing, especially on deep trees. Not too shabby for a tiny team of volunteers!

You're going to build the CLI using Ink, a React component-based library for building interactive CLIs. It uses Yoga to build Flexbox layouts in the terminal, so most CSS-like props are available in Ink as well. Ink is simply a React renderer for the terminal, so all the React features are supported. No need to learn a new syntax specific to Ink.

Interesting.

I was thinking that this was going to be a crazy amount of layout engine work, but now I look a little closer it appears the layout work is farmed out to yoga [0] (not trying to take away anything from the effort here). So this project is almost a wrapper around running yoga as a renderer and using SVG as a form of backend target?

I say "appears" because the yoga landing page doesn't do a great job of explaining what it does.

[0] https://github.com/facebook/yoga

Sourcegraph | REMOTE | Full-Time | Machine Learning Engineer, Developer Advocate, Enterprise Product Manager, Technical Advisor | https://sourcegraph.com

Sourcegraph is a code AI platform that makes it easy to read, write, and fix code–even in big, complex codebases.

We are building Cody, an AI coding assistant that uses code search and code intelligence to help devs quickly understand what's happening in code and generate new code that matches the best practices in your codebase. Cody supports AI-enabled autocompletion, fixing bugs, refactoring, test generation, code explanation, and answering high-level questions. You can read Steve Yegge's post on why Cody's code context engine differentiates it from the fast-moving field of AI dev tools: https://about.sourcegraph.com/blog/cheating-is-all-you-need.

Apply here: https://grnh.se/0572f98b4us

That's pretty much what https://sourcegraph.com/ are selling, is it not?

Despite their shitty rug-pull <https://github.com/sourcegraph/sourcegraph/pull/53345>, I do really like Sourcegraph and one doesn't (currently?!) need to be logged in to use it: https://sourcegraph.com/search and they have a handy rewrite pattern such that one can just plug the repo path into the URL for quick searching e.g. https://sourcegraph.com/github.com/JetBrains/intellij-commun...

- https://sourcegraph.com is pivoting and building a copilot application (named Cody). This is pretty good, since sourcegraph is great at understanding your code

While a readable Dockerfile can work as documentation, there are a few caveats:

* the application needs to be designed to work outside containers (so, no hardcoded URLs, ports, or paths). Also, not directly related to containers, but it's nice if it can be easily compiled in most environments and not just on the base image.

* I still need a way to notify me of updates; if the Dockerfile just wgets a binary, this doesn't help me.

* The Dockerfiles need to be easy to find. Sourcegraph's don't seem to be referenced from the documentation, I had to look through their Github repos to find https://github.com/sourcegraph/sourcegraph/tree/main/docker-... (though most are bazel scripts instead of Dockerfiles, but serve the same purpose)

We use Sourcegraph, which is a tool that searches through code in repositories. We leverage this tool in order to understand the adoption curve of our components across all of Reddit. We have a dashboard for each of the platforms to compare the inclusion of RPL components over legacy components. These insights are helpful for us to make informed decisions on how we continue to drive RPL adoption. We love seeing the green line go up and the red line go down!

SourceGraph: https://github.com/sourcegraph/sourcegraph/pulls?q=is%3Apr+a...