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

301–310 of 522 posts

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

#301

Post by insulanian »

donatj wrote: post #155
marktangotango wrote: post #136

Earlier quoted context omitted.

I don’t disagree here at all, but I would note that generally server side templating is often a mish mash of business logic, view logic, accessing query string and session parameters, and whatever server side Singleton/globals available in the template context, that becomes horrific spaghetti in no time at all. Compared to client side rendering discrete web requests with minimal templates; you usually get much better…

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.

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

#302

Post by Scarblac »

ryukafalz wrote: post #189
mattmanser wrote: post #181

Earlier quoted context omitted.

This is a load of nonsense. If you can't separate concerns in a hybrid MVC pattern, you'll be screwing it up just as much in an SPA. Plus you've got the extra layer of an API to maintain too making it even more complicated, and more likely to spaghettifi, not less.

>Plus you've got the extra layer of an API to maintain too On the other hand, if you're providing a service that will always have an API, and you want to make sure that all the functionality you provide is nicely accessible through the API, building the frontend on top of it can be a good approach. The developers at the company I work for have done this, and IMO it's worked out pretty well.

This is also the main argument that keeps me on the side of SPA for our own project, at the moment. Our product is a specialized database with a fancy GUI on top, but we have customers that only use the database through its API; by using it ourselves for our frontends we make sure everything is doable that way.

The other argument is that frontend developers are looking for SPA work because they see SPA work everywhere. There's an element of everybody having to go with the flow...

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

#303

Post by insulanian »

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 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.

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

#304

Post by [deleted] »

jamespollack wrote: post #255
trimbo wrote: post #115

Earlier quoted context omitted.

> Developing SPAs is easier than server-render applications. Not sure about "easier". I'm a backend person so take this with a grain of salt but, to me, nothing on the web is easier than doing everything server side. All of your code can be in one language (plus a template) and the same build. Consider what it takes to make a change in each model. In an SPA with one of the frameworks mentioned, it requires several ch…

I think that "I'm a backend person" says it all -- most of the people in this thread are probably not JS natives or front-end natives. All of the complaints about JS fatigue, or not knowing how to use client-side routing are because you've done things differently on the backend. Is it such a surprise that front-end frameworks and tools make more sense to people who actually enjoy and have experience working on the fr…

[deleted]

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

#305

Post by bhauer »

kyledrake wrote: post #67

Agree with the article. I find server views to be substantially easier to work with. But more importantly, I also find server view rendering to be a faster, better UI experience. It's really frustrating having to wait several seconds for a SPA to load, or to have unexpected behavior when clicking the browser back button, or failing completely because some random hunk of JS garbage errored out, and it's one of the big…

> I definitely get edge cases like Slack, but honestly don't think SPA has been a positive development, overall. I think the web was better as a document/HTML oriented design.

But even Slack is subject to the same clunky and slow user experience you're describing because its entire user interface is an SPA.

In my opinion, a site for the SPA hall of shame is the Starbucks.com progressive web app [1]. My grievances about it are legion, but to name a few:

* It's agonizing slow, both on the client and server. The server is an egregiously-slow GraphQL endpoint.

* It hasn't been tested on anything but Chrome, as far as I can tell. It flat out refuses to work in Firefox or Edge, even fresh installations I've put into VMs. These browsers may not be mainstream targets, but odds are you would have no trouble supporting them if you weren't using these unnecessarily complicated client-side frameworks for placing a coffee order.

* It routinely messes up state management. I've had it forget my selected store location; fail to add items to the shopping cart; fail to submit orders; fail to apply star points (coupons); get into a weird state where it thinks I have a coupon when the server disagrees; etc. It's constantly introducing new and imaginative ways to fail.

* If you use it for months, white-page failure modes are surprisingly common.

Every time I use it, I wish that Starbucks had made just a plain responsive web app with simple server-side rendering. It would be fast and probably work better as a way to place orders.

[1] https://app.starbucks.com/

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

#306

Post by dangoor »

sbov wrote: post #184
dangoor wrote: post #142

Earlier quoted context omitted.

This separation of concerns is also good if you have both a web app and native mobile app. The server side ideally puts forth an API useful for both;

Our controllers use APIs. This was common before SPAs became all the rage.

Indeed, that's true. While I'm not saying they're good for everything, one thing I like about SPAs is that the server can just serve up an API that is usable by both web and mobile clients. No duplication of templating/view logic between server and client as often happens when the server is serving up HTML.

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

#307

Post by kortilla »

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…

You can do that separation either way. People working on state sync and actual apis should be different anyway (unless your team is small).

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

#308

Post by insulanian »

kortilla wrote: post #307
insulanian wrote: post #303

Earlier quoted context omitted.

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…

You can do that separation either way. People working on state sync and actual apis should be different anyway (unless your team is small).

I'm not convinced. We were using MVC for years and tried different approaches, but the API code is incomparably cleaner when it doesn't deal with client concerns.

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

#309

Post by kingcrais_420 »

latronic_notron wrote: post #77
danielovichdk wrote: post #28

I tried the other day, yet again, to give it a go. You know, firing up VS Code and make an app with express, node, react bla bla bla. Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked. The hundreds of possible directions you can go in, in terms of frameworks, packages and what not is ludacris. I stopped working when my node modules directory topped…

> Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked. > I stopped working when my node modules directory topped 60mb and I still hadn't made a data layer. This is cute. I have a 40gb virtual machine with Windows + VS Enterprise and SQL Server, that I have to use to work on a single .NET project that can't be migrated to .NET Core yet. What is 60mb c…

60MB is a significantly lower amount compared to 40GB, but I don't think it is fair to compare the disk space of an operating system, IDE, and database server to a directory of javascript libraries.

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

#310

Post by andrei_says_ »

Spivak wrote: post #254
LaGrange wrote: post #213

Earlier quoted context omitted.

> smoothness in their flows ...what? > continuous saving No problem. > and all those nicely choreographed state transitions Learn to say "no." It works wonders whenever people tell you that your aircraft has to go under water now.

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 :)

Post reply on HN