ES6 is beautiful | Hacker News Reader

ES6 is beautiful

ewanvalentine.io

56 pointsedward102 comments

No, it isn't. It's a kitchen sink of unrelated and often ugly, difficult to parse and unnecessary features. Yes, there is some good in there, but overall it's a shit show.

Why can't we just be honest about it? "Welp, this is what we've got. We shouldn't be surprised, since this is what happens when we design by committee. Now let's make the best of it."

I'm guessing you don't write Javascript full time? After using ES6 in depth for a few months now, I can vouch that all of these syntax details are well thought out, practical, and improve the readability and writability of the language. I've used most of the ES6 features, if not all, repeatedly in production code. None of them seen "unnecessary" and teams I've worked on echo this experience.

Who cares though, Hacker News embraces trolls who engage in syntax wars.

Hating on Javascript is one of the trendiest things to do in online tech-centric communities.

The future of Javascript is bright, and the new features added are vast improvements onto a language that stagnated far too long. Many of the criticisms towards the new features are not well thought out. Luckily the TC39 committee is full of extremely intelligent developers who have a good understanding of the nuances in adding new features.

On the other hand, there are at least some that have been coding in JS for a long time and loved the simplicity and yet versatility of the language. And there's a feeling of some of this being lost in the latest iterations of the standard. To be fair, I would rather observe this criticism in a RISC vs CISC context. (With ES6, JS is definitely taking a rather CISC-like direction.)

It's a fair point. In fact, I wrote a javascript library, http://intercoolerjs.org, to avoid writing a lot of javascript, so I have a somewhat ironic relationship with the language.

On the other hand, I also work on Gosu (http://gosu-lang.github.io/) which is has its own kitchen sink issues, so I believe I'm not being a troll, or at least not simply being a troll, when talking about language design.

Overall Javascript even with ES6 still seems like a fairly immature language. It is a definite step in the right direction though. Specifically:

I think the lambda syntax is nice and concise, although the disconnect between an implicit return with a bare statement versus required explicit return with braces is kind of silly. They should have made it just implicitly return the evaluated value of the last statement in the lambda all the time.

The de-structuring syntax is less clear and consistent than, for example, Python's. The fact that both array-like things and object-like things are de-structured using '...' means that you have to consider the context when you see it, and you could probably construct cases where it isn't clear exactly what is going on.

Template literals are obnoxious because they bind when declared. This means you can't pass a template literal around to be evaluated later. You could wrap it in quotes and use eval, but then you lose multi-line support. Pretty fail.

The fact that module support is finally part of the language is a good thing. Not having a built-in module system is probably the biggest embarrassment in the language. Now we just need a dependency manager built into the browser so people can require jQuery >= 2.0 for instance, and we won't have to worry about CDNs and what not.

Netscape 4 had dynamic HTML entities bound to JS ("&{...};"), which were resolved by the rendering engine. I think, it would have been interesting to revive this approach.

Other, one thing I often observe in ES6 examples is replacing quite complex constructs that could have been expressed much simpler using older JS standards. E.g., "Array.prototype.push.apply(arr1, arr2)", where "arr1.concat(arr2)" would have done fine. Not too sure, what this means for real-life applications, but there's definitely a trend in expressing things in artfully complex ways.

The template literal "fail" (which is really just static scoping) is necessary to make JS JITting anywhere near reasonable. You may not care about JS runtime performance, but lots of people do.

Or they could have just made template literals be multi-line strings, and added an eval method, taking an optional context object which could override local names. That would have been a lot more useful...

while i agree that everything mentioned in the article is useful, i think ES6's import is horrible. why do i have to look at (potentially outdated, esp. in js world) documentation or look at the code to know whether or not to do

  import Foo from 'bar';

  import { Foo } from 'bar';

I think it was a PITA to learn, but it's also very necessary to interoperate with the existing JS ecosystem. Many libraries have a default export (often, a function) and then a number of sub-exports that are assigned as fields of that. Without the distinction you mention, there'd be no way to specify whether you want to import 'bar' and bind it to Foo, or whether you want to import the Foo member of bar.

Given an extra few days to learn the semantics of import vs. losing access to the millions of npm packages out there, I'd rather spend the extra few days.

I find it fairly intuitive. The former is for importing the default module, while the latter is simply using the ES6 destructuring syntax to import specific named modules.

and how do you know whether or not for library X you need to import the default export or one of the named exports without looking at documentation? furthermore, you have to remember which to use for every library because there's not a lot of consistency among libraries

i think syntactically the destructuring syntax for imports is cool and clever, but in practice i find it annoying to use

For most of the libraries I've used so far, they generally seem to follow the convention of having the entire library in a single object as the default export while also exposing each individual function/property as named exports.

In the case that they don't, I generally just try "import * as Foo" to find out exactly what the library exports. Not saying this is ideal, but it really isn't too bad either, in my opinion, considering the flexibility and conciseness this approach offers for the general case.

I don't get this. I am using almost all new ES6 features and absolutely love the productivity I am getting thanks to it. To be honest JS became my favorite language. I can write mobile apps with it(react native), have unmatched user experience on web (isomorphic react), write backend server in like a minute (koa), write multiplatform games that would run even on your fridge(phaser.io), write some sci-fi like data visualizations (D3), desktop apps(electron) and the thing I like absolutely the most is ease of debugging. Whenever I tell somebody about all the things I do with js at my work place I am mocked 'coz js is shit and slow xD" usually by an experienced architect who writes enterprise level webforms-jquery applications that are the biggest mess I have ever seen. From my experience the people who very vocaly hate js are the ones who never moved past jquery and now refuse to catch up so only thing they have left is often very vague criticism like its ugly,difficult to parse,have unnecessary features, it is hard to google the features(lol)

You know what other language is a kitchen sink of unrelated and often ugly, difficult to parse and unnecessary features?

English.

We're talking about languages here. The most popular languages tend to be the ones that are the most adaptable. Successful languages aren't afraid to borrow and tend to have multiple overlapping grammars. They are not designed. They evolve over time. They are far from perfect.

The things you hate about these languages are exactly why they are so successful. Instead of being endlessly upset at the dominant programming language for not being 100% perfect, just embrace and celebrate its haphazard nature.

You're exactly right. Arguably worse than ugly, unnecessary and difficult to parse are that many of these things are difficult to research with a search engine. For example, `const { user, post } = this.props;` there is nothing to plug in to a search engine (and the meaning is not obvious, even to somebody with plenty of experience in ES5). Same thing with `arr1.push(...arr2);`.

Destructuring assignments are extremely useful, especially within function signatures.

Without knowing the type of what you're destructuring though, that's quick to land you in some type of undefined hell.

Why wouldn't you know what your destructuring?

`({ id, option = true, name = 'unnamed' }) => // ...`

replaces

``` function(userObject) {

  const id = userObject.id;

  const option = userObject.option || true;

  const name = userObject.name || 'unnamed';

  // ...

} ```

I think this comparison speaks for itself. In pre-es6 code bases you TONS of code that looks like the second.

Come off it, destructuring is hardly unique to javascript.

What syntax would you recommend/prefer for unwrapping 'props'?

This is a real problem for me these days. I see a new syntax in someone else's codebase and it is very difficult to google it.

Take a look at this site http://es6-features.org/ there is even comparison ES6 vs ES5 code. You can just go over every feature really fast a then you may get rough idea where to look next time you feel lost.

Am I the only one to think throwing "difficult to parse" as criticism to a programming language like JS is disingenuous?

It could be an argument to criticize changes proposed for a nimble performance-oriented language like Lua where "parseability" means hackability as a feature for developers working on the language & core tooling itself. But it seems to me that the bulk of the users of a popular / high-level language like JS is people trying to get things done, not tools developers hacking on JS itself.

"Difficult to parse" semantic constructs may be a hurdle for the 1% doing the parsing, but they mean more syntax goodness to help the the other 99% programmers do things pleasantly and succinctly.

I've heard Python is difficult to parse, too, but behind this difficulty there's syntax sugar helping your average developer. Much like Python list comprehensions, context managers and decorators, these ES6 features make the task harder for tool builders, but they help me as a developer.

>Am I the only one to think throwing "difficult to parse" as criticism to a programming language like JS is disingenuous? (...) "Difficult to parse" semantic constructs may be a hurdle for the 1% doing the parsing, but they mean more syntax goodness to help the the other 99% programmers do things pleasantly and succinctly.

You probably got it wrong. When he says "difficult to parse", he means for the programmers using JS -- not for people working on JS parsers.

Besides compiler construction, "parse" is also commonly used to mean "read/understand" some new code.

Oh right, thanks for pointing this out :)

In this case, I'd still contradict OP, arguing the same as stevebmark did in a sibling comment: "[...] these syntax details are well thought out, practical, and improve the readability and writability of the language [...]. None of them seen "unnecessary" and teams I've worked on echo this experience."

> Why can't we just be honest about it? "Welp, this is what we've got. We shouldn't be surprised, since this is what happens when we design by committee. Now let's make the best of it."

Lots of people are being honest, this article included. Don't disguise your different opinion as "the truth". Not everything can or should have a consensus.

Compare Reagent code with JS React code (React being about the most elegant solution possible in JS). Not only more beautiful, but much easier to understand, AND with an added performance bonus:

https://reagent-project.github.io/

Back when investigating React for a personal project, I fiddled around with Reagent as a short introduction to Clojurescript, I was not familiar with the language at all, and yet Reagent was immediately more understandable to me than React.

When an alien framework in an alien language are easier to grok than one in a familiar language, one can't call that language "beautiful" with a straight face.

ES6 is "less shitty", (maybe,) but the language itself is still a garbled mess. I can't wait for the day it goes the way of the dinosaur (or survives merely as a transpiler target).

I'm not usually one for bikeshedding. But in the case of JS, where the syntax actively hurts one's ability to understand and organize code, maybe it's warranted. Ever inherit a JS project of even moderate size? More often than not, it's a nightmare moreso than most other languages.

I think you're pretty heavily stating your own opinion as fact here. I have the opposite opinion and consider the React equivalents much easier to read than the Reagent examples you linked to, because I find the syntax more expressive.

(Also please don't tell me I don't understand the lisp-syntax due to 'familiarity', I've heard that a thousand times and it's not the case, I just don't agree with the syntax trade-off).

As much as I love ClojureScript and libraries like Om/Reagent, you're comparing apples to oranges here. React is a lower level API that other abstractions build on top of. Reagent itself is one such abstraction. Saying that Reagent is more elegant and understandable than React is akin to saying C is more elegant and understandable than assembly: An obvious truism.

A fairer comparison to Reagent would be something like Redux, which is far more elegant and understandable than low-level React code. I personally still prefer working with ClojureScript frameworks like Om/Reagent when given the choice since they have a much more robust solution for handling async tasks, but Redux doesn't fall very far behind in most other aspects.

Though I agree with most of your points, I would argue that the reason most Javascript codebases are a mess is because many people who develop in it don't have as rigorous a software engineering/computer science background. The language itself lacking built-in a module/dependency system (requiring everything to be dumped in the global namespace, maintain a tangled web of closures) is particularly egregious.

I recently witnessed the absurdity of arrow functions NOT returning implicitly if you put the function body in {}. It's a shit show.

If you want to return an object literal just do this,

`(text) => ({ label: text })`

In my opinion the arrow function has great syntax. Rest assured, no matter what the syntax was chosen to be, there would be an extremely vocal group of people who hate it (such as yourself).

That actually is one of my favorite things about arrow functions next to the no-changing-this aspect. I find CoffeeScript's optional return statement really awkward to read for anything that isn't a one-liner. I don't want to have side-effectful functions return values, and dropping bare statements in in order to accomplish that seems extra noisy.

That's part of the spec, they're really meant for doing functional style, one liner type of things, like

[1, 2, 3, 4].map(x => x + 1)

You should probably avoid using them for other applications, particularly if you're using a library that uses prototypes because it won't work.

If that's what they are for, why call them "arrow functions", and not lambdas like everybody else does?

To distinguish from javascript's other longer way of writing the same thing:

    [1, 2, 3, 4].map(function (x) { return x + 1; })

Javascript already had lambdas/anonymous functions since the beginning.

I've been coding for over 20 years, and HTML was one of the first "languages" that I picked up, because it was cool to create websites in the infancy of the Internet.

When it came to writing more complex stuff, I gravitated towards IE, ActiveX, and VBScript. I hated JavaScript. I was also 10 years old, so my criteria for picking a language was a bit less nuanced.

Obviously, JavaScript became the programming language of the web, and I had to learn it. I hated the inane syntax, and the fact that I was always forced to use jQuery for dealing with browser differences. I tolerated JavaScript, but still hated it.

With React, Babel, and ES6, that's all changed. I've been writing a lot of ES6 code over the last year, and it's been an absolute joy to use. Everything the author writes about is what I've learned to love.

Perhaps I've become more mature. But I'd like to think JavaScript has too.

This seems to be selling existing JS developers on switching to ES6 features - all the comparisons are with ES5. No one is under any illusions about switching from Python to Node if you have the choice.

A lot of the criticism seems to be from people who will never like JS. I've always loved JS (for whatever reason) so ES6 is a godsend.

I hate JS with a fiery passion. Which is why I also think ES6 is a godsend.

I switched from Python. They are very similar languages, but one works on the web. Django might pull me back in if I need a CRUD app, but otherwise, it's easier to build a one-language team.

I came from Python too. I took the opposite tack. Our entire backend is written in Django + DRF. We have a Node.js front-end renderer in front of it to handle server-side rendering.

I'd rather have a team that can handle multiple languages and shift between them, understanding that a language is simply a syntax for expressing your ideas, not something to be limited by.

Some poetry is written best in French, Arabic, or English. Some technical manuals are best written in German or Japanese.

You should choose the best language that fits your needs that lets your express yourself fully.

Did you really prefer VBS over JS?

Really?

Dude, I was 10. What did I know back then?

I like and use ES6, but I am not a fan of the trend to use as little syntax as possible to be 'beautiful' or 'clean'. Am I the only one who is bothered by this ultra reduction? To me, it ends up as either parentheses soup or unreadable clever code.

I agree. I think a language's determined beauty is by its readability, and the less complexity/clever code the more readable it becomes.

I agree, when I look at the code in his examples, I have to work a lot harder to figure out what's going on. Maybe I'll get used to it, but as I mature in my programming style I strive to write code that others will not have to work hard to understand.

OTOH We've been using some ES6/Babel at work, and I'm really digging the Promise/resolve/reject paradigm.

Yep, I had just submitted a comment making basically the same observation. There's always the clarity vs. conciseness argument in every language evolution process, and compromises made due to compatibility issues, but ECMAScript veered too far towards line noise this round for sure.

The ambiguity that EMCAScript 2015 added really makes mentally parsing code a lot harder, and not what I would describe 'beautiful'. I've learned to accept it, but => functions are especially hard to see - it makes function definitions into Perl-like line noise, which I really don't think was worth the 4 characters savings. e.g. function(a){ and (a) => { . *functions as well is just badly designed. JavaScript would be well served to emulate Python's model of less options/more clarity, not pandering to uber-geeks who want to use as few keystrokes as possible for whatever reason.

I couldn't disagree more about arrow functions:

    x => this.y + x

Is almost pure signal, compared with the noise of:

    (function(x) {
      return this.y + x;
    }).bind(this)

I know which piece of code I'd rather maintain.

Arrow functions are immensly useful, and the lack of some of this syntax for a language which naturally lends itself to a functional approach was so jarring that coffee-script grew to immense popularity because of it. Like any sufficiently popular language, literally any choice will be met with a vocal group of people who dislike every single aspect of it.

ES6 was a long time coming, and has made Javascript much more legible to read as well as making it easier to write.

The implicit return in the last variation of arrow functions presented is a terrible implementation mistake and not a win for clarity nor consistency.

It's an expression... clear and consistent. You're confusing it with a statement.

Actually, everything should be an expression.

Can we call it EMCAScript2015? It will help people get into the habit of referring to annual releases. ES6 was actually never called that right? The last ES was ES5.

I agree, es2015 would definitely be preferable, and I do my best to remind myself to refer to it as that, but people do tend to be partial to what's terse and most easily pronounceable

Literally every time I see ES6 I think "Elder Scrolls 6." Without fail. I wonder when that's coming out...

What's the plan for browser support of ES6? I like to imagine a world where I don't have to transpile my code with Babel first.

Most modern browsers are gunning hard for full support. Here is the best breakdown:

https://kangax.github.io/compat-table/es6/

That said, it will be a long time before you can write vanilla ES6 without transpilation and publish it, for the same reason that many sites still sadly support IE<=8.

Sadly, looking at that table, it's clear that Safari is the one dragging their feet. Full support for ES6 in the latest Chrome, FF, and Edge, but very poor support in the latest Safari.

Apple recognizes that the Web poses a threat to their business model (although I think it's not as big as they fear, after all, how much of their profits come from the app store). This is why I am skeptical they will support WebAssembly in the end. After all, it will be possible to compile ES6 to WebAssembly just as much as any other language.

I'm open to other suggestions for why Safari has become essentially the IE6 of our time, but pure business strategy is the only one I can come up with (which is fair, since Apple is a business after all).

I guess were in luck then. Apple recently released the Safari Technology Preview version of Safari.[0]. And if you open the ES6 support page in the post you replied to it shows support for 98% of the features.

Supposedly the STP version is getting updated every 2 weeks, so lets hope that that also transitions to the non-developer version of Safari.

[0] https://developer.apple.com/safari/technology-preview/

They are getting a little bit better, transparent about new features lately. https://webkit.org/status/

WebAssembly is listed as in development.

WebKit Nightly gets a 98% on that table.

>Sadly, looking at that table, it's clear that Safari is the one dragging their feet. Full support for ES6 in the latest Chrome, FF, and Edge, but very poor support in the latest Safari.

Actually Safari (well, Webkit), in beta, is the closest to full ES6 support of all current browsers -- down to 98% or so.

It's just that Safari has a release only once or twice a year. But when it has, suddenly everybody on OS X/iOS using Safari would get all that stuff at once.

(And recently they started a public beta builds program that might see them releasing new versions much sooner).

>Apple recognizes that the Web poses a threat to their business model

And with that information above, can we put this age old conspiracy theory to rest?

Apple had long had the best mobile browser when Android still had the horrible "Android Browser". They regularly added all kinds of features that benefit apps (e.g. the canvas, css animations, several API to access native mobile features, etc.), and they continuously improve it (see this 98% ES6 support).

For a company that "fears web apps" Apple not only promoted them to developers (before and after they created their native app frameworks and app store), not only has extensive documentation and how to's for best mobile experiences on their dev pages, but also has seen that Safari webkit based apps have traditionally been a better experience than Chrome based web apps on Android.

Even today, it's faster, and more memory/cpu/battery efficient on mobile than Chrome is on Android.

https://blog.runspired.com/2016/03/25/the-chrome-distortion-...

Safari was only held back because it's not a huge priority for Apple -- not because of some fear that web apps will eat their app store lunch.

After all, web apps are difficult to monetize (no credit cards at hand), people expect most of them to be free, have a subpar experience for anything more demanding compared to bare metal languages, and don't integrate that well with native APIs anywhere (iOS, Android, Desktop, etc), as they have to run in a more restricted sandbox than native apps do (and of course somebody has to continuously porting all the native APIs, and at a great common denominator at that, since they also need to be portable).

Fair enough. However, my paid work for the past several years has been as a frontend developer, and consistently, the browser that has held us back from adopting newer features has been Safari. I'm very happy to hear they have better/very good ES6 support coming up, I'm very glad to be wrong there.

And hey, for whatever reason, Apple has earned my eternal gratitude (and my consumer dollar) over the past few months by being one of the only entities in this country capable and willing to stand up to government bullying and surveillance. Web standard are great for me in my job, and I believe they're important for the future of online communication. But standing up to government overreach is of critical importance to all of us. I'm an Android user myself, but wife uses iPhone so I'm already getting ready to buy her a new iPhone 7 when they come out.

many sites still sadly support IE<=8

I'm curious: how much have "evergreen" browsers changed this? Do developers typically target Chrome from a few months ago? Two years ago? Just "today"?

Maybe a better way to put it: if you only cared about Chrome, how long would you wait after a new feature was introduced to start using it?

Chrome/Firefox/Safari auto-update unless a user disables autoupdates which is atypical. As such, most devs will only target the most up-to-date version and maybe a single version back (which if something breaks in a single version back, you're already using bleeding edge stuff and probably don't care...)

Few devs care for older support unless they're working on enterprise, are masochists, or really really really care about supporting 0.00000001% [0] of their users because they care that much (and more power to them!!)

Most devs can point to Microsoft and say "Look, even the guys who created it are no longer supporting it." as an excuse to not support it themselves. I frequently do this when asked to support Safari 5... on Windows. Apple doesn't support it - neither do I.

If you work with say.. Healthcare clients you often need to support back to IE7 or even IE6 because that is what they use internally....

[0] I mean to say "practically zero, but not zero percent".

Well, IE8 is the most recent version that's supported on Windows XP, which is still used in a distressingly large amount of corporate environments. There's also still a load of corporate IT on Vista and 7 that won't upgrade past IE8 because reasons. IE9 and above is effectively evergreen, and Edge explicitly is, but we're gonna have a load of people stuck on IE8 for a while to come.

I don't know about IE9 being "effectively evergreen" but I can say that the only browser specific bugs we've had to deal with recently have been IE9 so I wouldn't consider it on the same level as IE10 and IE11.

IE9 is the oldest browser we support, and soon we won't support it either.

Basically when IE11 and old Android browsers can be ignored. Even Windows 10 ships with with IE11. I guess it will take several years before IE11 market share is <2-3%. Still, it will be a glorious day.

The main thing I am looking forward to becoming accepted is the async/await proposal.

It makes my code look a lot easier to follow, easier to write, and less error-prone.

I agree this is great stuff for JS, but it is nothing new if you have been using a modern dynamic language like ruby.

Or Python, or .NET 4+, or Haskell, or many other languages, static, dynamic, or otherwise.

No, it's just lipstick on a pig. The pig is still there, and no amount of syntax sugar will fix it.

CoffeeScript errr... ES6 is beautiful

I thought variable unpacking was called destructuring assignment.

And transpilers are called compilers.

header is bigger than the article. Nothing wrong with that, but was expecting more insight.

What is truly lacking of content is your pointless comment. HN has an annoyingly large amount of posters who feel the need to always comment on some minor design/structure related piece of a webpage which derails conversations and adds nothing but an extra small piece of cynicism ontop of the mountain of cynicism that already exists in nearly all anonymous tech-centric communities.

I don't think you got my point. I'm not complaining about design for no reason. I'm complaining about the fact that this post's content is not HN front-page worthy. If those are the reasons why the author thinks ES6 is beautiful, I think he hasn't explored enough yet.

The top comment is literally someone trying to shit on something someone else says is beautiful.

Why the fuck? What? WHAAAT?

face palm

I should have been more generous in my comment. I emailed an apology to the author.

What about safety? Optionals? Interfaces? TypeScript has a lot of value here.

Agreed. But it's not an either-or. Interfaces are a TypeScript thing, not an ES6 thing.

TypeScript is (or tries to be) ES6/ES2015 plus interfaces/types. If you want types use TypeScript.

Heh, my comment goes +3 -1 +2 in less than a minute.

Always amusing to refresh a few times after saying something that isn't Technolitically Correct.

Please don't post unsubstantive comments here.

We detached this subthread from https://news.ycombinator.com/item?id=11449599 and marked it off-topic.

That's fair. Sorry for the distraction.

It's because for those who don't know better, you sound like a snobby hater. There are definitely redeeming qualities about JavaScript, but it's not beautiful. JavaScript is lacking and even with the ES6 improvements is still lacking.

Get over yourself. Some people agree and some people disagree. Replying to your own comment like this is just cringeworthy.

> Get over yourself.

Please don't be uncivil in comments here.

In fairness, my original comment was pretty uncivilized.

If I could edit it now, I would rephrase it to something more along the lines of "This blog post shows some pretty nice code you can write in ES6, but overall the new features in ES6 are deeply flawed etc. etc."

It's also against the HN guidelines.

Technically the guidelines only mention complaining about being downvoted. Crowing over upvotes appears to be permitted.

Personally I think the ability to anonymously downvote a comment is socially problematic, and it creates a climate in which long-term users (who can downvote) can appear to be more intolerant of dissenting voices than they probably are.

Sort of related, but possibly interesting... I've created a Chrome extension that completely removes all of the voting functionality and point tallies from my interface (except for being able to upvote threads on the main or new posts page). Including removing the lighter-grey of downvoted posts. I noticed long ago that I was allowing myself to be behavior-shaped through comment voting, and saw how it had impacted my own conversation and even thought processes. Had to do away with that as much as I could.

>Technically the guidelines only mention complaining about being downvoted. Crowing over upvotes appears to be permitted.

https://mind-exchange.com/wp-content/uploads/2015/05/thank-y...

The surest way to have wild karma swings up and down on a comment is to say something critical of the Javascript Orthodoxy.

Shhhhh. The feeliest of feels is the Javascript Community. But the entertainment is always top-notch.

Come on you guys. JavaScript is hardly the pinnacle of computing, but comments like these just make HN worse.

Here's how to deal constructively with the situation you deplore: post stories about things that are better. Then you'll help others learn and improve, even if only a minority do so.

Reply on news.ycombinator.com