[Edbrowse-dev] V8

[Edbrowse-dev] V8

[Karl Dahlke]

After about ten minutes of reading, I'm almost convinced
we should switch to v8.
https://developers.google.com/v8/intro
The api just has to be cleaner than mozilla (he said somewhat on faith),
and there's an entire public domain dom on top of it in google chrome,
that we might be able to pilfer.
I was about to step through the download and build process,
just so I could play with it, but on a whim I typed in
	yum install v8
and here it comes, packaged with fedora 20.
Very likely it is available on your distro too.
So that saves us a few hours work and hassle,
and makes the path all the more plausible.
It is a distributed package, with a public api, just like moz24.
Perhaps we should all pull it down and write a few hello world programs,
just to get a feel for it.

Karl Dahlke

Re: [Edbrowse-dev] V8

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

On Fri, Dec 05, 2014 at 06:25:58AM -0500, Karl Dahlke wrote:
> After about ten minutes of reading, I'm almost convinced
> we should switch to v8.
> https://developers.google.com/v8/intro
> The api just has to be cleaner than mozilla (he said somewhat on faith),
> and there's an entire public domain dom on top of it in google chrome,
> that we might be able to pilfer.
> I was about to step through the download and build process,
> just so I could play with it, but on a whim I typed in
> 	yum install v8
> and here it comes, packaged with fedora 20.
> Very likely it is available on your distro too.
> So that saves us a few hours work and hassle,
> and makes the path all the more plausible.

Yeah, on debian I think there's a package,
I'll install and play with it over the weekend.
Tbh, having seen the way mozilla's api changes between releases,
making it a maintainability nightmare,
I'm ready to investigate another engine (I'd thought of v8 before but couldn't
find a Debian package for it and didn't want to do the work myself).
I'll also have a look at the api to see if it's worth changing.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Edbrowse-dev] V8

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> Tbh, having seen the way mozilla's api changes between releases,
> making it a maintainability nightmare,
> I'm ready to investigate another engine

I'm not convinced that V8 will solve this problem.  Gentoo
stopped offering v8 as a standalone package some months ago, and if I
remember correctly, the reason had something to do with the speed of
development of both v8 and chromium.  So now they package v8 as part of
chromium, in order to keep them in sync.
My memory is fuzzy here, so I may be blowing smoke.
But we need to take a very hard look at API stability before jumping
ship.

-- Chris

Re: [Edbrowse-dev] V8

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]

On Fri, Dec 05, 2014 at 01:52:12PM -0800, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> 
> > Tbh, having seen the way mozilla's api changes between releases,
> > making it a maintainability nightmare,
> > I'm ready to investigate another engine
> 
> I'm not convinced that V8 will solve this problem.  Gentoo
> stopped offering v8 as a standalone package some months ago, and if I
> remember correctly, the reason had something to do with the speed of
> development of both v8 and chromium.  So now they package v8 as part of
> chromium, in order to keep them in sync.
> My memory is fuzzy here, so I may be blowing smoke.
> But we need to take a very hard look at API stability before jumping
> ship.

That's interesting, I didn't know that.
The problem is that I suspect the next thing we'll probably need to do is
support mozjs 31 (whenever that's released)
and Mozilla publicly say that they've developed spidermonkey for use in firefox
and they can (and do) change the api frequently to keep up with the needs of
the firefox project. That's fine, but Debian's already on mozjs 26 (all be it
they're still packaging mozjs 24),
and I've seen a mozjs 31, and who knows what the api changes are like there.
I'm not saying v8's the answer, but we need to try and find something which we
can maintain, if only for the purposes of keeping up with security advisories etc.
In addition, it'd be beneficial if we could decouple the DOM from the js engine
we're currently using (which I know is slightly different to previous thinking)
since at the moment, changing engine's going to be a *lot* of work.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[Edbrowse-dev] V8

[Karl Dahlke]

> on debian I think there's a package,

Oh, a heads up, I had to install v8 and v8-devel.
That makes sense; we want to develop for v8.
But ... their hello world program calls upon a header file
that is not part of my v8-devel.
libplatform/libplatform.h
I can't find this in any other package, and I'm at a loss.
I could step back and build everything from source,
but damnit I was trying to avoid that.

The v8 shell is called d8.
Somewhat like jsh in the mozilla world.
I played with it for a bit and it works as expected.

> having seen the way mozilla's api changes between releases,
> making it a maintainability nightmare,
> I'm ready to investigate another engine

Agreed.

Karl Dahlke