React v15.5.0 • Hacker News Board

Re: React v15.5.0

#171

Post by amk_ » Sat, Apr 08, 2017, 5:06 PM UTC

danabramov wrote: post #140

amk_ wrote: post #108

The breakup of the React package into a bunch of smaller modules really puts packages that treat React as a peer dependency in a pickle. I have a component module using createClass that works fine and exports a transpiled bundle in package.json. I guess now we'll have to switch to create-react-class, or maintain some kind of "backports" release series for people that are still using older React versions but want bugf…

Switching to create-react-class sounds reasonable, that's what we intended. It will work in older versions too.

If we switch to it as a hard dependency, library consumers on React Is create-react-class smart enough to determine whether the version of React it is augmenting already implements createClass to prevent bundle size bloat?

Re: React v15.5.0

#172

Post by peterhunt » Sat, Apr 08, 2017, 5:14 PM UTC

wesleytodd wrote: post #154

peterhunt wrote: post #117

Earlier quoted context omitted.

I was the guy who came up with autobinding in older Reacts and I'm glad to see it gone. It might save you a few keystrokes but it allocates functions that'll never be called in 90% of cases and has noticeable performance degradation. Getting rid of autobinding is a good thing.

As much as I agree with the performance side here, I believe the usability for devs is an important factor. Let the users who really need that last bit of perf opt-in, and let everyone else just go along in blissful ignorance. And I am honestly alright if "opt-in" means use preact or some other project. Think about the reasons jQuery and WordPress were popular, despite performance issues, they JUST WORKED for people.…

Don't you think the fact that React.createClass() behaves differently than JS makes it less usable (i.e. more surprising) for experienced developers? The goal of React is not to fix JavaScript's warts, nor is its goal to make programming easier for non-programmers. I believe if this is the goal of your project the end result would look very different from React (probably would look more like Vue).

Re: React v15.5.0

#173

Post by erikpukinskis » Sat, Apr 08, 2017, 5:24 PM UTC

uranian wrote: post #122

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…

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.

Re: React v15.5.0

#174

Post by acemarke » Sat, Apr 08, 2017, 5:56 PM UTC

wesleytodd wrote: post #152

spicyj wrote: post #113

Earlier quoted context omitted.

Thanks for the feedback, we do appreciate it.

Well 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 m…

Out of curiosity, what issues are holding you to React 0.12 on that first codebase?

Re: React v15.5.0

#175

Post by iLemming » Sat, Apr 08, 2017, 6:12 PM UTC

I wonder how these changes would affect Clojurescript libs built on top of React, e.g.: Om.Next and Reagent

Re: React v15.5.0

#176

Post by spankalee » Sat, Apr 08, 2017, 6:37 PM UTC

petilon wrote: post #148

danabramov wrote: post #144

Earlier quoted context omitted.

You can use web components in React just fine if that's your cup of tea. https://facebook.github.io/react/docs/web-components.html There's also more opinionated integrations like https://www.npmjs.com/package/skatejs-react-integration . And of course you can do it the other way around too.

The problem when you use Web Components in JSX is that there is no way to wire up any custom events fired by the Web Component. JSX will only wire up "known events".

That's just when you use custom elements in _React_.

I've definitely wired up JSX createElement implementations that handle attributes and events properly. My preference is for Polymer-style naming: `on-*` for event handlers, `$` suffix for attributes and everything else is a property. Others who've done this use special `attributes` and `events` properties.

Re: React v15.5.0

#177

Post by YCode » Sat, Apr 08, 2017, 6:37 PM UTC

spicyj wrote: post #85

YCode wrote: post #69

Earlier quoted context omitted.

When I saw this post I immediately hit http://isfiberreadyyet.com/ and was sad it went back down to 92% :|

We added some more tests for server rendering (which Fiber doesn't yet support). Working on it though.

I appreciate all the hard work you guys are doing; I understand it takes time and I think most people are willing to wait.

Re: React v15.5.0

#178

Post by EugeneOZ » Sat, Apr 08, 2017, 6:45 PM UTC

seattle_spring wrote: post #159

EugeneOZ wrote: post #155

Earlier quoted context omitted.

Example with "extends" is also in your docs (exactly by link of this post), so I'm not sure what it proves.

That's extending the base react component class, not an existing component class.

Well, if you think there's a difference then we never agree :)

Re: React v15.5.0

#179

Post by TheSisb2 » Sat, Apr 08, 2017, 6:45 PM UTC

tlrobinson wrote: post #75

thatswrong0 wrote: post #48

Earlier quoted context omitted.

Mild rant: I'm not convinced ES6 classes are better than components created the old way. First, the lack of autobinding callback functions for child props is not ideal. I don't even have to think about it with createClass, and it requires at least one extra step with ES6. It's less convenient. Second, I don't think HOCs are necessarily easier to reason about than mixins in many situations. React is already quite defi…

If you don't want to think about binding, just use the arrow function syntax: class Foo extends Component { bar = () => { // ... } }

This compiles poorly and has a performance cost, it turns out. Doing:

constructor(props) { super(props); this.func = this.func.bind(this); }

Is better if you care about performance.

Re: React v15.5.0

#180

Post by jhall1468 » Sat, Apr 08, 2017, 7:03 PM UTC

erikpukinskis wrote: post #173

uranian wrote: post #122

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…

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 lo…

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.