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

141–150 of 168 posts

Re: The rise of React

#141

Post by dgb23 »

rimliu wrote: post #113
dgb23 wrote: post #25

Earlier quoted context omitted.

I’m currently training/mentoring a designer in using React, Tailwind, Markdown and basic CLI tooling (git and yarn). She appreciates the power and expression shes given and is learning quickly and steadily. No prior coding knowledge. Most of this comes down to getting past the fear of coding/programming. And it is a powerful enabler, even reshapes thinking. She recently came up to me with saying “why should I write t…

That's really the main reason React got popular. Somehow it lets the people who do not know what they are doing get by. At the expense of the users.

Mind you in my case the designer just really does JSX templating with it and styling. The wiring, plumbing, state and so on is not her business.

The reason I use React is mostly its composable, simple templating abstraction and the fact that it works both on the server and the client.

UX is generally improved. If a site/app is done well, it will work w/o JS enabled, loads fast and transitions even faster.

JS typically makes things better, not worse. What makes sites slow is putting in external and/or heavyweight stuff: ads, analytics, tracking, fonts, images and so on.

Re: The rise of React

#142

Post by arvinsim »

acemarke wrote: post #105
hn_throwaway_99 wrote: post #31

Earlier quoted context omitted.

I totally agree. If you need access to one config variable CRA doesn't support out of the box, your only option is to eject. I really wish there were the option of just providing an "overlay" file that only had your changes from the CRA defaults, rather than being forced to eject the whole config.

There are multiple existing third-party tools in the ecosystem that let you do exactly that: - https://github.com/gsoft-inc/craco - https://github.com/harrysolovay/rescripts - https://github.com/timarney/react-app-rewired - https://github.com/arackaf/customize-cra No, they're not "officially" supported, and you basically void the warranty by poking the configs manually, but the tools do what you want them to do.

But I think that is the problem. Since there are many ways to do it, you will have to evaluate each one and hope the one you pick gets upstream updates.

Re: The rise of React

#143

Post by srg0 »

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 of the common tasks; and even if a popular framework is not the fastest, it is not necessarily a bottleneck in the real life applications.

"Smaller" - it is just "faster" download. Irrelevant in many usage scenarios. It might be important in some applications, but shaving milliseconds vs man-months is a tough sale.

"Official batteries" - bundling of the dependencies is completely irrelevant from the business perspective. It's something that the developers are paid to figure out.

Re: The rise of React

#144

Post by MaxBarraclough »

Marazan wrote: post #140
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?

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?

Re: The rise of React

#145

Post by jasongi »

bobthepanda wrote: post #109
lucassen wrote: post #88

Earlier quoted context omitted.

> everything (local state management, API calls, forms, URL routing, etc) hooks, axios, html, reach-router. my point is that if you start with the assumption that browser APIs are sufficient, there is a natural progression to your project and «taste» in supporting libraries to react

just curious, what does axios provide over basic browser "fetch"?

Browser compatibility

Re: The rise of React

#146

Post by nickbauman »

ht85 wrote: post #2

Props to the people who have been managing the project. I have done a lot of React in the last 6 years and have never been frustrated with their decisions, which is very rare. I think beyond the technical aspects, the way React evolved over time was really on point. The roadmap has always been very well designed and the literature around new features and deprecated ones top notch. The way React is used has changed co…

I prefer to use it as a rendering library only. That part is good. But much of the ecosystem is a mess. CRA, a fundamental piece, is a trainwreck. If you eject you can see how much focus on local simplicity has been implemented at the expense of global stability...

Re: The rise of React

#147

Post by TuringTest »

ng12 wrote: post #85
k__ wrote: post #78

Earlier quoted context omitted.

CRA focuses on the very basics, so it's probably not suited for your problem. Can't you switch Next.js to SSG for all routes since v9?

CRA is exactly suited to my problem: these are simple React front-ends. I don't want any sort of server-side rendering. I don't need any of the features from Next.js. I just the ability to modify some of the basic configs that are hard-coded in CRA for unclear reasons.

When there is a clear case of use like this, the usual procedure is to create and publicize your fork.

If enough people start using it, the original maintainers will see the need it covers, and hopefully will get rid of their dogmatic attitude, seeing how real people are adopting the approach they found no value in.

Re: The rise of React

#148

Post by acemarke »

arvinsim wrote: post #142
acemarke wrote: post #105

Earlier quoted context omitted.

There are multiple existing third-party tools in the ecosystem that let you do exactly that: - https://github.com/gsoft-inc/craco - https://github.com/harrysolovay/rescripts - https://github.com/timarney/react-app-rewired - https://github.com/arackaf/customize-cra No, they're not "officially" supported, and you basically void the warranty by poking the configs manually, but the tools do what you want them to do.

But I think that is the problem. Since there are many ways to do it, you will have to evaluate each one and hope the one you pick gets upstream updates.

I'd go with `craco`, personally.

Re: The rise of React

#149

Post by k__ »

TuringTest wrote: post #147
ng12 wrote: post #85

Earlier quoted context omitted.

CRA is exactly suited to my problem: these are simple React front-ends. I don't want any sort of server-side rendering. I don't need any of the features from Next.js. I just the ability to modify some of the basic configs that are hard-coded in CRA for unclear reasons.

When there is a clear case of use like this, the usual procedure is to create and publicize your fork. If enough people start using it, the original maintainers will see the need it covers, and hopefully will get rid of their dogmatic attitude, seeing how real people are adopting the approach they found no value in.

Also, there may very well be forks already that are used by many people that allow to do what they want.

Re: The rise of React

#150

Post by hajile »

MaxBarraclough wrote: post #108
Marazan wrote: post #99

I was a Flex developer. No JS framework felt anywhere close to the ease and power of Flex until I saw React. React is Flex done right. React is Flex but armed with the knowledge that two way data binding is the fucking devil.

> 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 refusing to use most of the 2-way binding features. At that point, you're going to basically be doing one-way data flow anyway and might as well go all-in with a library tailored to do that.

Post reply on HN