You must log in or register to comment.
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
it was me sorry
I don’t know how to React to this.
Don’t React, just Vue?
I think we all just need a different, Angular approach
That’s a Solid suggestion
Try writing your backend with browser limitations and see what kind of wild wrappers you make to keep yourself sane.
You mean NodeJS lol
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
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
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
No framework will make FSM for you. Managing state of web ui is not as hard as managing state of game.
Using TCP for networking? Loss, retransmit, lag, you’re dead. Using UDP for networking? Loss, desync, you’re dead. Sending full game state? Congestion, loss, lag, dead. Doing sync right, but still pushing too much data? Congestion, loss, lag, dead. Also keeping on server you need not only track game state, but what game state client confirmed to receive.
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.
Doesn’t SPA require polling the web server for more information? I feel like any website which retains information outside of the client device (like anything with a login page) would require state to be stored somewhere on the backend.
What kind of polling are we talking about? If you are talking about realtime data, SSE doesn’t solve that either. You need SSE or WebSocket for that (maybe even WebRTC). If what you mean is that every time the page is refreshed then the data is reloaded, it is no different than polling.
Typically, you just have a session cookie, and that doesn’t even need to be part of the app as auth can be handled by a separate proxy. The server just provides dumb data pull operations to the client in this setup, with all the session state living clientside.
That data has to be stored somewhere though. So you would still need some kind of database server to store it all or some other solution. That’s what I mean by outsourcing state. Data is still stored in the backend, just in a database rather than a web server.
There is data that gets persisted and needs to be stored somewhere, and then there’s the UI state that’s ephemeral. The amount of data that gets persisted tends to be small, and the logic around it is often trivial.
So I was right then. Colour me surprised.
Than*
