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

331–340 of 522 posts

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

#331

Post by crooked-v »

pault wrote: post #327
AnIdiotOnTheNet wrote: post #108

Earlier quoted context omitted.

I'm with you. I'm not employed as a developer, and am certainly not a web dev, but a few years ago I (perhaps foolishly) used some spare time at work to create a tool to help the people who do the non-sitting-in-an-office work in our company get more accurate and relevant documentation for their day-to-day workflow that they could access via a cheap tablet connected to our WiFi. It grew, as projects do, out of its or…

> I'm thinking that my simplest option is to just write a single page of JS that writes HTML to the DOM directly and works with data entirely locally, synchronizing it with a server API (.NET) when available. I don't know what your requirements are, but you've just described an SPA framework. Do you think it will be easier to implement your own instead of using something like vue or react? Also, localStorage is suppo…

My thoughts given that outline would be:

- Redux with a middleware that saves the whole state to localstorage automatically

- Some simple background timer stuff that uses ononline and onoffline events to know when to poll for updates, then dumps the JSON contents from the polling into the Redux store

- Some React components that act as one-way output of the stuff in the Redux store, optionally with a basic routing lib if some menus/navigation are necessary

Then stick some Progresssive Web App stuff in there so the whole bundle can work offline entirely from browser cache.

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

#332

Post by pault »

wreath wrote: post #208
syllable_studio wrote: post #195

I have experience building both SPA apps and server-side templated apps. They each have their strengths and weaknesses. Just as a SPA won't solve all your problems without any trade-offs, getting rid of a SPA framework also won't solve all your problems -- you'll probably need to re-invent some wheels and then discover that your new solutions are hard too. I think it's good to have a healthy dose of skepticism about…

> it's often just simpler to use a SPA framework in the first place. Simpler or more convenient? I've yet to see a production-grade React setup (for example) that is simpler than having either vanilla JavaScript or even jQuery to achieve the same interaction. The amount of tooling required to do simple interactions does not justify the technology for most applications IMO.

How complex were the applications that used those production-grade React setups?

As the number of possible states increases, your vanilla JS solution explodes in complexity when you have to manually define every state transition. The declarative nature of SPA frameworks means all you need to worry about is presentation of your data. If all you need to do is some form validation, then writing an SPA is a terrible idea. If you need to build a UI that functions more like a desktop app with long-lived sessions and complex workflows, trying to manage all of your DOM updates will be a monstrously difficult task. You'll basically end up implementing a slow, buggy version of react.

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

#333

Post by dnautics »

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 turned around an SPA fast because I'm only a backend developer. I wrote API endpoints only and contracted a friend to write the frontend, delivering a swaggerspec and vague ideas of what I wanted. Completed the thing in like four design meetings and one touch-up meeting. Couldn't be happier.

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

#334

Post by crooked-v »

potench wrote: post #156

“do I need a component library?” is the question I ask when deciding to use react or not. It’s a totally different question to ask do I need a spa or a server rendered app, both can be dead simple or heinously complex or reasoned away to prove a point... I 100% of the time want (1) to architect my UI as a collection of atomic, reusable components, (2) get page specific server rendered html per route, and (3) do JS in…

For (2), take a look at Next.js. It's a React SSR framework, but there's a static build option that turns every page into prerendered HTML files with embedded JS at build time.

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

#335

Post by skinnyarms »

bwilliams wrote: post #291
jamespollack wrote: post #252

Earlier quoted context omitted.

> That doesn't seem like a valid issue. If a bug in a single page could take the application down then the same could be said for the API powering the front-end. What? The previous poster said coupling frontend / server tightly will result in crash of both if there is a server bug. Your response is that a bug in an unattached API could happen? Of course a bug in your API could crash your API. But at least then it's j…

If your API is down who cares if your app is being served or not? In the majority of cases it won’t work because the API is down.

If my app runs off multiple API, then the bug in my (for example) commenting API shouldn't prevent users from using the shopping cart API to check out.

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

#336

Post by nkingsy »

colecut wrote: post #166
nkingsy wrote: post #116

I have a list of widgets and a button to create a new widget. I don’t want a full page reload when I create a new widget. What are some elegant strategies for handling this with SSR? I’ve used turbo links and found it rather clunky. Haven’t seen a solution that lets me elegantly reuse server side components in JavaScript without going SPA.

Why does creating a new client side widget require a server call at all? Couldn't you have the widget in a JavaScript template and just clone it on the dom client side?

Cloning from a template would be the what, but I was wondering if there are tools designed for this. It's the kind of thing that could spike complexity and I would want an established pattern of delivering html solely for the purpose of javascript manipulation. It's not a hard problem, but a messy one.

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

#337

Post by Twirrim »

ibty wrote: post #290
Twirrim wrote: post #79

Earlier quoted context omitted.

With gmail: Move your mouse pointer down to the lower right corner of the tab. Do a forced refresh (Ctrl+f5) and you'll see some text pop up while it's loading, one of which is a link to a basic HTML version of the site. Click on it and you're back to what appears to be almost the original gmail interface. Up the top of the page you'll see an option to make it default. It's super fast. Almost absurdly so, compared to…

There is a direct link to access basic HTML version of GMail : http://mail.google.com/mail/h/

Ahh nice, thanks!

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

#338

Post by pault »

hello_moto wrote: post #313
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…

> 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 delive…

Hah. I just finished a huge refactor of an application where the back end developers "dramatically simplified" the business logic and architecture. What they meant is they removed all of the business logic from the back end so the client could do it instead. You might be able to tell I'm still a little bitter about that.

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

#340

Post by pault »

mnm1 wrote: post #314
insulanian wrote: post #301

Earlier quoted context omitted.

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.

I'm not sure I buy this. I recently worked on a project where we had one .net core developer, a dev ops guy, and me doing the client SPA. We were all able to focus on our core competencies and turn around the project incredibly quickly. I would argue that you can get away with the same team size split between front and back end and possibly end up with a more efficient allocation of resources.
Post reply on HN