361–370 of 522 posts
It seems like a good 80-90% of the hate of SPAs doesn’t seem to be aimed at SPAs as much a poor programming and poor user experience because of that. In a lot of the cases that people here use. It’s not the SPAs fault as much as the programmers that messed it up. And honestly why do we think that putting it all back to SSR is magically going to fix poor programming?
Earlier quoted context omitted.
You overlooked this part: > Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks
Is there any possibility that the added complexity is a symptom of the framework in use and not a general problem with ALL frameworks? I know I've experienced many projects and found server side rendering more complex then client side when using frameworks like Ember.js.
What ends up getting built is in part due to the requirements the problem presents, and the rest is down to prejudices or inclinations of specific people in the organization. I'll never forget the time we had to build an Angular app because a bunch of people who were not frontend developers were convinced that Angular was the way web apps would be built in the future. Because it came from Google. Welp. (That was back in the Angular 1.x days, which even the people who make Angular couldn't drop quickly enough.)
Earlier quoted context omitted.
You overlooked this part: > Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks
Is there any possibility that the added complexity is a symptom of the framework in use and not a general problem with ALL frameworks? I know I've experienced many projects and found server side rendering more complex then client side when using frameworks like Ember.js.
There are benefits and things you can do with an SPA that you can't do with pure SSR, but they _do_ come at a cost. TANSTAAFL.
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…
Earlier quoted context omitted.
You overlooked this part: > Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks
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)
Earlier quoted context omitted.
It's difficult to tell the person who's writing your paycheck "this is totally possible I just don't like it and so won't do it." Like if you're doing SSR you could at least use something like turbooinks to implement state transitions.
How about “that’s totally possible. It will cost you 10x what you’re paying now, it will be much more brittle and harder to fix. I personally would love to work on it, just keep in mind that any changes will require 10x the time and budget” And ... “Here are a couple of technologies which would allow us to speed up the experience at a very low cost. I recommend we try these first.” Turbolinks for the win :)
Earlier quoted context omitted.
Separate frontend from backend development and make it even two teams. This makes it much more robust and loosely coupled because both sides protect the interface from each other.
This works. Now you only need double the engineers to create the same app as you would using a server side framework. Hardly a more powerful argument against SPAs than this.
Earlier quoted context omitted.
>Plus you've got the extra layer of an API to maintain too On the other hand, if you're providing a service that will always have an API, and you want to make sure that all the functionality you provide is nicely accessible through the API, building the frontend on top of it can be a good approach. The developers at the company I work for have done this, and IMO it's worked out pretty well.
Nonsense. People have been doing that for years before the single-page hype. The servers generating HTML contents use the API as their own backend and you have better layering.
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.
I agree with slower, at least for computational tasks, but not security. Do you feel safer installing an organisation's native app than using their web app?
> The only positives are to corporations and institutions with profit motives...
What advantage does the web give to corporations that native apps don't? You mention spying, but the native mobile app ecosystem is filled with tracking and analytics code (and it's easier to hide it). The only corporation-level difference I can see is that native apps are heavily tied to a specific company's platform, while web apps aren't. This is a huge positive to the web - I've felt free to change platforms many times.
A second huge and underestimated positive of the web is backwards compatibility (ie. lower maintenance headaches). A complicated internal web app I wrote eight years ago is still running despite not being modified. The websites and lousy javascript I wrote as a kid in 1999 still run exactly the same as in 1999. Spacejam.com is unmodified from 1996. Yet I have many native apps from two years ago that no longer run correctly due to OS updates (especially on mobile).