Sorry, it’s just the manner in which Javascript is being actively demolished
has really irked me. Especially the speed with which these decisions are
carried out. Suggestions like “you should really do some light reading before
engaging in arguments” don’t help either.
These are decisions we as developers have to live with for years to come. It’s
very easy to add features to a language. It’s almost impossible to remove them.
Hence the (uncalled for) curtness.
On Fri, 04 Aug 2017 at 14:31 James M Snell
<
mailto:James M Snell <[email protected]>
> wrote:
a, pre, code, a:link, body { word-wrap: break-word !important; }
Dmitrii,
Quick aside: the rude manner in which you are communicating is interfering with
your goal of convincing anyone. Perhaps if you tried not being so rude, people
here would be more willing to listen to what you're saying.
- James
On Fri, Aug 4, 2017 at 1:09 AM Dmitrii Dimandt <
mailto:[email protected]
> wrote:
Let’s continue with the trend of light reading. Let’s see the multitude of
things that are in JS, and no one bats an eye:
— start quote —
Note that
implements
,
let
,
private
,
public
,
interface
,
package
,
protected
,
static
, and
yield
are disallowed in strict mode only.
You may have noticed I included
eval
and
arguments
in the list. These are not strictly reserved words, but they sure
http://ecma-international.org/ecma-262/5.1/#sec-12.2.1
— they’re disallowed in strict mode too.
Also, the (unlisted)
NaN
,
Infinity
, and
undefined
properties of the global object are immutable or read-only properties in ES5.
So even though
var NaN = 42;
in the global scope wouldn’t throw an error, it wouldn’t actually do anything.
To avoid confusion, I’d suggest avoiding the use of these identifiers
altogether, even though they’re not strictly reserved words.
— end quote —
Oh, hello. What do we have here? Non-reserved words like they are reserved, and
JS treating them in a special way.
So. The *only* reason *not* to introduce a proper global introspection API is?
On Fri, 04 Aug 2017 at 10:03
mailto:[email protected]
<
mailto:[email protected]
> wrote:
I’d recommend you assume your opponent has done some light reading. And I’d
suggest you yourself read the links you post (that is, practice what you
preach).
Multiple reserved keywords have been both added to the language and removed
from the language. Because *the language evolves*.
However, you (and TC39 in general) keep insisting that short-sightedness and
ad-hoc solutions is the only way forward for JavaScript.
You don’t like System, you think it cannot be used? Oh, introduce an
`introspect` keyword. Introduce a `system` keyword. Heck, nothing stopped you
from introducing a language-level built-in in the form of Symbol, what’s
stopping you now?
On Fri, 04 Aug 2017 at 09:55 Jordan Harband
<
mailto:jordan+harband+%[email protected]%3E
> wrote:
Because it's been reserved syntax since JavaScript's inception, and System
hasn't.
I'd recommend some light reading before attempting to continue arguing:
https://mathiasbynens.be/notes/reserved-keywords
On Fri, Aug 4, 2017 at 12:53 AM, Dmitrii Dimandt
<
mailto:[email protected]
>
wrote:
But you can’t `var x = import`, for example. I guess you can’t `var import =
{}` either.
Hmmm… I wonder why…
On Fri, 04 Aug 2017 at 09:50 Jordan Harband
<
mailto:jordan+harband+%[email protected]%3E
> wrote:
It can't be made syntax, because `var System = {};` is valid code, and we can't
break the web. (seriously)
On Fri, Aug 4, 2017 at 12:31 AM, Dmitrii Dimandt
<
mailto:[email protected]
>
wrote:
Make “System” syntax, and there you go.
Instead we have multiple ad-hoc random additions to random keywords just
because someone needs something and since there are rarely any long-term design
decisions anymore, we’re stuck with new.target, function.sent, import.meta (add
your own)
Seriously. How is new.target is “syntax that has context information”, but
System.whatever cannot be provided with context information because it’s API?
On Fri, 04 Aug 2017 at 09:26 Jordan Harband
<
mailto:jordan+harband+%[email protected]%3E
> wrote:
>
There’s nothing stopping you from providing context to System.load. Or
Loader.import, or…
Those are APIs. It is, in fact, impossible to provide context with API, since
it's just normal functions - it must be with syntax.
Additionally, please don't use sexual language, especially in a derogatory
manner - that's against TC39's code of conduct, and I'm quite sure it won't be
tolerated on this list.
Criticism that's purely insult, and doesn't actually explain the cons of
something, is also not productive or useful.
_______________________________________________
es-discuss mailing list
mailto:[email protected] https://mail.mozilla.org/listinfo/es-discuss
On Fri, Aug 4, 2017 at 12:20 AM, Gil Tayar
<
mailto:[email protected]
>
wrote:
Myself, and tens of programmers I know, use ES6 modules (and their precursors,
CommonJS modules) for years now and can't even believe there was a time when
they didn't exist, given that they have totally transformed (in a good way) the
way we work. And that is also the vibe I am getting from the community
(twitter, blog posts, meetups, etc). So when you say that modules are "
redundant and unnecessary on the server-side. and [...]continue to fail to
solve an relevant pain-point for everyday programmers on the frontend-side
now", I believe you are not talking about myself or about the community I
surround myself with.
- Gil Tayar
On Fri, Aug 4, 2017 at 9:47 AM kai zhu <
mailto:[email protected]
> wrote:
> I’m curious what the concerns were. You mentioned disliking the syntax, but
> I’m guessing there’s more to it than that?
the concern is that es modules are starting to look like a solution in search
of a problem. its redundant and unnecessary on the server-side. and it
continues to fail to solve an relevant pain-point for everyday programmers on
the frontend-side now, or in the foreseeable future, while creating new ones.
> I’ve been experimenting with ES Modules over HTTP 2 for a few months. I used
> rollup to create my dep graph without actually bundling, then served
> requested modules as entry points with a server push for their deps. I
> imagine that it won’t be long brolefore generic tooling for this sort of
> approach emerges (my own solution is pretty hacky, just wanted to see how it
> might work).
for most projects, dep-graph and tree-shaking have marginal benefits in
frontend programming, given their complexity. for all that extra work and
boilerplate, the result is typically not anymore smaller, more efficient, or
more maintainable than a pre-es6 rollup file.
_______________________________________________
es-discuss mailing list
mailto:[email protected] https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
mailto:[email protected] https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
mailto:[email protected] https://mail.mozilla.org/listinfo/es-discuss_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
