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 "alienated"; in fact, the additions made in ES6 are widely loved overall (even though there are, as with anything, scattered complaints).
On Thu, Nov 2, 2017 at 3:43 AM, kai zhu <kaizhu256 at gmail.com> wrote:
any thoughts? i'll break the ice with a quora question i recently answered
Link to that answer for those who are interested: www.quora.com/Why-is-JavaScript-so-hated/answer/Kai-Zhu-9
Why is JavaScript so hated?
I have seen no indication that it is. Quite the reverse. And like Jordan, I see a lot of love for the improvements in ES2015 and ES2017 (and many of the current Stage 3 proposals which seem likely to make it to ES2018, like object rest/spread).
the primary reason is because traditional oop skills gained from c#/c++/java/python/etc translate poorly to javascript.
I disagree. Understanding the concepts of objects and object references, creation patterns (constructor, builder, etc.), functions/methods, pass-by-value (which is dominant in those languages), mutability vs. immutability -- all of these are just the same.
Yes, the fact JavaScript used Java syntax but is prototype-based rather than class-based can trip people up if they don't have experience of prototype-based languages (which are less common today than class-based ones) and don't bother to read a tutorial or two before jumping in. (Disclosure: I made that mistake, years ago.) There are things to learn in any new language. I see Java people tripped up by generics or nested classes every bit as much.
in javascript, class-instantiated objects are inferior to plain-objects, because plain-objects come with JSON.stringify/JSON.parse baked-in
No more or less so than objects created with other constructors.
..., while classes require needless extra serialization/deserialization routines which can easily double your codebase or more (as real-world javascript-code is heavily i/o based).
First, if serialization code is doubling your codebase, you're doing it wrong. :-)
But more importantly, no, serialization is no easier with objects created only with the Object constructor than it is with objects created with other constructors. In both cases, if you want true objects (not just property bags), you have to reattach their methods. Doing so is not difficult.
javascript and frontend-programming...
False conflation.
...there's currently a civil war going on in frontend-development,
The gentlest characterization I can make of that statement is that it's...hyperbolic. There is no civil war. There are a couple of different object creation patterns, and some people use one kind, and other people use another kind. In both cases, you end up with objects with properties and methods, which can interoperate just fine. It's like claiming there's a civil war in the Java world because some projects use constructors and others use the Builder pattern. E.g., a gross mischaracterization.
-- T.J. Crowder
-----Original Message----- From: Claude Petit [mailto:petc at webmail.us] Sent: Thursday, November 02, 2017 4:24 PM To: 'kai zhu' <kaizhu256 at gmail.com>; 'es-discuss' <es-discuss at mozilla.org>
Subject: RE: javascript vision thing
For mostly real OOP under JS, please see my project (doodad-js). But I can't warranty its future without a custom language because nobody
Honestly, this entire thread reads as partially misinformed, borderline trollbait. These kinds of questions and thoughts should really be asked directly (and a bit more respectfully) to TC39 representatives and/or put in blog posts wherever. es-discuss is primarily about language design, and although the subject implies it's about the language's design in the abstract, I'm not convinced the content and responses really are.
- Claims of a language "civil war" don't belong on this list, and are objectively false. Yes, there's disagreement, but even TC39 members aren't exactly in agreement here - consider the difference between Lodash/Ecmarkdown (Domenic Denicola) and Ecmarkup (Brian Terlson). Please take that into account.
- Yes, there are multiple idiomatic uses of JavaScript, but it's
large enough you can carve out a subset and be done with it. You don't
like classes? Don't use them. You don't like arrow functions? Don't
use them. You don't like
array.map? Don't use it. Just because they exist doesn't obligate you to use them, and they don't hurt you in any way if you don't. Also, complaints of a person's or group's choice of idiom do not belong on this list whatsoever. Leave that crap to a private message, a blog post (if it's a group), or whatever. - 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 could in theory replicate this in the rest of the language with a
combination of
Object.defineProperty,Object.setPrototypeOf,new.target, and existing ES5.
Isiah Meadows me at isiahmeadows.com
Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com
I agree with everything else you said but since you mentioned the word "misinformed" I'd like to improve this misleading sentence:
It's 99% sugar over the existing prototype-based model
This has been one of the most misunderstood and undertaken parts of ES6.
Classes are not just sugar, thinking about classes as just sugar that can be replicated on ES5 is FUD and even if I've pointed out Babel documentation has a wrong description of classes it's still there and 99% of developers believe classes are like that, just sugar over prototypal inheritance.
This is so wrong that TypeScript fails with the most basic extend:
class List extends Array { method() {} }
(new List) instanceof List; // false
(new List).method(); // throws because it's not a List so no method
To simulate ES2015 classes you need Reflect.construct, unavailable in ES5.
Polyfilling Reflect.construct with ES5 features is not enough: you need
Symbols too.
Symbols are technically impossible to polyfill (i've gone very close, yet not a perfect poly). Symbols are needed to keep the instance so that in a transpiled world:
(new List).slice() instanceof List; // true
Most developers that went for classes have broken code out of the box thanks to transpilers and yet at the end of 2017 we keep writing that ES classes are just sugar on top of ES5.
We should stop starting from this ML to keep spreading this wrong information.
Thank you all for your understanding.
it may be standard-operating-procedure to sub-class builtin arrays in other languages. but it becomes awkward in javascript when time comes around to serializing/reconstructing the custom array-type while baton-passing it around frontend<->backend<->database via JSON.
it becomes awkward in javascript when time comes around to serializing/reconstructing the custom array-type
To be honest, I've found that overriding toJSON() and providing some
static helpers for your JSON.parse() reviver lead to pretty expressive
(de)serializability:
class MySerializableArray extends Array {
toJSON() { return { $type: this.constructor.name, items: Object.values(this) } }
static isSerializedInstance(val) { return typeof val === 'object' && val.$type === 'MySerializableArray' && Array.isArray(val.items); }
}
const reviver = (key, val) => { if (MySerializableArray.isSerializedInstance(val)) { return new MySerializableArray(...val.items); } return val; };
const instance = new MySerializableArray('a', 'b', 'c'), serialized = JSON.stringify(instance), parsed = JSON.parse(serialized, reviver);
jsbin.com/kasiwevobo/edit?js,console
If that's too much boilerplate for you, there's probably some low hanging fruit for a decorator implementation that generalizes some reasonable default serialization behavior.
On Thu, Nov 2, 2017 at 4:43 AM, kai zhu <kaizhu256 at gmail.com> 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 plain-objects come with JSON.stringify/JSON.parse baked-in, while classes require needless extra serialization/deserialization routines which can easily double your codebase or more (as real-world javascript-code is heavily i/o based). i would say many people burn-out from frontend-programming because they can’t cope with debugging all the i/o edge-cases serializing/deserializing their custom classes.
javascript and frontend-programming is essentially about efficiently managing the program-state like a baton, constantly passing it back-and-forth between the browser’s ui and various backend-servers / persistent-storage. plain json-objects utilizing idiot-proof JSON.stringify/JSON.parse, are naturally better at this baton-passing business than writing classes with custom serializers.
I dislike many things about JS, and I've been writing JS since 2002. It never occured to me, not once, until 3 minutes ago, that this was in any way, shape or form some significant JS disadvantage, primary concern of anything or even any sort of impediment.
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)
class Serializable {
// usable as JSON.parse(str, Serializable.fromJSON)
static fromJSON(key, value) {
if (value.hasOwnProperty('__proto__')) {
const Class = value.__proto__.split('.').reduce(
(o, k) => o[k],
typeof global === 'object' ? global : window
);
delete value.__proto__;
return Object.create(Class.prototype, value);
}
return value;
}
// provide a way to retrieve your class back
// from a namespace
static toJSON() {
return this.name;
}
// serialize any instance
toJSON() {
return Object.defineProperty(
Object.getOwnPropertyDescriptors(this),
'__proto__',
{
enumerable: true,
value: this.constructor.toJSON()
}
);
}
}
Assuming the class is somehow reachable, something that is an issue with any other language too (the class must be available to properly unserialize)
window.Anything = class Anything extends Serializable {
constructor(pub, acc) {
super();
this.public = pub;
this.accessor = acc;
}
get accessor() {
return this._private;
}
set accessor(value) {
Object.defineProperty(this, '_private', {
configurable: true,
value
});
}
};
you can serialize and unserialize instances with ease:
const before = new Anything(123, 456);
const serialized = JSON.stringify(before);
const after = JSON.parse(serialized, Anything.fromJSON);
console.log(
after.public,
after.accessor
);
There are also battle tested utilities to make recursive properties serializable too (CircularJSON to name one).
Yet, what everyone serliazes and unserializes instead, is some data any instance could eventually consume so having full classes/instances there doesn't apparently bring much value.
Serialization is IMO one of those things when you come from capable langauges you apparently cannot live without, but you forget on your way with JS and its debugging ability across various environments.
@jeremy and @andrea the workarounds using to/fromJSON wouldn't be necessary in first place, if static-functions were employed instead of classes.
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)." that vision is the same whether javascript is used in browsers, servers, or embedded-systems.
es5 was the epitomy of achieving that vision in the simplest way possible.
what did es6 bring? symbols, meta-programming, and fancy ways to construct classes. but classes in javascript are usually transient things whose ultimate purpose is to serialize to JSON-output and then get destroyed. that is a poor use for them, compared to using static-functions to directly manipulate JSON-input and outputting it back out. i would say most things you write in es6 with classes to handle JSON data could be done more efficiently with half-the-code using static-functions. and a growing number of people with javascript fatigue probably realize this.
for a real-world example of what i'm talking about, here's a web-demo of a google-maps javascript-client @ kaizhu256.github.io/node-swgg-google-maps/build..beta..travis-ci.org/app/#!swgg_id__2Fmaps_2Fapi_2Fdirections_2Fjson_20GET_1
the app use no classes whatsoever. it relies entirely on static-functions to baton-pass JSON-data between dom <-> browser <->
proxy-server <-> google-server (or nodejs <-> google-server).
On Tue, Nov 28, 2017 at 6:40 AM, kai zhu <kaizhu256 at gmail.com> 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's a tool to write computer instructions for taking input, manipulating it, and generating output? Breaking news: That's what all programming languages are.
If you mean specifically JSON, and specifically a DOM, and specifically network I/O and DBs and...well, sorry; as you've been repeatedly told, your vision is at odds with that of the JavaScript community at large and, I believe, of the committee. JavaScript is bigger than that. Cope. Because I don't see that changing. Harping on about that conflict on this list is simply not useful.
es5 was the epitomy of achieving that vision in the simplest way possible.
Great. Again: Keep using it. Nothing is stopping you or anyone else. The
committee have done a huge amount of work to maintain backward
compatibility. (Speaking of which: In all the harping, I don't recall
hearing a thing from you appreciating that hard work from the committee.
Did I just miss it?) Yes, it's 99.99999999% instead of 100%, and code
written assuming nothing would ever change (say, values from typeof) was
ever-so-slightly impacted. Well, that's unfortunate, but it's very much an
exception to the rule of compatibility, the decision was not made lightly
or without research on impact, and it's not like it takes any significant
time to fix the code in question. Rather less time than complaining about
it on the list, in fact.
You have a different view from most reasonably-informed people on this. You're entitled to it. As a reasonably-informed person, you're entitled to express it, and you have. It's time to move on.
-- T.J. Crowder
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 other channels of communication which have been more successful.
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 6:51 pm, T.J. Crowder <tj.crowder at 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 programming languages are.
@T.J. the thing about javascript as a "tool mainly for baton-passing JSON-data around", is that unlike other programming languages that take generic io data, javascript oftentimes doesn't need a class-abstraction layer to parse the input, or serialilze to output, because they are already in JSON.
i already demonstrated the feasibility of a non-trivial webapp that has no class-abstraction layer - it relies on static-functions instead to directly manipulate JSON/plain-text to/from io (aside from builtin classes like XMLHttpRequest that i have to use for ajax).
showing you can efficiently manage javascript's JSON-focused io with static-functions and no class-abstraction layer then raises the question of the necessity of all the class-related tc39 proposals being considered.
demo urls:
On Tue, Nov 28, 2017 at 2:19 PM, kai zhu <kaizhu256 at gmail.com> 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.
...the thing about javascript as a "tool mainly for baton-passing JSON-data around", is that unlike other programming languages that take generic io data...
Well, no, it isn't. It's just like other programming languages: Used in a variety of environments, with different inputs and outputs. A point which has repeatedly been made to you by multiple different people.
i already demonstrated the feasibility of a non-trivial webapp that has no class-abstraction layer
I never said you couldn't. You can write just about everything with just about every paradigm out there. Which is entirely irrelevant.
-- T.J. Crowder
On Tue, Nov 28, 2017 at 6:19 AM, kai zhu <kaizhu256 at gmail.com> wrote:
On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder < tj.crowder at 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 programming languages are.
@T.J. the thing about javascript as a "tool mainly for baton-passing JSON-data around", is that unlike other programming languages that take generic io data,
javascript has grown to be a generally useful language; and indeed because it had the ability to read generic IO data; maybe that's somewhat incorrect... systems supporting javascript have been created that allow generic IO.
NodeOS node-os.com some really powerful fontend chosts - Electron and NWJS for instances ( above and beyond what a browser can do itself, or working standalone without requiring passing batons to anyone)
3D and Vr programming webvr.info, threejs.org
I used it to create 100's of millions of bingo cards (would have been able to do that faster if I had threads but broke it up into several processes in parallel and managed it quite quickly) Those got output as a binary format (also SQL and CSV flavors)
It even works well to add logic to GUI elements created outside of a browser www.npmjs.com/package/sack.vfs#frame-methods
I do think you're looking at the world somewhat myopically or with a bit of tunnel vision.
While true, classes don't help in basically any of those cases... and they really tke javascript as just the pure functional language it started as ( just like it's C roots, which I found rather amused that Functional Programming is this 'grand new thing that javascript does'
I would have used classes more, but since they encapsulate no data, I found them more of a hinderance to develop since I had to do all the work in a constructor/factory anyway the extra cryptic layer I find unnessecary. If it had supported data fields, I'd think there would be additional performance benefits to having a full template, without having to adjust underlaying tracking to add fields all the time.
From long time in C, my development practice is always to create the data
structures I'm using and then create the functions to manipulate said structures; having functions first and nothing to operate on is kinda useless... Javascript does such a habit a little harder to follow, requiring a factory for the structure first like these ... mrdoob/three.js/tree/dev/src/math vectors, matrixes, etc....
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 general rambling thread about certain language standards or even the language itself. I don't see how this discussion is productive in any way.
Could someone please point out the exact problem that this discussion is trying to solve? Note that the usual platitudes apply, i.e.,
- Classes have been standardized and aren't going anywhere, and the same applies to functions. Get used to things evolving.
- The language has its weirdnesses, yes, but so does every other language.
- Classes are just syntactic sugar, so why would it be so tremendously hard to mix them?
- What stops you from just not using the features that your personal ideology or religion forbids you to use?
Please do correct me if I'm missing the point here, but I just can't see what this thread is trying to achieve.
I think you pretty much hit the nail on the head here. Probably best if we can just let this thread die now.
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-problems encountered by large companies like google/facebook/microsoft as a trade-off to simplicity and ease-of-use for smaller web-projects?
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 being able to replace JS by Web Assembly in a couple of years and write on whatever language I prefer.
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 7:21 PM, Jordan Harband <ljharb at gmail.com> 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, markedly improves simplicity and ease-of-use. As has also been repeatedly pointed out.
Kai: Genuine questions are fine. Questions which are really just you pushing your agenda of "don't change anything ever again" and your personal -- and solitary -- claim that "all this new stuff makes life difficult for people" are, at best, pointless. Your position has been made crystal clear. There's no need to bang on about it.
-- T.J. Crowder
I appreciate hearing Kai's point of view and don't think he should be silenced.
-Terence Bandoian
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
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 when they are the same as each other). The only encapsulated way of doing this before ES6 was to use prototype, which is easier to get wrong especially if there is more than two levels of depth of method inheritance.
You get to chose what works for you. You can even argue for using plain objects in certain cases where somebody has decided to use classes. That has nothing to do with what the language offers for those whose applications are simpler and more performant using classes instead.
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 quite a bit when I have a bit of state that needs accessed in several places, but actions are more easily encapsulated. This isn't as elegant for things like DSLs, but it's useful for more stateful programming.
Isiah Meadows me at isiahmeadows.com
Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com
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 Dec 19, 2017 01:36, "Naveen Chawla" <naveen.chwl at gmail.com> 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 search or typeahead input-validation) to a frontend-ui that primarily relied on classes? you generally cannot implement these features like you would for BLOCKING code (as taught in college cs) by simply updating a class-method or two. in practice, you oftentimes have to rewrite the entire class to accomodate a "simple" ui feature-request that changed the async data-flow. classes normally end up being a non-reusable pile of async-hacks as a frontend-ui evolves, which makes them no better than writing throwaway static-functions from the start. at least there's no pretension for re-usability when writing throwaway static-functions, with the more realistic expectation they will be constantly re-written as async-feature-request get added.
On Mon, 18 Dec 2017 at 20:53 Isiah Meadows <isiahmeadows at gmail.com> wrote:
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 quite a bit when I have a bit of state that needs accessed in several places, but actions are more easily encapsulated. This isn't as elegant for things like DSLs, but it's useful for more stateful programming.
Isiah Meadows me at isiahmeadows.com
Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com
On Mon, Dec 18, 2017 at 6:25 AM, Naveen Chawla <naveen.chwl at gmail.com>
wrote:
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 when they are the same as each other). The only encapsulated way
of
doing this before ES6 was to use prototype, which is easier to get
wrong
especially if there is more than two levels of depth of method
inheritance.
You get to chose what works for you. You can even argue for using plain objects in certain cases where somebody has decided to use classes.
That has
nothing to do with what the language offers for those whose
applications are
simpler and more performant using classes instead.
On Mon, 18 Dec 2017 at 03:31 Frederick Stark <coagmano at gmail.com>
wrote:
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 <terence at tmbsw.com>
wrote:
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 <ljharb at gmail.com>
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, markedly improves simplicity and ease-of-use. As has also been repeatedly pointed out.
Kai: Genuine questions are fine. Questions which are really just you pushing your agenda of "don't change anything ever again" and your
personal
-- and solitary -- claim that "all this new stuff makes life
difficult for
people" are, at best, pointless. Your position has been made crystal
clear.
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.
Every other logical necessity when things change is the same.
Just use the one that's simpler to implement based on what your app is doing!
To answer your question, yes I've done async with classes. It poses no additional challenge whatsoever.
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 developers).
for example (and this is a great frontend interview question btw), how many proponents on this mailing-list who envision transforming javascript into c# know how to implement a frontend-class to upload images/files (encompassing the ui-element, ajax form-uploader, progress-indicator, and post-upload previewer), that can be made re-usable across different use-cases such as facebook and gmail? if you don't know how to implement such a re-usable class, then your opinion on the design and architecture of javascript classes doesn't mean much from a frontend-perspective.
i suspect most backend nodejs programmers would not know how to implement such re-usable code. frontend-engineers otoh, are now constantly being asked to write such stuff using es6 classes (but its so simple! frontend! easy compared to backend!). if many of the javascript new-comers transitioning from backend c# were put in such frontend-shoes, it wouldn't be hard to imagine them developing javascript-fatigue and burning out as well.
On Dec 20, 2017 3:02 PM, "Naveen Chawla" <naveen.chwl at gmail.com> wrote:
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. Every other logical necessity when things change is the same.
Just use the one that's simpler to implement based on what your app is
doing!
To answer your question, yes I've done async with classes. It poses no
additional challenge whatsoever.
On Wed, 20 Dec 2017, 8:44 am kai zhu, <kaizhu256 at gmail.com> wrote:
On Dec 19, 2017 01:36, "Naveen Chawla" <naveen.chwl at gmail.com> 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
search or typeahead input-validation) to a frontend-ui that primarily relied on classes? you generally cannot implement these features like you would for BLOCKING code (as taught in college cs) by simply updating a class-method or two. in practice, you oftentimes have to rewrite the entire class to accomodate a "simple" ui feature-request that changed the async data-flow. classes normally end up being a non-reusable pile of async-hacks as a frontend-ui evolves, which makes them no better than writing throwaway static-functions from the start. at least there's no pretension for re-usability when writing throwaway static-functions, with the more realistic expectation they will be constantly re-written as async-feature-request get added.
On Mon, 18 Dec 2017 at 20:53 Isiah Meadows <isiahmeadows at gmail.com>
wrote:
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 quite a bit when I have a bit of state that needs accessed in several places, but actions are more easily encapsulated. This isn't as elegant for things like DSLs, but it's useful for more stateful programming.
Isiah Meadows me at isiahmeadows.com
Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com
On Mon, Dec 18, 2017 at 6:25 AM, Naveen Chawla <naveen.chwl at gmail.com>
wrote:
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 when they are the same as each other). The only encapsulated
way of
doing this before ES6 was to use prototype, which is easier to get
wrong
especially if there is more than two levels of depth of method
inheritance.
You get to chose what works for you. You can even argue for using
plain
objects in certain cases where somebody has decided to use classes.
That has
nothing to do with what the language offers for those whose
applications are
simpler and more performant using classes instead.
On Mon, 18 Dec 2017 at 03:31 Frederick Stark <coagmano at gmail.com>
wrote:
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 <terence at tmbsw.com>
wrote:
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 <ljharb at gmail.com>
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, markedly improves simplicity and ease-of-use. As has also been repeatedly pointed out.
Kai: Genuine questions are fine. Questions which are really just
you
pushing your agenda of "don't change anything ever again" and
your personal
-- and solitary -- claim that "all this new stuff makes life
difficult for
people" are, at best, pointless. Your position has been made
crystal clear.
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.
- 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.
- Event emitters and callbacks are easier to manage for anything async that's not one-off. They're much simpler than classes for most things.
- Sometimes, if your view is a class, it's easier to add a
handleEventand use the instance itself with multiple event handlers. - Node.js work usually requires a lot more one-off async actions (like reading files) than the front end.
- "JavaScript fatigue" has more to do with the mass of library options (and is especially prevalent in React circles) than anything actually about the language.
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.
Also, JavaScript idiomatically prefers classes without much inheritance, and it prefers using promises/observables directly over wrapping them. Don't confuse it with the typical Java/C# idiom of subclassing.
Isiah Meadows me at isiahmeadows.com
Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com
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 offoo.on("bar", callback). Android's works similarly to JavaScript, although it uses enums instead of strings.
foo.bar.listen(callback) is not an event but a signal.
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.
Isiah - JavaScript has no idiomatic preference in terms of depth of inheritance for classes. In fact that's where classes become really useful in the first place.
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 not because of any engineering/technical merits. its entirely a derivative of the fact that browsers have taken over the world, and many new software-jobs are either frontend-related, or some [glorified] form of backend-support for the frontend. the business-proposition for why your employer hired you as a nodejs-developer (vs. php, etc…), is likely because they thought using the same language as their frontend-developer, would allow you to better support the needs of the frontend. and if you can’t do a better job at supporting the frontend than a cheaper php/etc… developer, then you honestly should be fired (or “promoted” to management).
my problem with tc39, is that they “claim” javascript is a general-purpose language (and try to design it as such), when industry-wise, its really not. if javascript was not a browser-language, most employers could not justify hiring developers to create software with it. if tc39 is sincerely interested in keeping javascript a dominant/relevant language in industry, they should focus on practical (vs academic) features that help it maintain its edge as a frontend/web-integration language over its competitors.
and the primary-edge javascript has over its competitors (in an industry dominated by web-programming), is that it can transparently manipulate-and-serialize JSON data-structures between frontend <-> backend systems, while competitors like java depend on clumsy, error-prone, class-constructors and custom-serializers.
kai zhu kaizhu256 at gmail.com
On Tue, Jul 24, 2018 at 11:27 AM, kai zhu <kaizhu256 at gmail.com> 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 at, the need for the next thing after JSON, and that some focus on that would be a good thing. That doesn't mean stopping work on other good things. Perhaps you could take the lead on addressing the issues you run into. I'm sure constructive input would be welcomed.
my problem with tc39, is that they “claim” javascript is a general-purpose language (and try to design it as such), when industry-wise, its really not.
Yes, it is. Just because you don't see it that way doesn't mean others don't. And others have been telling you they see it differently repeatedly over a long period of time on this list.
if tc39 is sincerely interested in keeping javascript a dominant/relevant language in industry, they should focus on practical (vs academic) features
class notation is practical (simplifying a common pattern and making
it less error-prone). (I know you don't use that pattern. That's fine.
But lots of people do, so it's practical for them whether you like the
pattern or not.) Promises are practical (simplifying and standardizing
callbacks, making them composable; again making them less
error-prone). async/await is HUGELY practical, massively
simplifying writing asynchronous code. Arrow functions, rest and
spread, default parameter values -- all practical. (NOT trying to put
words in your mouth, but if you were going to reply "Yes, but those
problems could already be solved in others ways.", then: Sure, and we
could all write assembly code, too. But it's useful to address these
in the language.)
All of them are useful beyond the web. All are also useful in web programming.
I have no problem with skepticism of specific proposals. What I would find useful, though, would be a focus on the proposal's merits, rather than constant re-raising of this claim that JavaScript is a web-only language. You've made that claim, ad nauseum. My view is that it's been rejected by the list membership and by TC39, but whether that's true or I'm mistaken, please stop spamming the list with it. We all know how you feel about it.
But again: I'm sure constructive, research-based input on how to deal with JSON issues related to (for instance) BigInt would be welcome in that BigInt thread and, ideally, eventually a proposal. There's no need for some big conceptual argument over the course of the language -- that is a waste of time.
-- T.J. Crowder
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 possible future developments should take place, including dealing with new data types like BigInt.
Personally I think the JSON WG should be rebooted but apparently I'm rather alone with that idea.
Obvious extensions include comments and dropping the "" requirement on keys that are JS compliant.
Anders
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 Jul 24, 2018, at 16:31, Anders Rundgren <anders.rundgren.net at gmail.com> 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.
including dealing with new data types like BigInt.
That, indeed, is a question for JavaScript. It has nothing to do with “developing” JSON; JSON can already represent BigInt just fine.
Personally I think the JSON WG should be rebooted but apparently I’m rather alone with that idea.
Indeed.
Frankly, JSON, together with the JavaScript-induced limitations in its ecosystem as documented in RFC 7493, is not a very brilliant data interchange format. It is popular because it is extremely simple (at least on the surface), it is already familiar to users of most dynamic programming languages, and it hasn’t changed since 2002. “Changing” JSON simply means no longer having JSON.
(And there are quite a few much better data interchange formats; maybe JavaScript can start to support some of them out of the box.)
Obvious extensions include comments and dropping the "" requirement on keys that are JS compliant.
Shudder. These are not needed for data interchange. For configuration files and other data input by humans, DO NOT USE JSON. If you need YAML(*) (which also has been fully stable for more than a decade, by the way), you know where to find it. YAML also is the extended JSON that so many people are wishing for.
Grüße, Carsten
(*) and of course YAML supports graphs, binary (byte string) data, human-friendly input, etc. It is approximately what any other effort to “humanize” JSON and fill in its shortcomings will arrive at eventually, just with some microdecisions you and I may not like but that are not relevant in the big picture.
Native JSON streaming would be nice in my opinion.
On 2018-07-24 17:09, Carsten Bormann wrote:
On Jul 24, 2018, at 16:31, Anders Rundgren <anders.rundgren.net at gmail.com> 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.
including dealing with new data types like BigInt.
That, indeed, is a question for JavaScript. It has nothing to do with “developing” JSON; JSON can already represent BigInt just fine.
Serializing BigInt as JSON Number is the solution then?
There are a few argument against that:
-
This would typically require low-level parsers to always rely on a BigNumber type. Oracle's JSON-B does exactly that. Currently there is no BigNumber type in JS or .NET.
-
There is quite a bunch of IETF standards defining JSON structures. As far as I know none of them exploit JSON outside of its original, JS-induced limitations.
-
Although BigInt is a very welcome addition to JS, usages are few and typically confined to specific things like crypto or money. Creating backward incompatibility for that is IMO counterproductive.
-
Serializing BigInts as a string does not break anything.
Personally I think the JSON WG should be rebooted but apparently I’m rather alone with that idea.
Indeed.
That might be the case but it doesn't solve the problem.
Frankly, JSON, together with the JavaScript-induced limitations in its ecosystem as documented in RFC 7493, is not a very brilliant data interchange format.
It seems to work well in spite of not being brilliant.
Even "the impossible", JSON Canonicalization actually works as described if you stick to the same limitations existing IETF-defined JSON objects do: tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01
I'm not going into the the rest of the mail because supporting another interchange format is another question.
Yes, CBOR is great tools.ietf.org/html/rfc7049 :-)
On Jul 24, 2018, at 18:29, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
On 2018-07-24 17:09, Carsten Bormann wrote:
On Jul 24, 2018, at 16:31, Anders Rundgren <anders.rundgren.net at gmail.com> 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. including dealing with new data types like BigInt. That, indeed, is a question for JavaScript. It has nothing to do with “developing” JSON; JSON can already represent BigInt just fine.
Serializing BigInt as JSON Number is the solution then?
For applications that make good use of BigInt, I would say so. So you wouldn’t use JSON.parse, but a new interface that preserves integers beyond 2**53 as BigInt (or possibly even all integers; I don’t want to design this on a napkin)
There are a few argument against that:
- This would typically require low-level parsers to always rely on a BigNumber type. Oracle's JSON-B does exactly that. Currently there is no BigNumber type in JS or .NET.
There is no need for the above interface to handle floating point numbers (NR2/NR3).
- There is quite a bunch of IETF standards defining JSON structures. As far as I know none of them exploit JSON outside of its original, JS-induced limitations.
Maybe the IETF was smart enough to stay in the confines of I-JSON…
But really, JSON never had that particular limitation. A JSON-based ecosystem that wants to enable the use of JavaScript JSON.parse does, as Twitter found out when they were sending their perfectly valid JSON to JavaScript applications.
- Although BigInt is a very welcome addition to JS, usages are few and typically confined to specific things like crypto or money. Creating backward incompatibility for that is IMO counterproductive.
Right, so maybe the motivation for touching JSON really isn’t that massive.
- Serializing BigInts as a string does not break anything.
After JSON.parse, they are text strings then, not BigInts. Generally, there is the expectation that, for an interesting set of x, JSON.parse(JSON.stringify(x)) == x Hence the exception when you pass BigInt to JSON.stringify today.
Personally I think the JSON WG should be rebooted but apparently I’m rather alone with that idea. Indeed.
That might be the case but it doesn’t solve the problem.
It also doesn’t create the problem of damaging JSON by instability.
Frankly, JSON, together with the JavaScript-induced limitations in its ecosystem as documented in RFC 7493, is not a very brilliant data interchange format.
It seems to work well in spite of not being brilliant.
Right. As do bicycles. Until you need to transport a sofa or cross the Atlantic. JSON is the right tool for a large number of jobs.
Yes, CBOR is great tools.ietf.org/html/rfc7049 :-)
Can’t disagree here :-)
Grüße, Carsten
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 me at isiahmeadows.com, www.isiahmeadows.com
For me the biggest thing JSON lacks is the ability to add comments.
R. Mark Volkmann Object Computing, Inc.
@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 javascript is making our backend-programs accessible to the masses via browsers/webviews. javascript’s dominance/relevance in industry is as a web-integration language. and its aided by its special-ability to directly serialize JSON data-structures (an underrated, and very useful web-integration feature), while most of its competitors have to rely on clumsy, hard-to-serialize classes.
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. so why does tc39 insist on pushing distracting language-features (clumsy java-like classes, non-integration-friendly meta-programming, static module-loading, etc.) for an unrealistic future-scenario that’s not going to happen?
kai zhu kaizhu256 at gmail.com
Classes are widely used on the web. See any modern web framework.
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:
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
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 Theriot" <michael.lee.theriot at gmail.com>
wrote:
Classes are widely used on the web. See any modern web framework.
On Wednesday, July 25, 2018, kai zhu <kaizhu256 at gmail.com> 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 that scenario? as i've said before [ad nauseam], the only drive most of us [non-frontend-developers] have in javascript is making our backend-programs accessible to the masses via browsers/webviews. javascript’s dominance/relevance in industry is as a web-integration language. and its aided by its special-ability to directly serialize JSON data-structures (an underrated, and very useful web-integration feature), while most of its competitors have to rely on clumsy, hard-to-serialize classes.
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. so why does tc39 insist on pushing distracting language-features (clumsy java-like classes, non-integration-friendly meta-programming, static module-loading, etc.) for an unrealistic future-scenario that’s not going to happen?
kai zhu kaizhu256 at gmail.com
On 24 Jul 2018, at 5:56 PM, T.J. Crowder <
tj.crowder at farsightsoftware.com> wrote:
On Tue, Jul 24, 2018 at 11:27 AM, kai zhu <kaizhu256 at gmail.com> 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 at, the need for the next thing after JSON, and that some focus on that would be a good thing. That doesn't mean stopping work on other good things. Perhaps you could take the lead on addressing the issues you run into. I'm sure constructive input would be welcomed.
my problem with tc39, is that they “claim” javascript is a
general-purpose
language (and try to design it as such), when industry-wise, its
really not.
Yes, it is. Just because you don't see it that way doesn't mean others don't. And others have been telling you they see it differently repeatedly over a long period of time on this list.
if tc39 is sincerely interested in keeping javascript a dominant/relevant language in
industry,
they should focus on practical (vs academic) features
classnotation is practical (simplifying a common pattern and making it less error-prone). (I know you don't use that pattern. That's fine. But lots of people do, so it's practical for them whether you like the pattern or not.) Promises are practical (simplifying and standardizing callbacks, making them composable; again making them less error-prone).async/awaitis HUGELY practical, massively simplifying writing asynchronous code. Arrow functions, rest and spread, default parameter values -- all practical. (NOT trying to put words in your mouth, but if you were going to reply "Yes, but those problems could already be solved in others ways.", then: Sure, and we could all write assembly code, too. But it's useful to address these in the language.)All of them are useful beyond the web. All are also useful in web
programming.
Classes are just sugar for a predominant pattern.
Mostly a lurker here. I fully agree with your points, and also use JS for non-web projects.
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 nodekit.io that aim to provide a bloat-free universal Electron / Cordova replacement.
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.
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).
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.
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 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
On Thu, Jul 26, 2018 at 5:23 PM, Anders Rundgren <anders.rundgren.net at gmail.com> 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. JSON doesn't handle Date instances, Maps, Sets, or Symbols as values either (much less Symbols as keys).
But JSON support for BigInt (or BitInt support JSON, whatever) is something to pick up in its thread, not here.
-- T.J. Crowder
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 added to JS, and none of them will likely ever be added to JSON at this point.
As stated even more strongly in ECMA-404:
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 respond to my "limbo" claim:
Take your pick! Whatever you come up with, I'm sure there will be some rotten tomatoes flying around :-)
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 tc39.github.io/ecma262/#sec-json-object:
Conforming implementations of JSON.parse and JSON.stringify must support the exact interchange format described in the ECMA-404 specification without any deletions or extensions to the format.
Both BigInt and Symbol lack native support in JSON, and although adding in custom serialization is relatively easy, custom parsing is not because JSON.parse doesn't expose the text used to produce a value. But in my opinion, it would be a mistake to characterize that explicit lack of support as "limbo".
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 discern between:
a) a competent javascript employee/contractor who can get things done and ship products (albeit with legitimate delays), and b) an incompetent-one who can easily hide themselves in non-productive es6 busywork, and continually pushback product-integration (again with “legitimate” delays, until its too late).
its gotten bad enough that many industry-employers no longer trust general-purpose-programming technical-interviews when recruiting js-devs, and rely almost exclusively on either a) an applicant's reputation / word-of-mouth for getting things done, or b) their ability to complete a time-consuming tech-challenge, where they must demonstrate ability to ship a mini-product. both methods are not scalable to meet the demand in industry for qualified js-devs in product-development.
the only solution i can think of to this industry-problem is to hold-back on introducing new disruptive/unproven javascript design-patterns, and figuring out how to educate the industry with tightened javascript style-guides and existing design-patterns proven to work (more is less); generally, ways to enhance the current, woefully inadequate “bullsh*t detector” of employers so they can better identify and mentor/train/weed-out unqualified js-devs.
kai zhu kaizhu256 at gmail.com
Unsubscribing from this mailing list, which seems to have become a spam platform.
You do that by going to here, typing in your password, and clicking "unsubscribe"
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 ahead to learn new things.
JS isn't really evolving any more than Java, C#, go, python and others as a whole in the past 20 years. And having to fight uphill to use newer features is a pain. I'm not on the younger side of this (I'm 42)... But I've managed to keep up.
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 not see this issue was Assembler. So, from my perspective, the problem has been around for over 25 years and probably goes beyond the software development realm.
In my experience, during an interview, close to 100 percent of developers will rate themselves as a 7 or an 8 out of 10 (with 10 being best).
any thoughts? i'll break the ice with a quora question i recently answered
quora question:
answer posted:
there's currently a civil war going on in frontend-development, between those who don't want to deal with writing extra class-based serializers/deserializers and those who do. these 2 different design patterns have incompatible styleguides that often break web-projects when people try to mix-and-match both together. i don't have a simple solution to this issue, but tc39 should be made aware of it as they try to formulate a javascript vision that doesn't alienate frontend-development.