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”.
The rise of React
161–168 of 168 posts
Re: The rise of React
#162Earlier 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.
> 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
#163Earlier 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…
Re: The rise of React
#164sidenote : 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.
Re: The rise of React
#165Earlier 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.
Re: The rise of React
#166React 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…
Re: The rise of React
#167Battery 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
#168Earlier 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?
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...