javascript vision thing

Thu Jul 26 15:24:55 UTC 2018

Here's the funny part:

JSON = JavaScript Object Notation

If the OP wants to see improvements in JSON, why not just submit a proposal
to alter what ES can do with JSON? If it makes it to stage 4, there's a
pretty good chance that the standard for JSON will also change as a result.
Sitting around complaining about what's wrong means nothing if you're not
even willing to think about a solution and take action accordingly.

On Thu, Jul 26, 2018 at 9:55 AM Luan Nico <luannico27+es-discuss at gmail.com>
wrote:

> 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 gmail.com>
> wrote:
>
>> 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 gmail.com> 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 https://nodekit.io/ that aim to provide a
>>> bloat-free universal Electron / Cordova replacement.
>>>
>>> On Wed, Jul 25, 2018 at 12:00 PM, Jacob Pratt <jhprattdev at gmail.com>
>>> 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 farsightsoftware.com> 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 gmail.com> 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 mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180726/84131c11/attachment.html>