Yeah, but as you said, it is highly dependent on the implementation. Theoretically it is possible that the user is also seeding the previously downloaded/streamed chunk (via WebRTC for example if using a browser). That reminds me of a madlad that stores data on a ping packet (see suckerpinch channel on youtube, specifically his video titled “Harder Drive”)
For NAT, there is apparently a way to traverse NAT. I haven’t tried it tho, but the dude has a lot of research on the topic (NAT traversal), so if that didn’t work, maybe others will
Instagram by Meta has started using user generated content for their training data. Naturally users are upset about this and are flocking to a new platform named Cara made by an artist which has principle and are actively fighting for artist copyright. Cara uses Vercel to host their platform. The problem is that the sudden influx of users means bigger bills to pay to handle those traffic (I think they are billed around ~$96k). As of now, it is unclear how they will proceed to pay the bills. The creator of Cara didn’t want to compromise his stance by accepting any money willy-nilly, but also acknowledged that angel investors are not easy to find.
Client still needs to call the server. How offline PWAs work then? They emulate server in ServiceWorkers.
Yes they do need server for initial resource loading. Usually with PWA, you need to fetch the static resource once from a CDN since every resource is bundled. And no, they don’t need to emulate server in service worker, wtf. You can if you want, but you can also store the data locally using indexeddb and sync periodically baked into the app. Service worker doesn’t emulate server, they just intercept a network call and check their cache. A man in the middle if you will. I think it is debatable if that is called emulating a server or not.
- Let’s call it page generation to not confuse with actual rendering.
Yeah, that is fair. Its just the usual web tech shenanigans.
- It not always saves bandwidth and processing time, but static resources can allow to hide CDN latency on initial load. Although it is not property of SPAs, just separation of static and dynamic part and generating dynamic part after static page already shows something.
When developing an application, you usually didn’t develop the dynamic and static part separately. Which data can be cached and which needs to be sent to the origin so it can be properly generated. If you fail to configure it correctly the static resource which should go to a CDN get sent to your origin instead. With SPA you just ship the frontend to the cdn and make the backend separately.
- It will still result in more requests, but may trasfer less data per request. May.
I mean, if you are making an SPA without splitting the bundle, there should only be a single html, css, and js. A bunch of images and some font too if you want to be complete. But if you are making the page server generated, you always need to transmit the HTML. ALWAYS. So I think it definitely saves requests.
Static web page after loading will not request more styles. SPAs imply client-side dynamic page, and they may request more data INCLUDING styles. Also client still need to load styles on page load.
SPA will not request more style if you are bundling them tho? Wtf are you talking about? Unless you explicitly split the style, once SPA is loaded every page navigation is just JavaScript replacing the whole HTML with the one bundled in the JS file.
Write for QT.
Sure, QT exist as a UI library for cross platform. But that doesn’t solve the iOS mafia. We only got Apple to allow 3rd party store now, we haven’t got sideloading yet. It is a hassle if you want to make an app that can be used in any devices. Especially if the app is just some form filling app.
Strictly speaking, the original commenter is talking about website but sure there is an FSM JS framework too (XState).
When you are writing some complex web app, you will wish you used a framework. Some web apps can have more than 50 pages with multiple states that depend on remote data to be locally cached and synced depending if you are online/offline. Framework can handle a lot of the heavy state management for you and even provide a nice UI component library. But I do agree that React is too much, but jQuery is being replaced by vanilla JS. That is why I usually use Vue. But for simple stuff, yes, Vanilla JS is pretty much good enough
I do think everything has its place. For example, you can do offline PWA with SPA since a page load doesn’t need a call to the server for rendering it. It also saves processing time/bandwidth by offloading the server from the burden of rendering the page. Once the page has loaded, the web app only needs data, not markup nor style. And last is that it is great since it only requires a browser without needing to write native apps in myriad of languages. Distributing and installing it is also not limited by the Apple/Google tax.
For clouds, there are certain workflows that can surely benefit from it. Maintaining your own infrastructure 24/7 with minimal downtime can be overwhelming for SMALL teams, especially one man show. Even more so when the product/web apps suddenly blows in popularity and now need to scale. Even more so when it is being DDoSed. The point is, many things can go wrong. And when you are deploying it for 24/7 use, down times can be costly. Deploying to cloud early and then slowly building towards on-premise after the team gets bigger is a viable route IMHO
And last is container devops. I think it also solves a lot of problems in multi-tenancy or even when running multiple services. Not everyone will use the latest-and-greatest version of a shared library. If the library is somehow conflicting with other tenants/service, you will have a bad time. Also, developing inside a container or virtual env can make testing and messing around safer since you didn’t affect your system installation.
You jest but it can happen when what the docs says doesn’t reflect the implementation. And also, that’s what we call bugs.