Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React v15.5.0

facebook.github.io

Post reply on HN
Print view View original

61–70 of 209 posts

Re: React v15.5.0

#61

Post by untog »

STRML wrote: post #42
spankalee wrote: post #39

Earlier quoted context omitted.

It'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.

I 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.

It'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.

Re: React v15.5.0

#62

Post by streptomycin »

raquo wrote: post #57
streptomycin wrote: post #23

Earlier quoted context omitted.

Flow is not a replacement for propTypes, they are complementary. Flow for compile-time errors, propTypes for runtime errors.

It is though. Runtime type validation is just a clutch that's needed when you don't have compile time validation.

Technically true, but how many projects actually are 100% typed, including:

* absolutely no any types or other imprecise types, no files skipped, no lines skipped, etc * every single piece of external data (API requests, reading from localstorage/IndexedDB, etc) is explicitly validated to make sure it exactly conforms to expectations * all dependencies are also typed to the same standard (not just some type definitions slapped on top of an npm module, those could easily be wrong and often are)

Probably some are. But none of mine are, sadly. And I don't think I'm in the minority.

Re: React v15.5.0

#64

Post by baron816 »

jschrf wrote: post #56
swalsh wrote: post #54

Earlier quoted context omitted.

Care to add more to this? I've been doing javascript in some form or another for 10 years. We've always been able to do something "class like", but having actual real classes in ES6 is great. What is there not to like?

I think this is just a trope that JS devs and newbies have launched on to, and that it's without merit. Classes are good. Classes express concrete taxonomies of concrete things in ways that most developers can understand. I think we should be happy that JS is flexible enough that adding "class" to the language is almost purely syntactical: it clarifies and makes semantic a bunch of otherwise boilerplate "Foo.prototyp…

There's nothing wrong with classes, they're just not right for JavaScript. I'm not going to claim that I'm a JS expert or anything, this is just something I've learned from pretty well established JS experts like Kyle Simpson and Douglas Crockford.

The reasons they give are that 1) you should favor composition and delegation over classical inheritance 2) classes keep you from using and understanding closure and other functional patterns and 3) you just get a lot of really weird behavior when trying to use classes in JS which results in a lot of confusion and wasted time, especially for those who don't have 10 years of experience under their belt.

Edit: Here's Simpson's take: https://github.com/getify/You-Dont-Know-JS/blob/master/this%...

Re: React v15.5.0

#65

Post by ng12 »

baron816 wrote: post #43

I hate that the React team prefers ES6 classes. This is what I do: function App(params) { const component = new React.Component(params); component.lifeCycleMethod = function() {...}; component.render = function() {...}; function privateMethod() {...} return component; }

Oh god why. This is like Google Closure code, which is terrible to maintain even at it's most idiomatic.

Re: React v15.5.0

#66

Post by untog »

raquo wrote: post #57
streptomycin wrote: post #23

Earlier quoted context omitted.

Flow is not a replacement for propTypes, they are complementary. Flow for compile-time errors, propTypes for runtime errors.

It is though. Runtime type validation is just a clutch that's needed when you don't have compile time validation.

Not necessarily - you could be parsing a JSON API response or something.

Re: React v15.5.0

#67

Post by ng12 »

TheAceOfHearts wrote: post #29

React team is doing an amazing job. I remember when it was first announced, I thought Facebook was crazy. "JSX? That sounds like a bad joke!" I don't think I've ever been so wrong. After hearing so much about React, I eventually tried it out and I realized that JSX wasn't a big deal at all, and in fact it was actually pretty awesome. Their migration strategy is great for larger actively developed applications. Since…

Agreed 100% about JSX. Especially since the only alternative anyone uses is opaque stringly-typed template nonsense (Angular, Vue, Ember, etc).

Re: React v15.5.0

#68

Post by YCode »

xamuel wrote: post #60

Happy to see propTypes getting shelved. Too many people stubbornly use propTypes even in Typescript projects. Hopefully this change will usher in the final stamping out of that.

What's wrong with propTypes?

Re: React v15.5.0

#69

Post by YCode »

Rapzid wrote: post #3

Fiber is what I'm really waiting for. Not much official chatter about it, but looks like a 16 release? They just removed some addons in master that many third party packages rely on, including material-ui. Hopefully these other popular packages can be ready to go with the changes when the fiber release hits.

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

Re: React v15.5.0

#70

Post by acemarke »

baron816 wrote: post #64
jschrf wrote: post #56

Earlier quoted context omitted.

I think this is just a trope that JS devs and newbies have launched on to, and that it's without merit. Classes are good. Classes express concrete taxonomies of concrete things in ways that most developers can understand. I think we should be happy that JS is flexible enough that adding "class" to the language is almost purely syntactical: it clarifies and makes semantic a bunch of otherwise boilerplate "Foo.prototyp…

There's nothing wrong with classes, they're just not right for JavaScript. I'm not going to claim that I'm a JS expert or anything, this is just something I've learned from pretty well established JS experts like Kyle Simpson and Douglas Crockford. The reasons they give are that 1) you should favor composition and delegation over classical inheritance 2) classes keep you from using and understanding closure and other…

It's worth noting that the React team promotes composition over inheritance, and discourages any levels of inheritance past `class MyComponent extends React.Component`.

Long term, the React team plans to investigate concepts like "stateful functional components", but until then, classes are the most straightforward way of having lifecycles. The existence of ES6 classes is based on the wide range of third-party "class" implementations across the JS ecosystem, so clearly there was a desire to have them available. Since they're available, React is using them.

Post reply on HN