None of my projects want to be SPAs • Hacker News Board

Re: None of my projects want to be SPAs

#341

Post by mixmastamyk » Tue, Feb 12, 2019, 11:58 PM UTC

sangnoir wrote: post #331

slavak wrote: post #317

Earlier quoted context omitted.

For God's sake, STOP trying to re-implement my browser's interface with Javascript! I don't want you to "put in the effort" to make my URL bar, back/forward buttons, and tabs work the way they naturally do in my browser; that's what my browser is FOR! Even when the developer does put in the effort, the results are usually _just_ different enough in various subtle ways from the browser's native behviour as to be annoy…

> Your forum/email interface/management API would work better as a normal website. Good for you with your fast, always-on internet, I guess. Some consumers have to deal with expensive and unreliable 3G internet (that downgrades to 2G occasionally) - an offline-capable email (or management) SPA is indispensable for them. Sure, you could write 4 native offline apps for MacOS, Windows, iOS and Android but that is a bigg…

SPA is orthogonal to storage, nor are lightweight web techniques exclusive to it, and often in opposition. Native email clients already exist of course.

Re: None of my projects want to be SPAs

#342

Post by pault » Wed, Feb 13, 2019, 2:02 AM UTC

rashkov wrote: post #339

pault wrote: post #335

Earlier quoted context omitted.

> persisted to a back-end and re-fetched on route This is a huge pain in the ass and requires a ton of really tricky UX design. What happens when the data is cached and you fetch it again? Do you disable the UI and show a spinner until the request is complete (why bother caching the data in the first place)? Do you allow the user to continue making changes while the request is pending and try to reconcile conflicts w…

Thanks for the time and effort you've put into this thread, it has been very interesting reading your comments, which have a lot of content and a lot of experience behind them. I wanted to ask you about this because I've been reading about when to use Redux and when not to, and I had basically come to appreciate that it would be helpful for the kind of app that I'm working on daily. That app is very complex and very…

> attitude that front-end should be easy, and then people are rudely surprised when they find out that it's actually very hard. Distributed systems problems, cache invalidation problems, combinatorial scaling of complexity with every feature and source of user interaction...

This sums it up so succinctly I'm going to borrow this next time I'm discussing react with one of my C# teammates. :)

If you want to chat more my email address is in my profile.

Re: None of my projects want to be SPAs

#343

Post by rachkovsky » Wed, Feb 13, 2019, 2:43 AM UTC

WorldMaker wrote: post #268

kerkeslager wrote: post #229

Earlier quoted context omitted.

> 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 itself is just the "stuff inside the…

> The observer pattern is mentioned in the Gang of Four Book[1], published in 1994. JavaScript first appeared in 1995. Observers predate Redux. You don't need Redux to use observers, and in fact there's nothing about React that is incompatible with RxJS. Yes, and before I was using React+Redux+Redux-Observable I was using Cycle.JS and everything was RxJS and/or Xstream (an RxJS-like) observable-based patterns. As I s…

What "state side-effects" are you dealing with?

Re: None of my projects want to be SPAs

#344

Post by vlasky » Wed, Feb 13, 2019, 2:49 AM UTC

The Meteor framework has been actively developed ever since it was released and continues to have a broad, enthusiastic user base.

Mr Goldstein would have known this if he had visited the Meteor blog (https://blog.meteor.com/) and Meteor forums (https://forums.meteor.com/).

Re: None of my projects want to be SPAs

#345

Post by kerkeslager » Wed, Feb 13, 2019, 11:37 AM UTC

pault wrote: post #296

kerkeslager wrote: post #249

Earlier quoted context omitted.

> In React, when you lift state up and up, you mostly end up tracking lot of irrelevant state in the top most component which kind of weirdly manages lot of state just for their children. I'm not sure why you think the data is irrelevant, or why the component manages it "weirdly". I'll point out that these top components actually share a lot in common with Redux, except that they can be duplicated and composed with o…

> I'm not sure why you think the data is irrelevant I believe the GP meant "unrelated". Can you drop your top level component into another application with different children and still have it work? Can you move the child components to another view tree and still have them work? It seems like what you are describing is a top level component that is tightly coupled to its descendants with too many responsibilities. In…

> Can you drop your top level component into another application with different children and still have it work?

Yes, it's a matter of passing the child into the parent as a prop.

> Can you move the child components to another view tree and still have them work?

Yes, this sort of thing is exactly what you get for free by doing things the way I describe.

> In the ideal react app architecture you should be able to take any component and move it anywhere else in the app and it should Just Work.

This is exactly not what happens in Redux projects in my experience.

Re: None of my projects want to be SPAs

#346

Post by BerislavLopac » Wed, Feb 13, 2019, 1:29 PM UTC

em-bee wrote: post #244

hombre_fatal wrote: post #144

Earlier quoted context omitted.

Well, SPAs are attractive even for websites that don't particularly benefit from them because of the technical attractiveness of having the website be like any other client that consumes your server's API.

exactly that. since 2012 i build all my websites as SPAs for this reason. more so, i am not even writing any new backends. i reuse the same backend over and over. most websites (at least the ones i have been building) are just CRUD and don't really need a custom backend. SPAs bring back the client-server architecture we had before the web. you build desktop clients that consume server-api's. server-side html generati…

It should be trivial to build a server-side client app in the same manner, using an API for any persistence instead of directly accessing the database. Most of the full-stack frameworks (Django, Rails, Laravel etc) are unfortunately still conflating the persistent state entities with business logic objects.

Re: None of my projects want to be SPAs

#347

Post by raihansaputra » Wed, Feb 13, 2019, 2:06 PM UTC

morpheuskafka wrote: post #56

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…

This sounds interesting. I'm light on details on how CouchDB and its sync works, but how do you deal with data validation/data conflict? Or maybe malicious actors tampering your data? Or is it a closed app that already have those dealt with in the spec? It would be awesome if you can share more about the project.

Re: None of my projects want to be SPAs

#348

Post by pault » Wed, Feb 13, 2019, 5:14 PM UTC

kerkeslager wrote: post #345

pault wrote: post #296

Earlier quoted context omitted.

> I'm not sure why you think the data is irrelevant I believe the GP meant "unrelated". Can you drop your top level component into another application with different children and still have it work? Can you move the child components to another view tree and still have them work? It seems like what you are describing is a top level component that is tightly coupled to its descendants with too many responsibilities. In…

> Can you drop your top level component into another application with different children and still have it work? Yes, it's a matter of passing the child into the parent as a prop. > Can you move the child components to another view tree and still have them work? Yes, this sort of thing is exactly what you get for free by doing things the way I describe. > In the ideal react app architecture you should be able to take…

> This is exactly not what happens in Redux projects in my experience.

Sorry to beat this dead horse, but how does redux, which binds data directly at the level of the component that displays the data, make portable components more difficult than vanilla react where stateful components and functional components are tightly coupled? Do you have links to a gist or something so I can see what you're describing?

Re: None of my projects want to be SPAs

#349

Post by WorldMaker » Wed, Feb 13, 2019, 5:22 PM UTC

rachkovsky wrote: post #343

WorldMaker wrote: post #268

Earlier quoted context omitted.

> The observer pattern is mentioned in the Gang of Four Book[1], published in 1994. JavaScript first appeared in 1995. Observers predate Redux. You don't need Redux to use observers, and in fact there's nothing about React that is incompatible with RxJS. Yes, and before I was using React+Redux+Redux-Observable I was using Cycle.JS and everything was RxJS and/or Xstream (an RxJS-like) observable-based patterns. As I s…

What "state side-effects" are you dealing with?

The obvious and most common is asynchronous state that has some associated loading process/time. Especially those situations where loading some top level object implies to start loading a collection of lower level objects.

Reacting to object changes (persisting them to a database, or otherwise audit logging them).

Kicking off and managing "background tasks" like chron-job equivalents (5 minutes after a state update do some other related thing, such as a automatic state machine transitions), database synchronization/replication processes, cross-checking/merging in data from GPS/geolocation/compass streams, etc.

Re: None of my projects want to be SPAs

#350

Post by em-bee » Wed, Feb 13, 2019, 8:13 PM UTC

BerislavLopac wrote: post #346

em-bee wrote: post #244

Earlier quoted context omitted.

exactly that. since 2012 i build all my websites as SPAs for this reason. more so, i am not even writing any new backends. i reuse the same backend over and over. most websites (at least the ones i have been building) are just CRUD and don't really need a custom backend. SPAs bring back the client-server architecture we had before the web. you build desktop clients that consume server-api's. server-side html generati…

It should be trivial to build a server-side client app in the same manner, using an API for any persistence instead of directly accessing the database. Most of the full-stack frameworks (Django, Rails, Laravel etc) are unfortunately still conflating the persistent state entities with business logic objects.

you are of course right. there is no stopping anyone from doing that. in fact the university which initially developed the backend i am using has been doing just that, using the backend like a database, creating "frontends" in PHP.

though that doesn't negate the point of SPA which enables building clients that run directly on the users devices and are not hampered by the difficulty of emulating stateful clients on a server.