The whole idea of the "document web" versus the "application web" is completely silly to me.
Fair enough but as a page takes on more and more interactivity it becomes more and more "app like" and even though in 2014 Scott Jensen described applications as "technology tillers" with reference to the web a lot of the industry is continuing to chase the "rich user interface" experience (also [1]).
In my judgement it was the often reported jQuery spaghetti code that resulted from sprinkling too much interactivity on a page that pushed many developers to adopt pure client side rendering with the hope that it should be much easier to maintain given that the DOM is now entirely managed in one place - the client - rather than always having to go back to the server code to make the necessary adjustments to the various templates. So it could be argued the move to pure-CSR marked the beginning of the "application web".
no reason this or anything like it should be mainstreamed.
I don't think anything is being mainstreamed here. It's a development of interest against the background of Paul Lewis's observation six years ago and a change in direction from the status quo. If you look into the tweet thread:
"Paul, any examples of frameworks that actually play nicely with PR+B?" [2]
"No, and that’s my issue. Most (if not all) seem to expect all the JS up front before giving the user anything" [3]
In an earlier blog (2015) Paul Lewis aimed squarely at React to state: developer ergonomics should be less important than our users’ needs.
That message fell largely on deaf ears as evidenced by the continually growing JS payloads delivered to clients. "The network will save us" and "client devices are becoming more performant every year" are the typical excuses despite evidence that networks are at risk of becoming over subscribed and large numbers of less performant devices are entering the market while even flag ship devices are architected with a larger number of small, low power cores when the current generation of web technology requires peak single thread performance.
Back in 2016 there were some suggestions that FaceBook BigPipe and Drupal BigPipe were examples of "Progressive Rendering and Bootstrapping". (Perhaps Marko's introduction of async fragments in 2014 should at least count as "progressive rendering".)
So while Qwik emphasizes "Resumability" and "Progressive Hydration" it seems to embrace the "Progressive Rendering and Bootstrapping" approach which would likely be impossible to implement with the current generation of mainstream frameworks (Miško Hevery introduced the concepts in 2019). Interestingly during Qwik's development developer experience was only problem/priority #9 - echoing "developer ergonomics should be less important than our users’ needs".
I don't know why the trend is to find complex solutions to simple problems.
Now this is complete speculation on my part but Qwik is being developed at Builder.io - and they feature low-code services. Reportedly services like Wix, Squarespace and Webflow tend to result in fairly hefty JS payloads (likely requiring developer/engineering intervention to correct, defeating the "low-code" concept) which harms user experience. Qwik (or some derivative) could be the foundation for a low-code web site builder that has a performance advantage over those established services.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Fair enough but as a page takes on more and more interactivity it becomes more and more "app like" and even though in 2014 Scott Jensen described applications as "technology tillers" with reference to the web a lot of the industry is continuing to chase the "rich user interface" experience (also [1]).
In my judgement it was the often reported jQuery spaghetti code that resulted from sprinkling too much interactivity on a page that pushed many developers to adopt pure client side rendering with the hope that it should be much easier to maintain given that the DOM is now entirely managed in one place - the client - rather than always having to go back to the server code to make the necessary adjustments to the various templates. So it could be argued the move to pure-CSR marked the beginning of the "application web".
I don't think anything is being mainstreamed here. It's a development of interest against the background of Paul Lewis's observation six years ago and a change in direction from the status quo. If you look into the tweet thread:
"Paul, any examples of frameworks that actually play nicely with PR+B?" [2]
"No, and that’s my issue. Most (if not all) seem to expect all the JS up front before giving the user anything" [3]
In an earlier blog (2015) Paul Lewis aimed squarely at React to state: developer ergonomics should be less important than our users’ needs.
That message fell largely on deaf ears as evidenced by the continually growing JS payloads delivered to clients. "The network will save us" and "client devices are becoming more performant every year" are the typical excuses despite evidence that networks are at risk of becoming over subscribed and large numbers of less performant devices are entering the market while even flag ship devices are architected with a larger number of small, low power cores when the current generation of web technology requires peak single thread performance.
Back in 2016 there were some suggestions that FaceBook BigPipe and Drupal BigPipe were examples of "Progressive Rendering and Bootstrapping". (Perhaps Marko's introduction of async fragments in 2014 should at least count as "progressive rendering".)
So while Qwik emphasizes "Resumability" and "Progressive Hydration" it seems to embrace the "Progressive Rendering and Bootstrapping" approach which would likely be impossible to implement with the current generation of mainstream frameworks (Miško Hevery introduced the concepts in 2019). Interestingly during Qwik's development developer experience was only problem/priority #9 - echoing "developer ergonomics should be less important than our users’ needs".
Now this is complete speculation on my part but Qwik is being developed at Builder.io - and they feature low-code services. Reportedly services like Wix, Squarespace and Webflow tend to result in fairly hefty JS payloads (likely requiring developer/engineering intervention to correct, defeating the "low-code" concept) which harms user experience. Qwik (or some derivative) could be the foundation for a low-code web site builder that has a performance advantage over those established services.