DEV Community

loading...

Discussion on: What has the Marko Team Been Doing all These Years?

Collapse
132 profile image
Yisar

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.

Collapse
stereobooster profile image
stereobooster

I would like to read post about that. Do you have any good links or maybe you want to write one?

Collapse
132 profile image
Yisar

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.

Thread Thread
stereobooster profile image
stereobooster

Thanks. I will take a look

Collapse
peerreynders profile image
peerreynders

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.

Thread Thread
stereobooster profile image
stereobooster

I'm more interested in China view. I know what west have to say about that

Thread Thread
132 profile image
Yisar

Yes, Miniapp is our main architecture. I am an architect. I have developed a dedicated miniapp architecture for our company(ctrip.com).

Collapse
ryansolid profile image
Ryan Carniato Author • Edited

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.