Live data from Hacker News

The rise of React

increment.com

161–168 of 168 posts

Re: The rise of React

#161

This article was great…up until the very end when it failed to mention any alternatives to React that already exist . "Alpert, who helped chart React’s rise, doesn’t see an alternative emerging anytime soon." This is completely ridiculous. Vue, Svelte, LitElement / Web Components, to name but a few. Maddening to see this level of journalistic malpractice.

(Sophie Alpert here.) What I meant is it’s not clear the next thing that will _replace_ React. Certainly there are plenty of great alternatives, each with their own pros and cons – but at this point, none clearly poised to “take over”.

I appreciate the clarification Sophie. :) Sometimes quotes just don't come through well in translation in finished articles.

Re: The rise of React

#162
post #153
post #152

Earlier quoted context omitted.

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

Since you're claiming the answer is not technical, why would Vue be more popular in China than React and why isn't Vue more popular in the Western world?

> I think it's a preference thing. "Batteries included" vs "modular" are both viable designs.

Again, it's not one or the other.

Vue in itself is just a simple rendering engine much like React, Inferno, etc. There are official libraries (router, state, etc) but those are separate projects which you can choose to use or not. It's not a framework like Angular, Ember, etc.

Re: The rise of React

#163

Earlier quoted context omitted.

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

Switching to one-way-binding is really just replacing upward propagation with events, right? Aren't both approaches vulnerable to data-change cycles, just by different means?

Re: The rise of React

#164
post #77

sidenote : i find it funny nobody in the comments mentions vue.js. i find mentions of ember and angular, but i had the impression vue was the one that got all the love recently. Has something bad happened to this framework ?

No, might just be the timing of this submission. Vue is doing great and is about to release version 3 which will be another big leap forward.

Vue 3 looks very much like they're just taking one more step closer to just being react, but made by a different company.

Re: The rise of React

#165
post #164

Earlier quoted context omitted.

No, might just be the timing of this submission. Vue is doing great and is about to release version 3 which will be another big leap forward.

Vue 3 looks very much like they're just taking one more step closer to just being react, but made by a different company.

How so? The functional paradigm of data -> view model -> events -> mutation is the same in every framework and state management library but there are lots of differences in other features. Vue has a lot that sets it apart.

Re: The rise of React

#166
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…

One-way data binding is what made React successful. Angular took a long time playing catch-up and with Vue it was optional.

Re: The rise of React

#167
post #158
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?

Sorry, I was refering to the CPU requirements of just running SPA code regardless of unzipping.

Re: The rise of React

#168

Earlier quoted context omitted.

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

Switching to one-way-binding is really just replacing upward propagation with events, right? Aren't both approaches vulnerable to data-change cycles, just by different means?

Maybe the difference is that you keep control with events, i.e. you can filter, retarget, cancel or otherwise reason in general about the way they propagate?

I'm no expert, but the essence of the "reactive functional programming" programming paradigm is that you have composable high level abstractions about the streams of events (e.g. marble diagrams).[1]

[1] https://blog.danlew.net/2017/07/27/an-introduction-to-functi...

Post reply on HN