Re: [nodejs] Re: javascript vision thing

I agree with Isiah. (And like Isiah, I'm just this guy, you know? Not TC39 or anything.) In particular, the constant re-litigating of decided issues, rehashing the same data-free assertions almost every time anything is suggested to move forward, seems flatly off-topic for the list to me, and I'm

Re: [nodejs] Re: javascript vision thing

(Not TC39 or a list admin, so please don't take this as authoritative by any means. These are all my personal opinions and mine only.) To add onto this, could you all maybe take the complaints and general software discussion to Reddit, Twitter, private emails, or elsewhere? Philosophizing about JS

Re: [nodejs] Re: javascript vision thing

I find the general tone of the preceding thread condescending toward developers who have dealt with real problems recent ES additions have addressed. Though I don't think I totally follow your argument that continuing to increase API surface area decreases the surface area for bugs. Perhaps for the

Re: [nodejs] Re: javascript vision thing

> 1. es6 generators and modules are the top 2 notorious things that come to mind as being difficult to debug/integrate in product-development. How exactly are generators and modules difficult to integrate or debug? Difficult compared to what? How are ES modules more complicated for the developer

Re: [nodejs] Re: javascript vision thing

ES6 doesn't encourage any design patterns. All it does is allow you to shorten existing constructs into simpler-to-program ones, and simpler-to-understand ones. I want TC39 to continue in this vein, making big things easier to accomplish with less, hence, speeding up development time (very importan

Re: [nodejs] Re: javascript vision thing

> 1. es6 generators and modules are the top 2 notorious things that come to mind as being difficult to debug/integrate in product-development. How exactly are generators and modules difficult to integrate or debug? Difficult compared to what? How are ES modules more complicated for the developer

Re: [nodejs] Re: javascript vision thing

this is not a troll-account, and I’m a live-person with realistic (albeit uncomfortable) views on limitations of javascript product-development in industry. es6 seems to adopt java’s philosophy that with careful-planning, you can create semi-permanent, well-abstracted code during the design-pha

Re: javascript vision thing

This has little to do with Javascript ... I started coding in 1985 and managing (while still coding) in 1990. I have managed teams of up to 200 working on multiple products at the same time and delivered products in 8086 Assembler, Lisp, Prolog, C++, and Javascript. The only language in which I did

Re: javascript vision thing

Considering how many js devs fail to answer "what values evaluate to false in JavaScript". It isn't the new features that are the problem. There's a combination of problems. People believing they're better developers than they are. People who look down on js and front end development. And those

Re: [nodejs] Re: javascript vision thing

yes, in order of severity: 1. es6 generators and modules are the top 2 notorious things that come to mind as being difficult to debug/integrate in product-development. 2. classes (and typescript, though not directly es6-related), tend to create lots of unnecessary structure that becomes a PITA

Re: Re: javascript vision thing

You do that by going to here, typing in your password, and clicking "unsubscribe" https://mail.mozilla.org/listinfo/es-discuss On Fri, Sep 21, 2018 at 21:11 Darien Valentine wrote: > Unsubscribing from this mailing list, which seems to have become a spam > platform. > __

Re: Re: javascript vision thing

Unsubscribing from this mailing list, which seems to have become a spam platform. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: javascript vision thing

a problem i've observed in industry is that many es6 language-features have the unintended-consequence of incentivising incompetent javascript-developers at the expense of competent-ones. its generally difficult for many employers (even those knowledgeable in general-purpose programming), to di

Re: JSON support for BigInt in ES6. Was: javascript vision thing

@isiah, actionable items before stage-4 are currently being debated @ https://github.com/tc39/proposal-bigint/issues/162 On Aug 1, 2018 14:00, "Isiah Meadows" wrote: > > Is 1 a byte, int, double, BigInt or BigNumber? You tell me! This > obviously > > has major consequences for parsers. Howeve

Re: JSON support for BigInt in ES6. Was: javascript vision thing

> Is 1 a byte, int, double, BigInt or BigNumber? You tell me! This obviously > has major consequences for parsers. However, as long as you stay with the > original JS Number scope everything works just fine. BTW, most strongly typed languages parse numbers one of two ways: - If it's just digit

JSON support for BigInt in ES6. Was: javascript vision thing

Richard et al, If we call the situation "limbo" or not isn't that important, I just happen to have a preference for strong or funny expressions. The root of the problem (not only for JavaScript) is that JSON is *the only general purpose data interchange format in existence* that uses a single

Re: javascript vision thing

JSON is defined by ECMA-404 and RFC 8259, not by ECMA-262. An ECMAScript JSON.parse implementation simply cannot accept e.g. 0n and still uphold the conformance guarantees : > > Conforming implementations of *JSON.parse* and *JSON.stringify* must > s

Re: javascript vision thing

On 2018-07-28 00:34, Richard Gibson wrote: As stated even more strongly in ECMA-404: Because it is so simple, it is not expected that the JSON grammar will ever change. This gives JSON, as a foundational notation, tremendous stability. Richard, that's great but it doesn't completely resp

Re: javascript vision thing

As stated even more strongly in ECMA-404: > > Because it is so simple, it is not expected that the JSON grammar will > ever change. This gives JSON, as a foundational notation, tremendous > stability. On Thu, Jul 26, 2018 at 9:43 AM Jordan Harband wrote: > That's a ridiculous claim, considering

Re: javascript vision thing

That's a ridiculous claim, considering JSON has never supported functions, or `undefined`, or RegExps, or Dates. ES6 also introduced `Symbol`, `Map`, `Set`, etc all of which have no JSON representation. There's no "limbo" - JSON is, and will forever be, a subset of JS. Many new things will be add

Re: javascript vision thing

On Thu, Jul 26, 2018 at 5:23 PM, Anders Rundgren wrote: > On 2018-07-26 17:24, Ranando King wrote: >> >> JSON = JavaScript Object Notation > > This obviously broke down when tc39 introduced BigInt leaving the JSON/JS > community in limbo. Not supporting all of JavaScript's features is nothing new

Re: javascript vision thing

On 2018-07-26 17:24, Ranando King wrote: JSON = JavaScript Object Notation This obviously broke down when tc39 introduced BigInt leaving the JSON/JS community in limbo. Anders ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.o

Re: javascript vision thing

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 beli

Re: javascript vision thing

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 c

Re: javascript vision thing

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

Re: javascript vision thing

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, an

Re: javascript vision thing

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

Re: javascript vision thing

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 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 >

Re: javascript vision thing

Classes are just sugar for a predominant pattern. On Wednesday, July 25, 2018, kai zhu wrote: > > Classes are widely used on the web. See any modern web framework. > > indeed, and i conjecture in doing so, developers have caused more harm > than good for their employers in getting their web-proj

Re: javascript vision thing

> Classes are widely used on the web. See any modern web framework. indeed, and i conjecture in doing so, developers have caused more harm than good for their employers in getting their web-projects shipped, when JSON-serialization web-integration problems arise. On Jul 25, 2018 17:44, "Michael T

Re: javascript vision thing

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 wrote: > there is no foreseeable future where javascript will be a better tool >

Re: javascript vision thing

Classes are widely used on the web. See any modern web framework. On Wednesday, July 25, 2018, kai zhu wrote: > @tj, would you or i care about nodejs/javascript if the language did not > exist in browsers? in fact would anyone on tc39 give a damn about > javascript (aside from its creator) in t

Re: javascript vision thing

@tj, would you or i care about nodejs/javascript if the language did not exist in browsers? in fact would anyone on tc39 give a damn about javascript (aside from its creator) in that scenario? as i've said before [ad nauseam], the only drive most of us [non-frontend-developers] have in javascr

Re: javascript vision thing

For me the biggest thing JSON lacks is the ability to add comments. --- R. Mark Volkmann Object Computing, Inc. > On Jul 25, 2018, at 4:26 AM, Isiah Meadows wrote: > > IMHO, I'd like to see four things: > > - Native JSON multi-object support > - Binary data support that doesn't require delimit

Re: javascript vision thing

IMHO, I'd like to see four things: - Native JSON multi-object support - Binary data support that doesn't require delimiters - Native JSON property streaming support - Spec-level binary JSON support Apart from that, I don't really see anything JSON lacks. - Isiah Meadows m...@isiahmeadows.co

Re: javascript vision thing

On Jul 24, 2018, at 18:29, Anders Rundgren wrote: > > On 2018-07-24 17:09, Carsten Bormann wrote: >> On Jul 24, 2018, at 16:31, Anders Rundgren >> wrote: >>> >>> JSON isn’t really a topic for tc39 only but since the IETF consider JSON >>> "done", an open question is where possible future dev

Re: javascript vision thing

On 2018-07-24 17:09, Carsten Bormann wrote: On Jul 24, 2018, at 16:31, Anders Rundgren wrote: JSON isn’t really a topic for tc39 only but since the IETF consider JSON "done", an open question is where possible future developments should take place, No, that is not the question. includin

Re: javascript vision thing

Native JSON streaming would be nice in my opinion. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: javascript vision thing

Please refrain from jokes about domestic violence. It distracted from the rest of your email, which I decided not to read. Ben Le mar. 24 juill. 2018 11 h 09, Carsten Bormann a écrit : > On Jul 24, 2018, at 16:31, Anders Rundgren > wrote: > > > > JSON isn’t really a topic for tc39 only but sin

Re: javascript vision thing

On Jul 24, 2018, at 16:31, Anders Rundgren wrote: > > JSON isn’t really a topic for tc39 only but since the IETF consider JSON > "done", an open question is where possible future developments should take > place, What is the best place where I should beat my wife? No, that is not the question

Re: javascript vision thing

> Personally I think the JSON WG should be rebooted but apparently I'm rather alone with that idea. You're not alone in wanting to see the JSON WG get back to work. I'd also like to see the addition of a syntax for serializing recursive structures. On Tue, Jul 24, 2018 at 9:32 AM Anders Rundgren

Re: javascript vision thing

On 2018-07-24 12:27, kai zhu wrote: tldr - tc39 should focus more on JSON-friendly javascript-language-features instead of wasting-time on hard-to-serialize classes/meta-programming. JSON isn't really a topic for tc39 only but since the IETF consider JSON "done", an open question is where pos

Re: javascript vision thing

On Tue, Jul 24, 2018 at 11:27 AM, kai zhu wrote: > tldr - tc39 should focus more on JSON-friendly javascript-language-features > instead of wasting-time on hard-to-serialize classes/meta-programming. This is a false dichotomy (the fallacy of the either/or choice). I'd agree we're approaching, or

Re: javascript vision thing

tldr - tc39 should focus more on JSON-friendly javascript-language-features instead of wasting-time on hard-to-serialize classes/meta-programming. have you ever wondered why javascript is so popular? why you decided to become a nodejs/backend-javascript programmer? javascript’s popularity is no

Re: javascript vision thing

Front end. You wouldn't create the uploader in a JavaScript class. You would do so in a component HTML template and use its associated JavaScript class as the model/controller layer. Async stuff is really easy. This doesn't change whether you use the class / a static function / another class. Isi

Re: javascript vision thing

> > C#'s event model is like the DOM's or Node's if you were to factor event > names to separate variables, like `foo.bar.listen(callback)` instead of > `foo.on("bar", callback)`. Android's works similarly to JavaScript, > although it uses enums instead of strings. foo.bar.listen(callback) is no

Re: javascript vision thing

Kai, I'll come at this from a full stack perspective - I've done a lot of both front-end and Node.js work, and I know how they compare. 1. Promises are useful for pretty much any one-off async action. They're *way* easier to manage than callbacks for anything substantial, and they take less code.

Re: javascript vision thing

> To answer your question, yes I've done async with classes. It poses no additional challenge whatsoever. did you do async with classes on the frontend or backend? because its generally more difficult to do when working with the ui (and also why javascript-fatigue is so prevalent among frontend de

Re: javascript vision thing

Aynchronicity has nothing to do with whether you use class instance methods or static functions. The only difference is whether `this` or an arg is the instance, and the ability to override in type hierarchies, and whether you can use a plain data object (without functions/methods) as the instance.

Re: javascript vision thing

On Dec 19, 2017 01:36, "Naveen Chawla" wrote: > > Using static methods with plain objects can be cool if you don't want method overriding and/or inheritance. Otherwise using classes and methods makes that simpler to accomplish. @naveen, have you tried adding asynchronous features (e.g. typeahead

Re: javascript vision thing

Using static methods with plain objects can be cool if you don't want method overriding and/or inheritance. Otherwise using classes and methods makes that simpler to accomplish. On Mon, 18 Dec 2017 at 20:53 Isiah Meadows wrote: > For one specific example, plain objects can be treated like C stru

Re: javascript vision thing

For one specific example, plain objects can be treated like C structs. For most scenarios you'd want "methods", you could get away just as easily with functions taking the instance as an argument (in particular, you could still use `this`, although I don't in practice). I've used this pattern quit

Re: javascript vision thing

Javascript won't lose plain objects. Classes simplify cases of type hierarchies that require overriden methods, and offer a memory performance gain in the case of when there are many instances vs using plain objects to do the same (which incurs a memory overhead for each instance's functions even w

Re: javascript vision thing

I appreciate hearing Kai's point of view and think that we've had this exact discussion enough times. At this point it just adds to inbox weight without changing any minds On Dec 18 2017, at 8:23 am, Terence M. Bandoian wrote: > I appreciate hearing Kai's point of view and don't think he should

Re: javascript vision thing

I appreciate hearing Kai's point of view and don't think he should be silenced. -Terence Bandoian On 12/17/2017 2:03 PM, T.J. Crowder wrote: On Sun, Dec 17, 2017 at 7:21 PM, Jordan Harband > wrote: > > Adding features in *no way* sacrifices simplicity or ease-of-use >

Re: javascript vision thing

On Sun, Dec 17, 2017 at 7:21 PM, Jordan Harband wrote: > > Adding features in *no way* sacrifices simplicity or ease-of-use > for smaller web projects; as has been said many times on this > list, if you don't like any new feature, simply choose not to use > it. And in many or even most cases, mar

Re: javascript vision thing

Adding features in *no way* sacrifices simplicity or ease-of-use for smaller web projects; as has been said many times on this list, if you don't like any new feature, simply choose not to use it. On Sun, Dec 17, 2017 at 6:21 AM, Pier Bover wrote: > I doubt there is a long term grand vision for

Re: javascript vision thing

I doubt there is a long term grand vision for JS. After all the focus is on small incremental changes. Personally I'd love to see optional static typings implement into the language much like we had in ES4 but I feel it's too big of a change to be considered by TC39. My hope now is on completely

Re: javascript vision thing

i'm generally curious what the overall vision is for those who want continued aggressive evolution of the javascript-language. is it to transform javascript into a class-based language similar to c#? also, is another part of the vision to add features to javascript to solve special engineering-pro

Re: javascript vision thing

On Tue, Nov 28, 2017 at 7:41 PM, Isiah Meadows wrote: > > I think you pretty much hit the nail on the head here. > Probably best if we can just let this thread die now. Thirded. ;-) -- T.J. Crowder ___ es-discuss mailing list es-discuss@mozilla.org htt

Re: javascript vision thing

I think you pretty much hit the nail on the head here. Probably best if we can just let this thread die now. On Tue, Nov 28, 2017, 10:20 kdex wrote: > I apologize for my ignorance, but I've been seeing this thread in my inbox > for > around a month now, and most of what's being discussed is just

Re: javascript vision thing

I apologize for my ignorance, but I've been seeing this thread in my inbox for around a month now, and most of what's being discussed is just people glorifying ES5 and other people justifying the usefulness of recent language additions. This discussion has gone way off-topic and appears to be a

Re: javascript vision thing

On Tue, Nov 28, 2017 at 6:19 AM, kai zhu wrote: > > On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder < > tj.crow...@farsightsoftware.com> wrote: > > You mean, it's a tool to write computer instructions for taking input, > manipulating it, and generating output? Breaking news: That's what all > progra

Re: javascript vision thing

On Tue, Nov 28, 2017 at 2:19 PM, kai zhu wrote: > > > On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder ... wrote: > > You mean, it's a tool to write computer instructions for taking > > input, manipulating it, and generating output? Breaking news: > > That's what all programming languages are. > > ...

Re: javascript vision thing

I oppose moderation. These views about ES, however misguided they might seem, allow us to reaffirm the reasons why decisions were made and guide those with similar views to the answers to their concerns. I don't see any loss, only gain, in engaging these concerns. On Tue, 28 Nov 2017 at 13:46 Jame

Re: javascript vision thing

I don't understand what this thread is even trying to achieve. This mailing list should really just be shut down. The lack of moderation ruins it and it sucks having to subscribe to it for the occasional important/interesting information/discussion. I'd rather have that content moved to one of the

Re: javascript vision thing

On Tue, Nov 28, 2017 at 6:40 AM, kai zhu wrote: > > if i were asked what the vision of javascript is my current > answer would be: > "javascript is a tool to take JSON-input, manipulate it, and > output it back out (via DOM, event-handling, network-socket, > file-io, or db-driver)." You mean, it'

Re: javascript vision thing

If classes contain all the "super powers" and their instance handle their own states it's straight forward to serialize JS these days following basic conventions (easy to do with poisoned objects) ```js class Serializable { // usable as JSON.parse(str, Serializable.fromJSON) static fromJSON(k

Re: javascript vision thing

On Thu, Nov 2, 2017 at 4:43 AM, kai zhu wrote: > > the primary reason is because traditional oop skills gained from > c#/c++/java/python/etc translate poorly to javascript. > I've never found that to be the case. >in javascript, class-instantiated objects are inferior to plain-objects, > because

Re: FW: javascript vision thing

, or whatever. > >> 3. JavaScript "classes" are not technically class-based OOP, and TC39 > >> members have acknowledged this in blog posts. It's 99% sugar over the > >> existing prototype-based model, just with easier native subclassing. > >> You

Re: FW: javascript vision thing

over the >> existing prototype-based model, just with easier native subclassing. >> You could in theory replicate this in the rest of the language with a >> combination of `Object.defineProperty`, `Object.setPrototypeOf`, >> `new.target`, and existing ES5. >> - &

Re: FW: javascript vision thing

Or a new website? > Send me an email and we can get started. > www.isiahmeadows.com > > > On Thu, Nov 2, 2017 at 4:32 PM, doodad-js Admin > wrote: > > > > -Original Message- > > From: Claude Petit [mailto:p...@webmail.us] > > Sent: Thursday, Novemb

Re: FW: javascript vision thing

iah Meadows m...@isiahmeadows.com Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com On Thu, Nov 2, 2017 at 4:32 PM, doodad-js Admin wrote: > > -Original Message- > From: Claude Petit [mailto:p...@webmail.us] > Sent: Thursday, Novem

FW: javascript vision thing

-Original Message- From: Claude Petit [mailto:p...@webmail.us] Sent: Thursday, November 02, 2017 4:24 PM To: 'kai zhu' ; 'es-discuss' Subject: RE: javascript vision thing For mostly real OOP under JS, please see my project (doodad-js). But I can't warranty it

Re: javascript vision thing

On Thu, Nov 2, 2017 at 3:43 AM, kai zhu wrote: > any thoughts? i'll break the ice with a quora question i recently answered Link to that answer for those who are interested: https://www.quora.com/Why-is-JavaScript-so-hated/answer/Kai-Zhu-9 > > Why is JavaScript so hated? I have seen no indicati

Re: javascript vision thing

I'm really not sure what "civil war" you're referring to; nor do I agree that JavaScript is any more hated than anything else. Plain objects don't come with JSON representations "baked in" because functions, undefined, regexes, dates, etc all don't serialize. Frontend development is not "alienate

javascript vision thing

any thoughts? i'll break the ice with a quora question i recently answered quora question: > Why is JavaScript so hated? answer posted: >the primary reason is because traditional oop skills gained from >c#/c++/java/python/etc translate poorly to javascript. > >in javascript, class-instantiated o