Philosophical questions about virtual DOM rendering and typescript

[EightArmCode]

Hello! Thanks for d3js. I have always been a big fan.

I was wondering if there is any plan to update docs or examples to use typescript and/or to shift the focus away from DOM iteration since virtual DOM rendering has all but taken over the web?

For tasks that require complex mathematics and visualizations, I’m not aware of a better library, but nowadays we can get the best of both worlds if we offload some of the work to a web framework. DOM traversal is passé and, perhaps more importantly, inefficient.

There are quite a few articles and tuts that illustrate how to get the best of both worlds, and I personally think this is the best I have read of them so far.

I’m also curious about Typescript. The source code is (necessarily) quite idiomatic and not that easy to read, but it seems like typescript could give readability quite a boost. It is true the ‘@types/d3’ package is for the most part technically sufficient, but in the interest of maintaining the library in the long term, it seems like a logical next step to move the library into ts files.

Thanks in advance!

[Fil]

(Only speaking for myself as a user and contributor.) We all have freedom to use React or vue (or D3!) to manage the DOM, it's a matter of taste more than anything. I've used the three of them and still prefer the D3 way, with htl when it's easier to write long fragments, but that's probably just me. Fortunately you can use the modules of D3 that you need (say, d3-delaunay), and forget about those you don't (d3-selection in your case). If you look at recent activity over the whole of D3, the focus recently has clearly been more over d3-array and other "computational" modules (d3-delaunay…) than d3-selection.

I'm convinced that Typescript is useful (see the ongoing effort in Plot if you need proof ;-)). But the discussion about readability ought to be much larger than typescript. TS helps a lot, but it's not a magic wand. Most of D3's source code is perfectly (human) readable without it, and I'm not sure the most difficult parts would benefit that much from ts. If you look at d3-geo’s projection pipeline, or d3-delaunay's voronoi clipping, the source code is difficult to enter, but the difficulty is inherently conceptual/algorithmic/mathematical, and not (or rather, not only) about implementation. For these two cases in particular, I've been (day-…)dreaming of making interactive literary programming documentation. But it's a lot of work.

[EightArmCode]

Thank you for your response @Fil. A lot of what you say is spot on. However, it's hard to debate that the learning curve is quite high. Typescript and additional documentation and examples could make a big difference.

Regarding typescript, take the following code as an example (taken from d3-shape/stack):

function stack(data) {
    var sz = Array.from(keys.apply(this, arguments), stackSeries),
        i, n = sz.length, j = -1,
        oz;

    for (const d of data) {
      for (i = 0, ++j; i < n; ++i) {
        (sz[i][j] = [0, +value(d, sz[i].key, j, data)]).data = d;
      }
    }

    for (i = 0, oz = array(order(sz)); i < n; ++i) {
      sz[oz[i]].index = i;
    }

    offset(sz, oz);
    return sz;
  }

It is not very easy to read this at first glance, and not super accessible to find the lines and stop the debugger on the webpack chunk (or insert another preferred task runner) in order to see the variables changing at runtime. Plus, for those of us who are not a quant by nature or education, it's already a lot to understand.

Cue typescript. If this was marked up with information about the types the function accepts and returns, that would save a lot of time in inference and deduction.

As for DOM manipulation, it's true what you say, we are all welcome to pick and choose what is needed and leave the rest. My question was specifically about examples and documentation. I personally do not find observable to be super helpful (it's yet another framework to learn). "Official" examples of implementing d3 with typescript and without DOM traversal, and/or that capitalize off of web frameworks like React are scarce. Would it not increase d3 usage and adoption, and thereby increase d3's overall longevity, to address the steepening learning curve? The further web devs get from DOM traversal, the harder it is for uninitiated devs to pick up, and d3 has always implied a bit of a paradigm shift for most.

It seems an existential dilemma to me. As a fan of the framework, I'd like to keep on using it far into the future.

[jayDayZee]

I couldnt possibly disagree more with this. React etc are anti standards traps built by large corporations to pull developers away from standards and into objectively low quality tool sets. React itself is an abomination in terms of system design, consuming massive resources, generating new domain specific languages which obfuscate standards, making existing mature browser tooling break constantly. Its garbage, and only exists because large companies support the stupid stuff that other large companies produce. React works by horribly limiting the expressiveness of current standards technologies (into a fixed tree structure), which then has to be augemented by very inefficient tools (useful as they may be in the context of React) like... all this garbage: https://www.google.com/search?q=react+state+managemntn+tools&oq=react+state+managemntn+tools&aqs=chrome..69i57j0i10i512l9.2512j0j7&sourceid=chrome&ie=UTF-8 "passe" lol, with a good coding style, and a deep understanding of the meaning of UX, react is an impediment, requiring ridiculous layers upon layers of tooling to perform basic tasks a web browser already performs. "Virtual DOM" is insane. Server Side Rendering has a place... but... server side rendering of what? Of a thing that SEO cannot read? I use and love Svelte, which was built after React, and is a vastly better designed platform. But my own tooling is fully standards compliant and compatible with both those and WebComponents, but in vanilla is much more efficient and easy to use than either. D3 is a standards compliant tool for manipulating the DOM. thats all it is. It also has some cool data features. Wrapping D3 in a React component is only even a consideration because of the limitations of React. In Svelte you can just Use D3, you dont need to wrap it in a pointless abstraction. Typescript exists because of the limitations of development tools. Its not a provability tool, its a crutch for programmers to keep track of all the decisions they have made. In a large, long term project, it has its place, and perhaps even to be applied after a project is developed, however, forcing an IDE to artificially apply typing so that documentation can be visible and... APIs can be easy to find, is Not what types are for, and types are Not a good way of doing that. lol. Though I understand why people think they are. developer hours go burrrrrrr

…

On Mon, 27 Mar 2023, 10:05 Philippe Rivière, ***@***.***> wrote: (Only speaking for myself as a user and contributor.) We all have freedom to use React or vue (or D3!) to manage the DOM, it's a matter of taste more than anything. I've used the three of them and still prefer the D3 way, with htl when it's easier to write long fragments, but that's probably just me. Fortunately you can use the modules of D3 that you need (say, d3-delaunay), and forget about those you don't (d3-selection in your case). If you look at recent activity over the whole of D3, the focus recently has clearly been more over d3-array and other "computational" modules (d3-delaunay…) than d3-selection. I'm convinced that Typescript is useful (see the ongoing effort in Plot if you need proof ;-)). But the discussion about readability ought to be much larger than typescript. TS helps a lot, but it's not a magic wand. Most of D3's source code is perfectly (human) readable without it, and I'm not sure the most difficult parts would benefit that much from ts. If you look at d3-geo’s projection pipeline, or d3-delaunay's voronoi clipping, they are difficult to enter, but the difficulty is inherently conceptual/algorithmic/mathematical, and not (or rather, not only) about implementation. For these two cases in particular, I've been (day-…)dreaming of making interactive literary programming documentation. But it's *a lot* of work. — Reply to this email directly, view it on GitHub <#3644 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGIAA33YM42IGMY7EFWP543W6FJ57ANCNFSM6AAAAAAWI2XTDQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[EightArmCode]

Wow, @jayDayZee Even if your extremely narrow and opinionated perspective had merits, they are entirely lost by your arrogance.

[jayDayZee]

lol, perhaps it's my addiction to passé technology, or maybe the 20 years of research into neurological processes behind programmer behaviour. nah, it's the passé thing that makes me wonder if you are a Twitter bot working for some react factory :) lol. if you wanna understand what I'm saying better, then you are welcome to ask :)

…

On Mon, 27 Mar 2023, 16:34 Kat Chilton, ***@***.***> wrote: Wow, @jayDayZee <https://github.com/jayDayZee> Even if your extremely narrow and opinionated perspective had merits, they are entirely lost by your arrogance. — Reply to this email directly, view it on GitHub <#3644 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGIAA37QWEMJDNOBDHKTVQDW6GXQVANCNFSM6AAAAAAWI2XTDQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Fil]

I'm goin to lock this convo that is not philosophical anymore and can only become a waste of everyone's time. Thanks for the input.