[uranian]

What is this problem in the Javascript landscape to keep forcing developers to do things differently, with the penalty of your app not working anymore if you don't comply?

I mean, creating a new type of brush for painters is ok, but I don't see the need for forcing them to redo their old paintings with the new type of brush in order to keep them visible..

IMHO Coffeescript and some other to Javascript transpilers are still a much better language than the entire Babel ES5/ES6/ES7 thing. But for some reason my free choice here is in jeopardy. The community apparently has chosen for Babel and are now happily nihilating things that are not compatible with that.

In my opinion this is not only irresponsible, but very arrogant as well.

Although I do understand and can write higher order components, I still write and use small mixins in projects because it works for me. I also use createClass because I enjoy the autobinding and don't like the possibility to forget calling super.

Now I need to explain my superiors why this warning is shown in the console, making me look stupid using deprecated stuff. And I need to convince them why I need to spend weeks rewriting large parts of the codebase because the community thinks the way I write is stupid. Or I can of course stick to the current React version and wait until one of the dependencies breaks.

It would be really great if library upgrades very, very rarely break things. Imagine if all the authors of the 60+ npm libs I use in my apps are starting to break things this way, for me there is no intellectual excuse to justify that.

[Rygu]

Although I don't agree with the overall sentiment of your message, I do understand your situation as a professional. In fact I believe by far the largest (less vocal) group of React users only use it at work, and never wilfully agreed to spend their spare time on GitHub because of FOMO, or fear of dependency upgrades (FODU).

And I believe there should be a better way to prepare your users for a major version upgrade (React 15 -> 16) than to update the current branch with all kinds of deprecation warnings. Even if a library - as popular as React - doesn't plan to provide lifetime support for any major because they like to to move fast, I understand that, it's simply not okay to ruin older branches this way, madly assuming everyone is surely going to upgrade to React 16 in the immediate future.

Ideally, I'd imagine there could be a separate optional package that adds these warnings dynamically. If that's not possible technically, then an optional build flag would be nice. Or two separate releases: react-15.5.0 and react-15.5.0-upgrade-support. Even better: go back to semver, and treat major upgrades as optional for the first 6 months. This allows other libraries like routers and style libs to catch up, so app devs can upgrade even more smoothly.

Maybe after all, DX is about when to provide helpful errors and warnings. And when not to?

[danabramov]

Yea, this is a good idea and something we are considering for the future!

[erikpukinskis]

The JavaScript world is going to fragment soon. I'm an old school JavaScript developer... I'm not interested in Async, I'm not interested in promises, I'm not interested in classes. I think Javascript had some incredibly powerful features (functional, event-driven, small language) and ES6 removes all of those features.

I totally understand why the ES6 community likes it. It lets you write very Rubyish code and has lots of ergonomics for developers who don't want to have to think through the kinds of problems that functional programming forces you to think through. It's a push towards the Rails declarative aesthetic and away from functional/imperative. Declarative programming makes you feel like a wizard, until you have to debug something and then you feel like you don't know how to code at all. I've come to terms with the fact that the majority of JavaScript developers like this change.

But as libraries slowly drift out of compatibility with the older Node-style of programming, there comes a point where it's really a completely new language.

I think we're in for a fork of the community. Maybe there can be one runtime, but I think we're going to start seeing an alternative to NPM that allows developers to have an opinion about what JavaScript is.

[jhall1468]

What the hell are you talking about? None of those features are removed. The issue at hand is that we are developing more and more complex single page apps and we desire our primary language to support that trend.

Don't use classes. Don't use promises. Can't comment on what you said about async since it's literally nonsensical.

There is no fork coming, or if there is, it will only be used by a tiny portion of the community who thinks they are brilliant because they can "think through" functional programming problems but don't understand what role async calls play in modern development.

[erikpukinskis]

Can't not use promises because they're littered all over NPM now.

Not sure what's wrong with what I said about async? it's a new keyword in ES2017. It's a difficult to use control structure that doesn't do anything you couldn't do with callbacks. What part of "modern programming" do you need Async for?

I don't think I'm brilliant for being able to think through basic functional programming concepts. Actually the opposite... I think you need to be very smart to understand and debug promises, that's why they are bad. I like callbacks because they don't require me to be smart.

Maybe I'm smart for knowing I'm shooting my future self in the foot when I write code that requires smarts, but that's a little convoluted. The reason I care is because the ES6 community sold out beginners by adding all of this syntactic sugar. Javascript used to be a good beginner language.