On linux a natively packaged JavaFX application is about 40mb (without 
webview). I don‘t think we need any of the Electron / NodeJS APIs when we use 
our HTML/Java APIs, since we have access to the complete Java API. We’ve been 
developing reasonably large applications with it, and we didn‘t miss anything 
so far.

—Toni 

Von meinem iPad gesendet

> Am 19.03.2018 um 11:51 schrieb Neil C Smith <neilcsm...@apache.org>:
> 
> On Mon, 19 Mar 2018 at 00:52 Victor Williams Stafusa da Silva <
> victorwssi...@gmail.com> wrote:
> 
>> But since people are/were talking about electron
>> (or other replacements for Swing/AWT/JavaFX), let's give a look at this and
>> not commit the same mistakes:
>> https://josephg.com/blog/electron-is-flash-for-the-desktop/
>> 
> 
> That Electron apps can be resource hogs I don't think is in dispute
> (although everyone seems to use Slack as the example - maybe it's just
> them! ;-) )
> 
> However, I think we're playing with the assumption, which might prove to be
> incorrect, that it is the backend part of these (and the interesting
> blocking behaviour) that's most of the problem.  So doing all the
> application logic still on the JVM mitigates that.  If it's actually the
> embedded Chromium that's the problem ...
> 
>> On Mon, 19 Mar 2018 at 07:05 Toni Epple <toni.ep...@eppleton.de> wrote:
>> 
>> I have no plans to embed electron as it would be overkill. A HelloWorld is
>> 115 mb and contains nodejs and desktop APIs we don’t need.
>> 
> 
> How big is a native packaged JavaFX Hello World then? ;-)
> 
> I agree with you about nodejs, but some of those desktop APIs are useful.
> Assuming a fully HTML UI application, surely we'd need those from
> somewhere?  I guess my thinking is more launcher, Chromium content, desktop
> API's and minimal profile headless JVM.
> 
>> On Sun, 18 Mar 2018 at 20:16 Kirk Pepperdine <k...@kodewerk.com> wrote:
>> 
>> A large part of the problem is the translation of the data set to HTML as
>> sometimes it’s difficult to know what is immediately needed.
>> 
> 
> This is the bit I don't understand.  Why would you want to do that?  In
> every Swing component I can think of you wouldn't render an entire large
> data set in the view in one go or it would grind to a halt - you'd render a
> subset/summary/coalesced view of the model surely?  The point of this
> approach, at least as I understand it, is to still do all the data set
> interaction, filtering and calculation on the JVM.
> 
> Best wishes,
> 
> Neil
> -- 
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
> 
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



Reply via email to