Asking the important questions

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

Backend developer: "The new functionality is done!" PO: Looks at tests "Seems good, ship it!"
Frontend developer: "The new functionality is done!" PO: Looks at his screen "This spacing could be a little to the right, also I think I didn't really like this text, also it should probably auto-scroll to the top and this button should change colors when I click it and also don't forget to change the error messages I was happy with before and also I think it should......"
- Lol - POs looking at backend tests, as if

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.

Try writing your backend with browser limitations and see what kind of wild wrappers you make to keep yourself sane.
- I remember the day of php files outputting html to the browser... it was 95% as functional as the stuff written in react and node today and incredibly simple.
  Heck, at my company, I still sneak in old-school HTML files when I can.
  
  I am starting to come around if not to the horrible solutions then at least the shift in thinking that made people consider using those, over the old-school approach.
  Back then, the internet was this cool new thing. Fast-forward to today, and all those old pages with broken links, outdated information, and outdated presentation of information, can be problematic. e.g., should a site show an email address, or a phone number, or will doing so allow it to be spammed by bots? (except: that will happen anyway, no matter what, and why prevent people who have legitimate needs to find information?)
  Back then, people had actual attention spans, and finding new information was cool, so when people saw it, they gobbled it up and relished the chance to do so. Fast-forward to today though, and there is so much more information (& unfortunately misinformation, plus active disinformation too) than could ever hope to be read, much less absorbed and/or retained, that the default is to skim or skip rather than actually "read", e.g. a ToS/ToC that is mandatory to continue with a service that you use literally daily.
  So, I am not advocating for e.g. CSS, or React/Angular, etc., but I at least see why people were considering those options, b/c there were problems with the old approach too.
- You mean NodeJS lol
- ServiceWorkers?
- What are limitations of browser for backend?

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.

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!

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.

Devs, fight!
- 😄

I feel (as a fullstack developer) that letting websites run arbitrary code in your browser was a mistake.

Frontend devs are the perps and victims at the same time.
Anti Commercial-AI license

É você que financia essa merda!

Not me!

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.

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