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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> >>> 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 < >>>> [email protected]> 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 >>>>> <[email protected]> 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 >>>>> [email protected] >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
