Fix JS and JSON

Thomas Güttler

unread,

Nov 5, 2019, 2:18:45 AM11/5/19

to v8-dev

Coming from Python I am very impressed by v8.

But there is one issue ... the language :-)

I guess you all know several aspects of JavaScript,

which you would never do like this if you could start from scratch.

How would you improve JS and JSON if you could?

I started a little github project to gather these ideas:

https://github.com/guettli/lets-fix-js

I don't want to work-around (base64 encode

binary data) and wrap (like Typescript) any more.

Regards,

Thomas Güttler

Jakob Kummerow

unread,

Nov 5, 2019, 5:16:11 AM11/5/19

to v8-...@googlegroups.com

V8's job is to implement JavaScript (aka ECMAScript) as specified.

To get involved with future ECMAScript specifications, TC39 is the place to go. Even if all V8 contributors agreed to change some feature, we couldn't just implement something that contradicts the spec.

Note that it's relatively easy to come up with things one would do differently if one were to design JavaScript from scratch; it is much more difficult to change anything in the language that already exists because of backwards compatibility: we wouldn't want to break existing, previously working code (which might be unmaintained, or whose maintainers don't have time or willingness to spend time updating their code just because someone thought it would be an improvement if the language's semantics changed). So you're left with adding new things, but adding something new never "fixes" something else that's already there -- for example, just because === is useful doesn't stop people from complaining about ==.

Changing JSON (even just additively) is even more difficult than changing JavaScript itself, because JSON is used so ubiquitously even in non-JavaScript scenarios. For example, that's the reason why JavaScript BigInts are not directly representable in JSON.

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/c8c25a3e-e514-4501-b2a4-0d4740df859c%40googlegroups.com.

Thomas Güttler

unread,

Nov 6, 2019, 4:15:49 AM11/6/19

to v8-dev

Am Dienstag, 5. November 2019 11:16:11 UTC+1 schrieb Jakob Kummerow:

V8's job is to implement JavaScript (aka ECMAScript) as specified.

There are environments where I know that my JS code will run on v8 (node.js, Chrome-plugin).

Yesterday I read Move Fast & Don't Break Things and understand these contrary goals,

but restricting yourself because of some spec ... grrrr.

To get involved with future ECMAScript specifications, TC39 is the place to go. Even if all V8 contributors agreed to change some feature, we couldn't just implement something that contradicts the spec.

Yes, you can't? Even if you preserve backward compatibility? Why not add features which can be used by all devs

who are sure their code only runs on v8?

Note that it's relatively easy to come up with things one would do differently if one were to design JavaScript from scratch; it is much more difficult to change anything in the language that already exists because of backwards compatibility: we wouldn't want to break existing, previously working code (which might be unmaintained, or whose maintainers don't have time or willingness to spend time updating their code just because someone thought it would be an improvement if the language's semantics changed). So you're left with adding new things, but adding something new never "fixes" something else that's already there -- for example, just because === is useful doesn't stop people from complaining about ==.

Yes, you are right. Nevertheless I think there a ways to improve the core language.

Python uses "__future__" imports to tell the interpreter that this file uses new features. Perl uses "use strict"..

Old code won't use "__future__" imports and this way you can make both parties happy.

Changing JSON (even just additively) is even more difficult than changing JavaScript itself, because JSON is used so ubiquitously even in non-JavaScript scenarios. For example, that's the reason why JavaScript BigInts are not directly representable in JSON.

Thank you for this hint. BigInt in JSON seems to be supported by python:

https://github.com/guettli/lets-fix-js/blob/master/README.md#javascript-support-for-bigints

I guess this is a JS issue, not a JSON issue. But I am unsure (have not read the specs in detail).

My current goal is to gather ideas what could be improved in JS and JSON.

I am particularily interested in things which can't be fixed by wrappers like TypeScript.

After writing, someone created the first issue here: https://github.com/guettli/lets-fix-js/issues

I hope more devs still believe that the future can be influenced.

Please create new issues if you have an idea how to improve JS/JSON.

Thank you Jakob for your reply!

Regards,

Thomas Güttler

On Tue, Nov 5, 2019 at 8:18 AM Thomas Güttler <guet...@gmail.com> wrote:

Coming from Python I am very impressed by v8.

But there is one issue ... the language :-)

I guess you all know several aspects of JavaScript,
which you would never do like this if you could start from scratch.

How would you improve JS and JSON if you could?

I started a little github project to gather these ideas:

https://github.com/guettli/lets-fix-js

I don't want to work-around (base64 encode
binary data) and wrap (like Typescript) any more.

Regards,
Thomas Güttler

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to v8-...@googlegroups.com.

Jakob Kummerow

unread,

Nov 6, 2019, 5:54:45 AM11/6/19

to v8-...@googlegroups.com

To get involved with future ECMAScript specifications, TC39 is the place to go. Even if all V8 contributors agreed to change some feature, we couldn't just implement something that contradicts the spec.

Yes, you can't? Even if you preserve backward compatibility? Why not add features which can be used by all devs
who are sure their code only runs on v8?

OK, to be precise: of course technically we could, but we do not want to diverge from the spec, because we believe that fracturing the ecosystem is bad (for a variety of reasons).

Note that it's relatively easy to come up with things one would do differently if one were to design JavaScript from scratch; it is much more difficult to change anything in the language that already exists because of backwards compatibility: we wouldn't want to break existing, previously working code (which might be unmaintained, or whose maintainers don't have time or willingness to spend time updating their code just because someone thought it would be an improvement if the language's semantics changed). So you're left with adding new things, but adding something new never "fixes" something else that's already there -- for example, just because === is useful doesn't stop people from complaining about ==.

Yes, you are right. Nevertheless I think there a ways to improve the core language.

Of course there are! Specifically, participating in TC39's work is the way to improve JavaScript. They even have a document explaining the process: https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md

Changing JSON (even just additively) is even more difficult than changing JavaScript itself, because JSON is used so ubiquitously even in non-JavaScript scenarios. For example, that's the reason why JavaScript BigInts are not directly representable in JSON.

Thank you for this hint. BigInt in JSON seems to be supported by python:

https://github.com/guettli/lets-fix-js/blob/master/README.md#javascript-support-for-bigints

I guess this is a JS issue, not a JSON issue. But I am unsure (have not read the specs in detail).

Indeed, I think it would be beneficial for your efforts if you did some research on existing issues and constraints. JavaScript supports BigInts just fine. Regarding support in JSON, there is a lot of existing discussion that led to this decision, e.g. at https://github.com/tc39/proposal-bigint/issues/24 -- I'm sure if you look around you'll find even more people arguing in all directions.

My current goal is to gather ideas what could be improved in JS and JSON.
I am particularily interested in things which can't be fixed by wrappers like TypeScript.
After writing, someone created the first issue here: https://github.com/guettli/lets-fix-js/issues
I hope more devs still believe that the future can be influenced.

The future can certainly be influenced; the way to influence JavaScript's future is to participate in TC39's work. V8 is represented there too; any decisions about language features/changes will be made there, not on this mailing list.

Thomas Güttler

unread,

Nov 7, 2019, 6:18:59 AM11/7/19

to v8-dev

Thank you very much Jakob for showing me the right direction!

Reply all

Reply to author

Forward