Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Docs will now use canvas based rendering

workspaceupdates.googleblog.com

Post reply on HN
Print view View original

821–830 of 953 posts

Re: Google Docs will now use canvas based rendering

#821

Post by miohtama »

lewisjoe wrote: post #30

We are working on a full-featured Google Docs alternative - https://writer.zoho.com . We are already capitalizing canvas technology for rendering documents across devices, except for the Web which still is DOM. Having a single codebase that renders across all platforms is our long-term motive, and it does require rendering to a cross-platform canvas backend - like Skia. I'm assuming Google Docs is already on that dir…

What are the pain points when switching to canvas based editing, or what does DOM based editing still do better?

Re: Google Docs will now use canvas based rendering

#822

Post by kemayo »

snewman wrote: post #776
bhl wrote: post #757

Earlier quoted context omitted.

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? More specifically, what do you think about open-source libraries like ProseMirror ( https://prosemirror.net/ ) or Slate.js ( https://github.com/ianstormtaylor/slate ) which do that (ProseMirror uses its…

> With a canvas-based engine, the editor is no longer relying on the contenteditable spec right? Correct. In fact, contenteditable went out the window a decade ago when the "#2" engine (low-level DOM manipulation) was launched. My experience with contenteditable is ~12 years stale at this point, so the only thing I'll try to say is that I expect it would work well up to a certain level of ambition, and no further. As…

My experience with modern contenteditable suggests that it does work pretty well, overall, though I've not been using it for something as layout-heavy as Docs -- I've worked on the VisualEditor for mediawiki, which has different requirements.

A canvas-based document editor with any sort of international ambitions has a fairly high bar to clear for reimplementing basic features. The browsers really do handle a lot of useful things for you in contenteditable, like the upthread-mentioned RTL issues, and complex IME input methods.

If you have a lot of HTML-rendering inherently required, strong internationalization requirements, and no need for something like page-based layout... contenteditable has advantages, particularly when comparing the up-front work required.

Re: Google Docs will now use canvas based rendering

#823

Post by reader_mode »

trinovantes wrote: post #470
Tyriar wrote: post #308

I wrote the terminal canvas renderers in VS Code that has been called out a few times here. Initially I implemented a canvas renderer using just a 2d context to draw many textures which sped things up "5 to 45 times"[1] over the older DOM renderer. Since then I moved onto a WebGL renderer[2] which was mostly a personal project, it's basically the first canvas renderer but better in every way since it works by organiz…

Do you think the large performance benefits can be achieved for any general web app (e.g. if I rewrite my Vue app's render functions to using a canvas instead of the DOM) or is the canvas' benefits mainly for niche workloads?

From what I understand DOM is pretty shit in terms of performance because it needs to support so much legacy crap (eg. float layouts) - so even using sandboxed WebGL (which adds overhead over native APIs which your browser would use to render) you can still be much faster.

Re: Google Docs will now use canvas based rendering

#824

Post by warkdarrior »

fwip wrote: post #571
warkdarrior wrote: post #559

Earlier quoted context omitted.

All web pages are editable currently, they are editable via Javascript. Not sure the distinction you are making is meaningful. The only thing we are missing is a good edit UI.

Google Docs is what happens when you write a good editing UI.

Sure, but now they are overriding the rendering layer (HTML+CSS) to benefit editing over reading.

Re: Google Docs will now use canvas based rendering

#825

Post by vkou »

Dylan16807 wrote: post #802
vkou wrote: post #663

Earlier quoted context omitted.

> For starters, a binary blob on your computer can be prevented from "phoning home" to collect personal data much more effectively than a web app can. In theory, it can be. In practice, the average user doesn't do a damn thing to do so, and installing a random native blob from the internet is far more dangerous than a webapp running in a browser sandbox. > Additionally, the vendor is often forced to compete with thei…

Security patches aren't important for most software, when it's not connecting out to any servers.

Surely, you realize that docs needs to be connected to a server in order to perform it's basic use case of collaborative editing... Right?

You must also realize that an arbitrary native blob can and will happily connect out to whatever server it's authors want it to.

I can't say that 'there are a few techies who aren't happy that Google doesn't ship docs as a native application' is a very compelling reason for Google to try to change core web standards.

Re: Google Docs will now use canvas based rendering

#827

Post by Dylan16807 »

vkou wrote: post #825
Dylan16807 wrote: post #802

Earlier quoted context omitted.

Security patches aren't important for most software, when it's not connecting out to any servers.

Surely, you realize that docs needs to be connected to a server in order to perform it's basic use case of collaborative editing... Right? You must also realize that an arbitrary native blob can and will happily connect out to whatever server it's authors want it to. I can't say that 'there are a few techies who aren't happy that Google doesn't ship docs as a native application' is a very compelling reason for Google…

> Surely, you realize that docs needs to be connected to a server in order to perform it's basic use case of collaborative editing... Right?

Isn't this conversation about programs in general, not just collaborative editing programs?

> You must also realize that an arbitrary native blob can and will happily connect out to whatever server it's authors want it to.

can

But if it doesn't, then most such programs don't need constant security updates.

Re: Google Docs will now use canvas based rendering

#828

Post by datavirtue »

highwind wrote: post #251
throwaway894345 wrote: post #100

Earlier quoted context omitted.

I also prefer desktop-first, cloud-backed solutions, but I have quite the opposite experience. Working with MS Office has been a pain and I've been a happy Google Docs user for about 10 years. My wife who isn't an especially technical person also finds Google Docs quite a lot more intuitive and laments when she has to use MS Office products for work (she is a consultant for Microsoft including their 365 line of busin…

What makes Google Docs a better product than MS Office? Can you provide some examples of features that are better in Google Docs?

What makes Google Docs a better product than MS Office? Ignorance and Dillusions.

Re: Google Docs will now use canvas based rendering

#829

Post by Gaelan »

IshKebab wrote: post #769
dangoor wrote: post #563

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. edit to add: and switching to D…

Try holding down Alt on https://makepad.dev/ Such a cool feature that you can't really do with DOM based solutions (VSCode could never do this).

Would anyone mind explaining/screenshotting what it does, for the benefit of those of us on phones?

Re: Google Docs will now use canvas based rendering

#830

Post by Gaelan »

Tyriar wrote: post #542
jackcviers3 wrote: post #517

Earlier quoted context omitted.

The major problem I have with electron apps is that they eat memory for breakfast, lunch, and dinner. This happens with jvm applications as well, but you can limit the max heap size and force the garbage collector to work more, trading off speed for the ability to run more apps side by side. AFAIK, you can't limit the memory used in electron apps, and they don't respond by sharing heap with their child processes. Wit…

This isn't entirely the fault of Electron though, but the convenient data types exposed in a web environment. Beyond the baseline memory of running Chromium, you could use various tricks to keep memory very low such as minimizing GC (eg. declare variable up front, not within loops), use array buffers extensively, shared array buffers to share memory with workers, etc.

> eg. declare variable up front, not within loops

I have trouble believing modern JS engines wouldn’t optimize this to the same thing.

Post reply on HN