Live data from Hacker News

None of my projects want to be SPAs

whatisjasongoldstein.com

231–240 of 362 posts

Re: None of my projects want to be SPAs

#231

Earlier quoted context omitted.

Why use a tool to solve a problem with another tool, rather than using tools that don't have the problem in the first place?

Because I decided I like React? :P From my perspective, React is the thing with the problem: it doesn't have great state management for complex tasks / multi-component coordination. What I want to use is something like RxJS to manage such interactions and state, because it gives me a lot of power/control in a relatively easy way. One of the best options out there that I've seen is redux-observable, and thus Redux its…

Plenty of people pair RxJS with React, including PayPal and Netflix. There is nothing precluding you from doing so. What kind of point is this?

Re: None of my projects want to be SPAs

#232

Earlier quoted context omitted.

> I have also witnessed discussions where management admits that they want something done in an SPA so that they can show that work to their investors, as a means of getting funding to do other projects. Absolutely. This extends well beyond SPAs, too, in my experience. I recently burned part of a month explaining to my senior management chain why you don't just, literally, "do machine learning." Of course, it turns o…

I do machine learning consulting and I see the flip side of this. I get new clients reaching out asking me to "add some AI" with no specific use cases in mind other than satisfying their investors that they are "leveraging AI."

Had a client that wanted a machine learning solution to determine if one name that was in one list was also in another list...

Re: None of my projects want to be SPAs

#233

Earlier quoted context omitted.

> The issue with Redux is that it encourages side effects in components. Which is why a lot of people that encourage Redux tend to also encourage one or more of the "side effect" managers such as thunks, sagas, or observables (my preference).

Why use a tool to solve a problem with another tool, rather than using tools that don't have the problem in the first place?

The problem that you end up with past a certain scale in a component-based app without a state management framework (third party or your own) is that you're performing business logic inside view components. By moving your business logic into your state management framework and using something like redux-saga that is designed specifically for managing complex asynchronous workflows, you can extract your application code from your views and make your views pure functions of the state tree.

When I hear someone complaining about redux using global state, I like to ask them what makes global state bad. The answer is usually that it allows any part of the application to change a value, which makes debugging difficult. This doesn't apply to redux and similar frameworks because every slice of the state can only be managed by a single, pure function, which makes it incredibly easy to debug. Additionally, redux uses a copy on write mechanism, so your state tree isn't actually being mutated, which allows you to use equality comparison instead of a deep compare to see what state has changed. That, combined with the fact that all actions go through a central dispatcher that is easily audited means unit testing your state transitions is almost laughably trivial. And since you are pulling all of your business logic out of your UI components, you can avoid the side-effect hell of unit testing your UI.

Having said that, I won't use react or redux for any website that doesn't have a heavily interactive UI with complex state that must be shared across many pages. Managing application state in your front end is an enormous burden and you'd be crazy to take it on without a need for it.

Re: None of my projects want to be SPAs

#235

Earlier quoted context omitted.

Building an SPA for every single project is like using a semi-trailer to commute everywhere you go. Sure, it will always get you where you need and sometimes turns have to be taken pretty wide, but what's the downside? Well, if you're destination is just 2 blocks down the road then why not walk? If you just need a simple page and the content doesn't need to be updated often, why not some flat HTML/CSS/JS? Many times…

I didn't consider small static sites. I agree with that and have done some landing pages that way that stand in front of SPAs. I guess I was commenting on OP wanting to use Rails or Spring MVC for views instead of only using them for APIs. I'm not sure what the term for it is, monolith maybe.

I believe the term would be "Server-rendered MVC framework". I think the argument for server-rendering is simply productivity. You can probably get stuff done about twice as fast if the use case fits the paradigm.

Re: None of my projects want to be SPAs

#236
post #92

Earlier quoted context omitted.

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 th…

> 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. Sticking to reducers IS a good idea and it does make things a bit better. The problem with global state goes deeper than that, though. Often, as you learn about the s…

It's generally considered a best practice to use pure selector functions in your UI components so the only place in your application that references the actual data structure is the root selector that pulls data out of the state tree. I personally try to structure my selectors so that any refactoring only requires changing a single line of code.

Re: None of my projects want to be SPAs

#237
post #220

Earlier quoted context omitted.

> 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. Sticking to reducers IS a good idea and it does make things a bit better. The problem with global state goes deeper than that, though. Often, as you learn about the s…

If you're giving me the choice between dealing with this: > Often, as you learn about the structure of the data, it becomes useful to change how the data is structured and stored. In global state, you can change that in reducers, sure, but then all the places that render that data have to be updated. You don't have the option to represent the same data in different ways that might be more suitable for different parts…

You selectively quoted me, ignoring where I explained that synchronization isn't as big of a problem with passing properties into components. I already addressed your concern. Don't selectively quote me, it's rude and just shows you aren't following the conversation.

Futher, Redux doesn't solve synchronization issues in situations where you can't represent the data the same way. In the most complicated situations, it actually exacerbates the issue because it separates the data from the components that use it, making static analysis tools unable to see how your data changes might break the components. This also goes to show you didn't even understand the part of what I said that you selectively quoted, since I already said this.

> I'm not even hesitating before I choose the first option.

Perhaps if you hesitated a bit more, you could use that time to read all of the options and understand them.

Re: None of my projects want to be SPAs

#238
post #116

Earlier quoted context omitted.

Infinite scroll, showing the details, clicking back sometimes doesn't bring me back to where I left off. Same when scrolling horizontally for example on the New releases I'll have to start scrolling right again after click on the details. Honestly, your website is probably the best implementation of a SPA website with multiple pages I have ever seen I can recollect. It still has quirks though. I just don't see why yo…

Hey, that's super helpful, thanks! Why SPA? Well, a good question indeed. Actually, we're cross-compiling the same code for the webapp onto iOS and Android targets with build flags, where we're leveraging more platform features (i.e. geolocate cinemas). Also, it lets us make the experience itself much more snappy once you're on the page, as there's just content to be re-loaded. You can switch tabs, we can remember sc…

> Stay tuned though for our completely rewritten release based on very recent technology

Nothing can possibli go wrong

Re: None of my projects want to be SPAs

#239

We recently went in the opposite direction for a student project I'm working. We have a full SPA Angular frontend, and we use CouchDB as our datastore. There is a Node "backend," but it only serves things like Slack integration, the browser has a local PouchDB instance that directly syncs with the server's CouchDB. This way, we can deploy hotspots with nothing more than a Couch install and a static server for the SPA…

Are you running your own CouchDB instance?

Yep, although the local hosts for offline use will be ARM so we are actually using PouchDB server which is really easy to work with in Node.

Re: None of my projects want to be SPAs

#240

Earlier quoted context omitted.

You have information which has global nature, used in multiple sorts of the application. This could be, among other things - STDIN/STDOUT/STDERR file handles - static configuration - some parts of runtime configuration - application info (in a game maybe current score, current level, active players, ...) All that information exists only once and is needed in many parts.

>exists only once and is needed in many parts. I think many people could argue that this concept itself is a bit misguided. There are plenty of application patterns and architectures that help you move stateful data around your app and translate it for the components who need to consume it or change it, while hiding it from components in the tree which do not interact with or care about the state. If you have many di…

Redux state isn't mutable. Mutating the state tree in a redux reducer is a bug.
Post reply on HN