(Replying to PARENT post)
This made me start digging into whether this was considered a "safe" way of executing untrusted JavaScript in a sandbox.
It's not completely clear to me if DukPy currently attempts safe evaluation - it's missing options for setting time or memory limits on executed code for example: https://github.com/amol-/dukpy
There's a QuickJS Python wrapper here which offers those limits: https://github.com/PetterS/quickjs
I'm pretty paranoid though any time it comes to security and dependencies written in C, so I'd love to see a Python wrapper around a JavaScript engine that has safe sandbox execution as a key goal plus an extensive track record to back it up!
(Replying to PARENT post)
(Replying to PARENT post)
(Replying to PARENT post)
https://www.html5rocks.com/en/tutorials/internals/howbrowser...
(Replying to PARENT post)
edit: it's a great article! But nothing on rendering tables :-)
(Replying to PARENT post)
(Replying to PARENT post)
(Replying to PARENT post)
(Replying to PARENT post)
(Replying to PARENT post)
(Replying to PARENT post)
(Replying to PARENT post)
W3C here is unfortunately a part to the problem.
Standardisation is good, but letting google pour streams halfassedly written RFCs onto other browsermakers is not good.
Non-enforcement of standards is also bad, and it's bad to extend W3C privileges to companies who themselves selectively implement their own proposals, so others' browsers can't match their behaviour.
(Replying to PARENT post)
Developing for the browser is a real challenge. I think working with html / css /js has been a neglected skill for a long time - most software engineers look down on that type of work and its rarely covered in comp sci course work.
Still, its good to see a lot of progress has been made, this book included.
My only critique - why use python instead of node.js?