Asking the important questions

it was me sorry

I don't know how to React to this.
- Don't React, just Vue?

Made the mistake of using react for a mobile app and my god why is it this convoluted, why are the error messages always along the lines of "something went wrong with networking 🤷"

Unfortunately I'm stuck with it now

react is better than the days when we jquery everything
- Am I the only one left writing pure JS webpages? I swear for the stuff I've done recently, adding React or even jQuery makes things 10x more complicated and bloated. The base JS support browsers have now is actually great. It's not like the old days trying to support every browser back to IE6
Linux has better error messages. "Dazed and confused, but trying to continue".
- I am spoiled by dotnet and rust error messages. They tell you exactly what the problem is, where it is, and in rust's case sometimes even how to fix it
  Then there's C with "segmentation fault"
I just have to say: designing a GUI in code in 2024 is asinine.
I feel bad for anyone who got suckered into learning convoluted bullshit like angular or react when they could've learned Godot or Qt.

Than*

You can write a stateless server. You can’t do stateless front-end since you have to deal with user interaction.

I would not be so sure. Maybe for a static web page this is possible. Outside of that I think people are kidding themselves. Writing code that might be stateless in isolation but relies on a database isn't a stateless server imo, it's just outsourcing state to another service.
- With the SPA approach, you can have remarkably little state on the server because all the state associated with the user session lives on the frontend. The value of doing this obviously depends on the type application you're making, but it can be a sensible approach in some cases.

I didn't read the community name and wondered who tf thought the back end of a goose requires more attention than the front end

Well...depends on what the vertical distance is I'd wager....

Often me. I make tools/interactions for learning management systems. So the back end is a thid party I have no controll over. Just take the api and make the magic happen.

You need me to save data somewhere but don't want to buy server space? Sure we can cram that into places it's not ment to go within the system. It will slow things down and likly cause issues but it's free.

That goose should be made mandatory in all customer meetings.

If that were true, you'd have more front end devs being able to do backend instead of the other way around.

These are completely different types of skills. Front end is complex because there's an explosion of different states driven by how the user interacts with the UI. On the other hand, backend workflows tend to be a lot more structured. You get a request, do some processing, fetch some data, and return a response.
- From where I sit, it seems like frontend is closer to being a graphic designer than on backend.
Backend devs can do frontend?
- html
  
  <!DOCTYPE html> <html> <body> <p>Hello World</p> </body> </html>
  here i wrote you a frontend
- https://imgur.com/a/wOgZwpn
- Yes. It'll look like a Geocities page, but yes.
- As a backend person, lol no. I mean I can make a thing that works, but it will require eye bleach afterwards, and I'll hate every moment of building it.
- They think they can.
- Not all, but more than front enders being able to do backend is my point.
- yes, according to every project manager i’ve worked with.

The proliferation of libraries that exist only to fix the problems introduced by making everything an SPA is hilarious. Everything in web tech from the last decade is basically “there was an old lady who swallowed a fly”*.

*see also Cloud and container DevOps

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.
- For example, you can do offline PWA with SPA since a page load doesn't need a call to the server for rendering it.
  Client still needs to call the server. How offline PWAs work then? They emulate server in ServiceWorkers.
  It also saves processing time/bandwidth by offloading the server from the burden of rendering the page.
  Let's call it page generation to not confuse with actual rendering.
  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 dynamyc part and generating dynamic part after static page already shows something.
  It will still result in more requests, but may trasfer less data per request. May.
  Once the page has loaded, the web app only needs data, not markup nor style.
  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.
  And last is that it is great since it only requires a browser without needing to write native apps in myriad of languages.
  ~~Write for QT.~~
  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
  I guess so. Not everything can be offline-oriented.

Lol. I fucking hate websites that take up half the page with a navbar.

Or a page that uses only half the screen width in the center. Just use the damn screen!
- Yes! Let the user resize the window if they want it take up half their screen!

Frontend devs are the perps and victims at the same time.

Anti Commercial-AI license

É você que financia essa merda!

Я гусь и я до тебя доебусь

As an infra guy... What's backend in this context?

Backend code, basically what is ran on the server and manages user requests, database interactions, etc.. Frontend is the user end, so managing input, displaying information from server requests, etc. and is in the form of an app or website page.
As a network guy...open up your favorite web-managed application and open the developer console. Inspect the transactions you see and compare it to the applications REST API reference, and you'll likely find a lot of commonality (and maybe some undocumented endpoints!).
Backend made the API and everything that is performed by it. Front end is doing the GUI based off the response and promoting for input.
Hah. I get it. Good one.