From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9684 invoked from network); 9 Nov 2020 22:58:44 -0000 Received: from hurricane.the-brannons.com (2605:2700:0:17:a800:ff:fe3e:bc77) by inbox.vuxu.org with ESMTPUTF8; 9 Nov 2020 22:58:44 -0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by hurricane.the-brannons.com (Postfix) with ESMTP id C16F421DE05 for ; Mon, 9 Nov 2020 14:58:39 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 965DB21DE03 for ; Mon, 9 Nov 2020 14:58:39 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id 23so10605829wrc.8 for ; Mon, 09 Nov 2020 14:58:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=3JdVxWYZbgCT2Hsxo7wbbBXyVkhDmMO+h3qi6CPEvBM=; b=lYd4QlOr2eN5qxv+O29K+bn8BFj8azFCMDiYZgf51xm2MyCokukX5I2Fd9WlR86NEg diHBW9BItXU8GhZCaEJ/PSp1ocf9919oMFKRsTJQ/WD6tjC051tCJvku5Fgliat2rIdi QgQfijqKilDfU8WWCw81ct9Njimvl+uDEDC4Rx6NAIijZUY0SHcaUDH1rDppqL5O8bK4 FClnA3i5jFld10mWS3ep3P9s9gEy9CK1VBXKamhRKVBXrzGoNejrW25Kg7rZvWtAQ65N eJiiMdXCdCoJZg5e+5ah7kb7mTJD6gaZFDyrS8bMeCHY4njgGcfDIiezSns5lAnpEKgS YR2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=3JdVxWYZbgCT2Hsxo7wbbBXyVkhDmMO+h3qi6CPEvBM=; b=TI0baC0cc/Oin3+yGLLB/LSwdnd9MBoDSF59REoiprrpINwDxmBMs8pk6aHq88xjpx lkiUeH7D2o+ds84BFUhHorCEThquwfB0pAkb0hoUgPy7bElMBRPQ8TEdoA+Us8i9EjvZ QsG29j9beRsaL4+jOdhDs9QQk7dbPm4RkXPGZuqrE/woJD8YxxeHtvogcAdfsI/wL3zj l9UpF1PJ+WLGJtxjb2LewWCMDoEwL7+TSMNg2u1b6gGCsB3JQ61DW0WyPTSaJRDRhJcZ 28DXWJLz5kHcVhpD9cLBTHMOyxWl2/ntT7bKKFHyadfqDPmrT/UWHMVsh/7a34ug6f6c JBMg== X-Gm-Message-State: AOAM532W2dm2EFaxVvk6IAP/t5pDHkqx260+qPVcngyc0FC6CcjzQtgQ nOiW4XPSChanTMKBQPmHbUk= X-Google-Smtp-Source: ABdhPJyKEukoeYwQmmn9vnLu342wdpujARDdFd3fY13HxhF0Xvr+AJ3LWyzr4+wGSyRkknn4bB6otg== X-Received: by 2002:adf:f245:: with SMTP id b5mr20586889wrp.389.1604962717852; Mon, 09 Nov 2020 14:58:37 -0800 (PST) Received: from toaster (b.5.b.9.4.f.e.f.f.f.c.f.1.b.a.e.1.4.0.9.2.4.1.1.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:1142:9041:eab1:fcff:fef4:9b5b]) by smtp.gmail.com with ESMTPSA id n10sm15345094wrx.9.2020.11.09.14.58.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Nov 2020 14:58:37 -0800 (PST) Date: Mon, 9 Nov 2020 22:58:35 +0000 From: Adam Thompson To: Karl Dahlke Cc: edbrowse-dev@edbrowse.org Subject: Re: [edbrowse-dev] Rooted Message-ID: <20201109225835.GA4369@toaster> References: <20200931232349.eklhad@comcast.net> <20201101223558.GA333510@toaster> <20201001182741.eklhad@comcast.net> X-BeenThere: edbrowse-dev@edbrowse.org List-Id: Edbrowse Development List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201001182741.eklhad@comcast.net> On Sun, Nov 01, 2020 at 06:27:41PM -0500, Karl Dahlke wrote: > No problem Adam. Thanks for your work long ago, which I'm revisiting, and your thoughts. That's ok, I've been meaning to have another look at edbrowse code for a *long* while now but never quite manage. > We almost certainly have to change to something, because duktape is now 2 years out of date, and shows no sign of catching up. > No proper function.toString(), no es6, no let, no Promise, etc etc. > They don't respond to our emails. > They aren't part of anything commercial and don't have a pressing need to stay current. > A lot of projects just use it as an engine for their own, in-house js, which they can write any way they want. > As a result, we are able to browse fewer and fewer sites each month. > nasa.gov just switch to some es6 features, for example. I thought they were looking at es6 last I heard but that was a while back. It's a shame if that project's died like this. On the other hand the github repo shows commits from October this year including 2.6 release prep. In addition it looks like they got promise support (at least from the commit log) a while ago so it may not be as bad as all that. The deb package is from at least late 2019 based on the version numbering so I'm not sure how out of date they actually are. It may be that the commit log makes things look better than they are, I'm not sure. How do you mean about the lack of email response? that's concerning if that's the case. > We're not entirely sold on mozjs, also taking a hard look at v8. > But both are c++, and both have a lot of the same challenges for edbrowse integration. > The up side is, both will always stay current, as they are at the heart of commercial browsers. The problem is that, at least in my experience, neither is really treated as a library for external consumption. Sure they're available but they seem to be somewhat more of a framework sometimes than just a js lib. May be this says something about how the web (and thus browsers) are going in terms of needing more and more features and being increasingly js driven... I don't know. Anyway, as you say, we really need to try and keep up as otherwise we'll just end up with worse-than-no js support soon which wouldn't be a good thing. >From what I can see (brief look for debian packages) they appear to have multiple spidermonkey versions packaged (52 and 78) but nothing which (at least superficially) looks like v8. Even the version of nodejs (which I believe uses v8 under the hood) doesn't have a v8-looking dependency. this concerns me from the v8 side as I remember it being... difficult... to compile all those years ago whereas at least spidermonkey was doable. On the other hand, the following concerns me from a spidermonkey perspective: " Note: Standalone SpiderMonkey is not an official product. Our continuous integration system does produce a tarball that is built into a binary that runs our smoke tests, but we do not maintain it nor actively test its suitability for general embedding. We have periodically created "releases", but they are best-effort and incomplete. We do happily accept patches, and make some effort to keep the tip of the Gecko tree minimally working as an embeddable source package. We are very limited in our ability to support older versions, including those labeled as "releases" on this page. " I'm not sure where this leaves us in terms of our ability to keep up. Cheers, Adam.