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

241–250 of 362 posts

Re: None of my projects want to be SPAs

#241

Post by pjmlp »

alexbanks wrote: post #193
rossdavidh wrote: post #108

This may be a mean thing to say, but basically I think SPA's are massively overused, because developers want to demonstrate that they can do them. Why? Because big companies like Facebook and Google use them. Why? Because they actually are doing things that require them. 99% of the SPAs in production are things that should have been done the old Rails/Django/Laravel way, but that would not set you up as a developer w…

Unfortunately for most devs, the only way to set yourself up for "better" work later, is to force current mediocre work to use the tooling of the future work. In 2019 if you have on your resume that you're only familiar with Rails and ERB-sites, and you suggest using them for pretty much everything, you'll never get a new job. At a certain point, career-minded devs have to do the "resume driven development" game a li…

Depends pretty much where one wants to work.

Outside the software business, on companies whose focus is totally unrelated to software, no one cares that much how things work.

They just have a couple of devs, or hire some freelancers do do some stuff, no matter how, it just has to look pretty.

Re: None of my projects want to be SPAs

#242

Post by woolvalley »

As a mobile app developer, looking at the architecture of PWAs is a bit obvious to me. It's to turn webpages into stand alone mobile / desktop apps, with all of the power & setup that implies. But without the size overhead of an actual app, because every phone has a runtime library called the browser.

It's a great tool if that is your goal. Otherwise why spend the extra effort?

Re: None of my projects want to be SPAs

#243

Post by pault »

tobr wrote: post #54
lucidone wrote: post #21

I went from MVC style all-in-one frameworks (Rails, Laravel) to application APIs fronted by single page applications and hope the developer mindshare tilts back to MVC frameworks. Something that'd take me an hour or two in Rails can take a week using these new tools, even after being reasonably experienced with them. Don't even get me started on Apollo (not my thing at all, and from my experience most don't know how…

For a component here and there React is a pretty bad choice because of its size. Svelte could be a more suitable option, but I’m not so sure it passes the magpie test.

In my experience this is the use case where vue shines. It's far easier to drop it into an existing html template than to create a react application for a single component.

Re: None of my projects want to be SPAs

#244

Post by em-bee »

hombre_fatal wrote: post #144
rossdavidh wrote: post #108

This may be a mean thing to say, but basically I think SPA's are massively overused, because developers want to demonstrate that they can do them. Why? Because big companies like Facebook and Google use them. Why? Because they actually are doing things that require them. 99% of the SPAs in production are things that should have been done the old Rails/Django/Laravel way, but that would not set you up as a developer w…

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 generation now feels like cruft and an awkward way of building applications.

Re: None of my projects want to be SPAs

#245

Post by whytaka »

Illniyar wrote: post #122

Do we really need to defend SPA every other week? The market, users, product, ui/ux designers and the vast majority of developers decided that SPA is a better user experience. Page loads greatly degrade the user experience, especially when you have long lag (which for many of us the reoundabout time is longer then the download time of 100k). Even if you make your site extremely lean, it's still a worse experience, an…

The phrase, "the exception that proves the rule" is not used properly here.

A proper example is something like: "Parking allowed on Fridays", which is an exceptional case to a rule that is implied: "No parking any other days."

Just a heads up, feel free to ignore.

Re: None of my projects want to be SPAs

#246

Post by bunderbunder »

GVIrish wrote: post #180
rossdavidh wrote: post #108

This may be a mean thing to say, but basically I think SPA's are massively overused, because developers want to demonstrate that they can do them. Why? Because big companies like Facebook and Google use them. Why? Because they actually are doing things that require them. 99% of the SPAs in production are things that should have been done the old Rails/Django/Laravel way, but that would not set you up as a developer w…

> This may be a mean thing to say, but basically I think SPA's are massively overused, because developers want to demonstrate that they can do them. Unfortunately this is another side effect of the broken hiring process in IT. Recruiters are scanning resumes for the hottest buzzwords, hiring managers want people who have experience with whatever is currently hyped, so developers naturally steer towards those technolo…

It can be the same story on the hiring side: Teams will decide to build $new_thing using $NEW_THING! simply because they know it will help them attract more (and often less expensive) applicants.

Re: None of my projects want to be SPAs

#247

Post by kerkeslager »

pault wrote: post #236
kerkeslager wrote: post #110

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…

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.

Okay, so the only way it's actually possible to have any refactoring of your data structures require only changing one selector is that you've got a single selector for literally every piece of data in your system, at which point you've had to manually flatten everything out into a bunch of selectors, and lost all the benefits of being able to read a structured chunk of data. If you actually do that (which I don't think most projects do fastidiously) you're creating a lot of boilerplate, again to solve a problem which was created because you decided to use global state in the first place.

I'm not saying there aren't solutions to the problems I'm bringing up. I'm saying you don't have to solve them in the first place if you don't bring in Redux.

Re: None of my projects want to be SPAs

#248

Post by rchaud »

As someone who's self-taught in Wordpress development, I tried to branch into React but I had similar questions that stopped my progress. I'd always be thinking "why are they setting it up this way"?

Are there any barebones tutorials out there for CRUD apps that don't require Node.js, Python etc, and can be learned using PHP, MySQL and HTML?

Re: None of my projects want to be SPAs

#249

Post by kerkeslager »

palerdot wrote: post #133
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,…

Thinking of Redux as a 'detached state tree' that the whole app can subscribe too might give a better picture of some problems that it is solving. 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. There are some genuine use cases of Redux by tracking the whole 'app state' in a detach…

> 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 other components, if for example you decide to drop your top component inside of a larger application, and the toplevel components actually don't end up managing data they don't have to (LESS "irrelevant" data than Redux, perhaps?).

Re: None of my projects want to be SPAs

#250

Post by pault »

kerkeslager wrote: post #247
pault wrote: post #236

Earlier quoted context omitted.

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.

Okay, so the only way it's actually possible to have any refactoring of your data structures require only changing one selector is that you've got a single selector for literally every piece of data in your system, at which point you've had to manually flatten everything out into a bunch of selectors, and lost all the benefits of being able to read a structured chunk of data. If you actually do that (which I don't th…

Not at all; you can write selectors that return a branch of your state tree, and you can generally tell where the line should be (user makes more sense than userName and userEmail).

You keep saying that you won't have these problems if you don't use redux, but I am arguing that _you do have these problems_, you're just creating ad-hoc solutions for everything that you would use redux for, except those solutions are sprinkled into your UI components in a way that makes them full of mutable state that is impossible to test and a constant source of bugs. Note that I have already agreed that there is a scale where redux is overkill and creates more problems than it solves. Once your app has a few dozen components it's time to start thinking about another layer of abstraction.

Post reply on HN