javascript vision thing

Luan Nico luannico27+es-discuss at
Thu Jul 26 14:55:07 UTC 2018

Another lurker, and I agree with both points:

 * I think JS *is* useful for way more than just the Web. It might not be
my favorite language of all times, but sure is near the top and my language
of choice for several non-web projects, specially bash scripts (I have
simple bash utility in JS that I use daily, for instance).
 * I think the new additions were a almost a panacea for a lot of drawbacks
I had with the language while developing for the web (and not), including
basic frontend websites, especially things like; async/await, destructors,
spread operator and default values for parameters. I sincerely cannot
believe one could not see the usefulness and benefit of the latter, for
instance, in any project of any type whatsoever, in a language without
method overloading.

IMHO these additions shed a light on JS that made it stand on the top with
the others as a completely valid, useful, powerful, easy to write and read,
pretty, delightful language to code tiny or massive web apps or other
projects. I like most of the discussions here, that's why I follow the list
(I really like the recent Object.pick, for instance, and would personally
really like to see my proposed (and many other before me of whom I was
unaware) array.flatten), but this particularly topic doesn't seem very
productive. Changes have been made, and I love them, but they are optional,
backwards compatibility is the absolute goal.

If one has specific and well defined proposals, independent of the
philosophy behind them, I'd love to see them made in other topics,
specially if they come from someone who doesn't quite like what we have so
far. This broad and vague rambling, OTOH, doesn't seem to be adding much.
But those are just my couple cents, and in no way I incentivize banning a
topic or conversation or nothing of the sort (one can just ignore it if he
doesn't like to read). I have to add, if you allow me to, it's actually
quite funny to skim through when you have some spare time, and can be very
instructive too (some good points on both sides).

On Wed, Jul 25, 2018 at 4:05 PM Isiah Meadows <isiahmeadows at>

> In my experience, Electron is great for prototyping, but it's a mild pain
> to scale, and creating packaged binaries required building a massive
> toolkit just to get something that worked for most cases. Bundling scripts
> for Node itself is still a minor pain, enough that most projects don't
> bother, and testing support with bundled projects is also a bit sucky.
> Electron doesn't really help much in this area, since it's more Node than
> browser, absorbing all the testing and building warts it has. Oh, and don't
> forget that you *have* to (at least pre-N-API) recompile native extensions
> to work with it, which is incredibly inconvenient to set up.
> Not like this isn't solvable by more tooling, but eventually, it's going
> to feel like the typical Java + Maven + Ant monstrosity, just replaced with
> a mess of CLI apps instead. This isn't an issue for prototyping or larger
> apps where this might affect your workflow minimally, but it's certainly an
> issue when trying to scale initially. It's not really impossible, just
> annoying and full of potholes while you hook up all the boilerplate.
> On Wed, Jul 25, 2018, 13:42 Pier Bover <pierbover11 at> wrote:
>> Lurker here, I also agree with most points expressed by T.J. Crowder.
>> JavaScript is a scripting language that can serve many purposes. I think
>> the addition of class and async/await only make the language better, and if
>> optional static types were included (a la TypeScript or ES4) it would
>> probably make JavaScript the best scripting language.
>> I also think the Node ecosystem is a mess, and that Electron is a plague,
>> but those points are completely unrelated to the language itself. There are
>> projects such as that aim to provide a bloat-free
>> universal Electron / Cordova replacement.
>> On Wed, Jul 25, 2018 at 12:00 PM, Jacob Pratt <jhprattdev at>
>> wrote:
>>> Mostly a lurker here. I fully agree with your points, and also use JS
>>> for non-web projects.
>>> On Wed, Jul 25, 2018, 07:34 T.J. Crowder <
>>> tj.crowder at> wrote:
>>>> Lurkers: If I'm alone in this, please say so. If I'm **not** alone,
>>>> please say so (publicly this time). Either way, I'm done as of this message
>>>> other than linking back to it.
>>>> On Wed, Jul 25, 2018 at 11:33 AM, kai zhu
>>>> <kaizhu256 at> wrote:
>>>> > there is no foreseeable future where javascript will be a better tool
>>>> > than java/c++/python/etc. for non web-related projects.  there is no
>>>> > foreseeable future where employers would hire nodejs-developers to
>>>> > work on non web-related projects
>>>> This is where we differ (well, one place we differ), as I've said many
>>>> times before, and others have said many times before. That future is now.
>>>> How we got here is irrelevant. Where we **are** is that JavaScript is a
>>>> general-purpose programming language good for a lot more than just
>>>> web-related work. And "web" technologies are used for a lot more than just
>>>> the web, witness all those mobile app frameworks using HTML/CSS/JavaScript,
>>>> Windows store apps, Electron, etc. It's also a good language for writing
>>>> *nix shell scripts and command-line utilities, particularly now that it has
>>>> `async`/`await`. There are at least a dozen JavaScript engines for doing
>>>> embedded device work, completely removed from the web environment. And so
>>>> on.
>>>> Separately, the idea that web projects don't benefit from features like
>>>> `class`, `async`/`await`, and meta-programming features and such is flatly
>>>> contradicted by the evidence.
>>>> But leave all that aside. We all know you don't agree with that. You've
>>>> told us, ad nauseum. It's not that we haven't heard what you're saying,
>>>> it's that we disagree with it. (I say "we" because I've had private
>>>> messages from people supporting my pushback on this. I wish they'd be made
>>>> publicly.) Taking every vague opportunity to push your view of JavaScript
>>>> as a niche, limited language is not constructive at this point.
>>>> Robustly-expressed differing views are an essential part of
>>>> consensus-building, but there comes a point where one has to accept that
>>>> one's view has not been successful *and move on*. I think frankly we're
>>>> well past that point on this topic, and have been for a while. Specific
>>>> input on proposals is great, including raising specific concerns with
>>>> serialization etc. (ideally with a proposed solution, but sometimes just
>>>> raising a concern is useful). Putting forward constructive, specific
>>>> proposals for things you think TC39 should be acting on is great.
>>>> Constantly trying to push a view clearly at odds with the consensus of the
>>>> community here is just not useful, and gets in the way of useful
>>>> conversations we could be having, including about the things you care about
>>>> getting done. Please, please move on.
>>>> And again: I think you're right that issues around JSON interop with
>>>> new features like BigInt need focus (here, in the proposal itself, in some
>>>> JSON working group, somewhere), and there seems to be interest in doing so.
>>>> So if that's an area of interest for you, please contribute to that effort,
>>>> rather than spending time beating this dead horse.
>>>> I'm not going to keep writing these replies, I'll just refer to this
>>>> one from now on.
>>>> And again, lurkers, please weigh in.
>>>> -- T.J. Crowder
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list