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
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.
3 replies →
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/
> 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.
Seems especially cruel to reuse "lynx" for a fancy graphics project given the real lynx is focused on text.
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".
2 replies →
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
1 reply →