Acmeon

Thanks for the interesting info! Yeah, maybe Excel web will someday support local calculations via wasm, but for now I think I will stick with Excel desktop with add-ins.

Yeah, I was expecting that you do not train on business or enterprise user data. However, I am not just worried about "training", but also about "sharing". Furthermore, I am worried about cases where an individual has chosen to integrate an add-in and then inadvertently leaks sensitive data.

However, it may be important to note that these security considerations are relevant for most Office Add-Ins (and not just the ChatGPT add-in).

Yeah, that makes sense. For some reason, I was under the impression that all calculations run locally in the browser, which would have been comparable to how Excel desktop works (i.e., local calculations). Is there a reason for why the Excel calculations run on the server (e.g., excessive workload of a browser implementation, proprietary code, difficult to implement in JavaScript, cross browser compatibility issues, etc.)? Furthermore, if the reason for this architecture is (or was) limitations in JavaScript or browsers, do you find it plausible that the Excel calculations will some day be implemented in Webassembly?

Regardless, I have always preferred Excel desktop over Excel web (and other web based spreadsheet alternatives). This information makes me somewhat less interested in Excel web. Nonetheless, I find Excel Add-Ins useful, primarily because they bring the capabilities of JavaScript to Excel.

In principle, I find it valuable to integrate tools. However, in this case I would be somewhat cautious, especially as "your chats, attachments, and workbook content — may be shared with OpenAI" (as per the Microsoft Marketplace description: https://marketplace.microsoft.com/en-us/product/WA200010215?...).

This seems like a security nightmare, which is especially relevant because sensitive data is often stored in Excel files.

Do you mean that you worked on the Excel Add-Ins platform in Excel (and not on a specific Add-In)?

If you were working on the platform itself, then I would be interested in hearing your more detailed thoughts on the matters you mentioned (especially since I am developing an open source Excel Add-In Webcellar (https://github.com/Acmeon/Webcellar)).

What do you mean with a "OM" call? And why are they especially costly on Excel web (currently my add-in is only developed for desktop Excel, but I might consider adding support for Excel web in the future)?

In any case, `context.sync()` is much better than `context.executeAsync()`.

On my computer, the linked benchmark gives the following results.

Object.defineProperty getter: 82M ops/sec, Proxy getter 32M ops/sec => proxy get is 2.56x slower.

Object.defineProperty setter: 14M ops/sec, Proxy setter: 12M ops/sec => proxy is 1.17x slower.

However, in my simple self written benchmark that compares the time it takes to sum the property values (i.e., getter) of 100 million proxies vs plain objects, the result is that the proxies are 13x slower.

When benchmarking the setting of the property value of the 100 million proxies vs plain objects, the result is that the proxies are 35x slower.

My simple benchmark gives results that significantly deviate from the linked benchmark. Regardless, the relevance of the performance implications of proxies should be evaluated on a case by case basis.

Regarding the memoization, I was primarily referring to accessing the getter multiple times (i.e., not necessarily in DOM rendering), which can cause unnecessary computation in Gea (as far as I can tell). In my envisaged use cases, this could often lead to problems (with, e.g., large data sets).

My issues with async mainly relates to developer convenience (i.e., managing the async stuff can be cumbersome). For example, one can use await in a top-level module statement, but not in a class getter. There has been some relevant discussions about this in the context of Svelte, see, e.g., https://github.com/sveltejs/svelte/discussions/15845, https://www.youtube.com/watch?v=1dATE70wlHc and https://www.youtube.com/watch?v=e-1pVKUWlOQ.

Consider this conceptual example (i.e., async computed value):

  store0.url = "...";
  store1.res = await fetch(store0.url);

How would this be accomplished in Gea so that reactivity would be preserved (i.e., mutating store0.url would trigger a new fetch)? Is it possible to "listen" to changes to store0.url and handle the async code?

Looks quite cool! I have also considered similar ideas, but have decided to not develop anything. However, there are a few important areas where we have different points of view. My main use cases relate mainly to computationally demanding applications and, thus, runtime performance is quite important.

First, the claim that one gets "reactivity for free" is not entirely true (although the costs may be negligible for many apps). The stores are wrapped in proxies, which lowers the performance of, for example, property access. This is why I rejected the idea of proxies and instead considered generating getters and setters to handle reactivity. This could, in principle, enable zero overhead reads (assuming that all the reactivity stuff were to be handled in the setter). However, this approach fails to account for, for example, array mutations. Thus, I see the point in proxies, but the cost of them can be significantly lowered performance (which may not matter for all applications).

Second, not memoizing computed values (i.e., getters) can also have a significant negative impact on runtime performance, because expensive computations may have to be executed many times. I suppose that caching could be offloaded to the developer, but this could be laborious, at least if the developer would have to keep track of when to invalidate the computation. In, for example, Excel, computed values can be accessed fast, because they are stored in memory (although the added memory usage can become a problem).

Third, you have not addressed async stores or async computed values (as far as I can tell). I will admit that considering async can be quite complicated. However, for better or worse, async is still a key part of JavaScript (e.g., sync alternatives do not exist for all APIs). Thus, the claims "JavaScript is enough", "Zero Concepts" and "You already know the entire API" are slightly imprecise, because async is not supported (although, this does not necessarily matter for many applications).

These three points were the main reasons why I chose not to pursue my similar ideas (especially in the context of computationally demanding applications). Still, I find the idea that JavaScript should be enough for reactivity to be compelling and worthwhile of further development.