In our country (China), SSR is too slow, because HTTP requests are too slow. All large companies in our country are self-developed two thread framework, similar to React Native. They do not request network resources, but update offline packages when they enter app.
I've shared too many articles about the dual threaded framework in China. If you don't mind using the translation function, you can read this article: zhuanlan.zhihu.com/p/373958625
Our country's large companies are using similar architecture, there are many open source projects:
These days I'd look at µhtml + µhtml-ssr (and perhaps JSX2TAG if jsx support is desired).
Using template based rendering seems the logical choice here as it should be easier to optimize on the server as it isn't burdened with spinning up an entire component framework just to render the HTML for a single page.
The demo has the ServiceWorker serve primarily from the Cache while updating the cache in the background. However the application could just as easily render from data stored and managed in IndexedDB (perhaps via a sqlite-worker).
That said with this architecture you'll have a substantial download hit on the first request as the entire app downloads itself after the first (server side) page has been rendered - and the application has to carefully elide parts of the pages that are preferrably absent rather than stale. But at least this setup can make use of multiple (perhaps slow) cores on the client device. Also while the ServiceWorker is a promising technology, it isn't without it's problems.
Marko fits an entirely different use case. The page(s) need to always show up-to-date information on render (stock levels, pricing, etc.) and perform well even on casual engagement (i.e. perform as much work as possible on the server while not delaying client rendering, delivering later content asynchronously or via stream without necessarily committing to building a separate HTTP-API).
In many ways as certain legacy server-side stacks look to be updated it could be more effective to adopt Marko rather than building a separate React frontend and hiding the entire server-side capability behind an HTTP-API.
Yeah this is a very unique perspective at least compared to what is being pedalled in the west. We've been told that the way to make headway on slow networks and low powered devices is ship less JavaScript not make larger bundles that offload future interaction. These messages seem really in conflict with each other and I'd love to hear more.
Both MPA and SPA architectures can leverage Service Workers and PWA for offline and cached browsing but only MPAs have the ability to ship considerably less JavaScript since they don't need to render full pages on the client on navigation.
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.
In our country (China), SSR is too slow, because HTTP requests are too slow. All large companies in our country are self-developed two thread framework, similar to React Native. They do not request network resources, but update offline packages when they enter app.
I would like to read post about that. Do you have any good links or maybe you want to write one?
I've shared too many articles about the dual threaded framework in China. If you don't mind using the translation function, you can read this article: zhuanlan.zhihu.com/p/373958625
Our country's large companies are using similar architecture, there are many open source projects:
github.com/ctripcorp/wean
gitee.com/openharmony/ace_engine_lite
github.com/openkraken/kraken
github.com/NervJS/taro
I'm an expert in this field, but the architecture behind it is quite complicated. It's similar to React Native(or Flutter), so it's hard to explain.
Thanks. I will take a look
One possible architecture is presented in
Building a multi-page PWA
Article: Beyond SPAs: alternative architectures for your PWA
SO PWA live demo
SO PWA GitHub project
The repo has been updated from using plain JavaScript Template literals to rendering with lit-html and lit-html-server.
These days I'd look at µhtml + µhtml-ssr (and perhaps JSX2TAG if jsx support is desired).
Using template based rendering seems the logical choice here as it should be easier to optimize on the server as it isn't burdened with spinning up an entire component framework just to render the HTML for a single page.
The demo has the ServiceWorker serve primarily from the Cache while updating the cache in the background. However the application could just as easily render from data stored and managed in IndexedDB (perhaps via a sqlite-worker).
That said with this architecture you'll have a substantial download hit on the first request as the entire app downloads itself after the first (server side) page has been rendered - and the application has to carefully elide parts of the pages that are preferrably absent rather than stale. But at least this setup can make use of multiple (perhaps slow) cores on the client device. Also while the ServiceWorker is a promising technology, it isn't without it's problems.
Marko fits an entirely different use case. The page(s) need to always show up-to-date information on render (stock levels, pricing, etc.) and perform well even on casual engagement (i.e. perform as much work as possible on the server while not delaying client rendering, delivering later content asynchronously or via stream without necessarily committing to building a separate HTTP-API).
In many ways as certain legacy server-side stacks look to be updated it could be more effective to adopt Marko rather than building a separate React frontend and hiding the entire server-side capability behind an HTTP-API.
I'm more interested in China view. I know what west have to say about that
The MiniApp seems to be popular in China but relies on a native host app.
Mini app components
Mini app standardization
Other mini app runtime environments
Mini app open source projects
Project structure, lifecycle, and bundling
Programming the mini app way
Applying the mini app programming principles to an example project
Concluding thoughts about mini apps from a web developer
In 2017 Ele.me (an online food delivery service platform) seems to have converted to a Vue based MPA PWA.
Yes, Miniapp is our main architecture. I am an architect. I have developed a dedicated miniapp architecture for our company(ctrip.com).
Yeah this is a very unique perspective at least compared to what is being pedalled in the west. We've been told that the way to make headway on slow networks and low powered devices is ship less JavaScript not make larger bundles that offload future interaction. These messages seem really in conflict with each other and I'd love to hear more.
Both MPA and SPA architectures can leverage Service Workers and PWA for offline and cached browsing but only MPAs have the ability to ship considerably less JavaScript since they don't need to render full pages on the client on navigation.