javascript vision thing
Brian Barnes
ggadwa at charter.net
Thu Jul 26 15:31:13 UTC 2018
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 <isiahmeadows at gmail.com
> <mailto: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
> <mailto: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 <mailto: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
> <mailto: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 <mailto: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 <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto: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
>
More information about the es-discuss
mailing list