All frameworks need to keep state. Frameworks build up the state by executing the templates. Most frameworks keep this state in the JavaScript heap...
For further actions, you may consider blocking this person and/or reporting abuse
This may be fast, but the developer experience would be hell. I can't imagine how frustrating this would be to scale.
I don't think dev-exp NEEDS to be hell. Here is where the fromework comes in and helps you do the right thing and makes your dev-exp easy. Sounds like a perfect article to write next.
I would love to see it! I have found that the benefits of improving the developer experience often outweigh the performance reductions they portend. A world with both would be nice!
Every state variable is inside the html? What about circular dependencies? What about functions, observables? They can’t be serialized.
Maybe I don't understand it clearly, but if I have some meta info about the items/devices/users, and this meta info size is 5 Mb - will it be pushed to the HTML just to save the state? Are there limits for attributes content length?
querySelectorAllto find the components/listeners.Yes it involves a different way of thinking about the problem. I think the big point of these articles is that the industry is doing what is easy and as a result it ends up in hot water on TTI. We need to think about what is needed and adjust our development processes accordingly. Yes different is not trivial at first, but it does not have to be hard if you have the right guidance from the framework.
By observables I mean functions. I’ve re-read the post but still can’t find how they can be serialized. Please don't take it as criticism, I’m just trying to get the idea.
Right now I prefer to keep the state inside the rxjs observables, and if Qwik wants to “imprint” every state change into HTML, then all of these functions should be somehow serialized - I have no idea how to do this, but I admit that I don't know every trick existing.
Maybe Qwik is not going to save absolutely everything, maybe it should be the only amount of data, needed to “resurrect” the app from HTML attributes. Or maybe Qwik is not going to save the state on every change.
In the first case, it raises the question, how it will affect the performance if we are going to save-restore the state on every user action (or app internal event).
In the second case, the framework should be extremely smart to determine what state is important and what can be ignored. Or it should be controlled by the programmer.
Those are all excellent questions but explanation would require more text than a response here. Will follow up with more blog posts where we will explore this. The short answer is that the framework keeps caches to make this fast, but caches are done in a way so that loosing them is not an issue for functionality, just performance.
It's clearly nice to see it from this perspective. Most devs only think about their confort in programming. Here it is still easy to understand and use really simple principles.
But what about aspx. it looks like the aspx way of handling fullstate in the dom. The difference with aspx is that everything was sent back to the server, but the principles seems similar. While this one seems more human readable.
What about astro, it is bring your own framework, or amp
Yes astro is an interesting approach and can get you part of the way there. The issue is that as long as you retain monolithic way of thinking about the problem your options will be limited. If you are willing to re-think everything you can go a lot further. So think of astro as an improvment on the way to the ultimate speed.
this page should not be a framework explanation but a 101 on how the web works.
It looks very weird, the serialization is through HTML, otherwise the HTML will be messy.