Battle-Testing Lynx at Allegro

I thought it’s about Lynx Browser, a text based browser that lives in terminal

We must be really running out of names in the tech space:

- https://franz.com/products/allegro-common-lisp/

- https://lynx.invisible-island.net/

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.

i thought this was about allegro common lisp and lynx browser. It's about something else completely. That's not cool.

That name is taken, especially for anything web related.

> Delivery Methods screen

The one that recently kept "accidentally" switching pick-up points? I sure hope it was not caused by Lynx, just shitty business requirements.

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.

Ale was boli ten InPost, nawet na przykładzie wciskacie te swoje OneBoxy.