On Fri, 14 Apr 2017 23:03:02 -0300 Gustavo Sverzut Barbieri <barbi...@gmail.com> said:
> On Wed, Apr 12, 2017 at 9:14 PM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Tue, 11 Apr 2017 09:41:06 -0700 Cedric BAIL <cedric.b...@free.fr> said: > > > >> On Tue, Apr 11, 2017 at 2:52 AM, Carsten Haitzler <ras...@rasterman.com> > >> wrote: > >> > On Tue, 11 Apr 2017 18:58:58 +0930 Simon Lees <sfl...@suse.de> said: > >> >> On 04/11/2017 04:19 PM, Carsten Haitzler (The Rasterman) wrote: > >> >> > On Mon, 10 Apr 2017 12:01:49 -0300 Gustavo Sverzut Barbieri > >> >> > <barbi...@gmail.com> said: > >> >> >> On Mon, Apr 10, 2017 at 4:50 AM, Carsten Haitzler > >> >> >> <ras...@rasterman.com> wrote: > >> >> >>> On Sun, 9 Apr 2017 23:25:39 -0700 Cedric BAIL <cedric.b...@free.fr> > >> >> >>> said: > >> >> >>> > >> >> >>>> On Sun, Apr 9, 2017 at 7:51 PM, Gustavo Sverzut Barbieri > >> >> >>>> <barbi...@gmail.com> wrote: > >> >> >>>>> On Sun, Apr 9, 2017 at 9:38 PM, Simon Lees <sfl...@suse.de> wrote: > >> >> >>>>>> On 04/10/2017 12:39 AM, Gustavo Sverzut Barbieri wrote: > >> >> >>>>>>> Which brings me to my last point: we should adopt and use for > >> >> >>>>>>> REAL a > >> >> >>> one possible option is to jump behind the transpiler bandwagon. what > >> >> >>> about writing a js -> lua transpiler? this should be not that hard > >> >> >>> given the incredible similarity in the 2 languages. you can then > >> >> >>> write in lua or in js. just you need a compile step for js. perhaps > >> >> >>> we should also have a compile step for lua anyway? at least minify > >> >> >>> it for faster parsing etc....? > >> >> >> > >> >> >> isn't jerryscript good enough? Seems pretty small, not sure if > >> >> >> they're focusing on efficiency as much as ram/disk. > >> >> > > >> >> > jerryscript is interpreted only - no jit, so it's going to have a > >> >> > fairly big performance hit vs something jitted. if the point is to > >> >> > write more and more in such a language you want it to be as > >> >> > performant as possible. it can be more performant with a jit... so > >> >> > you'd want that. > >> >> > > >> >> > >> >> I'll be controversial and say that for many Desktop UI applications and > >> >> probably for a lot of smartphone ones as well performance really doesn't > >> >> matter that much, its not like were running these things on a 386, So I > >> >> guess sometimes less performant languages have other benefits which is > >> >> why people use them. > >> > > >> > then why does android precompile java apps to native code on installation > >> > now as opposed to just keep interpreting? :) > >> > >> No clue of what this guys are doing, but I can tell you for sure, you > >> will be fine writing EFL application in JS. For a reminder, EFL with a > >> JS binding without any JIT run fine for doing 2D games on a MIPS at > >> 200Mhz with no GPU. So speed is absolutely not necessary for the large > >> majority of application with EFL as a toolkit (Not talking bob here). > >> I think that if we are to choose a preferred binding, we should go > >> with what bring most developers in. > > > > then why did google bother with v8? why did firefox do tracemonkey? if js > > interpreted is fast enough? remember that js in a web page will be similar > > to js + efl - the web engine is doing the heavy lifting for ui, rendering > > and layout... > > there is a HUGE difference that you're ignoring: browsers shouldn't > start to incorporate extensions that pages can rely, thus they MUST > implement everything on their own... as I said in other emails, even > nice JS utilities such as sane "foreach" aren't there and needs to be > monkey patched, what to say about real useful frameworks that creates > the navigation, widgets, etc? boostrap, react, angular, jquery cannot > be implemented in other languages and exposed... so code starts to > grow quite a lot. That's also true for game engines and the likes. > > In EFL we have much more extensive feature set and those are > implemented in C, thus not that big problem. actually you can add new stuff. plugins. web browsers have had these for years. they are giving up now because people really didnt want to. if you have to then write something in c/c++ compile it and expose it you lose the point of using js (or lua or whatever) as what you have is now not portable as-is but needs recompilation. my point is that if you push js as the lang and then go "jerryscript will do" you'll have app devs that have to do more and more in their app as their apps get less trivial and it will become a burden and the whole "js in the web" will repeat history to get a faster js... which means v8. which means much bigger basic scripting engine vs luajit. we COULD give people js with a transpiler js -> lua - they write in js and it gets compiled to lua for distribution. it should give the performance needed with the "popularity". we could run the js natively or the developer and just transpile when packaging the app up for distribution. > > my point is ... it is NOT good enough. not in the general case. not when > > performance directly relates to battery life. if you go "well today's cpu's > > can run that ok" sure.. but then your battery life lowers by 5%. 10%, > > 20%... ? > > > > there is a solution that gets us both speed and simplicity - luajit. lua > > isn't an unknown language. it would be possible to write a js -> lua > > transpiler and thus get the best of all worlds using luajit as an execution > > engine. > > that's ok. > > > -- > Gustavo Sverzut Barbieri > -------------------------------------- > Mobile: +55 (16) 99354-9890 > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
