proxy-www VS Node RED

I have eliminated the need for stores in my tree by using proxies, my original little component inventions are very efficient a value changes in a store, I assign it to innerHtml. A store is just a nerfed emitter, it is a tiny little useful program. I don't know what svelte does, when it detects a change to a large nested tree. Does it re-render the whole thing, does it do dom or object, or both diffing, I am not sure. It should observe changes on a property level, like spreadsheet programs. But, browsers, diffing, shadow DOMs and computers are fast today, so as I was going over the twisty litte passages, I also rewrote my tree. In a really crazy way, and you really need to know about this, because when you use Object proxies, then svelte becomes ideal for nested objects. Let me show you how proxies work: https://github.com/justjavac/proxy-www This brilliant person made a www object, that is a proxy, meaning he can intercept the next property. in this case www.baidu, and return a proxy again to capture the data, which in this case is .com when .then is called. It then makes a request to www.baidu.com www.baidu.com.then(response => { console.log(response.status); // ==> 200 }) THIS TYPE OF REFERENCING MAKES SVELTE DEEPLY HAPPY, when the www is a variable that you are referencing in the DOM. Let's go to my tree now. tree is an instance of a normal Tree class, it has children, element, thype of stuff. But I also gave it a proxy... the read property is a proxy that will return a node this way: tree.read.abc.context.filename tree.read is a getter, that returns a proxy. that will spy on the next thing after the dot, in this case abc, which is a node id. it will grab that node and return it, for binding via bind: here I bind to context.filename, but I could bind to tree.read.abc.name which is a lable for the node. filename: {tree.read.abc.context.filename} input.name: THIS ACTUALLY WORKS tree.read.abc.name = 'Hello World', will re-render the UI. Because SVELTE does not care that read is a proxy, it only sees assignment to tree.something.something.something.something It does not care that .read.abc is not real data, though it returns the node object, it is not where the object really is. --- I think we have reached the limit of being able to communicate ideas, my concluding thought is: No, svelte does not not turn a nested object into nested writables, but it is OK, because simplicity has its benefits too. We can lie that tree.read.abc or even ($tree.read.abc if via import) is where out data is at, and say thing like tree.read.abc.name = 'Hello World', to really kick bubble gum. The store ends at your object bounday though it does not go inside, all the properties within are just nested POJO properties, BUT, svelte will detect changes anyway, so as long as you clearly refer to the ROOT object. In my case tree. in your case $data. One last thing to underline, between us noobs, you use stores when you can't bind:data for some reason. The store pipeline, is to be used, when you can't bind easily. Learn to use the proxies, they are of JavaScript not svelte, but they let you bind very deeply into complex data structures, and make an assignment, which svelte will then notice, and re-render the UI. Good luck, here is your program without stores, you don't need to use them if you don't need them: https://svelte.dev/repl/21f8cc38cf3e4b64b824d7c7b702d17b?version=3.44.3

Coming across this creative approach of using fetch, I was wondering in what cool ways you folks take advantage of JavaScript ES6 Proxies?

👉 Inspect the www proxy

Good question.

I expect that we're moving into a phase of AIs talking to AIs, and initially it'll be wasteful (because it'll be mostly English), but eventually, they'll derive their own language and seamlessly upgrade protocols when they determine they're talking to an AI. No clue how that will come about or what that language will look like, but honestly, it's kind of exciting.

Really interesting to think about how they might handle context, as well. Even though we have much bigger context windows (and they'll only get larger), context management is still a resource-management issue, which we'll probably continue to refine, as well. Imagine different strategies for managing both what is brought into the context of each request, as well as what form it could take (level of detail, additional references or commentary on it, etc). Things could get really unreadable even in English, and still be very interpretable for an LLM.

W.r.t. the graph-oriented interfaces, are you thinking something like Node-RED [1]? I'm seeing more and more people mention having LLMs produce non-text or structured outputs, like JSON, UI, and other things. Easy to imagine an LLM that wires together various open-source platforms, on-demand. Something like Node-RED for pipelines/functions, some UI tools for visualization/interactivity, other platforms for messaging, etc...

[1] https://nodered.org/

I skipped to chapter 9 in the article ("Clogged"), and it looked like Pipes failed because it didn't have a large enough team or a well-defined mission. As a result they couldn't offer a super robust product that would lure in enterprise users. "You could not purchase some number of guaranteed-to-work Pipes calls per month" is the quote from the article.

The reason I think that interesting is because that's the model these days for everything from AI tokens to Monday.com seats. It makes me feel like Pipes was before its time.

That said I've been collecting different "business glue" products that are similar to Pipes. To me, like you say, they aren't as interesting, exciting and intuitive as Pipes was, but maybe it just takes a little more digging. I tried to focus on open source tools but some aren't.

- n8n io: https://n8n.io/integrations/mondaycom/

- Node-RED: https://nodered.org/ (just read about this one in this thread)

- trigger dev: trigger.dev

- automatisch.io: https://automatisch.io/docs/

- Activepieces: https://www.activepieces.com/docs/getting-started/introducti...

- Huginn: https://github.com/huginn/huginn

- budibase: https://budibase.com/

- windmill: https://www.windmill.dev/

- tooljet: https://www.tooljet.com/workflows

- Bracket: https://www.usebracket.com/pricing (just SalesForce <-> PostgreSQL)

- Zapier: zapier.com/

Anyway I hope some of these are fun!

Source: https://github.com/node-red/node-red

I believe Node-RED (https://nodered.org/) the way to go. It's just an NPM package to install and you can run it how ever you wish (even on Windows). It has a friendly and helpful community with even the main developers tirelessly answering even beginner level questions. In fact the community forum its THE friendliest forum I've ever been a member of by a large margin. Node-RED's development is supported by the JS Foundation and it's completely free and open source. It's widely used in the industrial automation industry and even integrated by some PLC manufacturers such as Siemens.

Does anyone know if their are plans to implement something like this (or if there are already custom nodes out there). I'd like to experiment with things like looping and incrementing values (like a for loop) for a Ksampler for example. It's only an example though, so I am not looking for a ksampler specific solution; just a generic way to have a variable (e.g. Seed value), run some nodes that use that value, increment the value, and then loop back to the beginning until some sort of condition is met. Node-Red (an event driven node based programming language) has this functionality so it could defintely work in a node based environment such as ComfyUI (see here).