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

411–420 of 522 posts

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

#411

Post by manigandham »

GordonS wrote: post #273
mandeepj wrote: post #218

Earlier quoted context omitted.

Sorry, I don't have the complete context - SSR stack, app architecture, load times etc. So, I'm not in a position to comment on your SPA migration. But, I'd like to share thoughts from my current situation. We have a flagship product written in web forms (started in 2006). It's a big solution. Performance has always been a challenge with it. While I'm not proposing a complete rewrite into SPA, due to - migration requ…

> My proposal is to switch to json objects for information exchange between server and client. We'll get the benefits similar to SPA without rewriting for it If I understand your approach correctly, I often do something similar, but with modern ASP.NET Core MVC apps. Basically, I have a tiny bit of JavaScript that 'intercepts' all form POSTs and submits them using AJAX instead. Another tiny bit of JavaScript can then…

This is exactly what the article points out. Github/Gitlab and many other projects do the same thing.

Either small parts of the application are standalone SPAs (since they can be mounted to any single root element) or there are libraries like Turbolinks/Intercooler that just make the full-page request but in JS and then replace the DOM with the results so the browser doesn't actually experience a full page reload.

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

#412

Post by wokwokwok »

strken wrote: post #381
wokwokwok wrote: post #376

Earlier quoted context omitted.

Perhaps, but if both teams are half the size, specialised and deliver faster, it’s a win. That may not always be the case, but if your SSR team and API team are the same size, your devs suck, bluntly. API based backends are much easier to build, test, manage and look after.

That's a hell of a generalisation, and it falls down pretty fast when you move beyond CRUD apps. You can easily end up with entire teams whose role is just to babysit Elasticsearch.

No, it doesn’t.

Regardless of the backend stack, if you maintain both the front end and the backend, it is categorically less effort to only maintain the backend (ie. just run an API).

Half as much effort? 3/4? I don’t know, maybe your UI is a man autogenerated swagger frontend and it’s (43/50) as much effort.

It depends... but it is always less effort not maintaining an external user facing UI.

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

#413

Post by paultopia »

Theodores wrote: post #393
paultopia wrote: post #262

Unpopular opinion: I love SPAs for simple stuff. Yes, they're a ton of work. But the feel of them is unparalleled. I have my personal home page written as a Vue SPA. It was a silly amount of work to get together, and not everything works perfectly. BUT: it moves like a rocket. I pre-render the simple front page, so initial load is nearly instantaneous (especially with cloudflare &c), and, by the time a visitor finish…

Fun is fine, however, it can distract from the task in hand. Accessibility is queen. No criticisms here, just observations on what gets missed generally by people who go too far along the build tools path and overlook things like document structure along the way. The actual document could benefit from HTML5 niceties such as more accessible elements than 'div' and the table elements. Table has its place but the world…

I certainly think most of this stuff is right. I've been meaning to go through and make the whole thing more semantic, just haven't gotten around to it yet. So I really appreciate your thoughts, most of that stuff is going on the todo list. (Maybe not the SVG stuff; the way I do the SVGs is a lot more convenient for design flexibility.)

(But, to the original point, all of those great suggestions are totally compatible with doing things SPA-style. And actually, Vue components are so composable that these kinds of changes should be pretty easy when I get around to them.)

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

#415

Post by rainonmoon »

anonytrary wrote: post #407
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…

Eh. The problems you talk about have little to do with SPAs in general, and have more to do with "rewriting things from A to B". If you had started out with SPAs first and wanted to un-SPA everything, you'd be making the same comments. The issues you mentioned aren't intrinsic to SPAs, they're intrinsic in redoing things.

You're right, but it's also intrinsic to the senselessly shifting paradigm/bandwagon-jumping around SPAs. It's not just that redoing things is a problem, but that the motivation behind the rehaul is poorly conceived.

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

#416

Post by manigandham »

dimgl wrote: post #350
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…

You mean ludicrous? `node_modules` directory topping 60+ mb means nothing when the final product is an optimized bundle or a `node` process loaded in memory. A large majority of developers don't care about this because they're just looking to get actual work done... not sure why you're trying to "fix this". I'm also not sure what you're talking about when it comes to unclean code and complicated tooling. The tooling…

It's really down to language and ecosystem. JS as a language and NPM as a ecosystem are not as productive as C# and the .NET standard library, framework and Nuget.

With WebAssembly, C# Razor Components will soon be able to run either server or client side and still maintain the same highly productive development that's missing from JS.

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

#417

Post by wolco »

chalupa-man wrote: post #403
rhizome31 wrote: post #170

Earlier quoted context omitted.

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.

I couldn't disagree more. For anyone on a slower connection (I use a satellite connection that's 1 Mbps on a good day) a SPA is almost always a greatly superior user experience. A server-side rendered application is a blank white screen for roughly 50% of the time I'm using it. Even if a SPA takes longer to initially load, it's much nicer to keep the application actually onscreen while it's loading new content. Even…

1 Mbps and each page is 5 seconds? It sounds like huge pages you are viewing

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

#418

Post by manigandham »

s_y_n_t_a_x wrote: post #54
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…

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…

FYI: Blazor is using the Mono runtime and is still in experimental stage. It's 2MB raw, can be compressed over HTTP as any other file, and can get much smaller after linking and optimizing the build.

Early tests have made the whole package as small as 200kb which rivals many JS builds but with far more capabilities.

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

#419

Post by wolco »

woah wrote: post #205
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 what HN is always missing on the anti-SPA rants. It’s almost always a requirement from the client. How many hours have been wasted on here by programmers writing overwrought comments about how we’re losing touch with the user because of all of our complicated frontend frameworks? No. It’s almost always because the client’s designer wanted a real-time updating hamburger menu or whatever.

The client is rarely the user. Clients always ask for the latest buzzwords.

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

#420

Post by sriram_iyengar »

Valid points. - another aspect to consider seriously when designing SPAs is authentication. I have built ReactJs applications and everytime we need a different module that had only the login functionality. Somehow this always appeared disconnected whereas In traditional apps you have a middleware that watches before rendering, be it client side or server side rendered.
Post reply on HN