edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Adam Thompson <arthompson1990@gmail.com>
To: Karl Dahlke <eklhad@comcast.net>
Cc: edbrowse-dev@edbrowse.org
Subject: Re: [edbrowse-dev] Rooted
Date: Mon, 9 Nov 2020 22:58:35 +0000	[thread overview]
Message-ID: <20201109225835.GA4369@toaster> (raw)
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.


      reply	other threads:[~2020-11-09 22:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-01  3:23 Karl Dahlke
2020-11-01 22:35 ` Adam Thompson
2020-11-01 23:27   ` Karl Dahlke
2020-11-09 22:58     ` Adam Thompson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201109225835.GA4369@toaster \
    --to=arthompson1990@gmail.com \
    --cc=edbrowse-dev@edbrowse.org \
    --cc=eklhad@comcast.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).