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

131–140 of 522 posts

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

#131

Post by paulddraper »

cfv wrote: post #119

You probably don't need a single-page app, right up to the point where it's a business requirement and you have to translate a GB worth of convoluted JSPs into one because the client likes smoothness in their flows, continuous saving, and all those nicely choreographed state transitions you just cannot get without having a framework hijack the History and File APIs from the browser's paws. Yes, a nice state machine-l…

This is why it's important to understand the probable business requirements early.

Website != Browser app != Mobile app != Desktop app != AR/gaming platforms

If you know which of those you need, you can make an optimal technology decision. No one can expect to turn a wood-framed structure into a steel-framed structure. Nor build a steel-framed structure for the price of a wood-framed one.

In this day and age, chances are better than not for anything reasonable involved, that this smooth interaction is a business requirement, but YMMV.

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

#132

Post by mycall »

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…

I tell people don't implement SPA. Implement PWA. PWAs give you actual benefits that SSR doesn't provide (eg. offline).

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

#135

Post by tyingq »

skybrian wrote: post #126
tyingq wrote: post #8

I'm more interested in the future of "you probably don't need a native app" . It feels like browsers are closing the gap pretty well with things like IndexedDB, offline features, WASM, etc. Still a ways off, but seems like it's getting there. I do worry, though, that it's not really in Apple's or Google's best interest to move that along.

I look forward to a similar article saying "You probably don't need WebAssembly." I mean, it's neat and all, but most websites aren't CPU-bound.

I didn't view WASM on its own as the big differentiator. But, it is one of many things that's closing the gap between native apps and web apps. As you mention, it's useful in some situations.

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

#136

Post by marktangotango »

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 separation of logic, view, and code than the typical serverside solution.

There is a happy medium where server side services are encapsulated to separate concerns in a similar manner, but it rarely happens, even with competent, experienced, well intentioned teams.

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

#137

Post by petilon »

trimbo wrote: post #115
petilon wrote: post #47

I couldn't disagree with this article more. Developing SPAs is easier than server-render applications. The problem is React, Redux, and other such libs make this more complicated than necessary. React is all about surgically making the smallest possible change in the DOM to refresh the page. But is that really needed? Most of the time it is not. Why not re-render the whole page? This is what happens in the case of se…

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

You have to deal with multiple languages in any case: Java/C#/etc for the server logic, HTML for rendering and CSS for styling. You also have to deal with whatever syntax you are using to embed expressions in the template. If you use SPA there is one additional language (unless you use Nodejs for server logic) that's true. And you also have two different build chains. But the advantage is that the server logic becomes much simpler because you don't need session state or rendering logic. Your server can focus on being a stateless REST service which is more scalable (since you don't have session state clients can connect to a different server on each request). Your server is also more future-proof because it won't need to be rewritten to support native mobile clients.

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

#138

Post by mycall »

tyingq wrote: post #22
IloveHN84 wrote: post #18

Earlier quoted context omitted.

Native will always be the best solution... Because it's native.

Technically best doesn't always win the market. I'd love not writing 3 versions of every piece of functionality.

Have you tried Angular+NativeScript? one piece for all (minus UWP).

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

#139

Post by hyperpape »

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…

Great example, because the basic HTML version doesn't support keyboard shortcuts, which makes it a huge step back for me.

It's certainly possible to have a server rendered app that uses JS sparingly for interactive behavior, but it blows away a lot of the benefits once you're doing significant DOM-manipulation.

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

#140

Post by chimen »

What about separations in teams where designers don't mess with backend programmers code? Updates and parallel works on the frontend and backend projects without issues? What about servers that respond with minimal data and consumers that deal only with displaying the received data? Pushing code, re-compiling and restarting webservers all because a button had to be made green or its shadow changed? What about CI/CD, automated tests, automated migrations, builders and compilers consuming dollars and energy for that button change?

I'm happy with building SPAs where it makes sense (myaccount/admin). The problem is Javascript and its ecosystem but you could very well go with Ember which is stable as...and be relevant for years.

Post reply on HN