Dear JavaScript • Hacker News Board

Re: Dear JavaScript

#91

Post by bshimmin » Mon, Dec 05, 2016, 6:15 PM UTC

qwertyuiop924 wrote: post #57

I don't think I can say much about the article's main point that hasn't already been said. But I do have a question: Why the flying blue !@#$ would anybody think that Babel 6's Configuration over Convention decision was the wrong way to go? It was absolutely the right thing to do. It made Babel a far more uniform and simple piece of software, and actually made it easier to use. Why?

Most people use Babel for transforming ES6 into ES5. Before Babel 6, Babel did that out of the box with no configuration required. With Babel 6, it basically stopped doing anything out of the box, including the main thing it was famous for doing. While it is admittedly not a vast amount of effort to make it do precisely what it did before, I'm sure you can at least sympathise with people who found it strange that you have to include a "preset" to make it do the main thing that you expected it to do.

Re: Dear JavaScript

#92

Post by atemerev » Mon, Dec 05, 2016, 6:17 PM UTC

rhinoceraptor wrote: post #76

atemerev wrote: post #51

Dear James, I understand that hearing rants about your brainchild that took so much hard work is hard and depressing. I was in your shoes, too. And being a head of popular open source project is very emotionally unrewarding, to say the least. And thank you for your hard work — like nearly every front end developer out there, I used Babel, and it did it job, eventually. However, I am one of those people who think that…

Did babel force you to upgrade right when version 6 came out? They bumped the major version, that should be a pretty clear indicator that existing workflows will break. Whenever you use a tool, you're accepting risk for the reward you're getting from it. If I run Gentoo on my servers, it's not really fair to complain when an update breaks something.

JavaScript world is known by moving fast and breaking things (which is fine for me, I learned to respect this culture). So, when a new version of some popular framework or tool comes out, there's a very real risk that the previous version will be abandoned really soon and left without support from developers and community (I was burned by it quite a few times). So no, had to move forward like everyone else.

Re: Dear JavaScript

#93

Post by qwename » Mon, Dec 05, 2016, 6:19 PM UTC

beejiu wrote: post #66

I think it works both ways, too. Unfortunately there are some developers that take any form of criticism as negativity. Some time ago I discovered a major XSS security vulnerability in a very popular WordPress plugin (used on over 100,000 blogs). I notified the author and got it fixed, and published a blog post about the issue 12 months later. The article itself was entirely factual and described the nature of the is…

Did you consult the plugin author before blogging about the vulnerability? Is there a reason why you blogged about it a year later? I am guessing that you waited until the old version of the plugin wasn't (widely) used any more.

Re: Dear JavaScript

#94

Post by yegortimoshenko » Mon, Dec 05, 2016, 6:25 PM UTC

thejameskyle wrote: post #89

yegortimoshenko wrote: post #84

> When we launched Babel 6, we made an API change that we had planned for awhile. We moved from having an implicit (“works out of the box”) behavior to an explicit (“will work for everyone”) behavior. Just like Rich Hickey said in his last talk (see https://news.ycombinator.com/item?id=13085952 ), breaking changes are broken. For greater good or not, it's no surprise people complain when you break their code/workflow…

People keep assuming I have something against sharing criticism or frustration. I never said that. I explicitly said that's not what I'm trying to say. I'm saying that when someone does it in a way that is in pure unadulterated anger that the community should not reward them for it. It's unhealthy for everyone.

I don't think you understand. The critique itself, whether constructive or not, is something to learn from.

Just like breaking changes in Babel 6. There is a lesson waiting to be learnt, namely, don't make breaking changes to existing software.

As a matter of fact, I honestly don't understand why you take it so personally. Sometimes I do stupid things and people call me an idiot, and it's helpful to know that. Sometimes it gives me a perspective I haven't thought of.

Look at how Theo de Raadt and Linus Torvalds manage their projects. It is kind of the same.

Re: Dear JavaScript

#95

Post by ralusek » Mon, Dec 05, 2016, 6:26 PM UTC

fusiongyro wrote: post #50

I don't want to distract from the main thrust of the article, which was that we should be decent to each other even with our criticism, but I think both his examples (Babel 6 and Angular 2) had something in common that lead to a lot more anxiety: they changed the essence of the software in a way that a major version bump is not enough to communicate. I'm speaking especially of Angular 2 here. It's essentially a compl…

I went to the Angular 2 docs and was thinking "this is nothing like Angular 1, looks like a completely different framework." Then I read from them "this is nothing like Angular 1, this is a completely different framework."

Should they have gone with a different name? Probably. But my guess is that they kept it for 2 reasons. The first is the name recognition. The second, more important one, is that they're letting us know that development on Angular 1 is winding down and this is the place where their new resources are moving to.

Re: Dear JavaScript

#96

Post by gabeio » Mon, Dec 05, 2016, 6:28 PM UTC

moosingin3space wrote: post #58

detaro wrote: post #36

Earlier quoted context omitted.

regarding your first point: often there doesn't seem to be a dedicated support channel/community. Mailing lists are less and less popular, if one exists its web interface is likely a long way behind GitHub. There are no forums. Some languages have project-independent channels (e.g. message boards for python users will try to help you with whatever library you're messing with right now), but they don't exist for all e…

Project Q&A sites, subreddits, and IRC channels are a pretty good solution to this (based on my experience with Rust for the latter two), as at least it separates "support" from "issues". Doesn't fix toxicity, that requires consistent and effective moderation, another thing Rust does well.

I agree subreddits and IRC, can be moderated by users who don't need to directly have repo access, sort of an abstraction, unlike how github repo members/collaborators would, can be a huge assist to eliminating that toxicity. It even has the potential to be handled before the negativity ever gets to those who have so much going for the project, unlike github issues currently which really require the collaborators who have usually contributed a lot to the project, to directly mitigate the toxicity there. I think it would be a great asset if github added the ability to give certain collaborators access to issues only which might aid in fixing this issue allowing there to be sort of moderators/support users who love the project but maybe are better at giving back by moderating issues more than contributing code.

Re: Dear JavaScript

#97

Post by _asciiker_ » Mon, Dec 05, 2016, 6:31 PM UTC

hey now ...

"I’ve always been advised to avoid these “sub-communities” like /r/javascript and Hacker News. Maintainers say they are filled with assholes who don’t know what they are talking about, angry idiots shouting at everything and everyone, cesspools, giant piles of trash burning in the wind."

I find that HN has one of the most sober comment sections I could ever wish for, it's certainly better than Reddit. I mostly come here for the comments.

Re: Dear JavaScript

#98

Post by moosingin3space » Mon, Dec 05, 2016, 6:31 PM UTC

gabeio wrote: post #96

moosingin3space wrote: post #58

Earlier quoted context omitted.

Project Q&A sites, subreddits, and IRC channels are a pretty good solution to this (based on my experience with Rust for the latter two), as at least it separates "support" from "issues". Doesn't fix toxicity, that requires consistent and effective moderation, another thing Rust does well.

I agree subreddits and IRC, can be moderated by users who don't need to directly have repo access, sort of an abstraction, unlike how github repo members/collaborators would, can be a huge assist to eliminating that toxicity. It even has the potential to be handled before the negativity ever gets to those who have so much going for the project, unlike github issues currently which really require the collaborators who…

Sort of like gitlab's Reporter role?

Also, the biggest problem with IRC/subreddits with a dedicated community team is that it takes a long time for many projects to reach the point where this is feasible. Rust is large enough it's fine, but many small projects (like what's common in the JS community) will never get enough people to dedicate some of them to "community management".

Re: Dear JavaScript

#99

Post by mi100hael » Mon, Dec 05, 2016, 6:31 PM UTC

nkw wrote: post #17

I was commenting to a colleague the other day how amazed I was at the sheer quantity of github "issues" that I was seeing posted to a few popular open source repositories that were rants about why feature X wasn't available yet or a priority yet, or demanding that someone walk them through some installation issue because the poster couldn't understand (or didn't read) the README. None of the people that posted this s…

I agree 100%. GitHub muddles the contribution process and support process. Couple that with the irony of developing free software using a bunch of proprietary, commercial tools, and I much prefer the tried & true IRC/mailing list approach to the trendy Slack/GitHub stack.

I think a large part of the problem is that the current generation of new developers is completely conditioned by Facebook, Google, Dropbox, etc to relinquish control of their data rather than deal with the slightest inconvenience of configuring an IRC client or whatever else it may be.

Re: Dear JavaScript

#100

Post by jondubois » Mon, Dec 05, 2016, 6:32 PM UTC

I dislike all JavaScript transpilers. I still cannot get my head around how CoffeeScript ever got so popular. The complexity and friction that transpilers add is not worth the tiny benefits that they offer. I've worked on many projects where I had to wait for like 20 seconds for the code to compile each time I made a change to it.

From my point of view, it sounds like the author of this article is merely feeling the reality catching up to the hype.

Transpilers like CoffeeScript and Babel should never have become popular to begin with. Something unnatural happened in the evolution of those projects which allowed them to capture a lot of attention very quickly; and much of the initial adoption was driven by hype and network effects instead of real needs.