AaronO

Aaron from Deno here. I'm glad to see this come to light and very much looking forward to developing and strengthening foundational Web APIs underpinning modern JS runtimes such as Deno & Cloudflare Workers.

Happy to answer any questions you may have !

I don't think it's unfair to say that 1 man-hour equates to many machine-hours (in terms of dollar cost). Then in terms of per-core performance, modern JavaScript runtimes are nearly competitive with Go and per-core performance is ultimately what matters at scale since you'll load-balance between cores or VMs to saturate your compute.

We're building a highly multi-tenant "isolate cloud" (think VMs => containers => isolates, as compute primitives).

The isolate hypervisor at the core of our cloud platform is built on parts of Deno CLI (since it has a modular design), but each isolate isn't an instance of Deno CLI running in some kind of container.

Isolate clouds/hypervisors are less generic and thus flexible than containers, but that specialization allows novel integration and high density/efficiency.

Aaron from Deno here, happy to answer any questions you may have !

It was mainly intended to be a "cute" example of the latter.

Technically if you were doing this in Node, you would need at least a package.json and would have to configure your TS/JSX transpile, etc...

I agree we could have elaborated on auth, API endpoints or parametric routes (maybe a follow up !).

But this example does showcase a few things you don't typically get with a single vanilla HTML file:

- JSX + reusable/shared components

- Multiple URLs / pages

- Tailwind

What other kinds of examples would you like to see ?

The goal was to showcase simple yet intuitive JSX + tailwind at edge, we didn't elaborate on more advanced use-cases like authenticated pages, API endpoints/forms, dynamic pages (location, etc...) or parametric routes.

Aaron from Deno here. Of course it's producing HTML as an output, but the point is that you can use JSX and familiar technologies like tailwind to dynamically generate that HTML at edge vs client side.

And unlike a pure static site, you can add API or form routes

On many of our internal benchmarks, Deno's std/http server outperforms Node's http (so express/koa too). There's still some room for improvement on our end and we would like to put together rigorous benchmarks before sharing that broadly.

Aaron@Deno here, we've been exploring something with the Tauri team but don't have a concrete release on the roadmap since we're focusing on other priorities.

I believe an Electron alternative is an important part of the Deno stack, so hopefully we'll ship a first iteration next year.

Whilst not classical de/serialization I wrote serde_v8 (https://github.com/denoland/serde_v8), an expressive and ~maximally efficient bijection between v8 & rust.

It has powered Deno's op-layer since 1.9 (https://deno.com/blog/v1.9#faster-calls-into-rust-with-serde...) and has enabled significant improvements in opcall overhead (close to 100x) whilst also simplifying said op-layer.

Hi Aaron from GitBook here.

Exactly. I use git a lot, I'm familiar with git's internals and have written a lot of git related code (our git server and all our git related infrastructure). Yet I still flinch at the idea of solving conflicts in the CLI.

I'm sure other developers feel the same, more so for less or non technical people.

By TeX support I meant that we fully support TeX equations.

The website mentions TeX but means LaTeX, I'll get that fixed, sorry for the confusion.

Our TeX support allows you basically to write Markdown/Asciidoc and use TeX formulas wherever you need to, which gives you the best of both worlds (the simplicity of Markdown and the power of TeX formulas).

All books are stored as git repositories so you get branching, history, etc ... out of the box.

We have great GitHub integration because it's the main Git host out there, we store git repos too.

If we shutdown, our toolchain and book format is already open source (https://github.com/GitbookIO/gitbook), so no matter what you'll always be able to use that to build your book locally. Secondly our Desktop Editor (https://www.gitbook.com/editor) works offline so you could even continue to use that. And well since your book is a git repo, you can have a local copy, a copy on GitHub or any other git server of your choice. So I think you should be good :)

We don't believe in vendor lock, we're big supporters of open-source and we want users to use our tools and platform not because they're obliged to, but simply because it's the best workflow/product for them.

Does that make sense ?

You also might want to take a look at GitBook (https://www.gitbook.com/).

It supports both Markdown and AsciiDoc and is used by authors to write books, documentation, research-papers (GitBook has great TeX support, in all outputs: web, pdf, epub, mobi). (Here's a math heavy book for example: http://jandeleeuw.gitbooks.io/bras1/content/blockrelaxation/...)

The format and toolchain itself is open-source (https://github.com/GitbookIO/gitbook)

There's a ecosystem built on top of that such as a Desktop Editor (https://www.gitbook.com/editor), plugins (http://plugins.gitbook.com/), and more ...

I don't want to hijack the current thread, Madoko seems really cool, I thought some of you might be interested in a more established solution. I'm happy to answer any questions !

Disclaimer: I'm one of the GitBook co-founders

You can already download the MOBI from the book's GitBook page: https://www.gitbook.com/book/0xax/linux-insides/details :)

Hi, Aaron from GitBook here.

Thanks for the kind words! Yep, you might have seen the editor: https://www.gitbook.com/editor (the older version is on GitHub: https://github.com/GitbookIO/editor)

I think the publishing/documentation/writing industries have yet to see the benefits of automation and better tooling. Writing should be simple and accessible.

What we're trying to do is automate all the painful/boring parts so that writers can focus on what they do best: writing.

I'm not surprised you had the same idea :) If you want to share your thoughts or talk, you can email me at: aaron AT gitbook DOT com

And if you want to contribute to GitBook, our book format and toolchain is open source: https://github.com/GitbookIO/gitbook

Fixed ! Thanks

I did mean "guys" in a gender-neutral sense, but you're right it's just as good without.

Hi I'm Aaron, one of the GitBook co-founders checking in.

You are giving great feedback and I'm more than happy to answer any questions you have.

BTW, in case some of you missed it, we're a big believer in open-source, in fact our book format and toolchain is open: https://github.com/GitbookIO/gitbook

This allows us to build better publishing tools together, no vendor lock-in and developers can build plugins to extend GitBook's features, here's a few: http://plugins.gitbook.com/.

GitBook co-founder here. We have a lot of non-english books actually: https://www.gitbook.com/explore, over a thousand in chinese alone.

In the upcoming 2.0.0 release, we've further improved internationalisation: https://github.com/GitbookIO/gitbook/tree/master/theme/i18n We automatically detect your book's language (or you can specify itself) and so then the build chain can automatically use translations for menu entries etc ... if available in your language.

Yes, it supports inlined math formulas, through Mathjax (and KaTeX). It the upcoming 2.0.0 release, we actually render mathjax formulas to SVGs & PNGs so that they are visible in PDFs/EPUBs/Mobi.

Here's a very math intensive book for example: https://www.gitbook.com/book/jandeleeuw/bras/details

GitBook co-founder here, let me know if you guys have any questions !