After more than 6 years of building and running our own Server-Driven UI at Allegro, we decided it was time to ask: what’s next?
With all the hype around LynxJS last year, we took a closer look to see whether it really lives up to expectations. In this post, we share our experience, lessons learned, and thoughts on using it in a real production environment.
If you’re interested in mobile architecture, SDUI, React or cross-platform development.
Interesting read. This mirrors a lot of what we’ve seen with server-driven UI aging into something more complex than it was designed for. The lack of client-side JS tends to hurt once “content” screens start growing real interaction.
Lynx sounds promising if it really avoids the usual WebView tradeoffs while still letting teams reuse React knowledge. Curious how it compares in practice once screens get state-heavy or animation-heavy, and how painful debugging is across iOS/Android/Web.
11 comments
[ 4.0 ms ] story [ 32.7 ms ] threadWith all the hype around LynxJS last year, we took a closer look to see whether it really lives up to expectations. In this post, we share our experience, lessons learned, and thoughts on using it in a real production environment.
If you’re interested in mobile architecture, SDUI, React or cross-platform development.
- https://franz.com/products/allegro-common-lisp/
- https://lynx.invisible-island.net/
The one that recently kept "accidentally" switching pick-up points? I sure hope it was not caused by Lynx, just shitty business requirements.
Lynx sounds promising if it really avoids the usual WebView tradeoffs while still letting teams reuse React knowledge. Curious how it compares in practice once screens get state-heavy or animation-heavy, and how painful debugging is across iOS/Android/Web.