From SVG to Canvas – A new way of building interactions

A long time ago a small startup used unusual tooling in the industry. The startup was small, but the tooling had some great qualities, which allowed the startup to compete with bigger teams feature for feature, spending less efforts to produce the same functionality as their industry peers. Eventually the startup had a successful exit, the founders become rich, and one of them even started sharing his experience in a rather systematic manner. Happy end.

Is it so that SVG requires to use all the features of it, or is it possible that you can mix and match, choosing what's important now and what's not, while benefiting from already existing SVG features? Is it possible that SVG followers don't do something which SVG does for them? Aren't there features, sufficiently aligned with SVG, which outperform directly working with other layers?

Or, your stuck doing version upgrades of the framework before even getting to the fight.

React three fiber and React three drei? Not sure what you are trying to do, but I have been super impressed by what you can do with react-three-etc. Video textures, images, click through works well. And when you need web thingies - input boxes for example - adding in a html is simple. Built on top of the outstanding threejs library. Examples of what you can do: https://docs.pmnd.rs/react-three-fiber/getting-started/examp... of what you can do. This one: https://codesandbox.io/s/drei-reflector-bfplr is pretty cool and not much code.

After a few weeks with r3f I am trying to figure out whether I can just use a very small amount of css and react. I integrated webrtc video chat as a texture pretty easily. Surely there must be some gotcha, but I have not found it yet.

> Fun fact: Google docs is actually a canvas.

This is often said, and almost as often misunderstood as referring to what I call the “pure canvas” approach where you throw away almost everything the browser gives you and start from scratch. Some key points about Google Docs, just to clarify (I’m not disagreeing):

① Only its document area is rendered with canvas; its chrome is all still regular HTML.

② It still uses the browser for text shaping and painting, just not for macro-layout (breaking paragraph into lines, &c.). (I expect that’s what this article’s subject would be doing too, but it’s part of common misunderstandings.)

③ Even things like scrolling are completely left to the browser: it’s not a single , but a regular DOM scrolling area contains a bunch of tiles.

④ The shunning of using HTML-with-contenteditable for the entire thing makes editing perform very badly (throughput, latency and jitter), and things like keyboard caret navigation behave non-natively in ways that will be very frustrating for people that actually use and care about this stuff (you get to relying on things behaving the same, like with touch typing, so things that get it wrong like Google Docs and LibreOffice (which gets it all wildly wrong) constantly grate).

⑤ They could just as easily use HTML or SVG rendering as (while keeping their input and layout the same, so I mean still with all manual line breaks and that kind of thing). You’d get quite similar performance (though probably overall a little worse), and the same problems (since it’s the input layer that makes it slow and jittery—it just fundamentally can’t be as good in those ways as boring old contenteditable, given the current primitives). In fact, it’d mildly surprise me if they didn’t have an SVG or HTML renderer handy, or did in the past and could revive it to complete indistinguishable functionality within a day or two (even if hacky).

(I wrote a little more at https://news.ycombinator.com/item?id=33863185.)

That was long before they switched to canvas rendering, too: they were still just using contenteditable, though potentially with mild layout augmentation with things like absolute positioning and sizing of things (I don’t know).

Flowing text around an image: the web has been able to do this for donkey’s years, it’s the float property. More recently, there’s the CSS shape-outside property that even lets you use non-rectangular crop: https://developer.mozilla.org/docs/Web/CSS/shape-outside.