I'm a half lurker, as I've participated and thrown out ideas.
I've embedded javascript as a scripting languages outside the web, in
both personal and non-personal projects. I've used Javascript to write
games or experiments just to amuse myself, and this is coming from a
person who still believes C is the best language :)
Everything that has been added to the language of late -- classes and
modules especially -- have been extremely useful. I am really looking
forward to class fields. At this point, the only thing I would like it
support for static typing but I know that less likely, full of politics,
and would be a huge lift, though we have systems that have shown us a way.
These additions have made my code more readable (everything I do is open
source), more obvious, more self-documenting, and more contained to
functional unit (modules!)
I write so much in Javascript now because it's cross platform and can
run most anywhere and browsers are strong enough to be app platforms for
many uses. Easy start up and easy to publish your code for outside parties.
I'm happy with the direction. Even the # private fields, I can deal
with that and frankly that actually makes things more readable! Now,
just get us types (I know, had to end on that!)
[>] Brian
On 7/26/2018 10:55 AM, Luan Nico 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]
<mailto:[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]
<mailto:[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] <mailto:[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]
<mailto:[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] <mailto:[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] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[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
