Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

None of my projects want to be SPAs

whatisjasongoldstein.com

Post reply on HN
Print view View original

91–100 of 362 posts

Re: None of my projects want to be SPAs

#91

Post by chosenbreed37 »

kerkeslager wrote: post #79

Back when I was doing React, what pulled me in was that it WASN'T a framework for SPAs. What I got from it was the ability to build UI widgets (components, in React terms) that worked within a page, and were composable with other UI widgets. With that approach, you really wanted to keep every component self-contained. That meant a lot of bookkeeping with passing events back and forth between parent and child widgets,…

> Then introduce Redux and similar frameworks, and I totally lost interest. It's as if the entire React community forgot all the lessons they learned writing Python and C programs in college and went back to creating global state. What in the actual hell?

Fair point. But could it be possible that there are lots of people doing React that never went to college and never wrote Python or C programs?

Re: None of my projects want to be SPAs

#92

Post by skosch »

kerkeslager wrote: post #79

Back when I was doing React, what pulled me in was that it WASN'T a framework for SPAs. What I got from it was the ability to build UI widgets (components, in React terms) that worked within a page, and were composable with other UI widgets. With that approach, you really wanted to keep every component self-contained. That meant a lot of bookkeeping with passing events back and forth between parent and child widgets,…

I'm surprised you dislike Redux simply because it's a form of global state.

Sure, global variables make debugging difficult when you don't know which function changed them where and when and why. But that doesn't happen if you keep your functions pure and only make changes from within reducers – at least that's my experience.

(Boilerplate, yes, Redux adds that. But at least it's all in one place, and not scattered throughout your app.)

Re: None of my projects want to be SPAs

#93

Post by k__ »

laszlokorte wrote: post #24

What I did for a mobile web app I built last year after the react prototype was to slow on old devices: - Render all pages/routes/states into a single html file (size ~2mb) but each page/component/state hidden via style=display:none;. - then write some hand crafted js (few hundred lines) to add event listeners to forms and show/hide the components depending on url change - cache everything via appcache/serviceworker…

This is the worst approach I've ever read about.

Re: None of my projects want to be SPAs

#94

Post by mamcx »

Another angle is that "SPAs" are build on top of a fragile and anti-engineering tech stack: JS, CSS, HTML.

In the past a 'SPAs' was build on top of more solid foundation like smalltalk or later Delphi. Most issues is that the browser stack, put it in real terms, is not the "right tool for the job" and will never will, without serious re-engineering.

Re: None of my projects want to be SPAs

#95

Post by kerkeslager »

k__ wrote: post #85
kerkeslager wrote: post #79

Back when I was doing React, what pulled me in was that it WASN'T a framework for SPAs. What I got from it was the ability to build UI widgets (components, in React terms) that worked within a page, and were composable with other UI widgets. With that approach, you really wanted to keep every component self-contained. That meant a lot of bookkeeping with passing events back and forth between parent and child widgets,…

I don't think Redux is that big of a deal as you describe it. Many people just use setState. Since my last Redux project in 2015, I did many React and React-Native projects and not one of them used Redux.

You've been lucky then. I've worked on a few teams (I'm a freelancer) and even when they didn't add Redux, it's been something I've had to argue against.

Re: None of my projects want to be SPAs

#96

Post by kerkeslager »

WrtCdEvrydy wrote: post #87
kerkeslager wrote: post #79

Back when I was doing React, what pulled me in was that it WASN'T a framework for SPAs. What I got from it was the ability to build UI widgets (components, in React terms) that worked within a page, and were composable with other UI widgets. With that approach, you really wanted to keep every component self-contained. That meant a lot of bookkeeping with passing events back and forth between parent and child widgets,…

Redux was the solution to server side rendering state. If you don't use redux, then keeping state synced with a server side rendered application because nearly impossible.

> Redux was the solution to server side rendering state.

Could you explain what you mean by "server side rendering state"?

Re: None of my projects want to be SPAs

#97

Post by k__ »

kerkeslager wrote: post #95
k__ wrote: post #85

Earlier quoted context omitted.

I don't think Redux is that big of a deal as you describe it. Many people just use setState. Since my last Redux project in 2015, I did many React and React-Native projects and not one of them used Redux.

You've been lucky then. I've worked on a few teams (I'm a freelancer) and even when they didn't add Redux, it's been something I've had to argue against.

sounds bad.

I only did green-field projects where I was the only front-end dev.

Re: None of my projects want to be SPAs

#98

Post by pgm8705 »

We turned to React as the UI solution in our Rails app almost 2 years ago. It was the hot thing and I fell in love with the concept of components. While it did work well, I regret the decision. It convoluted our codebase and it seemed like simple tasks took way longer than I estimated. We're now back to doing things the "Rails way" with erb templates, turboklinks, and Stimulus to give us that JS functionality we were looking for when we chose to start using React. It's been a breath of fresh air.

Re: None of my projects want to be SPAs

#99

Post by joshuacc »

kerkeslager wrote: post #79

Back when I was doing React, what pulled me in was that it WASN'T a framework for SPAs. What I got from it was the ability to build UI widgets (components, in React terms) that worked within a page, and were composable with other UI widgets. With that approach, you really wanted to keep every component self-contained. That meant a lot of bookkeeping with passing events back and forth between parent and child widgets,…

> These frameworks add a huge amount of hidden global complexity just to avoid having to pass parameters to components, which is the simplest thing to do.

Redux offers a few benefits:

1. Allows you to keep your global application state 100% predictable by treating it as a pure function of an event stream (dispatched actions). This makes it trivial to test.

2. Allows you to "time travel" the state of your store using the Redux dev tools by replaying/modifying the event stream. You can also set up QA folks to export their events so that developers can reproduce any bugs in the global state 100% reliably.

3. Allows you to access global state without explicitly passing down props from great-grandparent to great-grandchild.

While I'm not a fan of using Redux for everything (it does have costs), you mentioned only the most minor benefit. If you only want #3, you would just use React's built in context API.

Re: None of my projects want to be SPAs

#100

Post by taeric »

koblas wrote: post #42
taeric wrote: post #22

Earlier quoted context omitted.

This builds an implication that spa tooling is the way to avoid a mess. Which is ironic to me. As soon as the teams I've seen start piling a ton of extra stuff into the UI, be it types to make things more safe or logic to make things feel faster, you get a mess. Note I'm not claiming either of those are the problem. More code is just almost always more mess. Keep it small. If possible, keep it separate.

There are two forms of mess in my experience, none of them have to do with SPA. 1) You have the problems that different developers have different styles. So when you jump from one area to another in the code base you're hit with WFT this is functional/procedural/inheritiance/composition, etc. style and your first thought is "barf" they did it wrong... 2) People either have huge functions that are spaghetti or tiny li…

Oddly, I would sum up both of those as bikeshedding problems. I agree it is a team issue.

I know the world is sick of gardening metaphors, but I do feel like there are lessons from community gardens. (Really any community thing.) You will usually have an owner that will paint broad strokes of what the rules are. Then, a bunch of spots that contributors are touching regularly. In their contributions, the rules are much more free form. But, you don't typically have people moving rapidly between contribution zones.

Which gets me to my favorite take on the answer. Solving the customer problem is not necessarily the same as solving any developer problem. If you are lucky, you can align them. However, as a developer brutal honest with self in "did this change actually provide any value to the customer" has to be constantly asked.

Post reply on HN