React v15.5.0 • Hacker News Board

Re: React v15.5.0

#181

Post by whitefish » Sat, Apr 08, 2017, 7:13 PM UTC

mlsarecmg wrote: post #138

frik wrote: post #102

Earlier quoted context omitted.

As soon as Shadow DOM v1 is implemented and active in stable in Chrome, Safari and Firefox, I am pretty sure it will start a new trend. And React might be persived like JQuery, Ember, Angular1 as a fad, that has been superseeded by new native browser capabilities. KISS. https://en.wikipedia.org/wiki/Web_Components

It won't. Web components are simple encapsulation sugar. Apps still have no means for dynamic structures while all the terrible templating pitfalls that frameworks like Angular brought are still present. React is a real solution. It isn't even a question or an "if" any longer. React has taken over, or rather, its principles have. They're clean, concise and don't twist the slightest standard all the while not breaking…

You can use JSX for Web Components too, see: https://github.com/wisercoder/uibuilder There is no need for a complex framework like React. Web Components + JSX is better than React. Why use a proprietary framework with patent issues when you could be using a standards based solution instead?

Re: React v15.5.0

#182

Post by thatswrong0 » Sat, Apr 08, 2017, 7:19 PM UTC

peterhunt wrote: post #172

wesleytodd wrote: post #154

Earlier quoted context omitted.

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

Where did we mention making programming easier for non-programmers? I think libraries should strive to be as usable as possible to _all_ programmers, which in this case means reducing or eliminating very common operations (such as binding callback functions). When we're talking about working on a large codebase, useless boilerplate is a legimate cost both in productivity and maintenance.

And by this logic, we shouldn't use JSX either.

Re: React v15.5.0

#183

Post by jhall1468 » Sat, Apr 08, 2017, 8:10 PM UTC

EugeneOZ wrote: post #178

seattle_spring wrote: post #159

Earlier quoted context omitted.

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 :)

Creating a nested class hierarchy and extending a single base class for all components are decidedly not the same thing.

Re: React v15.5.0

#184

Post by Silhouette » Sat, Apr 08, 2017, 8:26 PM UTC

spankalee wrote: post #165

Silhouette wrote: post #55

Earlier quoted context omitted.

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

Chrome, Firefox, Edge, Safari and Opera all support ES6. That's the current version of all major browsers. But, I'm not arguing that web sites should only serve ES6 to browsers, only that packages should be distributed as ES6 and the app should be responsible for compilation.

Chrome, Firefox, Edge, Safari and Opera all support ES6. That's the current version of all major browsers.

No, it isn't. For a lot of web developers, two of those aren't major browsers at all and you've missed the 800lb gorilla. You're also ignoring older versions of mobile browsers, the current Firefox ESR, and at least one other browser that has a larger market share than several of the above in parts of Asia, among other things.

But, I'm not arguing that web sites should only serve ES6 to browsers, only that packages should be distributed as ES6 and the app should be responsible for compilation.

And consequently, the entire community has to start incorporating a heavyweight build process that relies on third party tools just to use modules from the de facto standard package repository, and everyone also has to take extra time checking the exact requirements for every module they directly or indirectly depend on to make sure their build process supports it. In an ecosystem with absurd levels of microdependencies, which is certainly what we have today in JS world, the last thing we need is moving goalposts on the basic assumptions that everyone makes. This sort of thing is exactly why proper, long-lived standards are important as the foundation of a productive development ecosystem.

Re: React v15.5.0

#185

Post by crgwbr » Sat, Apr 08, 2017, 8:41 PM UTC

linkmotif wrote: post #81

fiatjaf wrote: post #36

Earlier quoted context omitted.

Yeah, in the beggining there wasn't autobinding, if you remember well. Then comes autobinding, now there's no autobinding anymore.

Yeah I still use `React.createClass({})` because... autobinding. Also wish someone would explain the draw of ES6 classes. React is about composition, not inheritance. Have never seen a `React.Component` extended.

We have a fairly large react codebase with some components using inheritance. It's not the solution to every problem certainly, but sometimes an abstract base component can be useful.

Re: React v15.5.0

#186

Post by peterhunt » Sat, Apr 08, 2017, 9:52 PM UTC

thatswrong0 wrote: post #182

peterhunt wrote: post #172

Earlier quoted context omitted.

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

Where did we mention making programming easier for non-programmers? I think libraries should strive to be as usable as possible to _all_ programmers, which in this case means reducing or eliminating very common operations (such as binding callback functions). When we're talking about working on a large codebase, useless boilerplate is a legimate cost both in productivity and maintenance. And by this logic, we shouldn…

The wordpress analogy.

I think the complaints you have are valid but should be solved by js, not react.

Re: React v15.5.0

#187

Post by mlsarecmg » Sat, Apr 08, 2017, 10:23 PM UTC

whitefish wrote: post #181

mlsarecmg wrote: post #138

Earlier quoted context omitted.

It won't. Web components are simple encapsulation sugar. Apps still have no means for dynamic structures while all the terrible templating pitfalls that frameworks like Angular brought are still present. React is a real solution. It isn't even a question or an "if" any longer. React has taken over, or rather, its principles have. They're clean, concise and don't twist the slightest standard all the while not breaking…

You can use JSX for Web Components too, see: https://github.com/wisercoder/uibuilder There is no need for a complex framework like React. Web Components + JSX is better than React. Why use a proprietary framework with patent issues when you could be using a standards based solution instead?

React is not complex, it solves complex problems, elegantly. Web components make it worse than it already is. By catering to the dom they fragment HTML even further. Now you rely on attributes for "if", "each", "of", "loop" and so on. It literally enforces frameworks shipping template parsers and script engines that duplicate and fight against Javascript, each with their own syntax. Without frameworks like Polymer you only get encapsulation and that's utterly pointless.

The extensible web is about low-level access. Web components go against everything that stands for. They're again pushing a bad vision that was decided on almost 10 years ago by people sitting in a closed room trying to interfere with how we write apps, resulting in a useless spec that adds complexity and weight. That spec btw took years of pushback against Apple and other vendors that weren't even interested in web apps rivalling their native stores. They have eventually given it green light because the spec is so tame it won't threaten a native app in a hundred years.

React on the other hand isn't much more than a simple idea:

    const Component = ({ text }) => {text}
    const Another = () =>

We can express UI declaratively and functionally. It solves our problems and pretty much has set the web free. Now there are dozens of frameworks that follow these principles, it's made it possible for Javascript to move on to native space, other platforms and devices. We're closer to truly universal apps than ever. Nothing proprietary about it, just technology that has managed to come through by its own merits which has evolved into an actual, living standard.

The W3C has the worst kind of track record, don't expect anyone to fall for all this hand waving for "standards," no one is that naive anymore. If a spec doesn't perform it gets discarded and by this point we already know web component don't.

Re: React v15.5.0

#188

Post by ravicious » Sat, Apr 08, 2017, 10:48 PM UTC

STRML wrote: post #34

ggregoire wrote: post #4

For those still using propTypes, I'd recommend to take a look at Flow as replacement. https://flow.org/en/docs/frameworks/react

We use Flow everywhere now and love it. It's not perfect by any means but it's a lot easier to use than Java's static typing and a lot more expressive to boot. I can't overstate how great it is to be able to strongly type your modules and ensure you don't send the wrong input or receive the wrong input from them. In fact, Flow allows us to confidently implement APIs that would just be cumbersome otherwise; we can use…

Flow is quite good, but over half of our React codebase is components connected to Redux or Redux Form and unfortunately there are no Flow types for the versions that we use, so type inference is very weak at some points.

Besides, Flow has a very ambitious target of delivering types for APIs which were not written with types in mind at all. I thought I'd be able to recreate some of the Elm's type safety with Flow, but that's just not possible and I doubt it'll ever be. But then again, these two projects have very different objectives.

Re: React v15.5.0

#189

Post by spankalee » Sat, Apr 08, 2017, 10:48 PM UTC

Silhouette wrote: post #184

spankalee wrote: post #165

Earlier quoted context omitted.

Chrome, Firefox, Edge, Safari and Opera all support ES6. That's the current version of all major browsers. But, I'm not arguing that web sites should only serve ES6 to browsers, only that packages should be distributed as ES6 and the app should be responsible for compilation.

Chrome, Firefox, Edge, Safari and Opera all support ES6. That's the current version of all major browsers. No, it isn't. For a lot of web developers, two of those aren't major browsers at all and you've missed the 800lb gorilla. You're also ignoring older versions of mobile browsers, the current Firefox ESR, and at least one other browser that has a larger market share than several of the above in parts of Asia, amon…

Yes, "current version" specifically doesn't include "older versions", that should be uncontroversial.

Not sure the 800lb gorilla you're referring to, but maybe UC Browser? That thing is so odd it's difficult to know what it supports, and it's not supported in nearly any popular CI service. I'm sure all kinds of things are broken on it, but you can still compile your app to ES5.

And ES6 _is_ a proper long lived standard. I'm not sure what would be more standard.

Compiling dependencies is not that heavyweight, especially when there is no configuration. Babel and TypeScript are fast. The results can be cached, it can be done on the fly for dev servers. Requirements shouldn't need to be checked - I'm not advocating for distributing code using decorators or class properties, nor modules (which without the HTML spec on module specifiers isn't a fully functional spec anyway) just plain ES6.

ES5 and ES6 classes cannot coexist on the same proto chain. Compiling to ES5 prevents things like mixins being usable against ES6 superclasses, so you force all dependents to be ES6. If you're going to force one way or the other, force in the future direction where there's still the option to compile the whole app to the older version of JS. ES5 classes can't extend subclassable built-ins like Array, Promise, Set, Map, HTMLElement, Error, etc. ES5 is now mostly slower than the equivalent ES6, it also doesn't minify as well as ES6.

Re: React v15.5.0

#190

Post by ng12 » Sun, Apr 09, 2017, 12:26 AM UTC

enraged_camel wrote: post #163

ng12 wrote: post #67

Earlier quoted context omitted.

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

I use single-page components in Vue and write templates like this: {{ title }} export default { data() { return { title: "Hello world" } } } Works well in my opinion. Separates the template into its own section but keeps it inside the same file.

In my mind this is strictly inferior to JSX, which would be:

   export default ({title}) => (
      
         {title}
      
   )

The only benefit to the template is if you use fancy features (#each, binding, etc) which is worse because now you have two places where the logic happens.