You must log in or # to comment.
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
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
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.
I do not code in C it was just a throwaway meme lol
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.
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.
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.
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.
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!
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
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.
Then you haven’t developed a non-trivial user interface before.
I’ve made UIs, and at least one I’d say was complex, but it was also really ugly. What am I missing?
This wasn’t a put-down, BTW. I couldn’t be a graphic designer either.
The complexity of dealing with different states a UI can be in. The user can navigate the interface of an app in many different ways. The US has to be able to handle all the different combinations of actions the users takes. This means maintaining a consistent state, loading data that’s needed, keeping track of navigation, etc. The logic in an interface of an app like an email client is far more complex than most backend workflows.
Yeah, that could be reasonably complex I guess. I’ve never dealt with more than one navigation structure in a UI, like that would have. All the memes are about clients wanting it to look different.
I mean… the browser can do all that shit itself, just give it some HTML and stylesheets. It’s incredibly important to realize that nearly all this complexity is optional - it may make sense for Facebook to invest this much in a UI but most companies could get away with plain ol’ html with a bit of styling.
As a front end developer you should know when things like infinite loading dynamic tables with a search bar add significant value and when
<table>is good enough. Maintaining complex systems costs money and developers should always advocate for the simplest most sustainable solution to a problem. I think we have a real issue with pursuing shiny new technologies.I mean… the database does all the shit itself, just give it some SQL queries. It’s incredibly important to realize that nearly all this complexity is optional - it may make sense for Facebook to invest this much in their backend infrastructure but most companies could get away with plain ol’ script that on top of Postgres.
As a backend developer you should know when things like load balancing and and complex db schemas add little value, a single table is good enough. Maintaining complex systems costs money and developers should always advocate for the simplest most sustainable solution to a problem. I think we have a real issue with pursuing shiny new technologies.
A simple web app will be okay with some HTML forms, sure. But something like a multi step wizard will lead you down the path of storing a huge amount of state on the server side, which turns into a mess. We have a wizard that uses Django’s forms and django-formtools’s wizard. You have to put the state and complexity somewhere. We put it in the backend and I can’t say I like how it turned out. The code is spaghetti and we get a stream of errors from people not acting how they’re expected to act.
How about UIs that are essentially web apps. I’m talking about needing to handle drag and drop, graphs and the like.
There is also the mess that is responsive design, multi browser support and proper accessibility.
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
How are you managing the state?
Join the dark side. We have cookies.
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.
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.
É 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.
Я гусь и я до тебя доебусь
