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

SPAs Were a Mistake

gomakethings.com

Post reply on HN
Print view View original

21–30 of 637 posts

Re: SPAs Were a Mistake

#21

Post by thr0wawayf00 »

Zanfa wrote: post #7

I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. For example, recently I had to deal with photo uploads on a Rails app, which works fine out of the box at first, until you want to show progress bars and uploaded previews etc. Then you add a couple of client-side…

This is my biggest gripe with the direction of Rails.

I completely understand the historic reasons for wanting to keep JS to a minimum and stay within ERB/Ruby, but the JS component-driven UI pattern feels like the correct front end architecture for most commercial projects these days, especially now with better JS tools like Svelte, which feels like rails for the front end to me.

I started playing around with InertiaJS recently and I absolutely fell in love with it. I was surprised to see how niche it still is because it's pretty much what I've dreamed what writing JS with Rails could be for the last 5 years.

Re: SPAs Were a Mistake

#22

Post by te_chris »

Zanfa wrote: post #7

I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. For example, recently I had to deal with photo uploads on a Rails app, which works fine out of the box at first, until you want to show progress bars and uploaded previews etc. Then you add a couple of client-side…

Phoenix LiveView really does solve a lot of these problems.

Re: SPAs Were a Mistake

#23

Post by a_chris »

The problem with SPAs is that they have been misused and overused, at least in Italy. Tons of projects built with SPA in which we have to re-implement basic browser features like the back button, just because project manager has no idea of how this technology works. I've worked on at least 4 projects which could be written in Nextjs in half of the time

Re: SPAs Were a Mistake

#24

Post by slashdev »

I hate SPAs. I would never do another SPA again if it were up to me. It just adds too much mental context switching and overhead. I can develop fully server-side apps that are lighter, run faster, and at least 20% less development effort (I actually compared that for the same task: https://medium.com/@mustwin/is-react-fast-enough-bca6bef89a6). So why would I ever do an SPA again if it were up to me? I would use https://github.com/jfyne/live which is inspired by Phoenix LiveViews. This is my professional opinion, having many years of experience in both kinds of web apps.

Re: SPAs Were a Mistake

#25

Post by pacifika »

slashdev wrote: post #24

I hate SPAs. I would never do another SPA again if it were up to me. It just adds too much mental context switching and overhead. I can develop fully server-side apps that are lighter, run faster, and at least 20% less development effort (I actually compared that for the same task: https://medium.com/@mustwin/is-react-fast-enough-bca6bef89a6 ). So why would I ever do an SPA again if it were up to me? I would use http…

When I was reimplementing “reset state” for a logo click I knew it should have been serverside rendering.

Re: SPAs Were a Mistake

#27

Post by bdcravens »

coding123 wrote: post #11

SPAs were not a mistake, SPAs were an attempt to make the front end work like front ends have ALWAYS worked. Back before the web people made C++ and VB user interfaces that interact directly with the data source. SPAs are an attempt to make the web closer to that well known paradigm. POST REDIRECT REFRESH cycle was an insane programming paradigm that wasn't found in any previous edition of programming.

Most SPAs don't interact directly with the datasource, but interact with a middle service. Also many older architecture do draw entire "pages" on the screen at once, rather than manipulating only individual components. (at least not on every interaction)

Re: SPAs Were a Mistake

#28

Post by aminerman »

Anyone can choose the tech stack, patterns, or whatever that he likes. But developers enjoy being absolutists, and deem something they don't like as a MISTAKE, or would tell you that the way they think is the ONLY way to think.

You do your app the way you want depending on the Ux you want to provide, on the tech you enjoy implementing, on the patterns you like to follow.

Re: SPAs Were a Mistake

#30

Post by antihero »

This article seems to be directed at dealing with people that use SPAs to make more content focused websites, which quite obviously are better made with the browser.

However, for an application with a persistent UI, I fail to see how constant page loads and navigation just because "the browser can do this" make any sense at all.

Even the example is a bit silly - SPAs that should be SPAs don't really have "links" per say, they will mostly have buttons, which will have a some sort of defined action. Perhaps these buttons will navigate to some other screen in the application, however, reloading all of the client side state every time one does this is absurd to say the least.

Finally, from a technical perspective, having a clear separation of concerns by having code talk to an API as opposed to HTML being rendered on the server, you remove a lot of complexity.

It feels like the people who write these articles don't actually remember how utterly shit the jQuery days were.

Post reply on HN