luannico27+es-discuss at gmail.com
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
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>
> 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.
>> 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
>> 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>
>>> 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:
>>>> > 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.
>>>> 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
>>>> 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
>>>> embedded device work, completely removed from the web environment. And so
>>>> 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
>>>> 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
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss