6 ms·
This is a big deal to deprecate `createClass` and `propTypes`. PropTypes' deprecation is not difficult to handle, but the removal of createClass means one of t
by STRML 9y ago
This is a big deal to deprecate `createClass` and `propTypes`.
PropTypes' deprecation is not difficult to handle, but the removal of createClass means one of two things for library maintainers:
(1). They'll depend on the `create-class` shim package, or,
(2). They must now depend on an entire babel toolchain to ensure that their classes can run in ES5 environments, which is the de-facto environment that npm modules export for.
I'm concerned about (2). While we are probably due for another major shift in what npm modules export and what our new minimum browser compatibility is, the simple truth is that most authors expect to be able to skip babel transcompilation on their node_modules. So either all React component authors get on the Babel train, or they start shipping ES6 `main` entries. Either way is a little bit painful.
It's progress, no doubt, but there will be some stumbles along the way.
- spion 9y agoIsn't there option (3) as well? Which would be, writing classes the old way, using prototypes and something like `util.inherits`
- acemarke 9y agoThat's basically what `createClass` does: https://github.com/facebook/react/blob/72196da82915bee400edb1599d4223926aa2a8a0/src/isomorphic/classic/class/ReactClass.js#L726-L831 https://github.com/facebook/react/blob/72196da82915bee400edb...
- fiatjaf 9y agoAre you afraid of Babel monopoly? I recommend trying https://buble.surge.sh/ https://buble.surge.sh/. My life is much better after I started using Buble and bubleify instead of this mess that is Babel.
- STRML 9y agoCome on. Buble is Babel, just with a few presets hardcoded. Yeah, it's better usability, until you need to run a production application.
- fiatjaf 9y agoOh is it? They deceived me!
- fiatjaf 9y agoHey, it isn't.
- skrebbel 9y agoWhy do you lie?
- evilduck 9y agohttps://gitlab.com/Rich-Harris/buble/blob/master/src/program/types/ArrowFunctionExpression.js https://gitlab.com/Rich-Harris/buble/blob/master/src/program... vs. https://github.com/babel/babel/blob/7.0/packages/babel-plugin-transform-es2015-arrow-functions/src/index.js https://github.com/babel/babel/blob/7.0/packages/babel-plugi... Maybe you could explain how this is the same thing?
- STRML 9y agoYeah, I'm actually completely wrong. My apologies to the Buble team. For whatever reason, I thought I saw an announcement of Buble essentially saying it was an opinionated feature-freeze of Babel with most of the configuration stripped out, but it appears to be a totally new project. That said, the two are very different tools. Buble appears to be essentially string manipulation (which Babel does to occasionally with babel-template) built on top of Acorn. It's much simpler but there are a lot of useful transformations you simply can't do with that approach. Edit: After some further looking into the project, I have to say that it seems like it would nice & easy to use for simple transformations, like the aforementioned React.createClass -> class Foo extends React.Component. However, you have to keep in mind that code that is not spec-compliant will break in mysterious ways perhaps months or years into the future. It may not be worth it, despite the ease. `yarn install babel-cli babel-preset-es2015; ./node_modules/.bin/babel --presets es2015 <sources> -d <out-dir>` is not particularly difficult.
- TheAceOfHearts 9y agoI think what we need is a mix between a module bundler and package manager. When you pull in a dependency, it should confirm the code can run on all your targets. If it wouldn't run, e.g. ES2015 classes but you have an ES5 target, it should be compiled. That way when you bundle your app, you can skip the compilation check on all third-party modules. Adopting an incremental compilation strategy will also speed up larger apps.
- spankalee 9y agoIt's really time to start distributing ES6 via npm. All current browsers support ES6. It's now generally faster than equivalent ES5, it minifies better, tooling is better, etc. It's the app that should compile all the code to run in the target environment if needed. This is what we've done in the new Polymer CLI / polymer-build: we compile all dependencies but only if necessary.
- STRML 9y agoI agree that this is the future. But that will mean telling everyone that they should now run their node_modules through Babel - no inconsequential feat, given the size of the code that must now be transpiled.
- untog 9y agoIt's not just that - is JSX part of ES6? It isn't, but a lot of pre-Babel transpiled code uses it. So people would need to transpile to ES6 for distribution, then to ES5 when someone uses the library. Messy.
- Silhouette 9y agoAll current browsers support ES6. That's debatable, particularly when you factor in bugs. However, even if they did, it seems unwise to assume that all relevant users for all or even most projects will be on the latest evergreen browsers. Several large groups, including business users on IE and mobile users on slightly older devices, probably won't be. I know there's a certain type of web developer who would love for everyone to have updated their browser within the last five minutes so all the new toys are available universally, but that has never been the nature of web development. Deliberately breaking major infrastructure is just going to make JS development even more screwed up than it already is.
- uieefx 9y agoyou know...if it can be transpiled by babel that means you could write it in es5 compatible syntax...yourself...so if you don't want to use the babel tool chain...what's stopping you? Don't know es5? IMO it's not too fun compared to es6...but...
- uieefx 9y agoSorry hn downvote police, but it is a true statement, even if you don't approve of the tone.
- wesleytodd 9y agoI agree, I am really concerned about this change. But unfortunatly I do not think my feedback via twitter was well taken: https://twitter.com/wesleytodd/status/850550711804989440 https://twitter.com/wesleytodd/status/850550711804989440 EDIT: I should add, that I didn't want to say that I completely disagree with the change to remvoe this api entirely on twitter to the maintainers. I am sure they get enough crap from people.
- spicyj 9y agoThanks for the feedback, we do appreciate it.
- wesleytodd 9y agoWell thanks then! I know social media sucks for this kind of stuff. And I am sorry for my contribution to that. And know we really all do appreciate it, we are just passionate and opinionated people. Personally I am more concerned about keeping my team building cool features than updating react. This has led to us having two distinctly non-interoperable code bases, one with react 0.12 and one with react 14-15. This makes me worried that now we will have a third with react >15. I think we can all agree that many of the ideas, while not new, were revolutionary to front-end web developers. And that is what I love about working in this stack. But other than these ideas, the projects themselves are just stumbling along trying to catch up with some perceived "modern" way of coding, and it is the dev teams and projects that suffer.
- acemarke 9y agoOut of curiosity, what issues are holding you to React 0.12 on that first codebase?