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
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
I like base JS and I like jQuery. Only reason I’m using React is for native cross platform mobile/web but I’m beginning to regret choosing it for that
I assume you mean react native, not react, unless you’re using something like capacitor. React native is a far shot from react and is much more annoying to deal with.
Yes I mean react native
Wouldn’t be bothering with it if I were just working with web
Using capacitor as a native shell for your web app can be very nice, actually. It lets you hook into native API calls and build native apps while hardly ever having to write native code, unless you want to, which presumably you don’t since you’re writing react native.
Honestly doing it again I’d just write in xamarin or something not web orientated because as it turns out the web app is going to need to be separate anyway
I might look into capacitor but is that not basically just electron?
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.
The biggest problem frameworks solve is “I need the value of this variable to be on the page and I need it to stay up-to-date.” If you don’t have this problem, or you only have it in a couple of places where hand-writing the necessary event listeners isn’t too arduous, then yeah you don’t really need a front end js framework.
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”
and in rust’s case sometimes even how to fix it
Then there’s C with “segmentation fault”
- You are comparing compiler-generated errors and runtime errors
- Rust can trigger segmentation fault and bus error too.
- GCC’s error messages are very detailed, sometimes can contain suggested solutions.
For example if I will try to compile helloworld without including stdio.h, gcc will warn
implicit declaration of function ‘printf’(by default, almost everyone make it error with -Werror=) and will suggestnote: include ‘<stdio.h>’ or provide a declaration of ‘printf’. And runtime error reports are as good as programmer makes them, no matter language program was written in.I am spoiled by core dumps(although rust technically has them too).
Also in context of kernel, it will print stack trace and (if used) will kexec into another kernel that can make core dump or continue working.
Then there’s C with “segmentation fault”
Successfully triggered a sea fan. (not me, another dude in the comments)
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.
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.
Я гусь и я до тебя доебусь
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
You might say he was very svelte
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.
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…
Not me!
É você que financia essa merda!
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!
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.
In many pages application url already bears part of state.
Sure, but that only gets you so far. I think it’s important to distinguish between document sites where the users mostly just views content, and actual applications like an email client or a calendar. The former can be easily handled with little to no frontend code, however the latter tend to need non trivial amount of UI state management.
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.
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.
You mean NodeJS lol
What are limitations of browser for backend?
Devs, fight!
😄
Than*
