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.
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.
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.
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.
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/...)
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 !
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
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.
Happy to answer any questions you may have !