51–60 of 72 posts
For NodeJS enthusiasts, Check out Docusaurus (by Meta). For Markdown Docs, Markdown Blogs, and JSX-static pages - https://docusaurus.io - https://docusaurus.io/docs/next/api/themes/@docusaurus/theme...
Earlier quoted context omitted.
Love it! yes, it might be better. We have found paying above market average and being tighter on interviews has a similar outcome.
Elixir market is already more high paying than python.
Sorry for asking a dumb question, but how is this different from using Jupyter to write your interactive documentation/runbooks and interactive tests?
While Livebook will mostly have an appeal for people already working with erlang/elixir, it does have a few features that are pretty nice. - it’s collaborative (think Google docs for code) when several people are working on the same instance of a livebook; - it’s easy to extend with so-called smart cells (which are essentially pieces of gui you can inject in your document https://news.livebook.dev/v0.6-automate-and-l…
For NodeJS enthusiasts, Check out Docusaurus (by Meta). For Markdown Docs, Markdown Blogs, and JSX-static pages - https://docusaurus.io - https://docusaurus.io/docs/next/api/themes/@docusaurus/theme...
This is about live "documentation". Docusaurus doesn't have programmable cells linked to live processes or systems. Docusaurus is fantastic, but it's static. Livebooks are like next-generation REPLs with slick UI, security, reproducibility, etc.
I'm not sure to understand what you mean by "Docusaurus is static". Docusaurus builds static pages and allows you to plug JS/React code anywhere in your docs, so it's quite interactive and can run anything that can run in a browser, including REPLs.
I read the Fly article but still don't really understand what Livebook is about. They say they use Livebook themselves, but the examples linked to only display a regular non-interactive doc to me.
Do you have any production url showing me an experience that is possible in Livebook, and impossible in Docusaurus?
Can someone show me a real production url of what is possible to achieve in Livebook and impossible/difficult to achieve with other tools?
I'm the Docusaurus maintainer, and making your docs interactive, and giving the ability to run the documented project inside its doc does not feel like something new.
Earlier quoted context omitted.
This is about live "documentation". Docusaurus doesn't have programmable cells linked to live processes or systems. Docusaurus is fantastic, but it's static. Livebooks are like next-generation REPLs with slick UI, security, reproducibility, etc.
Hey, Docusaurus maintainer here. I'm not sure to understand what you mean by "Docusaurus is static". Docusaurus builds static pages and allows you to plug JS/React code anywhere in your docs, so it's quite interactive and can run anything that can run in a browser, including REPLs. I read the Fly article but still don't really understand what Livebook is about. They say they use Livebook themselves, but the examples…
Imagine the following.
we click a play button to start an elixir runtime based on that metadata code block
with this component, we then issue commands to inspect state, manage elixir "processes" in the runtime, etc
Mix.install(
[
{:my_app, path: Path.join(__DIR__, ".."), env: :dev}
],
config_path: :my_app,
lockfile: :my_app
)
Alternatively, you can connect to a running instance, e.g. a Phoenix project:
$ elixir --sname my-app --cookie cookie -S mix phx.server
$ LIVEBOOK_DEFAULT_RUNTIME=attached:my-app:cookie livebook serverEarlier quoted context omitted.
While Livebook will mostly have an appeal for people already working with erlang/elixir, it does have a few features that are pretty nice. - it’s collaborative (think Google docs for code) when several people are working on the same instance of a livebook; - it’s easy to extend with so-called smart cells (which are essentially pieces of gui you can inject in your document https://news.livebook.dev/v0.6-automate-and-l…
thanks for the detailed answer of the differences. The interactive (I assume using CRDT's) is a good feature, jupyter server does not have this and is at a time a bit of a hassle. Also deploying it directly as an app is pretty sweet.
[1] https://github.com/jonatanklosko/notebooks/blob/main/article... [2] https://github.com/livebook-dev/livebook/blob/main/lib/liveb...
Today, in a very round-about way, one could use a livebook as if it were a blog post: download-install Livebook on your machive, download the blog post livemd file, run it locally. Here's an example. Note in the first paragraph a link to the post as a livemd file: https://genericjam.com/blog/image-processing If you go through the steps, you'll notice that the livemd isn't stylized as a blog post. This is where the ne…
Earlier quoted context omitted.
Hey, Docusaurus maintainer here. I'm not sure to understand what you mean by "Docusaurus is static". Docusaurus builds static pages and allows you to plug JS/React code anywhere in your docs, so it's quite interactive and can run anything that can run in a browser, including REPLs. I read the Fly article but still don't really understand what Livebook is about. They say they use Livebook themselves, but the examples…
Sure, here's a simple demonstration of what livebook can do that docusaurus cannot, at least without maintainer expertise ;) Imagine the following. we click a play button to start an elixir runtime based on that metadata code block with this component, we then issue commands to inspect state, manage elixir "processes" in the runtime, etc
Can you show a concrete example? IE a real production url running this?
What is "metadata"?
In Docusaurus you can have a live playground evaluating on your browser, or you can embed any embeddable playground if it requires a server integration.
> with this component, we then issue commands to inspect state, manage elixir "processes" in the runtime, etc
Another example would be useful.
So this is just an embedded widget to interact with something remote? Why can't this be built as a React component that you can add to any Docusaurus page?
---
It looks to me that you don't need maintainer knowledge to build that, and React knowledge is enough.