[Openmcl-devel] prompt-for-file (embarrassing question)

[Clint Moore]

On Thu, Mar 30, 2017 at 3:12 PM Tord Romstad <tord.romstad at gmail.com> wrote:

> On Thu, Mar 30, 2017 at 8:09 PM, R. Matthew Emerson <rme at acm.org> wrote:
>
>
> I think native is the only way to go for user interfaces.  Applications
> written using  cross-platform toolkits like Qt, for example, never quite
> look or feel right.
>
>
> I used to feel the same way, but after seeing the tremendous popularity of
> tools like Atom, VS Code, and Light Table, I am not so sure.
>

  Finally, I can comment on something with a bit of authority in this
thread full of people I look up to!  A banner day, indeed.

We shipped an application written against Electron using CL - specifically
SBCL.  Rather than a two page rant about it, I'll just post some
highlights.  Of course this is all my opinion and ymmv etc.

- We eliminated a lot of complexity with regard to JS and callback hell by
generating as much of the Javascript as we could with Parenscript.  While
the benefits of this approach to help manage the application's complexity
are apparent enough in the initial development, it's especially so 6 months
later when you have to make sense of the project to fix bugs.

- Electron by itself needs a surprising amount of memory.  Simply showing a
single page on startup requires just a bit over 400 megs.  Memory is cheap,
sure, but it still stings a bit in the programmer heart.

- If you forget that it's a framework, it will remind you, usually
quickly.  What I mean is, the moment you try to step outside of what the
framework provides, you're going to hit 'undefined behaviour'.  There's a
lot of state being mutated and passed around, and it's pretty easy to get
things to blow up spectacularly when you try to step outside of its
confines.

Of course, it's not all bad.  Electron provides a lot of application
creature comforts out of the box, most of it is written as sanely as you
can write anything in Javascript, and for the most part it operates the
same on each platform.  My distaste for using Javascript outside of the
browser is not so great that I don't recognize a reasonably good solution
to a problem, and this is one.

That said, the next time I am tasked with writing another desktop
application I'll take another look at Ceramic and weigh putting effort into
that project rather than another Electron application.  Note that I haven't
tried Ceramic in over a year so things might have changed.

I know it has probably been said ad nauseam, but I'll reiterate it here: If
it didn't cost, from what I gather from the price page, just under $10,000
to support the same platforms, we would have almost certainly used LW and
CAPI.  When that cost almost equals the entire revenue for a project, it's
a very hard thing to justify for a small company like mine.  It certainly
makes free solutions sparkle in an unnatural way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20170331/5a612877/attachment.htm>