javascript vision thing

kai zhu kaizhu256 at gmail.com
Tue Nov 28 06:40:07 UTC 2017


@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 @
https://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 11/28/17, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
> 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(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)
>
> ```js
> 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:
>
> ```js
> 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.
>
> Regards
>
>
>
>
> On Mon, Nov 27, 2017 at 8:17 PM, Florian Bösch <pyalot at gmail.com> wrote:
>
>> 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.
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-11-28 at 2.21.10 PM.png
Type: image/png
Size: 396615 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171128/cbcaf5c3/attachment-0001.png>


More information about the es-discuss mailing list