Correct 'forwards' to 'backwards'

[ghost]

Please type "I already searched for this issue": I already searched for this issue

Edition: 2nd

Book Title: Get Started

Chapter: 1: What Is JavaScript?

Section Title: Jumping the Gaps

Topic: 'forwards' was used where clearly 'backwards' was meant.

[getify]

This is a bit of a nuanced issue. I think perhaps an argument could be made for either "forward compatible" or "backward compatible" to be the appropriate term here:

1. The purpose of a transpiler is to pretend as if JS is "forward compatible" -- by making it seem like new features can work on older systems --, so the term could mean it in that sense. They can't actually work, so it's not really forward compatible. But it's implying that behavior.

2. The output of a transpiler is, strictly speaking, "backwards compatible" code -- it's code styled as if it had been written a long time ago with only the features of the older environments, but those older features are still able to work in the modern engines.

My mind keeps wavering back and forth between whether (1) or (2) is the right approach here. Initially responding here, I felt like "backward compatible" was the closer match. But re-reading this part of the chapter, I was clearly setting up transpilers as solving the "forward compatible" problem. So I know that's what I meant there.

Maybe I shouldn't have said "forward compatible" without putting it in quotes, to indicate that the code isn't actually forward compatible, but is acting that way.

Or maybe the better fix would be to change the succeeding phrase "forwards-compatible version of the code" to something like "forwards-compatible acting solution".

[getify]

All the above said, I'm not sure a change is warranted or not. In part, that's because the book has been published for 2.5 years (tens of thousands of copies sold). I'm not sure this is a big enough confusion to cause a divergence between what this repo says and what all those printed/ebooks say.

If I could go back in time, I'd probably have worded this more clearly/accurately. But I think the "forwards-compatible" is still more in line with the message of that section than "backwards-compatible" is.

[ghost]

But I think the "forwards-compatible" is still more in line with the message of that section than "backwards-compatible" is.

Isn't JS always forwards-compatible? Old code still runs fine in newer environments. The reverse is not the case. That's why we have transpilers. They make code backwards-compatible.

It looks you meant not merely 'forwards-compatible', but 'forwards-optimised' (future proof?). But that wouldn't apply to transpiling ES6 to ES5, because ES6 is already widely supported.

[chekibayed]

Le jeu. 25 août 2022 à 12:21, ilovehackathons ***@***.***> a écrit :

…

But I think the "forwards-compatible" is still more in line with the message of that section than "backwards-compatible" is. Isn't JS always forwards-compatible? Old code still runs fine in newer environments. The reverse is not the case. That's why we have transpilers. They make code backwards-compatible. It looks you meant not merely 'forwards-compatible', but 'forwards-optimised' (future proof?). But that wouldn't apply to transpiling ES6 to ES5, because ES6 is already widely supported. — Reply to this email directly, view it on GitHub <#1803 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJ5JVZ6V22LINIRXI24SQDV25CL7ANCNFSM57OQ7C3Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[getify]

Isn't JS always forwards-compatible? Old code still runs fine in newer environments.

That's "backwards-compatible" when old code still runs in newer environments. JS is indeed almost entirely backwards-compatible.

"Forwards-compatible" means that an older environment can still accept code that was written for a newer environment. The best example of that is CSS and HTML. If you take a CSS file written today (with all kinds of new features in it) and run it in an older browser, the CSS parser skips over the stuff it doesn't understand but keeps processing the stuff it does understand. Same for HTML.

Notably, JS is absolutely NOT "forwards-compatible". If you take a JS program with an arrow function => in it, and run it in an old IE6 browser, the JS program will completely break, since that JS engine will choke on that syntax while parsing and stop everything else.

So just to be super clear: a transpiler like Babel takes code written for a newer environment (with new syntax), and allows it to be able to run in an older environment. As a purpose and goal, that's creating "forwards compatibility" where it doesn't otherwise exist. It achieves this by actually doing the reverse: change the code from being designed for newer-environments to being designed for the older-environments... and THAT code still runs in both the old and new environment because JS is "backwards-compatible".

[ngtrhieu]

Developers should focus on writing the clean, new syntax forms, and let the tools take care of producing a forwards-compatible version of that code that is suitable to deploy and run on the oldest-supported JS engine environments.

I was confused when reading this line too. However, after reading Getify's comment above, I think I'd agree with the wording here. I don't think changing the text is necessary, it would cause even more confusions indeed. If you must absolutely need to update this section, I think the footnote to the comment itself should be suffice.

[getify]

Current:

and let the tools take care of producing a forwards-compatible version of that code

If I were to reword it, I would change it to say this:

and let the tools take care of forwards-compatibility by producing a version of that code

I think that would be clear and accurate. But as I said earlier, I don't think this is a big enough problem to warrant actually changing the text (which then would diverge from all the tens of thousands of copies of the book already printed/sold over the last 2.5 years).