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

111–120 of 522 posts

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

#111

Post by vinw »

danielovichdk wrote: post #28

I tried the other day, yet again, to give it a go. You know, firing up VS Code and make an app with express, node, react bla bla bla. Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked. The hundreds of possible directions you can go in, in terms of frameworks, packages and what not is ludacris. I stopped working when my node modules directory topped…

Riot is a good solution for simple SPAs if you don't like huge toolchains. It gives you web components and DOM binding and all that, all in a 15 KB package that does all the compilation in a few milliseconds on the client.

No configuration of babel or webpack or whatever to worry about, just host your app as static files that point at your API.

https://riot.js.org/

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

#112

Post by stevehiehn »

Most of the projects I've been on there is a web app & native apps. So the appeal of a single page app is you will write the exact API/auth for all the clients. Would it be tempting to not use the same auth flow/api etc if you don't use a single page app? Not sure.

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

#114

Post by tyingq »

leadingthenet wrote: post #85
tyingq wrote: post #22

Earlier quoted context omitted.

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

You're just externalising the time you save as a cost to your users.

It's equally possible you're doing the same thing by forcing users to download a native app. It's kind of hard to talk about in the abstract. Some things work better in an app, for other things it adds nothing notable.

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

#115

Post by trimbo »

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 changes, across directories and languages in both the front and back-end, and usually two different build chains.

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

#116

Post by nkingsy »

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.

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

#117

Post by joshfraser »

phkahler wrote: post #86
simple_phrases wrote: post #42

Earlier quoted context omitted.

Native apps allow Google to collect much more information than they can via the browser. They also allow for a wider range of advertising opportunities.

Except for people who won't put up with advertising in native apps.

They don't need to show you ads in their apps. They just use them to collect your data, like where you are every moment of every day and use that data to better target ads.

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

#118

Post by s_y_n_t_a_x »

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…

Seems like you're just looking through the nostalgia filter.

We're in a lot better place than we were a decade, let alone 2, decades ago.

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

#119

Post by cfv »

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-like flow with each thing happening only once at a given time is great, right until you get asked to make it so that clicking on a thing shouldn't reset all user input, and progress of a task should be communicated live, maybe while we also we want this app to just not show a blank screen like, ever, just comes and happens to you and that's what you kind of have to do now.

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

#120

Post by ldiracdelta »

One of the biggest reasons I reach straight for React is that I then have only one UI language. Instead of templating on the server in python or c# and then doing any UI updates in javascript on the client, I only have to write templating code in React and it runs on client and server.
Post reply on HN