51–60 of 192 posts
Earlier quoted context omitted.
IF you want the page to be interactive without refreshes though, you gotta do something. Unless you are advocating a completely pre-ajax web. https://en.wikipedia.org/wiki/Ajax_(programming)
A bit of Ajax here and there is fine. Look at how HN handles it when you upvote/unvote a comment. Look at how old.reddit.com handles it when you click "load more comments" in a long thread.
Earlier quoted context omitted.
A bit of Ajax here and there is fine. Look at how HN handles it when you upvote/unvote a comment. Look at how old.reddit.com handles it when you click "load more comments" in a long thread.
isnt ajax fancy sending html over the wire? or is it just the non fancy way?
You don't even need a fancy "send html fragments over the wire" approach to create a better user and developer experience. Just sending full pages, server side rendered, like Hacker News and Wikipedia do is fine: Going from the HN homepage to this topic we are on: 36 KB in 5 requests. Going from the Wikipedia Homepage to an article: 824 KB in 25 requests Going from the AirBnB homepage to an apartment listing: 11.4 MB…
Is that AirBnB stat including “content” stuff like images or embedded maps? It’s still worth critiquing the bandwidth spent on that stuff, of course, but it wouldn’t really be fair to include it here when the discussion is about the architecture of page transitions.
Whatever I click on AirBnB, I get a white screen, then some placeholders, then the placeholders one after the other get replaced by the actual content.
Whatever I click on Wikipedia - its just there instantly.
Isn't making a request for almost any user interaction a bit too much? I am more in favour of BE telling FE what to render. I honestly believe many apps could be simplified with better abstractions than hard coding html into messy components. Not saying it's a great approach for super complex layouts, of course.
If you're building an where you are going to open up an API, there is a little less benefit, but I've worked on projects in recent years where the API exists solely to be consumed by one client.
old man alert Back in my day, we wrote ASP.NET that was all server-side-rendered HTML. Once in a while we got REAL FANCY and used JQuery to make PARTIAL HTML requests and update only FRAGMENTS of the page. Hooboy I knew that fashion was cyclical but not tech!
You don't even need a fancy "send html fragments over the wire" approach to create a better user and developer experience. Just sending full pages, server side rendered, like Hacker News and Wikipedia do is fine: Going from the HN homepage to this topic we are on: 36 KB in 5 requests. Going from the Wikipedia Homepage to an article: 824 KB in 25 requests Going from the AirBnB homepage to an apartment listing: 11.4 MB…
IF you want the page to be interactive without refreshes though, you gotta do something. Unless you are advocating a completely pre-ajax web. https://en.wikipedia.org/wiki/Ajax_(programming)
You don't even need a fancy "send html fragments over the wire" approach to create a better user and developer experience. Just sending full pages, server side rendered, like Hacker News and Wikipedia do is fine: Going from the HN homepage to this topic we are on: 36 KB in 5 requests. Going from the Wikipedia Homepage to an article: 824 KB in 25 requests Going from the AirBnB homepage to an apartment listing: 11.4 MB…
IF you want the page to be interactive without refreshes though, you gotta do something. Unless you are advocating a completely pre-ajax web. https://en.wikipedia.org/wiki/Ajax_(programming)
[0] https://github.com/phoenixframework/phoenix_live_view
[2] https://laravel-livewire.com/
[3] https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...
old man alert Back in my day, we wrote ASP.NET that was all server-side-rendered HTML. Once in a while we got REAL FANCY and used JQuery to make PARTIAL HTML requests and update only FRAGMENTS of the page. Hooboy I knew that fashion was cyclical but not tech!
Gmail is one of the first to have adopted this paradigm.