Feasability to replace sao (js) by python for web client

Feature Ideas
1

As a node.js hater with a prevailing preference to keep the Tryton modules in python, I’m curious if there has been any recent evaluation of rewriting (porting) the webclient back to python…

This article I found quite interesting:
https://hackernoon.com/javascript-vs-python-in-2017-d31efbb641b4

This may be quite a nice topic for a SoC project.

2

Yes javascript has it’s drawbacks. The same applies for Python. For me it’s the best tool for the job. Python (together with Tryton) as the backend where almost all the logic lives. Javascript (together with EmberJS) for the frontend app for a nice and crispy user experience. Also with javascript you can have one codebase for your app and add extra logic for building the app for different OS-es.

So I don’t think I’m understanding you correctly, but do you mean creating a webserver and serving pages rendered by the webserver? Like Django does? If so, you don’t understand how sao is working. It’s a webapp, the builded (minified, zipped etc) app is downloaded to your browser and then fired up. After that it is doing the same thing as the desktop-client: just sending JSON-RPC messages to Tryton, which reacts with data. That data is then displayed to the user.

3

What I see directly is:

$ du -hs tryton{,d} sao
22M tryton
25M trytond
162M sao

not to mention installing:

$ npm install --production
npm WARN deprecated bower@1.8.4: We don’t recommend using Bower for new projects. Please consider Yarn and Webpack or Parcel. You can read how to migrate legacy project here: How to migrate away from Bower? · Bower blog
npm WARN deprecated minimatch@0.2.14: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated coffee-script@1.3.3: CoffeeScript on NPM has moved to “coffeescript” (no hyphen)
npm WARN deprecated graceful-fs@1.2.3: please upgrade to graceful-fs 4 for compatibility with current and future versions of Node.js
npm WARN deprecated minimatch@0.3.0: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated nomnom@1.8.1: Package no longer supported. Contact support@npmjs.com for more info.
npm WARN deprecated hoek@2.16.3: This version is no longer maintained. Please upgrade to the latest version.
npm WARN deprecated boom@2.10.1: This version is no longer maintained. Please upgrade to the latest version.
npm WARN deprecated cryptiles@2.0.5: This version is no longer maintained. Please upgrade to the latest version.
…
npm notice created a lockfile as package-lock.json. You should commit this file.
added 254 packages from 218 contributors and audited 1380 packages in 40.808s
found 65 vulnerabilities (32 low, 23 moderate, 10 high)
run npm audit fix to fix them, or npm audit for details

these are already quite troubling for a system manager. pip is bad enough, but becomes unnecessary when the prereq’s are duly installed by the system package manager.

4

If there would be a need/interest for a unified/shared codebase for the client, kotlin could be an option as it has native multiplataform as a goal. Those seem to be quite experimental and interesting.

5

The 162M for sao is the development version. You have to check the production-version which should not be bigger than 5M.

The point is that Javascript is developing very fast with new tools, updated libraries etc. That’s why I’m using a framework like EmberJS (you can use Angular or React or Aurelia that’s up to you), so I can focus on the app itself where EmberJS continously update to use the newest libraries and tools. This comes at the cost of a bigger builded app but with the advantages of more focus on the app.

That’s quite interesting indeed. But you have to learn a new language and it used JVM which can also be a pain in the back because of different versions.

6

according to npm help install

With the --production flag (or when the NODE_ENV environment variable
is set to production), npm will not install modules listed in
devDependencies.

What makes you think the development versions got installed?

It’s even bigger if I do the audit fix:

$ npm audit fix

phantomjs-prebuilt@2.1.16 install /home/richard/src/tryton-env/sao/node_modules/phantomjs-prebuilt
node install.js

Considering PhantomJS found at /usr/sbin/phantomjs
Found PhantomJS at /usr/sbin/phantomjs …verifying
Error verifying phantomjs, continuing { Error: Command failed: /usr/sbin/phantomjs --version
/usr/sbin/phantomjs: error while loading shared libraries: libicui18n.so.62: cannot open shared object file: No such file or directory

at ChildProcess.exithandler (child_process.js:294:12)
at ChildProcess.emit (events.js:189:13)
at maybeClose (internal/child_process.js:978:16)
at Socket.stream.socket.on (internal/child_process.js:395:11)
at Socket.emit (events.js:189:13)
at Pipe._handle.close (net.js:610:12)
killed: false,
code: 127,
signal: null,
cmd: ‘/usr/sbin/phantomjs --version’ }
Downloading https://github.com/Medium/phantomjs/releases/download/v2.1.1/phantomjs-2.1.1-linux-x86_64.tar.bz2
Saving to /tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2
Receiving…
[=======================================-] 99%
Received 22866K total.
Extracting tar contents (via spawned process)
Removing /home/richard/src/tryton-env/sao/node_modules/phantomjs-prebuilt/lib/phantom
Copying extracted folder /tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2-extract-1545824881689/phantomjs-2.1.1-linux-x86_64 → /home/richard/src/tryton-env/sao/node_modules/phantomjs-prebuilt/lib/phantom
Writing location.js file
Done. Phantomjs binary available at /home/richard/src/tryton-env/sao/node_modules/phantomjs-prebuilt/lib/phantom/bin/phantomjs
added 337 packages from 223 contributors and updated 1 package in 27.857s
fixed 4 of 65 vulnerabilities in 1380 scanned packages
1 vulnerability required manual review and could not be updated
7 package updates for 60 vulns involved breaking changes
(use npm audit fix --force to install breaking changes; or refer to npm audit for steps to fix these manually)
$ du -hs .
259M .

Regardless, it is a mess and seemingly highly vulnerable… more than questionable for a production machine.

7

You counted everything, sao is way lighter than that.

nicoe@mirabelle:~/projets/tryton/…/tryton-env/sao% du -h dist
1,3M    dist

And dist contains both the minified and the vanilla version.

It does not change that the javascript world is a mess but we have to do with what is available :unamused:

1 Like
8

npm stuff is a pain to package properly (aka having only minimal number of files required).

you could check if you have any bower_components/*/docs directories. for example, papaparse/docs is ~50Mo here.

it isn’t so simple.

for all the packages used, only some are effectively used at runtime: others are used at “build time” on trusted source code (sao code).

and for effectively installed packages, code will run on client side to communicate with trusted code (trytond server).

9

I think the problem is mostly with weight of dependencies :slight_smile:

you can’t run sao with only sao code (needs jquery, bootstrap, etc…)

10

Well, perhaps in more detail:

$ du -hs * |sort -h
9,0K bower.json
9,0K CHANGELOG
9,0K COPYRIGHT
9,0K Gruntfile.js
9,0K index.html
9,0K package.json
9,0K README
25K LICENSE
36K tests
65K package-lock.json
368K locale
440K src
493K dist
530K images
40M bower_components
116M node_modules

where it seems dist/, node_modules/ and bower_components/ are generated via npm & grunt

11

===================

$ find . -name docs -exec du -hs {} ; | sort -h
19K ./node_modules/bower/lib/node_modules/handlebars/docs
1,2M ./bower_components/eonasdan-bootstrap-datetimepicker/docs
2,5M ./bower_components/c3/docs
23M ./bower_components/papaparse/docs

12

Let me ask perhaps a real stupid question, how did OpenERP do their web client without all the node.js hocus pocus and bloat; I believe it was also in javascript, no?

13

node_modules aren’t necessary for deployment (not need on the webserver).

as you noted, bower_modules contains documentation that aren’t necessary for deployment.

on OpenBSD, the port for sao install a directory with 15.5Mo (well, currently it is 67Mo, but your post makes me consider to check, and I am cooking a diff to remove docs/ directories :smile:).

1 Like
14

Indeed but it’s a bit like saying “you can not run tryton without gtk”.
jQuery + bootstrap is a bit like gtk (but we have to build everything from scratch), etc.

Of course it’s like having one gtk library per browser tab but that’s the way the web works …

Well if you go on their github page you’ll see that the project is 46% Javascript and 43.4% python, so yes they have a lot of javascript. And I think that their web client is distributed through their web addons:

And they use grunt, npm, etc to build their client.

1 Like
15

If so, then they probably use it upstream and statically deploy the .js… I see this on our current 6.1 server:

src/odoo/addons$ du -hs web* |sort -h
70K web_rpc
89K web_tests
112K web_hello
359K web_uservoice
394K web_livechat
521K web_kanban
522K web_dashboard
623K web_process
696K web_diagram
803K web_gantt
1,3M web_graph
2,6M web_mobile
2,7M web_calendar
7,0M web

No idea for 7.0+ as we abandoned ship like many others staying on 6.1 until migration.

[updated] it appears so as I see the following:

src/odoo/addons$ find web/static/ -maxdepth 2 -type d
web/static/
web/static/test
web/static/src
web/static/src/img
web/static/src/css
web/static/src/xml
web/static/src/js
web/static/lib
web/static/lib/jquery.deferred-queue
web/static/lib/jquery.scrollTo
web/static/lib/jquery.superfish
web/static/lib/jquery.validate
web/static/lib/jquery.ui.timepicker
web/static/lib/json
web/static/lib/jquery.contextmenu
web/static/lib/jquery.form
web/static/lib/jquery.blockUI
web/static/lib/qunit
web/static/lib/jquery.tipsy
web/static/lib/labjs
web/static/lib/jquery.ui.notify
web/static/lib/py.parse
web/static/lib/jquery.ui
web/static/lib/qweb
web/static/lib/jquery.MD5
web/static/lib/jquery.ba-bbq
web/static/lib/underscore
web/static/lib/datejs
web/static/lib/jquery

16

For the deployment, you’re probably right but you can do the same with sao.

17

What I mean by upstream ‘deploy’ is what is committed into the DVCS (git, in this case).

18

Then why would there be a Gruntfile.js in their source ?
Also it’s a bit stupid to not put in your DVCS the source of your building process.

19

Beats me… just never needed to do anything to the upstream web sources like npm/grunt/etc.


But, naturally, the source is there - otherwise how could one do an in-tree update?

BTW - I don’t find Gruntfile.js… perhaps that came in a later version…

20

You’re talking about an old version of odoo (I don’t know exactly how old it is) … now they have switched to better practice it seems.

The link I provided has it. They’re using a more standard methodology instead of vendoring the libs like they used to do.