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

You probably don't need a single-page app

journal.plausible.io

Post reply on HN
Print view View original

311–320 of 522 posts

Re: You probably don't need a single-page app

#311

Post by pault »

acemarke wrote: post #263
save_ferris wrote: post #185

Earlier quoted context omitted.

I completely agree that a big part of this conversation falls on ensuring code quality is maintained over time, regardless of the architecture you choose. Fortunately, I inherited a set of pretty well-maintained SSR rails apps, and they've been pretty straightforward to continue working on (with a couple of exceptions). The single biggest disadvantage I see with front end apps is that comprehending state management v…

Hi, I'm a Redux maintainer. Any specific concerns that I can help with? You might want to check out our new Redux Starter Kit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once: https://redux-starter-kit.js.org

After having some pretty extensive (heated) debates about the merits of redux here on HN, I've come to the opinion that the love/hate for redux is a consequence of the departure from MVC architectures that more experienced developers are accustomed to. There are decades of best practices built up around scaling object oriented MVC architectures, but react and redux come from a completely different school of programming where trying to apply traditional inheritance patterns is impossible and can mortally wound a project.

There was an article about entity component systems recently posted here, which are typically used in game programming, and I was shocked at how similar it is to the architectures I use in my react apps. This entry [0] from the ECS wiki is a good summary:

> Whereas in an inheritance-based design, an enemy may have a complex inheritance chain such as Damageable It occurred to me that in a lot of ways, games are just extremely complex user interfaces. So it makes sense that patterns that work well in game architectures should map rather cleanly to application UIs. I'd be interested in hearing if anyone else sees the correlation here, or if I'm just confused and misunderstanding ECS architectures. My email is in my user profile.

[0]: http://entity-systems.wikidot.com/

Re: You probably don't need a single-page app

#312

Post by crooked-v »

lmilcin wrote: post #157

All that complaining serves no purpose. SPA is just another tool in a belt. Where I think it shines is making rich apps that need complex flow and communication. This is where productivity is important and the process is complex and up until recently I would be advocating native desktop app. Now with advent frameworks that help me organize this very efficiently (I use re-frame/reagent with ClojureScript) I can create…

> I use re-frame/reagent with ClojureScript

I personally feel like what's really missing here is something like a generic spec (not a generator, but a descriptive standard) for the structure and organization of CRUD-style JS/JS-derivative SPAs, something like what re-ducks (https://github.com/alexnm/re-ducks) did for the Redux world.

Re: You probably don't need a single-page app

#313

Post by hello_moto »

insulanian wrote: post #303
save_ferris wrote: post #26

This. So much this. My company (4,500+ people) ordered all products in their portfolio (~12 web apps) to migrate to SPA front ends about a year ago as a way to stand out from our competitors, and boy has it been painful. Prior to that initiative, we had been using the hybrid approach mentioned in this piece, embedding SPAs only where necessary and sticking to SSR everywhere else, which worked really well. Since the a…

Well, in our case moving from server side MVC to SPA approach has drastically increased productivity and stability of our applications. MVC approach was a hairball of code where 2/3 was dealing with synchronization of state between client and server, and only 1/3 being related to actual application logic. Clean separation of frontend SPA and backend API made both sides simpler and more robust. I would also wholeheart…

> I would also wholeheartedly recommend separating the development into two teams (frontend / backend) . It makes both pieces of the application even more robust due to both teams guarding the interface with the other part even better.

In theory, we should strive for that. In practice, back-end team tend to strive on "technical purity" and would ask the front-end team to take any hacks/workarounds necessary to deliver "compelling" user-experience. One example would be the disagreement over "Data Model" of front-end vs back-end.

Re: You probably don't need a single-page app

#314

Post by mnm1 »

insulanian wrote: post #301
donatj wrote: post #155

Earlier quoted context omitted.

SPA doesn’t guarantee good separation of concerns though. I have seen many a horrible SPA in my day that had all the business logic in the client side JS and zero validation server side. Server basically a very thin wrapper around the database. I’ve been doing this for 15 years, and if I’ve learned anything it’s that developers can figure out ways to abuse anything.

Separate frontend from backend development and make it even two teams. This makes it much more robust and loosely coupled because both sides protect the interface from each other.

This works. Now you only need double the engineers to create the same app as you would using a server side framework. Hardly a more powerful argument against SPAs than this.

Re: You probably don't need a single-page app

#315

Post by [deleted] »

petilon wrote: post #124
s_y_n_t_a_x wrote: post #104

Earlier quoted context omitted.

You don't have to deal with any of that crap when you deal with react. Just write pure functions as components. The arguments are the props.

Then you aren't benefiting from React at all. The point of React is DOM diffing, which you trigger using setState method.

[deleted]

Re: You probably don't need a single-page app

#316

Post by ivanhoe »

brazzy wrote: post #259
amoitnga wrote: post #226

Earlier quoted context omitted.

> My company (4,500+ people) ordered all products in their portfolio (~12 web apps) to migrate to SPA front ends about a year ago as a way to stand out from our competitors, and boy has it been painful. This doesn't seem like a problem of "MVC vs SPA". The same problem would occur if you were ordered to rebuild 12 apps written in Rails ( or whatever full-stack MVC framework) in a different one, like Django, for examp…

You overlooked this part: > Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks

You simply trade back-end frameworks complexities for the front-end framework complexities. With the right architecture there is no huge difference IMO, just of course you also need to upgrade your teams so that they can handle a lot more tasks on the front-end than with SSRs (and you'll probably need less back-end devs)

Re: You probably don't need a single-page app

#317

Post by a_wild_dandan »

kadendogthing wrote: post #293

Yes you actually do. At the very least you should build your web app with technology that makes it fairly trivial to move over to an SPA. MVC is a mistake. Read that again. MVC is a mistake. It's not a good paradigm to write web applications in. SPA's are not complicated. They do not take longer to build. They defacto are often way more responsive than any server side monolith that gets built. Because developers who…

I really wish I could upvote this twice. Tacking on features to a traditional MVC app causes orders of magnitude more technical debt and buggy, tightly-coupled, unmaintainable or extensible spaghetti code. React et al. didn't pass through a membrane from another reality for the sole purpose of annoying devs with more stuff to learn -- they're elegant, powerful solutions to the rapid growing pains and requirements of our modern web. The SPA pattern of completely separating front-end & back-end concerns is seemingly taking over the world for very good reason.

Re: You probably don't need a single-page app

#319

Post by RandomBK »

andrei_says_ wrote: post #310
Spivak wrote: post #254

Earlier quoted context omitted.

It's difficult to tell the person who's writing your paycheck "this is totally possible I just don't like it and so won't do it." Like if you're doing SSR you could at least use something like turbooinks to implement state transitions.

How about “that’s totally possible. It will cost you 10x what you’re paying now, it will be much more brittle and harder to fix. I personally would love to work on it, just keep in mind that any changes will require 10x the time and budget” And ... “Here are a couple of technologies which would allow us to speed up the experience at a very low cost. I recommend we try these first.” Turbolinks for the win :)

10x the cost!? Well, I have a quote from your competitor that's a fraction of that amount. If you keep quoting unreasonable prices, perhaps I should rethink our business relationship and move elsewhere.

Re: You probably don't need a single-page app

#320

Post by crooked-v »

petilon wrote: post #124
s_y_n_t_a_x wrote: post #104

Earlier quoted context omitted.

You don't have to deal with any of that crap when you deal with react. Just write pure functions as components. The arguments are the props.

Then you aren't benefiting from React at all. The point of React is DOM diffing, which you trigger using setState method.

You're dramatically overexaggerating the complications of global state handling in Redux. For a simple app, you could just use the useState hook, and pass the state-setting callback down into children components:

    import React, { useState } from 'react';

    export const SetterButton = ({ children, ...rest }) => (
      {children}
    )

    export const BoxComponent = ({ label }) => {
      const [value, setValue] = useState(0);

      return (
        
          {label}: {value}
           setValue(value + 1)}>+1
        
      );
    };
Or for a bigger app with many nested components, you can use context:

    import React, { useState } from 'react';

    export const ValueContext = React.createContext();

    export const SubComponent = () => (
      
        

          Here's a value:
          
            {({ value }) => value}
          
        

        

          Here's a button:
          
            {({ setValue, value }) =>  setValue(value + 1)}>+1}
          
        

      
    )

    export const App = () => {
      const [value, setValue] = useState();

      return (
        
          Some other stuff goes here.
          
        
      );
    }
None of this takes a ton of thought. Just make a file for contexts exports and a root level component with any Providers.
Post reply on HN