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

521–530 of 637 posts

Re: SPAs Were a Mistake

#521

Post by aminerman »

commandlinefan wrote: post #53
aminerman wrote: post #28

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.

> Anyone can choose the tech stack, patterns, or whatever that he likes Maybe for personal projects, but 99% of us have to use the tech stack, pattern or whatever of our employer that was decided on (presumedly by some consensus at some point in the past). Publicly pointing out the flaws in what might have made sense then but might not make sense now is a Good Thing so that those flaws might be taken into considerati…

That's what interview processes are for. And if the consensus goes for a stack you don't like, let's say for example for doing and SPA, then maybe it's not a mistake as stated in the article. Unless you guys think that any engineer that makes choices different than yours is incompetent.

Re: SPAs Were a Mistake

#522

Post by rtpg »

simonw wrote: post #479
rtpg wrote: post #464

Earlier quoted context omitted.

Multi-page forms without some front end stuff ends up with the very clunky either "rerender previous form pages over and over again, except hidden", or "have some token to track partial form data", or "build up a DB to store a partially complete form". With some frontend work you can have a multi-page form just work, with the data stored in the client up until final submission, and only sending in partial checks ahea…

"It also seems extremely uncontroversial that sending data for a single item is going to require less text generation than sending over that data + the entire page." And yet... so many SPAs feel so much slower than MPAs. They suck down MBs of JavaScript, constantly poll for more JSON and consume crazy amounts of CPU any time they need to update the page. If you're on an expensive laptop you may not notice, but most o…

I'm on expensive machine and notice a lot, too!

I also use a lot of "classic" websites where they fall over because of bad server-side state.

An example, a train reservation site, where I choose dates + a destination. The next page, it shows me some results. I decide to change the date. I hit the back button, and it falls over, cuz the state management on the server is messed up.

This happens a lot for me (this is mainly on Japanese websites), and it's extremely frustrating.

I don't like a lot of SPAs, I also don't like a lot of "classic" apps, but I do feel like SPA-y stuff at least demands less of the developers so the failure cases are a bit less frustrating for me. In theory.

And to the connections, the terrible websites with many megs of JS were likely terrible websites with many megs of HTML and huge uncompressed images before that... I don't want to minimize it (thank god for React, but old Angular bundles were the worst), just think comparing like-for-like is important.

EDIT: thinking about it more though, it's definitely _easier_ to send giant bundles on certain websites.

Given how many times this discussion happens on HN, I feel like instead of the hypotheticals, people should make a list of actual websites in both domains so that comparisons and proper critiques could be made...

Re: SPAs Were a Mistake

#523

Post by aminerman »

eloff wrote: post #293
aminerman wrote: post #35

Earlier quoted context omitted.

Quoted post unavailable.

You're being very rude and dismissive. I may well have more SPA experience than you do. Don't make assumptions about people and then use that to dismiss something they say - we're better than that here on HN.

I am indeed (rude). You can have 100 years of experience, it doesn't make you more credible at thinking that engineers who makes choices that are different than yours as incompetent, by deeming them as mistakes. I mean, if a company wants to choose a tech stack, there are so many things to consider for that choice. Your article is just generic ideas about the fact that SPA are mistakes and SSR apps are better. You're not taking into consideration any of each industry's and company's means, priorities, specificities.

In fact, your 100 years of experience are what's hindering your ability to see how useful SPAs are. And you're resorting to that same old narrative of "it was better before". It's also the niche you decided to position yourself in to sell courses and stuff. Which makes your ideas even more suspicious as they can't be unbiased. Like in politics, they'll dogmatically say that their opponents are wrong, just because they have a "market" to preserve.

So yes, I'm rude, as much as you're inconsiderate to the vast complexity of software engineering, just to preserve your niche market.

And as you say in your website: "Hate the complexity of modern front‑end web development? I send out a short email each weekday on how to build a simpler, more resilient web. Join 13k+ others."

Re: SPAs Were a Mistake

#524

Post by aminerman »

lp0_on_fire wrote: post #77
aminerman wrote: post #35

Earlier quoted context omitted.

Quoted post unavailable.

Instead why don't you let us know why you think that position is incorrect rather than resorting to reddit-tier insults?

Quoting another comment to OP

"I am indeed (rude). You can have 100 years of experience, it doesn't make you more credible at thinking that engineers who makes choices that are different than yours as incompetent, by deeming them as mistakes. I mean, if a company wants to choose a tech stack, there are so many things to consider for that choice. Your article is just generic ideas about the fact that SPA are mistakes and SSR apps are better. You're not taking into consideration any of each industry's and company's means, priorities, specificities.

In fact, your 100 years of experience are what's hindering your ability to see how useful SPAs are. And you're resorting to that same old narrative of "it was better before". It's also the niche you decided to position yourself in to sell courses and stuff. Which makes your ideas even more suspicious as they can't be unbiased. Like in politics, they'll dogmatically say that their opponents are wrong, just because they have a "market" to preserve.

So yes, I'm rude, as much as you're inconsiderate to the vast complexity of software engineering, just to preserve your niche market.

And as you say in your website: "Hate the complexity of modern front‑end web development? I send out a short email each weekday on how to build a simpler, more resilient web. Join 13k+ others." "

Re: SPAs Were a Mistake

#525

Post by UltraViolence »

I fully subscribe to this notion and hate it that our field is riddled with hyped technologies which everyone chases.

Just because something works for Google (Angular) or Facebook (React) doesn't mean it works for your SMB application.

Re: SPAs Were a Mistake

#526

Post by k__ »

gls2ro wrote: post #203
k__ wrote: post #183

While Web2 is moving to SSR, I think SPAs will be a huge part of Web3. SPAs are perfect for decentralized infrastructure like IPFS and friends. Same goes for mobile apps.

What exactly from SPA is making them good for decentralized?

Can be put on IPFS without much hassle.

Re: SPAs Were a Mistake

#527

Post by fulafel »

porker wrote: post #487
nfw2 wrote: post #471

I have worked as an engineer on products in a lot of different domains in my career including: - edtech - real estate - HR/payroll software and every single project I've worked on had enough complex state to benefit from using a SPA. I've also worked on one complex web project run by someone dogmatically against client-logic, and it was absolute hell. The codebase was full of janky hacks to approximate the same compl…

In your experience how often did the complex state have to be modelled on the backend as well as the frontend, to provide validation of submitted data? And for personal interest, how did you handle streaming in updates and edits from multiple people, and stopping people from editing eg the same real estate listing at the same time? I know it can be done but I find it easier with server round trips for every request.

These are good concerns. IME it's important to be able to share code and schemas & domain data manipulation code between BE and FE like you can do eg with Clojure + ClojureScript.

Re: SPAs Were a Mistake

#528

Post by Tabular-Iceberg »

411111111111111 wrote: post #517
Tabular-Iceberg wrote: post #506

Earlier quoted context omitted.

How does that work if a user is logged in and private data is visible on the page? I’m thinking of building something that only renders public data on the server, and then later gets that which pertains to individuals through an API. But I don’t want to spend more time on a lot of complicated plumbing than on core functionality in my application. A SPA seems like the path of least resistance here, since all you have…

GraphQL is a protocol, as such it cannot take away the pain of creating a backend for your frontend. There are tools which make the creation of the backend painless and utilize GraphQL for sure (i.e hasura), but claiming that GraphQL solved that issue is nonsensical, because writing the GraphQL API is generally way more annoying then the equivalent rest API is

Yes, I obviously mean leverage the existing tools, not roll my own implementation of the protocol, that would just be stupid and counter-productive.

Equivalent tools for REST and non-REST HTTP do exist, but none that I've seen has been as cohesive as for instance Apollo. I used it on a small side project and was amazed at how much time and effort it saved me. The alternatives are a patchwork of different tools with slightly different goals for things like client code generation, documentation generation, playgrounds, HATEOAS, etc. that have to each be evaluated and shoehorned in with the others.

Re: SPAs Were a Mistake

#529

Post by jmconfuzeus »

nawgz wrote: post #273
jmconfuzeus wrote: post #213

Earlier quoted context omitted.

Big tech companies love wasting money and developing a SPA is a good way to do that. Whether users prefers SPAs or not is debatable. Amazon, Github, and Aliexpress aren't SPAs because poor usability will cause users to move to competitors. If Hacker news turned into a SPA, I guarantee that it would suck big time. SPA developers seem to be living in a tiny bubble oblivious of simple solutions to simple problems.

> Github In what world is this not an SPA? I don't see page transitions hardly anywhere, except when you're switching from marketing material to repos maybe. Additionally, the fact that GitLab (which is devops/issue tracking/wiki/etc.) ISN'T an SPA drives me crazy every day. I have to wait for so many rerenders that could just be seamless loads, it's actually insane to me how unoptimized of a user experience it is, e…

You seem to be mistaken about what SPAs are. Github is simply a traditional Rails app that uses Javascript to enhance client side interaction.

A ton of web apps provide data visualization features without being SPAs by simply using libraries like D3.

I don't know what kind of apps you're building but claiming that everyone needs to start using SPAs instead of traditional progressive enhancement with Javascript is not right.

Re: SPAs Were a Mistake

#530

Post by efdee »

freedomben wrote: post #256
efdee wrote: post #90

Earlier quoted context omitted.

In case of slow internet, SPAs are much easier to make responsive than an SSR application.

Sure, if that's your goal. It won't happen by accident, and the "default" method of SPAs make it really easy to fire off lots of different requests, often on demand.

It doesn't happen by accident in the same way that preventing an SQL SELECT N+1 problem doesn't happen by accident. Poorly written software is poorly written.
Post reply on HN