Live data from Hacker News

The rise of React

increment.com

41–50 of 168 posts

Re: The rise of React

#41
post #22
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…

"there's nothing in between training wheels (CRA) and a motorcycle"

AFAIK the "betweens" are Next.js, Blitz.js, Gatsby, Remix, Expo, etc.

Re: The rise of React

#42

Earlier quoted context omitted.

> 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 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 ramp up of learning angular, but helping others on the team learn rx-js on top of it while trying to be productive probably cut our output in half.

It didnt help that we had a mix of junior developers and experienced .net devs all learning at the same time- half the battle was explaining which feature came from ES2015, typescript, angular or rx-js.

Hindsight may be 20/20, but I am reasonably confident that we could have been significantly better off with react. Ember was never an option because they are only just now getting features react and angular developers have been taking for granted for years.

Re: The rise of React

#43
post #22
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…

Check out craco, for overriding specific bits of config without ejecting:

https://github.com/gsoft-inc/craco

Re: The rise of React

#44
post #11
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…

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

on the native app side, ive seen this too with mvc, mvvm, mpv apps: people just arent very good at deciding what goes where in many specific cases

im not sure, but my guess is, the more layers you have to maintain, the higher the cognitive load that one has to implement so many parts, they start to tire and without knowing it, smear things across layers, making a huge mess over time

Re: The rise of React

#45
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 tried to start with React 5-6 years ago but got burned with WebPack complex config and scarce docs. Went back to it with Create React App 3-4 years ago and I'm in love, I don't ever want to go back to building complex apps with jQuery.

Re: The rise of React

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

I think there's a couple repos that provide exactly that - a webpackOverrides.js file or something similar.

I also think that next.js might have some of what the gp is interested in

Re: The rise of React

#47
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 feel the same way about React. Out of all of the current choices I feel like React is not only mature but very useful.

The only thing that really ever irked me is the weird LICENCE clause about patents but that was addressed.

Re: The rise of React

#48
post #7
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.

I meant more in the sense that different people could do different jobs. Non-developers/designers were able to do a lot of the frontend stuff. With the "new" complexity of frontend development that's mostly gone. I've seen it a few times with my own eyes that in teams the 1-5 frontenders specialised in html/css had a really hard time switching to react, at the same time more seasoned developers felt like fish in the…

FWIW enabling designers is one reason I like Vue a lot (as compared to react). With single file components[0], it's quite possible to contribute knowing just html+css.

In fact the scoped CSS makes Vue files superior to plain html+css for non CSS experts -- organizing large stylesheets is hard to get right!

[0] https://vuejs.org/v2/guide/single-file-components.html

Re: The rise of React

#49
post #25
post #7

Earlier quoted context omitted.

I meant more in the sense that different people could do different jobs. Non-developers/designers were able to do a lot of the frontend stuff. With the "new" complexity of frontend development that's mostly gone. I've seen it a few times with my own eyes that in teams the 1-5 frontenders specialised in html/css had a really hard time switching to react, at the same time more seasoned developers felt like fish in the…

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…

Some people just get development. I had one close person who was able to learn webdev and become and highly skilled freelance developer in 0.5 to 1.5 year (having played with computers his whole life), I had another friend who after 3 to 4 years still struggles to do a simple loop, let alone grasp a recursive function, at the same time he makes great designs and has good skills to implement them frontend wise. Different minds, different talents.

Re: The rise of React

#50
post #17
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.

The idea that HTML was meant to be a pure data format, styled by CSS classes that also were somehow part of that pure data format was always silly, but it became much more silly once REST apis became popular.

maybe its "ivory-tower thinking" in the end... that idea alwasy appealed to me to he honest... i guess the thing is its only one small facet of web development, not the whole thing
Post reply on HN