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

The rise of React

increment.com

Post reply on HN
Print view View original

151–160 of 168 posts

Re: The rise of React

#151

Post by hajile »

diffrinse wrote: post #73
brandonmenc wrote: post #51

Earlier quoted context omitted.

React may be an improvement on what came before, but it's still too complex for "draw a UI on the most-widely used platform." It's definitely not helping to democratize programming the way that the personal computer did when it simplified the world of computers down to a BASIC interpreter that a child could understand. The "advancements" are necessary, but let's be honest - they are far from ideal, overcomplicated me…

Unclear why React has to service that need. jQuery still exists, is still supported and maintained, and serves that need much more effectively I wager. And taking a step back I think many people in frontend confuse React for a jQuery alternative, the thing you whip up a web project with by default, but it really isn't. That there is a component ecosystem might suggest its a jQuery alternative, but they really are for…

I think that depends on how you use react. When I first started using it to replace jQuery, it resulted in different use patterns than when making a greenfield SPA. I just wanted something easier to maintain and it did that in spades.

React was an easy drop-in replacement. No state library or whatever else (there weren't a ton of libraries at that time). Just add React CDN, code up some simple components and add them to the page (they'd get a list of elements with the correct classname and inject one copy for each element).

Today, I still take a similar approach for the occasional CRUD site I work with. The only change is that now I use the much smaller pReact and use functional components with hooks instead of the old React.createClass() from the early days.

Re: The rise of React

#152

Post by pier25 »

srg0 wrote: post #143
pier25 wrote: post #128

React made a lot of sense to escape Angular, Ember, Backbone and jQuery in 2013-2014, but then it took 4-5 years to become wildly popular [1]. I've never understood its popularity despite the fact that during those years there were already better options out there by any metric you can think of (except popularity and hype). - Inferno and Preact: similar API but so much faster and smaller. - Mithril: vdom based with c…

Probably because none of those advantages of other solutions matter for small-to-medium scale business. It's about getting things done _fast_, not getting the fastest thing. And for that purpose, a popular tool is usually better (more people, more information, bigger ecosystem). As for the technical merits of the alternatives, they fail to manifest in most situations: "Faster" - any framework is fast enough for most…

> but shaving milliseconds vs man-months is a tough sale

It's not really one or the other. Both Preact and Inferno can be used with React libraries with a compat layer.

> bundling of the dependencies is completely irrelevant from the business perspective.

It's not irrelevant. Vue is used by major corps in China.

> It's something that the developers are paid to figure out.

Didn't you just argue that the advantage of React is that developers get "things done _fast_"? How come this is not an advantage in the case of Vue?

Re: The rise of React

#153

Post by srg0 »

pier25 wrote: post #152
srg0 wrote: post #143

Earlier quoted context omitted.

Probably because none of those advantages of other solutions matter for small-to-medium scale business. It's about getting things done _fast_, not getting the fastest thing. And for that purpose, a popular tool is usually better (more people, more information, bigger ecosystem). As for the technical merits of the alternatives, they fail to manifest in most situations: "Faster" - any framework is fast enough for most…

> but shaving milliseconds vs man-months is a tough sale It's not really one or the other. Both Preact and Inferno can be used with React libraries with a compat layer. > bundling of the dependencies is completely irrelevant from the business perspective. It's not irrelevant. Vue is used by major corps in China. > It's something that the developers are paid to figure out. Didn't you just argue that the advantage of R…

> Vue is used by major corps in China

It might be the case that in China Vue is the default and the most popular choice. And still my point holds: Vue is not the fastest, and is not the smallest framework. Technical merits alone ("faster", "smaller") are not enough to drive adoption.

On bundling/unbundling. I think it's a preference thing. "Batteries included" vs "modular" are both viable designs.

Re: The rise of React

#154

Post by jjeaff »

ricardobeat wrote: post #115
_hardwaregeek wrote: post #100

Meh, React is great for more reasons than modularity. One way data flow combined with automatic updating and rendering is really really nice. I just wrote a simple UI for a terminal and having to manually call a function to paint to the screen felt rather...quaint. We've had modular templates for years. It's only recently that we've had the ability to think of UI elements as functions that automatically get called wh…

> One way data flow combined with automatic updating and rendering React did not bring that. Flux , released a few months later, brought the unidirectional data-flow to it; we were already building similar architectures using event buses, though with looser abstractions. The 'automatic rendering' is a bit deceptive. Unless you manually optimize it, React will simply re-render everything all the time which is the same…

>React will simply re-render everything all the time which is the same as calling `App.render()` after every data change.

My understanding is that react will calculate the diff of your changes and what is already rendered and then only render the difference.

Re: The rise of React

#156

Post by XCSme »

satya71 wrote: post #8

The only reason I choose React today is the immense ecosystem around it. With every other framework, even though the core framework is capable enough, it feels like I have to reinvent wheels, axles, and more.

Same, when I had to choose the front-end framework for my neweset project I first looked at the UI libraries available at that time and went with React just because MaterialUI was so much better developed than all the Vue UI frameworks. The React ecosystem just feels a lot more robust and well maintained than the ones of Vue, Angular or Svelte for example.

Re: The rise of React

#157

Post by MaxBarraclough »

hajile wrote: post #150
MaxBarraclough wrote: post #108

Earlier quoted context omitted.

> two way data binding is the fucking devil You mean in terms of performance, or something else?

Mobx is a great example. It works well for small projects, but as they grow, you get bugs. One thing winds up depending on another that depends on yet another and before you know it, you've got all sorts of unexpected updates happening. These bugs often require digging into and though the mobx implementation details as you try to step your way to the problem. You can greatly reduce this issue, but you do so by refusi…

To mirror my other reply:

This is the 'spooky action at a distance' aspect of data-binding. Doesn't it apply to data-binding in general?

Re: The rise of React

#158

Post by XCSme »

cutler wrote: post #133

Battery drain is a metric often left out of the equation when assessing front-end frameworks. Download size is usually given priority but why? Your poor phone now has to run all that code you so zealously zipped.

That's interesting, are you also suggesting that serving non-gzipped content might lead to less battery usage than serving gzipped content? There will be less data downloaded, but mull CPU time to unzip the files. Isn't network a lot more costly (battery-wise) than CPU?

Re: The rise of React

#159

Post by Marazan »

MaxBarraclough wrote: post #144
Marazan wrote: post #140

Earlier quoted context omitted.

Reasoning about code. Creation of inscrutable bugs. Forcing to create convoluted hierarchy of data structures to work round the problems this convenient 'feature' created. The kicker for me is it is perfectly possible to use Flex in a one-way data binding manner. Just wish I'd worked that out 13 years ago!

Ah, the 'spooky action at a distance' aspect. Doesn't much of that apply to data-binding in general though?

I have found that the difference between one-way and two-way to be quite profound when it comes to the complexity of bugs produced.

Race conditions become an almost permanent fixture with two-way and the 'chains of causality' are exponentially more complex in a two-way situation.

One-way simplifies things in quite a profound way. I remeber when watching Dan Abromov's excellent Redux tutorial physically laughing and muttering "of course" as every single two-way bug I had ever worked on flashed before my eyes.

Re: The rise of React

#160

Post by ricardobeat »

jjeaff wrote: post #154
ricardobeat wrote: post #115

Earlier quoted context omitted.

> One way data flow combined with automatic updating and rendering React did not bring that. Flux , released a few months later, brought the unidirectional data-flow to it; we were already building similar architectures using event buses, though with looser abstractions. The 'automatic rendering' is a bit deceptive. Unless you manually optimize it, React will simply re-render everything all the time which is the same…

>React will simply re-render everything all the time which is the same as calling `App.render()` after every data change. My understanding is that react will calculate the diff of your changes and what is already rendered and then only render the difference.

It will diff the virtual dom, but you'll still be running the `render()` method again for every component. That is, unless you replace it with a PureComponent that does shallow diffing, write your own `shouldComponentUpdate` (if still using classes), or use something like Redux that will actually manage updates outside of React's component lifecycle and take advantage of immutable data structures.
Post reply on HN