Our great sponsors
-
makepad
Makepad is a creative software development platform for Rust that compiles to wasm/webGL, osx/metal, windows/dx11 linux/opengl
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
x-spreadsheet
The project has been migrated to @wolf-table/table https://github.com/wolf-table/table
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
slate
A completely customizable framework for building rich text editors. (Currently in beta.) (by ianstormtaylor)
-
-
-
In 2009, I joined Mozilla and started working on the Bespin[1] project, which Ben Galbraith & Dion Almaer had brought to Moz. Bespin was built with a canvas-based renderer. Bespin was way faster than other browser-based code editors at the time.
Then the Ajax.org/Cloud9 folks came along with their Ace editor[2], which was DOM-based and still very fast. We ended up merging the projects.
Rik Arends[3] was one of the Ajax.org folks and he's been working on a WebGL-based code environment called Makepad[4], which is entirely built in Rust and has its own UI toolkit. He's complained a lot about how difficult it is to make a performant JS-based editing environment.
My point in all of this is just that there are absolutely tradeoffs in performance, accessibility, ease-of-development, internationalization, and likely other aspects. If raw performance is what you're going for, it's hard to beat just drawing on a canvas or using WebGL. Google Docs needs to worry about all of that other stuff, too, so I'll be interested to see how this shapes up.
[1]: https://en.wikipedia.org/wiki/Mozilla_Skywriter
[2]: https://en.wikipedia.org/wiki/Ace_(editor)
[3]: https://twitter.com/rikarends
[4]: https://makepad.dev
Perhaps Flutter. It uses Canvas to render in the web.
> The way to fix this trend would be to reimagine the presentation layer of the browser as something other than a stack of hacks over hypertext, but so far nobody seems to have a good solution.
About a decade ago I had the start of a Eureka moment on how to do this (back then — https://medium.com/space-net/spacenet-51aca95d49a2, nowadays https://treenotation.org/). It seems to me we've missed a sort of fundamental universal notation of the universe, which you can think of as "two-dimensional binary". I predict we will soon see a Cambrian Explosion of new formats and notations that are simpler and more interoperable with each other, and some will have the opportunity to build new great languages for rendering stacks.
I didn't believe you at first, but then I gave it a try.
Yes, they actually built an email client from which you cannot copy text: https://gallery.flutter.dev/#/reply
Well, to be fair Libre Office online exists[0]. However, I believe EtherCalc[1] is faster.
[0] https://www.libreoffice.org/download/libreoffice-online/
I remember Flipboard using canvas to render their UI before using react, which has the same idea, you can look at the repo and their post about it:
It seems like WebGPU is the next thing:
With a canvas-based engine, the editor is no longer relying on the contenteditable spec right?
For the majority of use cases, do you think contenteditable + view layer which precisely updates the HTML is still viable though. Or more specifically, what do you think about libraries like ProseMirror (https://prosemirror.net/) or Slate.js (https://github.com/ianstormtaylor/slate)?
I understand if you have really long documents or spreadsheets (I imagine latter is more frequent), you could maybe solve performance rendering problems with virtualization, which canvas gives more flexibility to?
With a canvas-based engine, the editor is no longer relying on the contenteditable spec right?
For the majority of use cases, do you think contenteditable + view layer which precisely updates the HTML is still viable though. Or more specifically, what do you think about libraries like ProseMirror (https://prosemirror.net/) or Slate.js (https://github.com/ianstormtaylor/slate)?
I understand if you have really long documents or spreadsheets (I imagine latter is more frequent), you could maybe solve performance rendering problems with virtualization, which canvas gives more flexibility to?
Sorry, I should have clarified a bit more — I'm writing a cross-platform desktop application that has a preact[0] frontend (+ a Go backend) using `firefox --app application.ini`.
I have been experimenting with performant lists (which is why I brought up the XUL tree), though at the moment, I'm only using the XUL menubar element in order to populate the native macOS menubar.
I am a fullstack web dev in my day job, so my goal here is to write a fast, easily extendable UI that I can quickly iterate upon using modern html/js/css/etc.
Basically, since I love gecko and used to write XUL add-ons many years ago (I'm already familiar with the internal browser architecture, etc.), I'm using XULRunner (`firefox --app application.ini`, as previously mentioned) as a replacement for Electron.
I'm basically using XULRunner in the same way spotify uses the Chromium Embedded Framework[1].
[1]: https://en.wikipedia.org/wiki/Chromium_Embedded_Framework
