At Builder.io, we empower non-developers to build and edit blazing fast sites with a powerful visual editor. One of the cool things about our visua...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for sharing this! I love the concept!
So many questions, and I look forward to the answers in your future posts.
If I follow you, it renders server side, and you're saying it delivers that same HTML to the client. Then the javascript lazy loads after the TTI. Is that right?
Are you saying that the HTML that loads is the entire app's HTML or just the single page navigation you are on (I assume the latter, right)?
Once on the browser, is it truly interactive if the javascript is now being lazy loaded? Would some of the javascript possibly be delivered and ready after the HTML is painted?
Thanks again for sharing!
Yes, you fallow right. Play with the demo here: stackblitz.com/edit/qwik-todo-demo Notice how little JS gets downloaded, and how JS keeps getting downloaded as you interact with the page.
thanks!
What I don’t get it as how this would work on mobile 4G connection.
Yes the page would be available quicker but trying to lazy load tiny fragments of JS for each action as they are needed is surely going to hurt performance if you have a 500ms round trip time?
Maybe you have accounted for this so I look forward to the future posts.
Great question, a lot of people ask that. The server can keep track of what are common bahaviors users do on site and than can add a pre-fetch command to sart downloading (but not executing) the JS before you need it based on what the user is most likely to interact with.
Sounds like an interesting way to account for this, I obviously only grasp the concept at the moment so maybe I haven't quite got it based on just a simple todo list but what happens with a complex application?
If you preload say 50+ tiny JS snippets that is just going to clog even a preload strategy up?
Also look forward to seeing what a server considers "most likely" to be interacted with as that feels like something that is prone to issues.
On that line of thought one last question is if I interact with something and the script hasn't arrived yet for whatever reason, does it remember the command I entered ready for when the script is available or is that action just lost?
Prime example would be a spotty connection, I scroll the page to a contact form, start filling my name in but the validation is still lost in the ether, then I move to the next field and the validation finally loads in, will it suddenly validate the field I have just left? Would the developer have to account for this in the way they develop code (by not using
.blur()etc.)Like I said it is a really interesting concept (and the fact it focuses on HTML first is a big plus in my book) but I am just trying to understand how the "streaming JS" side of it works (for want of a better term for it!).
That implies, if some users do the uncommon behaviors (something not predicted by the server), then such users would experience the website to be slower. Am I right?
Fascinating idea. Really interested to see where this goes. I feel like this is the natural next step in the evolution of web frameworks. Stoked to play around with this.
Sadly it does not support firefox yet
For me that's a no go for now
Looks really interesting, can't wait to try it out. If you need beta testers you can put my name on that list 😉
Svelte (with Elder.js) or Astro (both using pure statically generated files + "islands of content" that only load the JS you need for that specific area) solve that issue in a similar fashion, don't they?
Sort of. There it is all about identifying the entry points. The components you want to render and they act as islands. Whereas Qwik simply breaks apart all components and then only ships the ones that you interact with on demand.
This lets you write your whole app like a single continuous app. You aren't thinking islands and it just happens that the code loads as needed. Like in the Todo MVC example. Realistically something like Astro or Elder would ship a Todo widget component. The state is all linked. If someone tried to remove a row you would need the parent to be present. With Qwik you could pull them in separately as needed.
So in practice it probably won't be that big of a difference between the two in what gets shipped and when for low interactivity pages. Unlike libraries that seek to make Islands and manually breaking things up like Elder or Astro, Qwik is more like Marko where the creation of these Islands are basically automated. You get to write your app as if it were a typical full page framework and leave the rest up to machination.
Wow. Played around with the stackblitz example. This is cool.
Looing forward to further posts and exploring it further to see how this seems suited for enterprise apps.
This looks very promising. Not only for Qwik itself, but I can also see other frameworks possibly support resumability. I will definitely follow this.
Hello, Angular Photon
Would you please explain why markDirty is needed? TSX with side effects?
It is an interesting concept. I will read more about it
I am in love with this concept.
Can you demo wrapping this up with Capacitor for a mobile (universal) app?