<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Mar 30, 2017 at 3:12 PM Tord Romstad <<a href="mailto:tord.romstad@gmail.com">tord.romstad@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Thu, Mar 30, 2017 at 8:09 PM, R. Matthew Emerson <span dir="ltr" class="gmail_msg"><<a href="mailto:rme@acm.org" class="gmail_msg" target="_blank">rme@acm.org</a>></span> wrote:<blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
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.</blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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. </div></div></div></div></blockquote><div><br></div><div>  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.</div><div><br></div><div>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.</div><div><br></div><div>- 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.</div><div><br></div><div>- 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.</div><div><br></div><div>- 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div></div>