You probably don't need a single-page app • Hacker News Board

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

#161

Post by rhapsodic » Sun, Feb 17, 2019, 4:50 PM UTC

beachy wrote: post #153

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…

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…

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

YAGNI

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

#162

Post by kissgyorgy » Sun, Feb 17, 2019, 4:51 PM UTC

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…

> I would note that generally server side templating is often a mish mash of business logic

If you don't have good, experienced senior developers or they don't have discipline, yes. But that's true for any technology. Good developers have the knowledge for simple things like how to separate business logic from templates...

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

#163

Post by itronitron » Sun, Feb 17, 2019, 4:55 PM UTC

fma wrote: post #82

So, a question coming from a guy who's been doing Java backend processing for a long time and thinking of making a side project. Was going to go the Angular route, but I'd like to have good SEO. I'd also like to get a POC/MVP up and running to build momentum...don't want to waste time on the front end when it's basic form submissions to kick off data processing. To show how long it's been since I've done front end...…

In that case then do not use a UI framework such as Angular or React and instead just roll your own UI with HTML and JS, and style your CSS to make your MVP look fresh and new.

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

#164

Post by stickfigure » Sun, Feb 17, 2019, 4:55 PM UTC

danielovichdk wrote: post #87

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…

I understand the toolchain juuust fine. I have been making HTTP and browser applications for two decades. The technology landscape is absolutely ridiculous if you want to do things for the web. Each browser has its own standard, chrome is the new IE6, the industry is hacking together assembly languages to port from other technologies, preprocessors, minification, state and what have you not. The web today had been tw…

chrome is the new IE6

I've heard this repeated a few times, and it's utter nonsense. Unless you're deliberately going off into the weeds, a full featured SPA works the same on Chrome, Safari, Firefox, and Edge. I don't even bother testing on multiple platforms anymore; they just work.

I did web development in the IE6 era (and before). This is nothing like that.

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

#165

Post by upheaval7276 » Sun, Feb 17, 2019, 4:56 PM UTC

petilon wrote: post #124

s_y_n_t_a_x wrote: post #104

Earlier quoted context omitted.

You don't have to deal with any of that crap when you deal with react. Just write pure functions as components. The arguments are the props.

Then you aren't benefiting from React at all. The point of React is DOM diffing, which you trigger using setState method.

First off, this is not “the point of React”. Second, direct use of setState is not somehow the only path to focused DOM updates with React. In order to understand this better, I suggest you read up on the topic of Reconciliation in React - https://reactjs.org/docs/reconciliation.html

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

#166

Post by colecut » Sun, Feb 17, 2019, 4:58 PM UTC

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?

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

#167

Post by itronitron » Sun, Feb 17, 2019, 4:59 PM UTC

joduplessis wrote: post #99

The massive problem with this approach is that more and more the requirements we see are exactly where SPA's shine: real-time elements, rich UI and eventually PWA implementation when/if. I agree that the traditional SSR has served everyone well - but I don't think we need to be stubborn about what has worked vs. what can work.

There are a lot of hidden/implicit requirements when people think of SPAs. In order to do them right the interaction design needs to be worked out in detail with the developers so that everyone on the team knows all possible states of the application and how to best manage that.

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

#168

Post by brylie » Sun, Feb 17, 2019, 4:59 PM UTC

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…

I think all of your requirements could be met in a myriad of ways. E.g. Django templates/Handlebars can be organized as reusable components, many backend frameworks will render HTML per route, and there are several JavaScript client libraries including Vue and, dare I say, jQuery that will give you a sane way to do client interactivity without page refresh with varying degrees of declarative code style.

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

#169

Post by ec109685 » Sun, Feb 17, 2019, 4:59 PM UTC

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…

You don’t have to use a single server for your business logic and rendering. Separating those two on the backend will ensure you have a clean api that things like mobile apps can hit, while still having a service that renders html for the server-rendered view of your app.

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

#170

Post by rhizome31 » Sun, Feb 17, 2019, 5:02 PM UTC

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…

Thank you for pointing the real issue with SPAs: they deliver awful user experience. It's quite telling how this fact is missing from the article and from most of the discussion here. We're a bunch of self-referential techies who've lost connection with reality.