There's also Allegro[1] (the graphics/gaming library). I was confused on why the old-school gaming library was interested in testing the old-school terminal browser
The 'who was there first' game doesn't make sense because neither of them created this term. One is older, the other is a company worth over seven billion euros and one of the biggest marketplaces in Europe. I'd argue that it has wider brand recognition because of that, but ultimately it all comes down to your background. I'd expect the number of people in the US who heard about it in context of the game library to be larger than for Allegro.eu and at the same time smaller than the original meaning.
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.
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.
I'm considering something similar and Lynx did seem interesting. Thanks to your article I think it is indeed a bit too early.
Another option looks like Tauri v2[0]. It also promises iOS, Android, and Web support (as well as a desktop application). The core is Rust which may or may not have the same adoption issues you saw for C++.
I haven't given it a try yet though but you may find it interesting.
The background story is that Allegro defaults the selection of infrastructure from their competitors to their own, even if the user uses competitor all the time. Sometimes the user forgets to check, and it will result in using Allegro's infrastructure even if the user didn't want it.
I thought it’s about Lynx Browser, a text based browser that lives in terminal
same
We must be really running out of names in the tech space:
- https://franz.com/products/allegro-common-lisp/
- https://lynx.invisible-island.net/
There's also Allegro[1] (the graphics/gaming library). I was confused on why the old-school gaming library was interested in testing the old-school terminal browser
[1]: https://liballeg.org/
In Poland Allegro.pl is much more recognizable than the Allegro graphic library. It exists for ~25 years already.
The game library first released in 1990, 36 years ago. (Most recent release January 2026.)
https://en.wikipedia.org/wiki/Allegro_(software_library)
The 'who was there first' game doesn't make sense because neither of them created this term. One is older, the other is a company worth over seven billion euros and one of the biggest marketplaces in Europe. I'd argue that it has wider brand recognition because of that, but ultimately it all comes down to your background. I'd expect the number of people in the US who heard about it in context of the game library to be larger than for Allegro.eu and at the same time smaller than the original meaning.
Well, true, but it was a small Atari ST library back then. For example, first commit to SourceForge SVN was done in year 2000.
I mean it wasn't popular back then at all.
That name is taken, especially for anything web related.
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.
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.
I'm considering something similar and Lynx did seem interesting. Thanks to your article I think it is indeed a bit too early.
Another option looks like Tauri v2[0]. It also promises iOS, Android, and Web support (as well as a desktop application). The core is Rust which may or may not have the same adoption issues you saw for C++.
I haven't given it a try yet though but you may find it interesting.
[0] https://v2.tauri.app/
Seems especially cruel to reuse "lynx" for a fancy graphics project given the real lynx is focused on text.
> 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.
Ale was boli ten InPost, nawet na przykładzie wciskacie te swoje OneBoxy.
What's the problem here? It was obvious that at a certain scale, they'll want to have their own infra for shipping.
The background story is that Allegro defaults the selection of infrastructure from their competitors to their own, even if the user uses competitor all the time. Sometimes the user forgets to check, and it will result in using Allegro's infrastructure even if the user didn't want it.
It's called "a dark pattern".
Right, now I get what you're referring to.
> Sometimes the user forgets to check, and it will result in using Allegro's infrastructure even if the user didn't want it.
Strasznie denerwujące, też mnie to spotkało.
dziwnie sie czyta komentarz po polsku na takiej stronie jak ta
Na początku próbowałem czytać to po angielsku i czytam "Ale był.." i potem nic nie miało już sensu haha
Especially when some of the responses are in English :D