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

91–100 of 522 posts

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

#91

Post by nabla9 »

bzalasky wrote: post #81

The answer to whether a single-page app is appropriate for a given project needs to consider product requirements, team structure and available resources. Libraries like React are awesome for breaking down complex (or even not so complex) UIs into story sized chunks that can be tackled by different engineers or even different teams. This is one of the biggest reasons to consider using them, IMO. Even in the case of r…

If the team structure is the problem, you should disband the team and rearrange the structure so that it produces the result what you want. Trying to fit your product to the existing organization is not a good idea.

Conway's law: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

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

#92

Post by EGreg »

Serious question:

At https://qbix.com/platform we wanted to stick closely to the Web standards so we built a hybrid - although new pages would be loaded with AJAX, out of the box we made the “easy development path” cause every to page load from the server. This was because back when we started, search engines and other crawlers didn’t execute Javascript very well.

We always kinda felt bad that we didn’t “fully” embrase the “new and best” SPA trend, but also felt good we were giving people choice and were more compatible with Web Standards. And now as time goes by I see more and more of our choices vindicated. Is this anti-SPA backlash just another fad? Or were we right to give people two ways to render the same page - one on dynamic navigation and one on refresh?

https://qbix.com/platform/guide/pages

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

#94

Post by tyingq »

Twirrim wrote: post #79
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…

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's a single file that's 584KB of javascript from hangouts.google.com in the "full experience" Gmail. Blocking that seems to help, a lot. I imagine there's probably some configuration to turn off hangouts that provides the same benefit.

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

#95

Post by petilon »

s_y_n_t_a_x wrote: post #80
petilon wrote: post #76

Earlier quoted context omitted.

> You don't get much simpler than Redux. Not true. With Redux you write reams of actions and reducers and other such unnecessary crap in the name of state management, when in fact most client apps don't have state, all they do is fetch data from the server, display it, send updates back to the server. React used to be a simple lib, now it is getting more and more complicated. Look at the libs I mentioned they are way…

If you don't need state, don't include it. That's the beauty of React. But as far as a state management lib goes, Redux is one of the simplest, go look at the source. I agree JSX is very nice. It's one of the best features of React, and another reason React is a great templating lib. My point was you don't need it. React does a lot of other nice things like browser compatibility, event management. If you want a small…

React requires too much incantations, rituals and ceremony. You have props and state, context, error boundaries, refs, keys, you have to figure out where state should live, etc. You make a component that contains state. Then you want to use it in a component hierarchy -- now the component is supposed to have props not state. You make a component that has props, now you want to use it at the top level -- now the component is supposed to have state, or have an otherwise unnecessary wrapper.

You don't have to deal with any of that crap.

The best part of React is DOM diffing and incremental screen update. Obviously this is only useful if your application needs to update screens it previously rendered. In fact I'd argue that React is only useful if you need to incrementally update complex screens, because simple screens can be re-rendered completely and no one will know the difference. Very few applications need to incrementally update complex screens. If your application doesn't have this need you can use simpler technologies that don't have the same "Care and feed" requirements of React, such as UIBuilder: https://github.com/wisercoder/uibuilder

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

#96

Post by dhimes »

todd3834 wrote: post #73
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 don’t think this is about edge cases but SPA have been abused. Imagine using google docs as a server rendered experience. Or any of the apps in iCloud.com. There are use cases where it makes sense and use cases where it doesn’t. Most of your complaints are about poor implementation but if a large percentage of people poorly implement SPA then it still looks bad. I used to say you could make a very native experience…

Exactly. In many places slow networks are the problem, and quick spa's give a great user experience comparatively. The biggest lag in Google Docs is when it has to refresh from the server, and then it's like using windows on a 386.

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

#97

Post by s3graham »

tyingq wrote: post #94
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's a single file that's 584KB of javascript from hangouts.google.com in the "full experience" Gmail. Blocking that seems to help, a lot. I imagine there's probably some configuration to turn off hangouts that provides the same benefit.

It's in Settings.

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

#98

Post by subpixel »

greenhatman wrote: post #75
subpixel wrote: post #65

On the one hand, site like https://dev.to/ that are built in Rails and rival the speed and performance of any _static site_ support the argument that you can just use the tools you know. On the other hand, to get your Rails site to function that well takes a lot of work - it is by no means the starting point. Systems like Next.js and Gatsby.js and others are attractive in that A) they offer the ability to use both se…

I think dev.to is an SPA. But not built with a framework.

It's not, it's just very...dialed-in: https://www.youtube.com/watch?v=Afy7H04X9Us

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

#99

Post by joduplessis »

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.
Post reply on HN