I read this discussion for a long time and I do not see anything which helps anyone...

I see TC39 members/supporters who say, there is no issue for them still having the old features in place:

Brendan Eich (TC39): "There's no evidence (I'm sitting in a TC39 meeting) other than grumping from a few that we are near the point of JS painted into a corner by backward compatibility."

Andreas Rossberg (google): "As for the reoccurring assumption that deprecation would help simplifying JavaScript implementations: no, not to a relevant degree (...) And clearly, modes or versions only make things worse in that regard."


Can't we agree on the following:

"As long as TC39 members do not feel being painted into a corner because of backwards compatibility and as long as browser vendors do not indicate having trouble maintaining the old features and as long as those old features are not security risks by design, there is no need to discuss further about the removal of language features."?

As a developer, "a user" of JavaScript I have no problem with features around, which I do not use. If there are features a group of people (and even if it were the whole JS developer community) agrees to be evil, they can agree not to use them. And as a developer using JavaScript I am thankful for the great work the TC39 and browser vendor guys do to keep this all rolling. And if they say one time, that they (for a good reason) have to abandon a feature, which I used and maybe even liked, I would spend all time necessary on making my software work without it. That being said I see no value in us developers discussing about removing old features which we just do not like.


On 27.07.2017 01:14, Tab Atkins Jr. wrote:
On Wed, Jul 26, 2017 at 3:37 PM, Florian Bösch <[email protected]> wrote:
On Thu, Jul 27, 2017 at 12:18 AM, Brendan Eich <[email protected]>
wrote:
The solution is not to hate JS. It's not going to change incompatibly.
Rather, you can use linters, "transpilers", compilers, voluntary unchecked
subsets -- all possible today.

So basically "the best way to use JS is to not use JS". Awesome.
That's the downside of shipping your programs to customers as source,
and letting them use any of 100+ compilers of varying ages and quality
to compile your code.  (There's plenty of upsides, of course.)

As Brendan said, examples of other languages don't really apply,
because they compile on the developer end, and just ship binaries to
customers. (Or something that has the same effect, like shipping
source+interpreter to customers in a package.)  If you want to benefit
from those network dynamics, you have to compile on your end, or in
the language of today, "transpile".

That doesn't mean "not use JS" - Babel and related projects let you
use modern JS, and you can apply whatever restrictions you want.  Or
you can go ahead and abandon JS, and use one of the myriad of
alternative transpilation languages. Whatever floats your boat.

But you can't get around the mathematics.  Delivering plain source,
without a well-controlled compiler monopoly, means breaking changes
are very, very hard to make.  Best to make peace with it and engineer
around it, rather than futilely fight it.

~TJ
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar 
• www.actifsource.com • +41 56 250 40 02


_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to