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

101–110 of 168 posts

Re: The rise of React

#101

Post by ridicter »

zdragnar wrote: post #42
ridicter wrote: post #32

Earlier quoted context omitted.

My experience with react with different: you have to spend a large amount of time upfront in order to get the basic features of a single page app. You burn a lot of mental energy figuring out which forms library, router library, etc to use. When it's time to upgrade, you have no guarantees that your libraries will continue to play together nicely. And quality and standards between libraries can vary dramatically. I p…

I dont know how much has changed in the two years since I last touched it, but Angular's blessed packages and ecosystem were more of a time sink than anything else- the flex layout package in particular was substantially buggier than simply using postcss with what was at the time css-next (I think it is preset-env now?) Additionally, baking in rx-js felt like a serious mistake- not only was there the roller coaster r…

I never used the flex layout package. That's a third party library, and I think sticking with CSS grid + flex makes more sense. (Alternatively, you can just use bootstrap or tailwind or whatever.)

RxJS is actually one of my favorite parts to Angular, but it _does_ lengthen the learning curve quite a bit. Once you get past that, you can have amazingly reactive apps. One of my beefs with ReactJS is that it doesn't play as well with RxJS. Now that I think of it, you're not actually required to use RxJS with Angular: you can convert observables to promises (`toPromise()`).

I could see how having junior/new developers could make things a lot harder. I remember first learning typescript and having to keep the TS playground open at all times to see how it compiled to ES5.

Re: The rise of React

#102

Post by ridicter »

mattlondon wrote: post #93
ridicter wrote: post #32

Earlier quoted context omitted.

My experience with react with different: you have to spend a large amount of time upfront in order to get the basic features of a single page app. You burn a lot of mental energy figuring out which forms library, router library, etc to use. When it's time to upgrade, you have no guarantees that your libraries will continue to play together nicely. And quality and standards between libraries can vary dramatically. I p…

Same experience here with Angular - I have heard it described as "batteries included". It has basically everything you need to do 99% of all projects right out of the box (notable missing thing is something cohesive to properly manage application state in a nice way). Takes a bit of effort to learn, but once you are up and running with Angular things are pretty fast to put together.

I think using managing state with an observable data service is a pretty good option w/o resorting to 3rd party libraries: https://blog.angular-university.io/how-to-build-angular2-app...

Alternatively, you could use Akita, which is built on top of this basic model, but offers a ton of additional functionality and the ability to use Redux Dev Tools.

Finally, you also have NgRX, which is based on Redux--but also adds a ton of overhead and boilerplate. I actually opted for Akita since it is way more ergonomic and offers most everything I need.

Re: The rise of React

#103

Post by marvindanig »

mcav wrote: post #75
marvindanig wrote: post #57

Agreed! The intent of React is to drive new developers away from the building blocks of the web. And it has definitely succeeded at that. The way its ecosystem has grown all over the place, I find very passionate developers that swear by it. But you never know, every technology at some point of time becomes a luddite’s take and then it’d become hard to even consider React. Someday may be near as well, given that it’s…

> The intent of React is to drive new developers away from the building blocks of the web. That’s not React’s intent.

not overtly, yes, but it is, you just don’t know it yet.

Re: The rise of React

#104

Post by simplify »

jaredcwhite wrote: post #87

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.

Is it really that maddening? This response feels much too political. There are things worth getting mad about, and then there are JavaScript frameworks.

Re: The rise of React

#105

Post by acemarke »

hn_throwaway_99 wrote: post #31
ng12 wrote: post #22

Earlier quoted context omitted.

> I have done a lot of React in the last 6 years and have never been frustrated with their decisions, which is very rare. Same, but this is also why I feel burnt by create-react-app. There's so many important features the team has simply decided it won't support. One of the biggest issues with the React ecosystem is that there's nothing in between training wheels (CRA) and a motorcycle (rolling your own config). Mayb…

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.

Re: The rise of React

#106

Post by exogen »

jaredcwhite wrote: post #87

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.

The writing could be improved, but to me it's clear that the previous paragraph is providing the context for this statement: they're talking about alternatives to using frameworks that provide a higher level of abstraction. Not alternatives to React itself.

Re: The rise of React

#108

Post by MaxBarraclough »

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?

Re: The rise of React

#109

Post by bobthepanda »

lucassen wrote: post #88
Nextgrid wrote: post #18

Earlier quoted context omitted.

Agreed. As someone unfamiliar with the JS ecosystem I find React to be difficult because it appears just as a UI library. I have to then choose between dozens of competing options for everything (local state management, API calls, forms, URL routing, etc) where as frameworks such as Ember (not sure about Angular) seem to provide those features out of the box using a consistent API as well as some structure. I guess R…

> 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"?

Re: The rise of React

#110

Post by mattlondon »

ridicter wrote: post #102
mattlondon wrote: post #93

Earlier quoted context omitted.

Same experience here with Angular - I have heard it described as "batteries included". It has basically everything you need to do 99% of all projects right out of the box (notable missing thing is something cohesive to properly manage application state in a nice way). Takes a bit of effort to learn, but once you are up and running with Angular things are pretty fast to put together.

I think using managing state with an observable data service is a pretty good option w/o resorting to 3rd party libraries: https://blog.angular-university.io/how-to-build-angular2-app... Alternatively, you could use Akita, which is built on top of this basic model, but offers a ton of additional functionality and the ability to use Redux Dev Tools. Finally, you also have NgRX, which is based on Redux--but also adds a…

Yeah the "inject a state service into everything you need" is one way of doing it, but it gets messy and it tightly binds your components with that particular state handling approach (e.g. re-using components across projects might get difficult if you have a bespoke state service for Project A and you want to use A's components also in Project B & C etc). We also found that there are big concerns about which components are allowed to access and update which state - e.g. why does a tiny inconsequential GUI control used to copy something to a clipboard potentially get access to read and mutate the entire application's state? You can start sharding it up and put in "ACLs" of sorts ... but that is some of the messyness I mentioned :)

Not seen Akita previously - will take a look. Thanks!

Post reply on HN