430
Asking the important questions
(lemmy.ml)
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
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
load more comments
(2 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
load more comments
(8 replies)
load more comments
(1 replies)
load more comments
(6 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.
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.
load more comments
(25 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.
That goose should be made mandatory in all customer meetings.
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.
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.
load more comments
(2 replies)
load more comments
(1 replies)
load more comments
(1 replies)
Making good UX is fucking hard. I say UX because making it good is really about the user’s experience, not graphic design. An ugly front end can be good if it’s intuitive and easy to use. But a visually gorgeous front end will still be garbage if it’s clunky and confusing.
It’s really something you have to experience to fully understand. Ultimately it comes down to this: front ends have to deal with people, backends only have to deal with computers. So backends can be cleanly organized and well structured. Applying backend design principles to a front end will get you a CRUD interface - something that’s usable but no one really wants to use.
load more comments
(2 replies)
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
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.
They think they can.
Not all, but more than front enders being able to do backend is my point.
load more comments
(1 replies)
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)
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!
load more comments
(1 replies)
Я гусь и я до тебя доебусь
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.
load more comments
(2 replies)
view more: next ›
this post was submitted on 26 Apr 2024
430 points (100.0% liked)
Programmer Humor
32563 readers
540 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