I've gone through and launched all 26 projects. It's impressive how fully-featured this is.
I might even start using this for some of my own projects. A wonderful thing about Common Lisp is that the code you wrote ten years ago tends to keep working forever. That might not hold true here, since this project has to interface with browsers which tend to shift like the air, but I live in hope.
Wow, I think this is quite amazing.
I'm a Delphi dev by day (I know, not many of them left). On first glance this lib looks and feels vaguely similar to Delphi, in terms of windows, events and such.
The difference though is the possibilities enabled by having it all running in Common Lisp. Dynamism, speed.. enjoyment :)
If it's actually similar to Delphi, I'm going to use it for my next project that needs a GUI. I used Delphi in the late 90s and it was one of the most productive GUI toolkits I've ever used.
Is there much Common Lisp to this framework or is it incidental and something that could be in any language? I guess I don’t mind either way.
And does this just let you do html/browser events in CL or does it have some solutions for dealing with the complexity of maintaining a correct view? I.e. is it trying to solve the problem that JavaScript is not CL, that JavaScript can’t easily access server resources, or the problem that react tries to solve?
from the blurb on the site it seems like its mostly server-side driven, sending changes to graphical objects through the web socket to a little JS stub that manipulates the DOM. at least I'm pretending that's what's going on since I do that a lot and like it as a model.
it clearly can suffer from interactivity issues, but for me its been surprisingly snappy for the kind of monitoring UIs with limited interaction that I use it for.
have done in Go, C, Rust, python, atmel assembly (and recently DDlog!)..and probably some other environments too. just need a web socket implementation. the js stub I carry around is ~200 lines and gets served off the same process
and yes - a big win is that you get to access state on the server directly instead of packaging it up, sending it across, unwrapping it, etc. oh right, you also get to do everything in your primary programming environment.
it doesn't address view maintenance specifically, but if the server is delta-based already (admittedly an assumption), then you don't have to do anything really.
i prefer justpy's approach because they work with vue on the frontend, taking advantage of all the work that has already been done on generating good browser UIs and just applying a python interface to it.
Does anyone know of a common lisp library similar to R's shiny? It provides a simple way to define the UI elements and how they intereact with the user's actions: https://shiny.rstudio.com/articles/basics.html
At some point I thought about porting the first release of shiny, which was relatively simple, and keep adding features but I realized that there is a lot of code in the javascript/browser side and I would never find my way around it.
This does look cool. I gotta wonder about the resource utilization though? I see the readme mentions the browser control is native, but it doesn't specify if the whole thing can be compiled to native code with SBCL? The manual is impressive, but I didn't see anything about compiling/packaging.
I’ve poked around the code a bit - not thoroughly, so take this with a grain of salt - and it looks like it’s all Common Lisp. There’s a very thin JavaScript shim that applies commands from the server, but that’s pretty much the only non-CL thing.
That said, it presents as a “GUI”, but it’s really more similar to Blazor or LiveView than, say, Qt or even Electron.
In the real world, where time to market basically trumps all, using the web as a presentation layer is almost a must for desktop applications because of the time and money saved.
I think I can explain that. A real GUI provides more than just visualization, otherwise you'll have to re-invent the wheel and will likely miss important platform conventions. You need support for drag & drop from and to outside the application, standard folders and standard file/folder Open and Save dialogs, command/action abstractions to implement unlimited Undo/Redo, near arbitrary keyboard shortcuts for all menu entries (which adapt to the platform conventions somehow), standard Quit, Print, Page Setup and Help menus, support for internationalization, support for platform-specific layout guidelines (spacing, default buttons, button ordering), tray icon support, support for platform-specific notification and indexing APIs, programmer access to file icons (surprisingly tricky on Linux), standard packaging and deployment, support for code signing, and so on and so forth.
Most "browser-based" applications don't even get basic keyboard shortcuts right. Only few of them are really usable and not a single one has better functionality then its native counterparts. There is a bit of a bubble around web "apps" created by a startup culture. The problem is that most of those startups die within a few years. I'm not saying that a browser-based app cannot be useful, but it's equally important to be aware that many types of applications require a real GUI. It doesn't have to be native (e.g. Qt is not "native" in the traditional sense), but it needs to be fairly complete and respect platform APIs.
There are also real common lisp gui frameworks. There's a tcl binding thing, this thing, mature qt and gtk bindings, a native common lisp solution (mcclim). Honestly I was a bit surprised when I was looking around how much there was, check awesome-cl.com
The cool idea is that you use language and environment of your choice without having to deal with any JS peculiarities. All the state is managed in whatever way is best inside your lisp code.
What sort of thing would you not hit the back button on and actually engage with, beyond reading the page, nodding your head, and moving to the next HN article?
Native, cross-platform, nice-looking GUIs seem to be getting harder and harder to make each year as native toolkits and styles continue to diverge. LispWorks and Allegro offer solutions [1,2], but they’re proprietary and definitely won’t let you do anything super slick.
GUI toolkits are no longer plain old C APIs, now we have a zoo of them in a bunch of different languages and frameworks.
How can we get back to an age where we can throw up text boxes, buttons, and canvases without the browser and without C++?
I’ve been hopeful that IUP [3] would expand support for native macOS GUIs, but it doesn’t seem like it’s happening any time soon.
> Tip for Windows WSL linux user. Create a symbolic link from wslview to xdg-open in /usr/local/bin so that run-tutorial uses the windows browser.
Oh huh, that's just a good tip in general!
I've gone through and launched all 26 projects. It's impressive how fully-featured this is.
I might even start using this for some of my own projects. A wonderful thing about Common Lisp is that the code you wrote ten years ago tends to keep working forever. That might not hold true here, since this project has to interface with browsers which tend to shift like the air, but I live in hope.
Wow, I think this is quite amazing. I'm a Delphi dev by day (I know, not many of them left). On first glance this lib looks and feels vaguely similar to Delphi, in terms of windows, events and such.
The difference though is the possibilities enabled by having it all running in Common Lisp. Dynamism, speed.. enjoyment :)
Hoping this goes well.
If it's actually similar to Delphi, I'm going to use it for my next project that needs a GUI. I used Delphi in the late 90s and it was one of the most productive GUI toolkits I've ever used.
Is there much Common Lisp to this framework or is it incidental and something that could be in any language? I guess I don’t mind either way.
And does this just let you do html/browser events in CL or does it have some solutions for dealing with the complexity of maintaining a correct view? I.e. is it trying to solve the problem that JavaScript is not CL, that JavaScript can’t easily access server resources, or the problem that react tries to solve?
from the blurb on the site it seems like its mostly server-side driven, sending changes to graphical objects through the web socket to a little JS stub that manipulates the DOM. at least I'm pretending that's what's going on since I do that a lot and like it as a model.
it clearly can suffer from interactivity issues, but for me its been surprisingly snappy for the kind of monitoring UIs with limited interaction that I use it for.
have done in Go, C, Rust, python, atmel assembly (and recently DDlog!)..and probably some other environments too. just need a web socket implementation. the js stub I carry around is ~200 lines and gets served off the same process
and yes - a big win is that you get to access state on the server directly instead of packaging it up, sending it across, unwrapping it, etc. oh right, you also get to do everything in your primary programming environment.
it doesn't address view maintenance specifically, but if the server is delta-based already (admittedly an assumption), then you don't have to do anything really.
along similar lines, there's justpy for python: https://justpy.io/
i prefer justpy's approach because they work with vue on the frontend, taking advantage of all the work that has already been done on generating good browser UIs and just applying a python interface to it.
Neat, reminds me of an old Java framework that did this. Anvil much later.
How are the leaky abstractions and performance?
only tried it for a couple of toy experiments, so i don't really know about how it performs in practice; i just like the idea behind it.
I also like the idea a lot. There is another approach, similar to LiveView taken in [1]. There is direct 1-1 matching between HTML and python objects.
Used it to great success to create interactive web UI completely in Python.
[1] https://lona-web.org
Interesting.
Does anyone know of a common lisp library similar to R's shiny? It provides a simple way to define the UI elements and how they intereact with the user's actions: https://shiny.rstudio.com/articles/basics.html
At some point I thought about porting the first release of shiny, which was relatively simple, and keep adding features but I realized that there is a lot of code in the javascript/browser side and I would never find my way around it.
The most relevant thing I found was this clojure(script) reactive web framework from Kenny Tilton: https://github.com/kennytilton/matrix
This does look cool. I gotta wonder about the resource utilization though? I see the readme mentions the browser control is native, but it doesn't specify if the whole thing can be compiled to native code with SBCL? The manual is impressive, but I didn't see anything about compiling/packaging.
I’ve poked around the code a bit - not thoroughly, so take this with a grain of salt - and it looks like it’s all Common Lisp. There’s a very thin JavaScript shim that applies commands from the server, but that’s pretty much the only non-CL thing.
That said, it presents as a “GUI”, but it’s really more similar to Blazor or LiveView than, say, Qt or even Electron.
Interesting, that part really does seem novel.
Is this just one more Electron but with Lisp? It seems to require web-browser, thus not a real GUI framework.
In the real world, where time to market basically trumps all, using the web as a presentation layer is almost a must for desktop applications because of the time and money saved.
Isn’t a GUI framework anything that lets you make… GUIs?
What’s a “real” GUI framework? Maybe you mean one that uses the provided operating system’s APIs directly, sometimes called “native GUIs”.
I think I can explain that. A real GUI provides more than just visualization, otherwise you'll have to re-invent the wheel and will likely miss important platform conventions. You need support for drag & drop from and to outside the application, standard folders and standard file/folder Open and Save dialogs, command/action abstractions to implement unlimited Undo/Redo, near arbitrary keyboard shortcuts for all menu entries (which adapt to the platform conventions somehow), standard Quit, Print, Page Setup and Help menus, support for internationalization, support for platform-specific layout guidelines (spacing, default buttons, button ordering), tray icon support, support for platform-specific notification and indexing APIs, programmer access to file icons (surprisingly tricky on Linux), standard packaging and deployment, support for code signing, and so on and so forth.
Most "browser-based" applications don't even get basic keyboard shortcuts right. Only few of them are really usable and not a single one has better functionality then its native counterparts. There is a bit of a bubble around web "apps" created by a startup culture. The problem is that most of those startups die within a few years. I'm not saying that a browser-based app cannot be useful, but it's equally important to be aware that many types of applications require a real GUI. It doesn't have to be native (e.g. Qt is not "native" in the traditional sense), but it needs to be fairly complete and respect platform APIs.
There are also real common lisp gui frameworks. There's a tcl binding thing, this thing, mature qt and gtk bindings, a native common lisp solution (mcclim). Honestly I was a bit surprised when I was looking around how much there was, check awesome-cl.com
This looks very cool! I can smell some smalltalk wafting through the veneer (this is a good thing!).
The cool idea is that you use language and environment of your choice without having to deal with any JS peculiarities. All the state is managed in whatever way is best inside your lisp code.
Not really suitable for an embedded device with lots of video/graphics components like game consoles.
It look very retro in the screnshots - like the visual style of a 90s website crossed with windows 95.
Such a pity: it requires a web browser.
I'm not saying it's not useful, but I swiftly pressed the back button when I read "uses web technology."
What sort of thing would you not hit the back button on and actually engage with, beyond reading the page, nodding your head, and moving to the next HN article?
Native, cross-platform, nice-looking GUIs seem to be getting harder and harder to make each year as native toolkits and styles continue to diverge. LispWorks and Allegro offer solutions [1,2], but they’re proprietary and definitely won’t let you do anything super slick.
GUI toolkits are no longer plain old C APIs, now we have a zoo of them in a bunch of different languages and frameworks.
How can we get back to an age where we can throw up text boxes, buttons, and canvases without the browser and without C++?
I’ve been hopeful that IUP [3] would expand support for native macOS GUIs, but it doesn’t seem like it’s happening any time soon.
[1] LispWorks CAPI http://www.lispworks.com/products/capi.html
[2] https://franz.com/products/allegrocl/acl_gui_tools.lhtml
[3] https://www.tecgraf.puc-rio.br/iup/
There are two promising native frameworks - Revery[1][2] and Sixtyfps[3][4].
[1] https://www.outrunlabs.com/revery/
[2] https://github.com/revery-ui/revery
[3] https://sixtyfps.io/
[4] https://github.com/sixtyfpsui/sixtyfps
You must be a gopher guy
It's more of a Web framework than an electron thing if that's what you think