Douglas Crockford

>You describe things like "access the file system" but what even is that? In Linux, if you write to a "file" in /proc or /sys, you can trigger all sorts of side effects, including cause a kernel panic.

well, you can could of course go ahead and read some of the literature on capabilities based security, but you don't seem interested in that, so I guess I will give a go.

Here I will give a not necessarily great description of capability based security where the capabilities are handled on the OS level, this is my poorly remembered version of a document read about 20 years ago.

In Windows if you, as an attacker, are somehow able to do a complicated attack on any program that a user runs and it succeeds you can make that program do anything that the user has access to do. For example make it write to the local filesystem. For a large number of programs writing to the local filesystem does not make any sense and they were not written to do that, but now that the program has been corrupted by your attack it will write to the filesystem.

But let us suppose our program, Solitaire, was written with a capabilities based language then in the manifest for the program when we installed it it would not give access to the file system. The capabilities system can in fact be very explicit, and you could easily have a program be explicitly limited to only those abilities that are needed to run your solitaire game, but instead of going on at length on this and the abilities it confers to…

"He has Douglas Crockford and Brendan Eich on the pro-trailing-semicolon side"

Brendan Eich, the conceiver of the language. The best placed person in understanding why the JavaScript language does what it does, and what problem a feature was trying to solve.

Douglas Crockford, the developer who took all of JavaScript and found within a clean elegant language. And then he pulled together what he considered the best bits of the language and used that subset as a starting point. http://anongallery.org/220/javascript-the-good-parts

@fat - no idea who he is, apart from being an employee of Twitter and works on Twitter Bootcamp, which is a framework for other people to use to build websites.

@izs - I think you overreach by grouping him as anti-semi-colon. Isaac is a pragmatist, he uses what suits the group of people he works with. NPM is a standalone app, a non-expert JavaScript developer doesn't need to delve into npm for it's standard usecases. So he choses a syntax he believes suits the group of people working with him. And yet, he is now the lead developer of Node.js, and he's already on record saying he won't be spending time changing Node.js into his preferred comma prefixed approach - because the existing team is already used to post fixed commas. That's what I like about Isaac - he listens to a wide range of opinions, and uses what works best for the environment he's in.

Thomas Fuchs - heard of him, he's done lots of stuff JavaScript and PHP wise. I'll give you that…

For JavaScript, I've settled on using JSMin (http://www.crockford.com/javascript/jsmin.html) + GZip at the server level. Someone did a test of various compression tools and found that while they had wildly varying sizes before GZipping, they all came out to roughly the same size after GZip, except that I think raw+GZip was a bit bigger than JSMin/Packer/YUICompressor+GZip. So there's no reason to pay the extra decompression & debugging overhead that Packer entails.

You'll probably want to concatenate all your JavaScript files together to save on HTTP requests. I wrote a dependency analyzer that reads dependency info off the JSDoc and automatically topologically sorts them to get the correct ordering. I'll probably open-source it and put it on the web when I get a chance to do some code cleanup and documentation.

I don't use anything for CSS; I probably should, but it hasn't been a big problem. I've heard that Dreamweaver will automatically remove whitespace for you, but I get annoyed by that kind of munging, and my guess is that GZipping will eat up all the bulk anyway. Just follow all the normal rules about factoring your CSS for maintainability - you want to actually think about what you're trying to accomplish, and assign rules based on the semantics of the page. The worst CSS bloat I've seen has come from coders just copying & pasting some CSS example off the web whenever they have a problem. Understand what you're doing & don't cargo-cult.

HTML is easy: use…

Yeah, and if people would solely use them as comments for humans to read... I'm with you.

But they won't. A big part of the reason comments weren't included in JSON is that people tried to get clever with them.

Directly quoting Crockford:

> I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability.

And while I'd also love to occasionally throw a comment in a json file, I don't want to have to deal with any of the headaches they would have created in the ecosystem.

And to be fair to Crockford here - it's not like he wasn't aware this was a downside. He even released a tool as a preprocessor for JSON if you wanted to put comments in: https://www.crockford.com/jsmin.html

JSON intentionally chose to stay as simple and compatible as possible, and personally - I think that constraint was the right call.

If I'm writing files I want to throw a lot of comments in... It usually means I should move to something like YAML instead.

Again - JSON is terrible at a lot of things, but really hammered on simple and easy as focus points. If you give devs a place to store data outside the structure of the protocol... they will use it for all sorts of complicated craziness... which devolves to either multiple protocols, or a really complicated protocol.

I'm not gonna bother quoting you to fisk you. Your approach towards my evidence is weak overall. I'm gonna throw more evidence at you.

Miller and Dean Tribble have been working on WeakRefs lately: https://github.com/tc39/proposal-weakrefs

Crockford's personal site no longer has the original JSON description, and neither does the Wayback Machine, but his site does still have a section on E: http://www.crockford.com/

In this talk [0], Crockford discusses the origin of JSON. He mentions working with Chip Morningstar (this guy http://habitatchronicles.com/2017/05/what-are-capabilities/) and has oblique references to his prior work. He doesn't bother to explain what he was doing during the 90s here, and at this point social interaction becomes required to learn more.

'hammering the ES peg in the E hole' is wrong. They're hammering the E peg into the ES hole. Not all of us believe in this approach; some of us think that JS is irredeemable and that we should keep iterating with languages like Pony and Monte which expand on the original E concepts.

Like I said, kicking and screaming. I don't know why you all kick and scream so much, but you do.

[0] http://www.youtube.com/watch?v=-C-JoyNuQJs

JavaScript is very expressive and powerful language. Maybe hard to learn. The prototypal inheritence and 'this' were confusing to me and took much time to understand those.

Then I learnt that prototypal inheritance is a superset of ''class''ical inheritance [1] as well as this [2]. Hmm.

With Reflect, Proxy etc. you have great metaprogramming capabilities that make this language much powerful.

Still, there are some (many?) edge/corner cases and unfixable bugs (aka features) that the language is stuck with for the sake of backwards compatibility and developers have to learn these. (The most famous of these might be typeof null === "object")

When I look at the amount of features added to the language specification, sometimes it seems like it is going to become another incarnation of the C++ specification.

I still like its expressiveness and power, but if it becomes another C++ in future, I have to look somewhere else. (TypeScript maybe.)

[1]: https://aaditmshah.github.io/why-prototypal-inheritance-matters/
[2]: https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent and https://www.crockford.com/javascript/private.html