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

31–40 of 168 posts

Re: The rise of React

#31

Post by hn_throwaway_99 »

ng12 wrote: post #22
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 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.

Re: The rise of React

#32

Post by ridicter »

whycombagator wrote: post #16
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.

> With every other framework, even though the core framework is capable enough, it feels like I have to reinvent wheels, axles, and more. Curious, does that apply to Angular/Ember?

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 prefer the Angular approach. The initial learning curve is steep, but once you get over that, it becomes a rapid development framework, as all the pieces work together cohesively. The Angular CLI makes creating components, services, updating, etc a breeze, and helps maintain structure as your scale your app up. The core libraries (like routing, forms) are developed and maintained by Google, so you can expect a solid level of quality. The typescript-first approach means that your IDE can help you explore APIs, auto import, and work with third party libraries just as well. And the strong foundation provided by the core framework means that third party libraries have a better starting point upon which to supplement/extend.

Re: The rise of React

#33

Post by alpinacloud »

ng12 wrote: post #22
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 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…

Not sure if I understood you correctly, but if I did then you can use react-app-rewired https://github.com/timarney/react-app-rewired

Re: The rise of React

#34

Post by cstuder »

ng12 wrote: post #22
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 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…

From the official docs: Alternatives to Ejecting.

https://create-react-app.dev/docs/alternatives-to-ejecting/

Re: The rise of React

#35

Post by lukeramsden »

ryandvm wrote: post #11
Swizec wrote: post #6

Earlier quoted context omitted.

In my experience that separation of concerns was fake. 15+ years of webdev and I ain’t ever seen a redesign that doesn’t fundamentally change the layout and business logic. Never seen a spec update to logic that doesn’t also change how things look. The coupling is super tight and always has been.

This is true. The MVC idea of separation of concerns on the surface seems like a good idea, but the reality is that I've never been on a team that was disciplined enough to actually keep things separated. As a mostly back-end developer, I am not a fan of the complexity and magical bullshit you have to know about to use React properly. I am also disgusted when a stopwatch app that can be done in 500kb of native code t…

> I am also disgusted when a stopwatch app that can be done in 500kb of native code turns into 25 MB of cruft when implemented with React Native.

On the other hand, the time saved from using React Native versus having 2 separate codebases for iOS and Android is the difference between having a product and not having a product for many teams and solo developers. The issue there is not React Native being bloated, but cross-platform development being such a pain.

Re: The rise of React

#36

Post by wintorez »

Swizec wrote: post #3

I think React’s biggest win is that it appeals to the programmers, not just the web developers. For the first time everything you need to make a website or webapp — html, css, etc – is just data. You have direct control, direct access, you can do what you want. There’s a beauty and simplicity in that. React is to web frontend what Lisp is to systems programming.

Exactly. React morphed front-end development into front-end engineering.

Re: The rise of React

#37

Post by ht85 »

ng12 wrote: post #22
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 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've has a lot of success using react-app-rewired to do small changes to the webpack config.

You avoid ejecting and benefit from upgrades to CRA, but you can customize anything you like.

There's a `customize-cra` lib that provides useful helpers that you can use to perform the most common operations.

Re: The rise of React

#38

Post by ht85 »

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.

See sibling comments for solutions to do exactly that.

Re: The rise of React

#39

Post by ht85 »

AbenezerMamo wrote: post #9
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…

Is “props” a pun? If it is...I appreciate it * snap

Nah, I just wanted to state my appreciation.

Re: The rise of React

#40

Post by baron816 »

toshk wrote: post #5
Swizec wrote: post #3

I think React’s biggest win is that it appeals to the programmers, not just the web developers. For the first time everything you need to make a website or webapp — html, css, etc – is just data. You have direct control, direct access, you can do what you want. There’s a beauty and simplicity in that. React is to web frontend what Lisp is to systems programming.

The downside to that is that I've seen a lot of old school frontenders who 5-7 years ago were able to just dus html/css and sass haven't been able to keep up, it just got too complex. In that regard the old situation had better seperation of concerns.

That's the luddite take.

You probably shouldn't take up a career in technology if you're not willing to continually learn new things to keep up with advancements.

Post reply on HN