About node abstracting: https://github.com/nodejs/node/pull/4765
Already working for Chakra: https://github.com/nodejs/node-chakracore There is a project from Mozilla too: https://github.com/mozilla/spidernode#spidernode-nodejs-on-spidermonkey About Babel, jsgtk already uses babel standalone to bring ES6 features in moz24. If you want to play with it, install it via: sh -c "$(curl -fsSL https://webreflection.github.io/jsgtk/install)" Best Regards On Wed, Aug 17, 2016 at 12:53 PM, Jeremiah Foster < jeremiah.fos...@pelagicore.com> wrote: > Great stuff everyone -- these are really good minutes with a lot of good > info. :-) > > On Wed, Aug 17, 2016 at 4:48 AM, <philip.chime...@gmail.com> wrote: > >> Hi list, >> >> Here are the notes from Day 1 of the GJS dev room at GUADEC. >> >> Profiling >> --------- >> Christian has had some profiler patches for a while that he wants to >> merge so that you can do GJS profiling with Sysprof. The problem is that >> they (ab)use SIGUSR1 and SIGUSR2 to enable or disable profiling. >> >> Proposal: toggling profiling using DBus. Would fall back to not allowing >> profiling if DBus was not reachable. gjs-console would export a DBus >> interface. For gnome-shell and other embedding cases, libgjs would have to >> provide API for exporting the interface yourself. Concern: We don't want >> GJS to change its behaviour by init'ing the bus before the application >> starts. >> >> Porting to mozjs31 etc >> ---------------------- >> Yes, we welcome this port, though we need to find time to do it. We want >> GNOME's JS to be modern, rather than use old Mozilla extensions. Tim Lunn >> (darkxst) did the ports to mozjs17 and mozjs24, but nobody knows whether he >> is available at the moment or how much time he has. >> >> Do we port first to mozjs31 or go all the way to mozjs45? In 31 the C API >> was removed, you can only use the C++ API now. It seems better not to break >> everything at once. However, it might be possible to skip mozjs38 in favour >> of mozjs45. >> >> In mozjs45 ES6 classes were introduced. We should figure out how to do >> GObjects as ES6 classes. Maybe a wrapper function that takes an ES6 class >> and adds a GType, properties, signals, etc., since we don't have >> metaclasses. We should also ensure that Lang.Class keeps working. >> >> Missing GObject Features >> ------------------------ >> Were hoping to hear from other GJS consumers about whether they were >> missing any GObject features in their apps. Here are a few that we can >> think of: >> >> GTask - this is not bindable because of bare gpointers in the API. Useful >> for implementing the GAsyncResult pattern, though if you were _consuming_ >> that pattern it might be better to have promises. Matt Watson wrote a GTask >> workalike which we can pull in: https://github.com/endlessm/eo >> s-knowledge-lib/blob/master/js/search/asyncTask.js >> >> Enums - of course JS does not need enums by itself, but it might be nice >> to be able to define enum-valued GObject properties. >> >> GValue boxing and unboxing - Philip C forgot which APIs he needed this >> for. However, if there's a GValue in an API, then it should probably be >> covered by an override. >> >> Promises? We'll get them in mozjs31. Several Node promise libraries have >> "promisify" functions that wrap other libraries' callback-based APIs, so >> we'd like to do something similar for GAsyncResult-based APIs. >> >> Some discussion about GErrors but it seems that support is pretty >> sufficient in GJS. >> >> Documentation >> ------------- >> The DevDocs site is temporarily out of commission because Philip C ran >> out of AWS free tier hosting. We need another place to host this. Owen >> might be able to get it on a VM on GNOME infrastructure. >> >> We also need to make sure the code in modules/overrides/ is documented, >> currently this is obscure and the only way to find it out is to read the >> source. >> >> Michael pointed out (as I was typing these notes up) that PyGObject has a >> fairly good tutorial for GObjects in Python ( >> http://python-gtk-3-tutorial.readthedocs.io/en/latest/objects.html) but >> really, the only good documentation story for people coming to the platform >> is for the C libraries. >> >> GJS Autocompletion >> ------------------ >> For use inside Builder. >> Tern? https://github.com/ternjs/tern >> Generate JS stubs out of GIR files for this? >> >> Debugger >> -------- >> How is this supported within mozjs? >> >> We would like to work with an existing debugger if possible. >> >> Owen knows of a patch in a Gentoo overlay where someone patched GJS to >> support a debugger protocol that can be used with a program called "JSRDB". >> (Link?) >> >> It would be great if we could debug via Chrome Dev Tools, since many >> people would be familiar with them. >> >> React Native >> ------------ >> Niv is interested in this. Ubuntu published React Native for QT and >> someone else published a React Native proof of concept hack in GJS. (Links?) >> >> Interoperability with Node >> -------------------------- >> Philip C has been thinking about a Node shim that implements Node's fs, >> require, and sockets APIs in terms of GIO, so that more Node modules could >> be used directly in GJS. There have already been several efforts in this >> direction (https://github.com/WebReflection/jsgtk, >> https://github.com/satya164/gjs-helpers) Niv is also interested in using >> Webpack/Babel for this purpose. >> >> Of course this wouldn't work for Node modules with native code, though. >> >> Does Node ever plan to support ES6 modules? >> >> Some debate about whether this should be part of GJS, or a side project. >> Also differing opinions about how important this is to the platform. In any >> case, we should follow the ES standard primarily, and have hooks to support >> Node stuff, rather than mutating GJS into something that looks like Node >> but is not quite the same. >> >> Developers used to Node have a lot of niceties at their fingertips; e.g. >> it's good to just be able to do `npm install jshint --save-dev` and your >> project has linting set up. We don't necessarily need to have the same >> answer as Node, but our answer should be something else than "we don't have >> that." >> >> Switching to a different engine >> ------------------------------- >> Consensus seems to be that staying on mozjs is slightly unattractive but >> not overly objectionable. There has been lots of tricky GObject code >> written, solving weird cases bit by bit, and another engine would have a >> lot of catch-up to do; though probably if we were starting GJS now, it >> would be based on top of Node. >> >> Node seems to be abstracting out JS engine backends? Anyone got a link >> for this? >> >> Standards for GNOME application development >> ------------------------------------------- >> Currently there's no place in /usr/share to install modules. We should >> add this. >> >> How do we make it really easy for people to Flatpak their GJS app without >> having to write a bunch of Autotools? Especially if they come from the >> wider JS community. We should discuss inside the community what our >> template for application development should be, and then make sure it is >> available as a default in Builder. Let's also look at apps like >> gnome-sound-recorder or Polari, to see what we want and what we don't want. >> >> Do we use package.js?? Should we be getting people to write ES6 modules >> using Babel?? >> >> Outreach >> -------- >> We should make more of an effort to point people to #javascript and >> javascript-list@gnome.org. At least everyone in this room should be >> subscribed :-) >> >> Action Items >> ------------ >> - [x] Philip C: Send these notes to javascript-list >> - [ ] Christian: finish profiling patches with environment variable, plan >> to merge for 3.22 >> - [ ] Christian: think about IPC for enabling/disabling profiler >> - [ ] Philip C: investigate targeting mozjs31 work for 3.24? >> - [ ] Christian: check out adding Tern to Builder >> - [ ] Niv: investigate bridging Tern with GObject >> - [ ] Niv: experiment with React Native >> - [ ] Philip C: move Endless's AsyncTask.js into GJS for 3.22, Owen will >> review >> - [x] Philip C: send setup script for DevDocs server to Owen >> - [ ] Owen: check out the JSRDB patch >> >> _______________________________________________ >> javascript-list mailing list >> javascript-list@gnome.org >> https://mail.gnome.org/mailman/listinfo/javascript-list >> >> > > > -- > Jeremiah C. Foster > GENIVI COMMUNITY MANAGER > > Pelagicore AB > Ekelundsgatan 4, 6tr, SE-411 18 > Gothenburg, Sweden > M: +1.860.772.9242 > jeremiah.fos...@pelagicore.com > > > > _______________________________________________ > javascript-list mailing list > javascript-list@gnome.org > https://mail.gnome.org/mailman/listinfo/javascript-list > >
_______________________________________________ javascript-list mailing list javascript-list@gnome.org https://mail.gnome.org/mailman/listinfo/javascript-list
