291–300 of 637 posts
No shit, Sherlock. Of course, all of this was obvious to any of us with more than 5 minutes of industry experience, alas this field seems super prone to reinventing the same things over and over again, making the same mistakes and never learning from the past. Also, this article does not even mention the fact that SPAs are terrible for SEO. Of course, that's not an issue for YouTube, but it might be a huge issue for…
SEO for SPAs is a solved problem
I hate SPAs. I would never do another SPA again if it were up to me. It just adds too much mental context switching and overhead. I can develop fully server-side apps that are lighter, run faster, and at least 20% less development effort (I actually compared that for the same task: https://medium.com/@mustwin/is-react-fast-enough-bca6bef89a6 ). So why would I ever do an SPA again if it were up to me? I would use http…
Quoted post unavailable.
Earlier quoted context omitted.
The correct answer for this stuff, and it absolutely kills me saying this, is probably something like asp.net web forms.
Please, go learn about Remix ( https://remix.run ), it is the actual correct answer for this stuff.
I hate SPAs. I would never do another SPA again if it were up to me. It just adds too much mental context switching and overhead. I can develop fully server-side apps that are lighter, run faster, and at least 20% less development effort (I actually compared that for the same task: https://medium.com/@mustwin/is-react-fast-enough-bca6bef89a6 ). So why would I ever do an SPA again if it were up to me? I would use http…
Sure, if you implement a trivial single-task app (one tiny feature of a Calendar app) with an unfriendly UI, you don't need an SPA. That doesn't prove anything.
Websockets+SSR (PhoenixJS) attempts to store state on the server rather than the client; in that way you can still have stateful interactions with minimal JS. NextJS does an amazing job patching the bridge between SPA+SSR by having the same codebase run on the backend and the frontend. What I would like to see more of from this industry is less "grass is greener on the other side" and the unification of a single tool that allows for the cross-collaboration of SPA + SSR without having two distinct codebases that one has to context-switch between.
I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. For example, recently I had to deal with photo uploads on a Rails app, which works fine out of the box at first, until you want to show progress bars and uploaded previews etc. Then you add a couple of client-side…
This is what jQuery solved. It made it ridiculously easy (compared to not using jQuery at that time) to add a little sprinkle of progressively enhanced JavaScript to a page. It still works today (and you don't even need jQuery now, as browser standards have mostly caught up), but everyone seems to have forgotten how to do it!
I stopped interviewing for front-end work since then. The landscape changes frustratingly too often.
This article seems to be directed at dealing with people that use SPAs to make more content focused websites, which quite obviously are better made with the browser. However, for an application with a persistent UI, I fail to see how constant page loads and navigation just because "the browser can do this" make any sense at all. Even the example is a bit silly - SPAs that should be SPAs don't really have "links" per…
Yeah - I think a lot of it might be developers who don't understand that SPA and caching go pretty much hand in hand. I'll admit that can make your life as a developer harder sometimes (to be blunt - caching is hard - full stop) but an SPA rendering from cache is basically a rocket compared to a server rendered page on a bad connection. Absolutely no one enjoys waiting 2-5 seconds after clicking the back button to se…
Wait, what. Don't basically all browsers nowadays keep previous pages in memory exactly not to do this?
I'm still bullish on the potential for Web Assembly apps to overtake mobile binaries. And instead of Single Page Apps, we'll have just plain Apps that run in browsers.