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

131–140 of 168 posts

Re: The rise of React

#131

Post by ulisesrmzroche »

hoorayimhelping wrote: post #111
hombre_fatal wrote: post #67

Earlier quoted context omitted.

I don't get it unless you interpreted that statement inversely. It's the content, not the underlying architecture of a website, that makes in quirky and fun.

React and the tools used to build React applications (mainly webpack) strongly incentivize engineers to create single page applications, but don't provide good routing and back-button support out of the box. To make a React SPA behave like a traditional web page, you need to add a third party routing library, and that has traditionally been a dumpster fire in React. That's a quick example of the way the React monocul…

But then as soon you click the back button you lose all the state and have to do a lot of craziness to keep it in sync with the server. That’s the problem you’re trying to solve, trying to keep the server-client data reliably in sync.

And no one wants to wait around for all that state to load, that’s why those websites were so slow. Plus, then there’s the challenge of scale and traffic

It’s just not about the back button. It’s not about fashion, there are real problems that an SPA fixes. Sure it’s more complex, but the problem is more complex

It looks like you and a lot of people in HN work on super small websites that don’t require React or any SPA but yall don’t have to shit all over it and people who choose an SPA to build their web apps. In fact, more often than not, it’s the right choice

Re: The rise of React

#132

Post by ramraj07 »

ulisesrmzroche wrote: post #131
hoorayimhelping wrote: post #111

Earlier quoted context omitted.

React and the tools used to build React applications (mainly webpack) strongly incentivize engineers to create single page applications, but don't provide good routing and back-button support out of the box. To make a React SPA behave like a traditional web page, you need to add a third party routing library, and that has traditionally been a dumpster fire in React. That's a quick example of the way the React monocul…

But then as soon you click the back button you lose all the state and have to do a lot of craziness to keep it in sync with the server. That’s the problem you’re trying to solve, trying to keep the server-client data reliably in sync. And no one wants to wait around for all that state to load, that’s why those websites were so slow. Plus, then there’s the challenge of scale and traffic It’s just not about the back bu…

I come from the never-react side, but I see the benefits as well.

However, the issue is that an SPA is fundamentally something that doesn't fully integrate with what browsers were designed to do, which is show independent webpages.

An SPA makes sense if your site is exactly that, an app in the form of a site. Gmail can be an SPA, Google Docs can be _another_ SPA, they shouldn't be in the same SPA. The question is if your particular problem is fully encapsulated as one app or not, and whether you even need any real interactivity in it at all.

The other issue is that practically react tends to make people think they understand what they're doing but they do not really. This happened in the php days as well, but at least the sphagetti code was still interpretable without fully breaking your head, it was much more linear. With react, if the code is written by someone who doesn't share the same ideas of state and data flow as you, it's a huge headache to figure out what they have done.

Re: The rise of React

#133

Post by cutler »

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

Re: The rise of React

#134

Post by cutler »

Ozzie_osman wrote: post #83

As someone who has been in the industry for a dozen years, and been an engineer or managed engineers at companies of different sizes, I love React. Some benefits: 1- It has bridged a previously large gap between FE code and BE code, and hence, made it a lot easier for engineers who aren't FE-specialists to build frontend code. I've found that backend engineers are a lot more willing and able to write React code, sinc…

Peter Hunt, one of the original creators of React, was heavily influenced by David Nolen from the Clojurescript community. So we have Clojure to thank for the return of declarative programming.

Re: The rise of React

#135

Post by cutler »

hombre_fatal wrote: post #64
smnplk wrote: post #62

Earlier quoted context omitted.

Clojurescript with reagent and re-frame (or keechma, hoplon and others) outlasted two generations of Javascript technical churn. Nothing comes close.

Not really. Remember when people used Om for React bindings in Clojurescript? Clojurescript changes too. React has been around the whole time though. Also, along the topic in this thread, I've never met someone who used Clojure/script. It's why I ended up just using Node/Javascript in the end. It gets lonely in the Clojure cave.

Me too. I love programming with Clojure[script] but Clojure jobs here in London are very thin on the ground.

Re: The rise of React

#136

Post by The_Amp_Walrus »

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?

In terms of reasoning about your code, I expect.

Re: The rise of React

#138

Post by yashap »

kgin wrote: post #54
andrekandre wrote: post #50

Earlier quoted context omitted.

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

Same here, I spent so much time making semantic html that felt great but in the end was never consumed semantically by anyone or anything.

Semantic HTML is a pretty important part of making your site accessible. Screen readers have likely consumed that HTML plenty of times.

Re: The rise of React

#139

Post by ulisesrmzroche »

ramraj07 wrote: post #132
ulisesrmzroche wrote: post #131

Earlier quoted context omitted.

But then as soon you click the back button you lose all the state and have to do a lot of craziness to keep it in sync with the server. That’s the problem you’re trying to solve, trying to keep the server-client data reliably in sync. And no one wants to wait around for all that state to load, that’s why those websites were so slow. Plus, then there’s the challenge of scale and traffic It’s just not about the back bu…

I come from the never-react side, but I see the benefits as well. However, the issue is that an SPA is fundamentally something that doesn't fully integrate with what browsers were designed to do, which is show independent webpages. An SPA makes sense if your site is exactly that, an app in the form of a site. Gmail can be an SPA, Google Docs can be _another_ SPA, they shouldn't be in the same SPA. The question is if…

But it’s been such a long since browsers were first invented and they have changed to accommodate for web apps. Chrome, safari, Firefox et al today are far more capable than the browsers of old, and they do so because the overwhelming majority of users, virtually all of them want web applications.

As for the spaghetti code yes, it can be, but it doesn’t have to. I’m not gonna say it’s beginner friendly, but the software React is meant to be used for it’s not for beginners either

Re: The rise of React

#140

Post by Marazan »

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?

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!

Post reply on HN