Replies: 1 comment
-
This is a very cool framework. I have been throwing together stuff in Svelte in the last year. It is pretty good, but has its limits. I am not sure they want to talk to me about those. But, maybe I just have to shout louder. So, I made a blog. I have streaming, movies and songs. I have a back-end. I am using IPFS, etc. etc. My blog is a grid. (Some of it is very like things you are doing... I think your interfaces are much better. I put a light touch on my search engine, because I am leaving room to plug stuff in, and I wanted to spend more time on distributing components with the plan for using blockchain payment pathways. So, my back-end has a lot of attention. And, I want to write less code in the interface, or make that into something someone else does.) Svelte allows for pretty good updating. But, in the end it's a little too static. In particular, if you build things into hierarchies too tightly, then it is hard to get dynamic loading going. One thing that has been helpful with Svelte has been its formalism. The tag binding has been magical at times. They have "bind: this={my_local_var}" or this "bind:subcompontent_var={my_other_local_var}". These are really nice. They also have a short way of saying what updates, "$:". This nice formalism is also a nightmare of sorts. I am very concerned about infinite loops, unexpected behavior. And, I find myself fighting unexpected updates. Yet, I am fairly certain it has reduced my coding in JavaScript. In the last month, I have been working on a graphics editor with it. All the good and bad of Svelte has revealed itself to me with this project. As for my blog... I don't just want to make a blog. I am making a blog of soft panels. The soft panels should be assembled from components that can be found in the blog. The use of the soft panels should allow for an assignment to a machine. In order to make soft panel components, I am reconstructing SVGEdit using Svelte, graphics editor I mentioned. This has gone reasonably quickly because of Svelte. Yet, Svelte consistently presented to me some of the worries I mentioned. I spent a good part of a day trying to figure out how to tell the top level of the app that a selection rectangle had changed from one component to another. It needed a sort of special magic. It seemed that every time I changed the slightest thing from a working state, everything fell apart. I eventually got things stable by coming up with selection modes, free mode, selection mode so that the top level could know if clicks were going from object to object or from an object to the empty space to an object. I am fairly certain that Svelte, being helpful, was causing some trouble and this had to do with bound variables updating according to Svelte's schedule. Then, there comes the part where I want to load a component from a database after having searched for it. The component can be compiled SSR into the DB. But, I need to have it be encrypted. It has to be decrypted in the browser. The freshly exposed component has to connect up with the soft panel chosen by the blog user and start functioning right away. It should connect to a machine and start working -- e.g. an Arduino app or something. So, this is almost impossible with Svelte. Yet, your framework has the ability to bring in a component as a string. Also, your framework is very performant. So, I would think it best to use your framework for loading and using the components. At some point, I am not sure that the ability to write in new tags is all that important. If the SVGEdit like app that I am making works, then components are drawn. And, they are connected by a program. (The SVGEdit knockoff is https://github.com/copious-world/vegdes) I wrote a little Petri-net class in JavaScript. I can imagine using that (or something better) in a soft panel organization of components. So, I am thinking that there can be clean way of managing causality when dealing with variable changes stemming from events or code, etc. How the components hook up becomes important. The tag languages are nice. But, if they are stored encrypted, they won't be searchable. My search framework has to do with meta-data as it is. That is, it looks at descriptors of media. Of course, songs and movies already work like this in the many media blogs out there. Components need to be described. Descriptions can talk about functionality, the kinds of inputs and outputs, the kinds of displays they might make, affects, effects, etc. For example, if my soft panels is some part of a DAW, the an FFT display might be a component. A compressor box might be a component. There might be a component that connects to a microphone. So, I might want to find those components and put them into my DAW panel. Then, the FFT will only operate or perhaps only display if the compressor has output frames. It might be nice to see a tagged language describing my components. But, then why? If my editor allows me to create a hole that hosts FFT displays, then I just need to find an FFT component that hooks into the hole with the right inputs, outputs, timing, etc. But, while I say that, I am still wanting to type or have a textual representation of my components or the panel's governing network. It may be easier to type and read a text representation of a Petri net, have that in the code to be the subject of a compiler. There are lots of programs that have allowed people to draw nets. But, the drawings are never terse enough. They are never easy to manage with version control - or at least the best of those tools are out my price range. Perhaps the basic principle is that it's hard to use a layout language to describe real time networks which might serve up data to displays. (think of it... most of things we do with interesting display elements requires them to have absolute position) So, that is all that I am good for today. I am going to spend some time making the vedges style text plus some other nice features. Pretty soon, I will start working on the component object. I will do that before I have vedges output or input SVG. (Also, I have yet to test rotations in vedges. It's pretty new. I made a Svelte component svelte-can-draw for drawing on a canvas. More testing has to be done on that. I have to put more work into the bounding rectangles of shapes. Should polygons only be regular?) |
Beta Was this translation helpful? Give feedback.
-
Let us talk about SSR and how to design this feature for Mikado.
Beta Was this translation helpful? Give feedback.
All reactions