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

151–160 of 522 posts

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

#151

Post by buu700 »

Anecdotal: cyph.com started off as an SPA, mainly so we could share some components and styling with our actual application — and ever since we migrated to a static WordPress site with a handful of Angular Elements it's been both a lot easier to maintain and way faster for end users.

(Sure, we could've gotten similar performance with server-side rendering, but at least with the current state of SSR tooling that would've been way more distraction from building our product than we could justify.)

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

#152

Post by bwilliams »

skinnyarms wrote: post #127

How about build-time rendering? Server-Side rendering tightly couples your front-end to your application server. Scaling the site means scaling up that application server. A bug in one "page" of the app can cause the whole application server to go down. If you leverage client-side rendering then it's easier to decouple your front-end from the back meaning you can take advantages of things like segregated micro/server…

> A bug in one "page" of the app can cause the whole application server to go down.

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.

> If you leverage client-side rendering then it's easier to decouple your front-end from the back meaning you can take advantages of things like segregated micro/serverless services and progressive web apps

Your PWA point is valid but I don't think the microservices point is. Microservices add a ton of complexity and can easily become overwhelming. If you get to the point where your application can benefit heavily from microservices then congrats, you've made it.

> I think that server-side rendering is on it's way out.

If anything I think its on its way back in. So many companies bought into the benefits of client side apps and are now seeing the trade-offs that aren't very favorable.

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

#153

Post by beachy »

marktangotango wrote: post #136
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…

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…

It doesn't often happen because of Conway's law - that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

Its always possible to architect the web/app back end to do everything through APIs, keeping the APIs pure, and ensuring that others will be able to build UIs on top of them.

But in many organizations the same people that own the APIs also own the back end. That means it takes discipline and an acceptance of extra costs to keep this separation. Its easiest and cheapest to just slop all the back end together.

With an SPA, a different team builds the front end from the back end, and APIs are the only way for them to talk. That acts as a force for good APIs.

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

#154

Post by s_y_n_t_a_x »

mycall wrote: post #141
s_y_n_t_a_x wrote: post #54

Earlier quoted context omitted.

You could use Blazor to export to webassembly, but it includes the entire .NET runtime, so the payload is huge. It's a bit silly to say you quit when you topped 60mb in your node modules directly, something you never have to look at and doesn't represent what gets built in to the final app. There's tons of dependencies when dealing with the .NET toolchain. There are hundreds of directions you could go in, and I consi…

Microsoft said they are optimizing the huge payload with tree shaking and other techniques.

So they're trying to get where Webpack already is. But I hope they do, it's nice to have as many development options for the web as possible.

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

#155

Post by donatj »

marktangotango wrote: post #136
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…

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.

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

#156

Post by potench »

“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 a sane way (manipulate DOM, manage client state, and support a series of interactions that do not reload the page.)

So, what are my options?

1. React/node 2. Sacrifice one of the above.

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

#157

Post by lmilcin »

All that complaining serves no purpose. SPA is just another tool in a belt. Where I think it shines is making rich apps that need complex flow and communication. This is where productivity is important and the process is complex and up until recently I would be advocating native desktop app. Now with advent frameworks that help me organize this very efficiently (I use re-frame/reagent with ClojureScript) I can create complex SPAs without the project collapsing under its own weight at some point.

I don't want to say you should use SPA frameworks for anything, don't make your company website with SPA. What I want to say that if you have a complex process you can consider creating "enterprise" UI instead of trying to dumb it down to a series of billion simple forms.

If you feel your business is overusing SPAs (is it so strange they want new shiny toy?) then as the technical person you need to educate them on pros/cons of the technology.

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

#158

Post by tyingq »

AnIdiotOnTheNet wrote: post #88
ken wrote: post #83

Earlier quoted context omitted.

> What's the difference between polyfill or some framework, and something like Qt or SDL? As a user, I usually can't even tell when they're using a polyfill on the web (except when they stop, like GitHub did with type=date). (As a developer, I often can't tell the difference, either. Some of them are that good!) So long as you generate HTML/CSS/JS, it doesn't matter to me how you do it. That's as 'native' to the web…

> I can spot Qt a mile away. A lot of the visuals look wrong and a lot of the controls don't behave right. You mean it has no respect for your native toolkit... just like the web?

"just like the web"

How true is that? I was under the impression that for Android and iOS, Chrome used the native widgets for most things.

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

#159

Post by dvogel »

marktangotango wrote: post #136
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…

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…

One reason the SSR mess is so easy to walk into is that everyone knows it's a reasonable amount of refactoring to get out of later. The cleanup of an SSR app lacks the deployment headaches of SPAs (doubly so with the service worker layer).

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

#160

Post by valeriobo »

AnIdiotOnTheNet wrote: post #125
valeriobo wrote: post #38

Totally agree with the article, the spa hype has produced a lot of crappy slow web sites and crippled productivity of many teams for years. I think ppl in the industry are way too young and have the bad attitude to nod add tools in their belt but keep only the last one that has hype. Spa are like applet or Silverlight, just different tech, same goes for ws* vs rest api and so on...

> I think ppl in the industry are way too young and have the bad attitude to nod add tools in their belt but keep only the last one that has hype. The current culture is to only keep a job for ~2 years before moving on, why wouldn't they adopt that attitude?

True, if you do not stay long enough to feel the consequences of your decision you do not learn from those years. We do not usually hire ppl that change job that often, but we are not in a silicon valley kind of enterprise
Post reply on HN