You probably don't need a single-page app

Post by qudat » Mon, Feb 18, 2019, 5:34 AM UTC

tspike wrote: post #366

ivanhoe wrote: post #316

Earlier quoted context omitted.

You simply trade back-end frameworks complexities for the front-end framework complexities. With the right architecture there is no huge difference IMO, just of course you also need to upgrade your teams so that they can handle a lot more tasks on the front-end than with SSRs (and you'll probably need less back-end devs)

Front-end frameworks have a way of going in and out of fashion / support much faster than backend ones.

Post by philliphaydon » Mon, Feb 18, 2019, 5:41 AM UTC

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…

Post by qudat » Mon, Feb 18, 2019, 5:45 AM UTC

varlogix wrote: post #196

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…

Same issue at the previous company. Engineering team decided to turn the web app into SPA, and spent months doing this. All that time which could have been spent on building customer value were wasted.

Post by qudat » Mon, Feb 18, 2019, 5:51 AM UTC

rhizome31 wrote: post #170

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.

Post by qudat » Mon, Feb 18, 2019, 5:57 AM UTC

superkuh wrote: post #289

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.

As browsers close the gap they simply become the OS but slower, more abstracted, and with less security. And they stop being good browsers. It's the old emacs situation come round again. The only positives are to corporations and institutions with profit motives to decrease dev time and increase ability to spy on users and extract rent from them.