Dear JavaScript • Hacker News Board

Re: Dear JavaScript

#201

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

magicalist wrote: post #189

atemerev wrote: post #88

Earlier quoted context omitted.

I do sincerely apologize if something I had said sounded offensive to you or anybody else. However, I can't help but ask the question: am I the one who resorts to personal attacks here?

Yeah, that's bullshit. > But Babel6 is still terrible, and no input from your side can change my opinion. Or perhaps it could, if you provided some technical justification for what you did. But this article is the request to stop ranting about your work, as it hurts you. > For that, I am sorry. So you get what he's asking (stop the sniping without substance), you're (supposedly) contrite about it, and yet in the same…

I do not attack or blame the author, I say that the work (Babel6) is no good. This doesn't imply anything about the author.

You, on the other hand, attack _me_ personally. You don't even say "your words sound rude" — that I would understand.

Or there is no difference to you?

Re: Dear JavaScript

#202

Post by fooey » Mon, Dec 05, 2016, 10:17 PM UTC

magicalist wrote: post #183

fooey wrote: post #165

Earlier quoted context omitted.

Someone saying "Angular 2 is terrible" really isn't that harsh. If you're going to get all worked up over something that slight, maybe doing work in public isn't the way you want to spend your time.

> If you're going to get all worked up over something that slight, maybe doing work in public isn't the way you want to spend your time. Or maybe the people doing the actual work have opinions that matter and the person whining only does at the contributors' discretion, so the complainers can pull themselves together if they want to be listened to at all?

He's complaining about an open article written about Angular2, which he isn't even a contributor to. He's complaining about general community dislike about the direction Babel 6 took.

It's not like this was Linus trashing a contributor for writing shitty code in a pull request.

So far as I can see in the article, he's not complaining about a single instance of anyone actually criticising him directly.

No one really cares who worked on Babel 6, all they know is there was a change that disrupted their work flow. No one is being personally attacked when the users criticize a change.

Re: Dear JavaScript

#203

Post by atemerev » Mon, Dec 05, 2016, 10:19 PM UTC

Klathmon wrote: post #196

atemerev wrote: post #186

Earlier quoted context omitted.

But why anybody even need a modular build tool? It's not like it is packed into final build, we don't need to shave off bytes. One size fits all works perfectly here. What is the killer use case for modularity?

You don't want to compile everything every time. We target a platform that has arrow functions, we don't need to compile them in any more. Not a big deal for arrow functions, but a HUGE deal for async/await, or for-of statements (both of which will compile to a LOT of code which includes a pretty large amount of runtime-checking to work). But there's also the fact that you do pack some of it into the final build. Man…

Thank you, this is actually a great explanation.

Re: Dear JavaScript

#204

Post by Gudahtt » Mon, Dec 05, 2016, 10:19 PM UTC

atemerev wrote: post #185

Gudahtt wrote: post #173

Earlier quoted context omitted.

>However, I am one of those people who think that Babel6 is terrible, that it "broke the web", and it marked the beginning of the entire JavaScript fatigue era. Granted, I wouldn't consider this a personal attack. But it definitely qualifies as negative and nonconstructive. I literally can't imagine how one could argue that they "broke the web"; that's completely ridiculous. If the migration path wasn't explained ver…

The migration path wasn't explained at all. This is fine, if there would be a nice documentation for new version. There wasn't, except for some scattered blog posts. This is fine, if new version offered some exciting new features or simplified thing a lot. But no, everything became significantly more complicated. This is fine, if Babel was a production library packed into final build, and modularity is necessary to s…

To address the other points you raised; I personally found Babel 6 easier to use and understand than Babel 5. I suspect this is because I needed to configure Babel 5 anyway to meet my needs, so I was required to understand the configuration either way. Babel 6 made it much easier to understand what I was asking Babel to do; no magic, everything explicit.

With version 5, the default settings were a moving target (which I found confusing), and explicitly configuring it was more complex. Apparently the Babel team had great difficultly deciding what should be included by default as well.

Basically anybody that used Babel for something other than "6to5" had to jump through hoops to overwrite the defaults. Seeing as how the Babel team were trying to position it as a general purpose Javascript compiler, that was a problem for them.

So, maybe it's worse off for most people because of the change (because it doesn't work with zero configuration anymore), but plenty of people were better off because of it. The library became easier to maintain, and easier to use for a non-negligible number of users.

Re: Dear JavaScript

#205

Post by ry_ry » Mon, Dec 05, 2016, 10:23 PM UTC

hankmccoy78 wrote: post #83

striking wrote: post #38

Earlier quoted context omitted.

See, but this doesn't address those community issues. It doesn't talk about the changes that these devs will have to make to keep up with the times. I don't have anything to say for Babel, as I'm not a user of it. But I remember the anger of the Angular community as Angular 2 was announced. No one could believe that they would eventually choose to leave behind Angular 1, that they'd have to nearly rewrite their apps…

Sure, people trying to use libraries and frameworks to make their living absolutely get frustrated for often legitimate reasons. But we're supposed to be professionals and as such we should have the self-control, skill, and empathy to channel our frustration into productive feedback instead of just venting our anger like an out-of-control toddler.

I suspect the professionalism aspect is a salient point - given the accessibility the platform offers, whilst many of githubs users are professional developers doing their day job, they might equally be somebody trying to build a webpage for their cat, who stumbled across the repo looking for a troubleshooting guide.

With platforms like github, it's difficult to attribute the degree of merit any given comment deserves, so we kinda have to take them all at face value. That can be pretty brutal at times.

Re: Dear JavaScript

#206

Post by algesten » Mon, Dec 05, 2016, 10:28 PM UTC

ajeet_dhaliwal wrote: post #105

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…

A better approach is to spin off a new system and give it a new name Great point. I think some developers or teams feel compelled to update the latest even if they are happy with what they have because using an older version number gives the appearance of being behind the standards and practices. In a case where changes take place to the extent that it makes the previous framework difficult to recognize or breaks com…

Remember this behaviour is encouraged by the deprecation warning notices of npm. I want my project to compile cleanly, but without me changing anything, from one day to the next, I may face a bunch of warnings because some maintainer somewhere decided they have a fresher version (lodash, pug/jade, node-uuid etc I'm looking at you).

Re: Dear JavaScript

#207

Post by detaro » Mon, Dec 05, 2016, 10:42 PM UTC

richardwhiuk wrote: post #190

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…

There isn't a dedicated support channel because OSS contributors don't want to support a project - that's a job you need to pay someone to do, they just want to write some code that scratches their itch. If you want more than this you need to be prepared to put down some money.

Stack Overflow and forums certainly do not pay their contributors. Many forums do not even pay their moderators. Just because there are coders that do not enjoy these things does not mean there is nobody who does. The tricky bit is to find the right people and allow them help as efficiently as possible.

Re: Dear JavaScript

#208

Post by kowdermeister » Mon, Dec 05, 2016, 10:50 PM UTC

magicalist wrote: post #187

kowdermeister wrote: post #54

There is no "fix" to this. This is how people work. Some like things some don't, you have to deal with it or look for a more secluded hobby. If you can call it a hobby. Maybe behind every angry post there is a frustrated developer who've thought or been told that XY framework "is-the-shit" and and it will rock the way he works. Then he tries it and faces a series of problems. One consequence might be that he feels st…

Why would a project maintainer be expected to write "exceptional" documentation, have a clear scope for something they might still be exploring, give visual architecture explanations, etc etc and we can't expect developers to deal with frustration like an actual human?

These project aim at the bleeding edge so if a maintainer sets the bar high, then it's expected to keep up with other aspects as well. Your work as a maintainer doesn't stop when the /src folder is full of code. Then comes the boring part.

These things change from project to project and if a project gets more traction other people will join to fill the missing gaps.

We can expect developers to contain themselves, but some just can't. They are precisely the ones who can't be stopped with any policy. Some are just in a bad mood and they also have graphomania, some are constructive some are mean. I think it's fine as is.

Re: Dear JavaScript

#209

Post by atemerev » Mon, Dec 05, 2016, 10:50 PM UTC

Gudahtt wrote: post #204

atemerev wrote: post #185

Earlier quoted context omitted.

The migration path wasn't explained at all. This is fine, if there would be a nice documentation for new version. There wasn't, except for some scattered blog posts. This is fine, if new version offered some exciting new features or simplified thing a lot. But no, everything became significantly more complicated. This is fine, if Babel was a production library packed into final build, and modularity is necessary to s…

To address the other points you raised; I personally found Babel 6 easier to use and understand than Babel 5. I suspect this is because I needed to configure Babel 5 anyway to meet my needs, so I was required to understand the configuration either way. Babel 6 made it much easier to understand what I was asking Babel to do; no magic, everything explicit. With version 5, the default settings were a moving target (whic…

The major point of frustration was JSX preprocessing for React.

Need JSX? You have to use Babel. There is no zero configuration for Babel anymore, so you have to spend time learning it and resolving numerous build conflicts with cryptic error messages.

Todo list example with React+Redux+Babel6 takes 14 JS files, Babel configuration file, Webpack configuration file and Node package file to be written anew. This is what "Javascript fatigue" is about: when you get to the working first example from the documentation, you will be completely exhausted.

The amount of boilerplate with this "standard" setup is worse than with Java/Maven, and this is quite an accomplishment. :(

Re: Dear JavaScript

#210

Post by joshmanders » Mon, Dec 05, 2016, 11:03 PM UTC

ajeet_dhaliwal wrote: post #105

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…

A better approach is to spin off a new system and give it a new name Great point. I think some developers or teams feel compelled to update the latest even if they are happy with what they have because using an older version number gives the appearance of being behind the standards and practices. In a case where changes take place to the extent that it makes the previous framework difficult to recognize or breaks com…

So then you're gonna have people looking at you and saying "ugh, Angular is old and outdated, you should be using ng-not-angular-but-newer-and-shiner!" and everyones gonna be upset that they didn't find out what the new versions name is so that they can upgrade to that.