Rather than acknowledge some of the criticisms are true the author complains that complainers are the problem. Can't see the forest through the trees.
Dear JavaScript
181–190 of 248 posts
Re: Dear JavaScript
#182I 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…
The change in Babel 6 was this: $ npm install babel-cli $ babel src -d lib To this: $ npm install babel-cli babel-preset-es2015 $ echo '{ presets: ["es2015"] }' >> .babelrc $ babel src -d lib It really wasn't that big of a change. Also, we did give it a new name. It used to be 6to5, and we changed the name around the intention to make it more generic. Which Babel 6 was the culmination of. As for communicating with th…
First off, I am sorry that it looks like my comments have continued to inflict pain on you and that really wasn't my intention. I agree with your main point: we should be decent to each other, and I apologize if I wasn't.
Second, I think you got burned harder on Babel because it was part of a bunch of starter packs. A lot of non-front-end guys like me started with things like Yeoman and didn't understand what was in the template, just that it worked for a while and then it didn't work.
Unfortunately, these seem like things you couldn't necessarily prevent by reaching out more, which is part of what I was trying to convey. The other party wasn't listening. And that's on us.
Anyway, I hope that people are more decent to you and you recover. We really do appreciate the work you are doing.
Re: Dear JavaScript
#183> But when someone starts to insult me in mock my hard work, when they criticize me and my work in a way that is extremely negative, it gets to me. That seems to be the essence of his entire essay. He wants people to be nicer. Yes, criticism is often necessary and often motivates progress, but the criticism should be nicer. Well, that's an ideal but his lament isn't limited to Javascript specifically. Nasty complaini…
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?
Re: Dear JavaScript
#184Great post. Open source maintainers clearly have some responsibility but we need to remember that they contribute their free time to make users lives easier
Re: Dear JavaScript
#185Dear 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…
>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 save precious bytes from web-transmitted JS. But no, it is a development tool. Nobody cares about its size or one-size-fits-all.
I just don't understand. What is the use case that required such a big sacrifice?
Re: Dear JavaScript
#186Dear 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…
Now I apologise if you've explained this elsewhere, but nowhere in your comment did you point out specific problems that you had with Babel 6. You called it "unintuitive", "terrible", "frustrating", and said that it "broke the web", but you never explain how or why. And I think that's part of the problem. It's one thing to suggest improvements, explain why something hurt, or how it caused an issue. It's another entir…
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?
Re: Dear JavaScript
#187There 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?
Re: Dear JavaScript
#188The problem with the JS learning curve is the HUGE amount of StackOverflow and blog posts that are insanely outdated, with no way for the casual reader to check if the question or the answers are actually usable on a modern version.
I believe that this, combined with complex, incomplete or outright missing documentation (hello Webpack, though the situation has improved since a couple of months) is something that holds the JS community back very hard - also because people complain all the time to framework authors "the example I c&p d from stackoverflow doesn't work" and answering these complaints takes nerve and time.
The PHP community suffers from the same fate, btw - remember mysql_*? People still find it in the top 10 Google results for some questions.
The only environments that have managed to resist this problem are Win32 and the userspace part of the Linux Kernel. In a lot of cases one is able to even open a VC6 project in a modern Visual Studio, have it converted and building - or at least just having to mess with the VC build process, but thanks to a hell of #ifdef's, the Win32 code still builds - and runs! For what it's worth, I can run Windows 95-era EarthSiege 2 on a 64-bit processor and the only things broken are the joystick input (by disassembly I believe the responsible code suffers from a bad version check on a struct) and some timer that binds a specific movement to the framerate and naturally overspeeds as a modern system can easily hit 100 FPS.
Same holds true for the Linux kernel, it's amazing that a statically compiled game like UT2004 still runs on a modern day Linux system.
In contrast, JavaScript - "npm install ", as many tutorials describe, is likely to already give an incompatible (with the instructions) package when the book finally gets printed. I have the feeling that like with libraries, major versions should always be backwards-compatible for their subversions, and have different NAMES for their major versions, e.g. "npm install angularjs1" vs "npm install angularjs2".
Re: Dear JavaScript
#189Earlier 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. Babel6 transition took three days of my life, filled it with misery and rage, lost me a customer, and led to my desire to never touch JavaScript again if I can help it. (I moved to ScalaJS eventually). Bad news: you are not a special snowflake deserving of a…
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 breath you continue to do what you acknowledge is exactly that behavior.
Either there's some fundamental disconnect in your mind that you need to address or you should just say what you mean.
Re: Dear JavaScript
#190I 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…
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.