Ceramic – Turn Lisp web applications into desktop apps | Hacker News Reader

Ceramic – Turn Lisp web applications into desktop apps

ceramic.github.io

176 pointsblue173 comments

This certainly looks interesting, but it might help generate interest if the landing page addressed two questions: what is the application size overhead (how large is a hello world app) and what is the app startup overhead.

I used to make standalone apps from SBCL Common Lisp, and they were not too large (even though SBCL has no tree shaker unused code remover).

I agree final app size would be a further selling point for me too. I am glad to see Lisp, CL, in the headlines other than clojure. I guess the ubiquity of JS has lead to the possibility Ceramic offers due to Electron. Slightly, OT, but I am reading 'The Handbook of Neuroevolution Through Erlang', and I am waiting to learn enough Erlang to jump over to using LFE (Lisp flavored Erlang) mid-book. @mark_l_watson, I started with your 'Common Lisp Modules:..' book, and now I am hooked on AI, NN and Lisp. Thanks!

Rob

Thanks! Richard Stallman asked me several years ago about releasing my old Lisp book under a FSF documentation license, but I can't find my old manuscript files. Maybe I will ask my wife to re-type it all.

What about crowdsourcing the job? I'm sure people would be willing to help.

I am glad to see Lisp, CL, in the headlines other than clojure.

We've had a string of really cool lisp projects this year, web frameworks, implementations, web servers, libraries, etc. Couple that with Edi Weitz's upcoming book, it's as exiting to be a lisper now as ever. Hack gloriously and eat your parenthesis for breakfast my lispy friends :)

wow that's an expensive book! even the ebook is $150

Which? Mark's book or the Erlang book I cited above?

Mark's book can be found used for $3.00 on Amazon.

Certainly not my book :-)

Edi's upcoming book on Amazon is listed as $56, due December 2015. I will probably buy a copy when it ships.

EDIT: I just pre ordered a copy on Amazon to lock in that price.

Which book are you referring to here?

Edi Weitz's "Common Lisp Recipes: A Problem-Solution Approach", listed on Amazon for December 2015.

Thanks for the $3 Amazon reference. I only have one copy of my (very) old book, and just ordered a used copy so I have a spare. I was surprised to see that Springer Verlag still sells it new - I thought that it was out of print a long time ago.

The Erlang book direct from publisher has to be one of the highest ebook prices I've ever seen.

This doesn't include ceramic, but:

I did a benchmark of executable image sizes and startup times for the popular open-source implementations[1] it depends on cl-launch since asdf:program-op was still experimental at the time.

A few points I discovered:

SBCL and CCL are neck-on-neck for startup time; very slightly longer than a hello-world in python, but much faster than any python script that has to do any significant importing.

SBCL has by far the largest image size overhead ~80MB for "hello world". It has an option to compress the image with zlib, but that is a big impact on image startup time. I did a proof of concept of an lz4hc image compressor, and it made for acceptable startup times while taking the overhead down to under 30MB. Someone else turned this into a real patch, and it is waiting to be merged.

CCL's image size is about 1/2 that of sbcl.

ECL has, by far, the smallest image size, even including the DLL (3.2MB for a lisp runtime is tiny!). However, it has a startup time that is two orders of magnitude higher than sbcl/ccl

clisp was ind the middle of things; executable image was about double that of ecl, it's startup performance is better.

1: https://github.com/jasom/image-bench

Thanks for the info on CCL's image size - that makes CCL worth switching to for bundling applications, but your SBCL patch sounds even better. That said, it has been a number of years since I sold a Lisp application - but still good to know!

The hello world app (bundle) is like 250 megabytes. Half of that is the Electron release, the rest is the Lisp image, whose size you can cut significantly using core compression (this isn't enabled, I'm looking into doing it through Buildapp without it crashing if it's not available).

Yikes. One would think that could be pared down by a significant amount: Node is only ~40mb installed, and the various webkit browsers aren't much bigger than that.

See my other comment about implementations' core image sizes. SBCL is the worst offender for runtime space overhead[1], and it's CLOS implementation is heavily biased towards the "space" side of the time/space tradeoff, and a brief look at the implementation of this shows a lot of CLOS usage. I would expect that delivering with a different implementation would show a significant reduction in size.

Barring that, most GUI executables are fairly insensitive to startup time, so SBCL core compression would the lisp image down by a factor of 4:1.

Lastly, you can always just not worry about it:

    du -s /Applications/*.app | sh ~/avg.sh
    Total: 28529040; Count: 126; Mean: 226420; Median: 56752; Min: 8; Max: 6132408

1: Note that SBCL generates the best code of any Free lisp implementation, and makes it the easiest to tune your code for better performance. As disk space is cheap, it's what I use for most of my applications.

Hey, eudox! We wanted to ask you, but we did not see you on the Reddit thread. Someone asked:

https://www.reddit.com/r/Common_Lisp/comments/3d3oqh/ceramic...

The gist is: for the Javascript parts on your site, any plans to integrate Parenscript for the full Lisp experience?

Thanks for your work. I saw again it was posted before today on /r/lisp and /r/programming, but I missed it.

Thanks!

The only JavaScript is in the Electron process, and it's fixed, ie you don't have to touch it. You interact with it through CLOS methods on window objects.

Other than that any JavaScript is optional, you write it yourself (using whatever source language, e.g. ParenScript) and ship it with your app as a resource.

Can we PLEASE just work on writing a decent native GUI library for lisp? Making QT work better? Something?

You are more than welcome to work on it and submit it to HN. However, please refrain from being gratuitously negative in this forum; someone just spent a lot of time and effort into making something, and your comment - which took less than a minute to write - is purely negative and adds nothing to the discussion.

I wish someone forced me to read this before making any comment...

It adds much more to discussion than your comment, TBH.

It is entirely legitimate to point out that somebody the submission is going in the wrong direction, yes they spend a bunch of time on it, but that is sunk cost and better they not waste any more.

GP was to the point, but not mean and added something to the discussion (even if you disagree with it). You, however, were rude.

Yeah, you're right. I apologize.

I can't see it ever happening. I first started learning Lisp in 2006. Some of the most common messages on Lisp forums were things like "what GUI library should I use?", "why is there no standard GUI?", "this library works but it's incomplete and looks abandoned," along with calls for the Common Lisp community to standardize around one GUI library.

If the situation hasn't gotten better since then, well... what are people waiting for?

https://common-lisp.net/project/commonqt/ works well, https://github.com/Shinmera/qtools is an attempt to make it work better.

Also https://github.com/robert-strandh/McCLIM looks maintained but if it's anything like what it was a couple of years when I last looked at it, it could use some contributors :)

There are also at least 3 GTK+ bindings that I've seen around.

http://cliki.net/GUI lists 31 GUI libraries. We have enough for every day of the month :)

Commercial Lisps have them.

http://docs.racket-lang.org/gui/ Racket has GUI libraries

Why is this downvoted? I'm just learning Racket and hoped that this was a good option. Is it not?

It is a good option, but not on topic of CL GUI libraries.

Let me address this and the comments asking 'why' below:

There are GUI libraries for Common Lisp. CommonQt+qtools is essentially the gold standard, and everyone seeking to make a GUI application should use it.

I like the web, it lets me design applications with a precision native GUI tools don't have. And you can make an app that runs on the localhost and you can access through the browser: I do this for some applications I've written.

The problem is distribution: most users won't really know what's going on when they run an executable and it opens a terminal window and a browser window to some weird URL called 'localhost:41000'.

So I wrote this.

LispWorks has CAPI which is an incredible cross-platform GUI library which compiles down to the native GUI tookit of the host. It's fantastic!

http://www.lispworks.com/documentation/lw70/CAPI-M/html/capi...

I think we can all agree that LispWorks is really, really expensive.

Of course you can! We would welcome your effort very much.

CommonQT works pretty darn good. qtools makes it work better. Ask Shinmera if you want to help him.

Heh weird. 15 years ago my job was porting apps the other way. Turning lisp desktop apps into lisp web apps with cl-http. Of course that was hard. Turning a web app into a desktop app is just a matter of embedding a browser. The other way around requires work.

This is a really cool/interesting way of packaging an entire app. I never even thought to have a CL backend in a separate process that you could communicate with via HTTP. I've done the same thing (browser, embedded lisp) using nanomsg, but this seems a lot more straightforward.

Good work =]! I also really need to look more into Electron. I've only used node-webkit (before it was NW.js).

If a given language you enjoy can run a web server, you could potentially take advantage of Electron. This of course includes Go, D, C#, Java, Clojure and plenty of other languages everyone loves. Not telling everyone to do this for every type of application though, but it is definitely not impossible to approach making a desktop application with web technologies.

Is there any reason that this wouldn't be able to work with another language? If the interface is an HTTP port, it seems like this isn't necessarily tied to Common Lisp.

Yes, you could rebuild the project in any language if you wanted.

Ceramic opens an HTTP server (in lisp), starts electron (using a shell command), communicates to the electron process via streaming, then electron sends back HTTP requests to the lisp process.

However this is tied to Common Lisp because the containing project itself is built in Common Lisp and can't be switched out without completely rebuilding in another language.

The links to Electron and Atom point to this page. Can someone provide correct links please?

http://electron.atom.io/

I just had a pull request accepted so the correct links now show on the homepage.

Why don't use haxe and openfl/nme and transpiling lisp code in haxe?

What do you reckon the benefits would be over this solution?

How much work it is to extend Electron to create the same thing but for a different language i.e. "Turn Haskell/Python web applications into native desktop apps"?

Along the same lines - how hard would it be to let Electron create more native widgets instead of just Window, Menu and BrowserWindow.

I'd be stoked if something like React Native (or indeed, React Native itself) landed for desktop development.

I guess I'm not alone in thinking so: https://github.com/facebook/react-native/issues/247

A "app" running in a webview on a desktop is NOT "native". A Swing app is not native nevermind these web apps running in chrome.

You'll be sad to known a ton of OS X and Windows applications these days are just running in web views. Heck, even a lot of iOS apps are partially/mostly UIWebViews.

Can you give some examples?. (genuinely curious btw).

Isn't the Atom text editor mainly a Chromium web view running on the desktop?

Yes, and many people don't think of it as native for that reason.

The colloquial definition of a native desktop application is an application that runs from a binary on your system. So yes, most people DO think of these as native applications.

It's beyond that. I also uses the native APIs to create the user interface.

Slack's desktop app is a web view. The iOS app is native.

I think the wells fargo banking app on the phone is not native. The At&t one doesn't feel like it. Usually there's something different about the controls and interactions that make it not feel native. Sometimes there's a dead giveaway like being able to double tap and accidentally zoom in just like in mobile Safari.

Yep! A common pattern is for the navigation to be written in the native language to take advantage of faster/smoother animations and all dynamic content is inside of web views.

Spotify and Steam are. Although Steam doesn't really pull it off all that well.

Neither does Spotify. Visually it's out of place on every platform, and performance on computers older than few years has become unacceptable IMHO.

Spotify on Linux: clicking on things often feels slightly janky and laggy. How fitting!

And the spacebar will 80% of the time page down rather than pause the music, something which sounds minor but which makes the user experience 50% more annoying for me. Do most people even use spacebar to page down in normal webpages!?

iTunes to a large extent is a wrapped WebView

> You'll be sad to known

It wouldn't be so sad if it wasn't so noticeable.

A native app is one you download and execute on your computer. In reality it doesn't matter much what gui toolkit you write it in, there is nearly always going to be some xml and styling involved - GTK is native on Ubuntu (I hope you will grant me that), but programs written in it typically uses glade files to design the gui and load and bind event handlers at runtime. Glade is XML.

.net uses the native win32 gui toolkit - but you typically build it WPF, which is XML, styled with XML.

On mac? plists - which is you guess it XML (I have no idea what, if anything, you style a mac app with).

So basically the three biggest platforms use XML to bind their guis with - and there isn't much difference between XML and HTML. Granted when you design XML for guis it tends to be nicer than if you wrangle HTML into that role but this is a programmer, not a user, issue.

That's a nonsense argument. There's a world of difference between using the platform's native framework and controls (which may be instantiated from an XML file) versus a single WebView which contains the entire app.

Saying "HTML is nearly XML, therefore HTML is native" is akin to saying "Vietnamese is written using the Latin alphabet, hence it's basically the same as English".

The "native" part of native app doesn't mean machine code. It means that it is native to, i.e. feels like it naturally came from, the host operating system. It uses its APIs, conventions, UI components, event queues, etc.

as JayVanguard already pointed out native means another thing. but putting that aside.

You are confusing what HTML and XML are if you think they are similar. XML is a way to encode data, validate it conforms to a schema, query it, etc. HTML is more than the surface syntax. It includes an schema and semantics (the DOM, the CSS OM, the boxing model, etc). Using XML as a declarative layer on top of their UI, as android does, does not make it similar to writing HTML because of the completely different semantics associated with it.

Android takes all the xml layouts and compile them and expose them through the R(esource) class.

I see more than one person on this thread who thinks native means "runs native machine code" and more than one person who thinks it means "looks like it was built with the native GUI library" so the term is ambiguous. Before iOS app store, I think it was more common to mean the former, so it may be related to that.

The browser is native code, the app is compiled to native machine code. There are no virtual machines involved, except the JS VM on the browser (and this doesn't need JS).

So it's native at least along those lines.

That isn't what people mean when they say native.

Right, when people say native, they talk about connecting directly with the OS-specific UI fundamentals. An application is "native" not by virtue of its execution environment, but by virtue of the UI primitives. That's why people talk about "native look and feel".

What people mean when they say native depends on what people you're talking about.

I agree. Using Electron on all of these desktop application "frameworks" keeps seeming like throwing a supertanker at a job when someone asked for a tugboat. I feel like this will only continue to bloat so many applications further, and will make writing (and refactoring) GUI applications more difficult.

Reply on news.ycombinator.com