it was me sorry
this post was submitted on 26 Apr 2024
445 points (96.3% liked)
Programmer Humor
32712 readers
1298 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
I don't know how to React to this.
Don't React, just Vue?
I think we all just need a different, Angular approach
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.
load more comments
(1 replies)
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.
load more comments
(7 replies)
load more comments
(1 replies)
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 suggest note: 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.
load more comments
(1 replies)
load more comments
(1 replies)
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.
load more comments
(1 replies)
You mean NodeJS lol
load more comments
(2 replies)
Than*
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....
You can write a stateless server. You can’t do stateless front-end since you have to deal with user interaction.
load more comments
(27 replies)
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.
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.
load more comments
(2 replies)
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.
load more comments
(13 replies)
Backend devs can do frontend?
<!DOCTYPE html>
<html>
<body>
<p>Hello World</p>
</body>
</html>
here i wrote you a frontend
And yet it still works better than a MB of JS
load more comments
(2 replies)
Yes. It'll look like a Geocities page, but yes.
Pah, as if Geocities had the good taste to use courier new.
Also, more seriously, if all the client needs is a geocities page is it reasonable for a front end developer to build it in react?
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.
load more comments
(3 replies)
That goose should be made mandatory in all customer meetings.
É 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.
load more comments
(1 replies)
view more: next ›