There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

Cysioland ,
@Cysioland@lemmygrad.ml avatar

I feel (as a fullstack developer) that letting websites run arbitrary code in your browser was a mistake.

onlinepersona ,

Frontend devs are the perps and victims at the same time.

Anti Commercial-AI license

uis ,

Я гусь и я до тебя доебусь

NigelFrobisher ,

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

bitfucker ,

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.

uis , (edited )

For example, you can do offline PWA with SPA since a page load doesn’t need a call to the server for rendering it.

Client still needs to call the server. How offline PWAs work then? They emulate server in ServiceWorkers.

It also saves processing time/bandwidth by offloading the server from the burden of rendering the page.

  1. Let’s call it page generation to not confuse with actual rendering.
  2. It not always saves bandwidth and processing time, but static resources can allow to hide CDN latency on initial load. Although it is not property of SPAs, just separation of static and dynamyc part and generating dynamic part after static page already shows something.
  3. It will still result in more requests, but may trasfer less data per request. May.

Once the page has loaded, the web app only needs data, not markup nor style.

Static web page after loading will not request more styles. SPAs imply client-side dynamic page, and they may request more data INCLUDING styles. Also client still need to load styles on page load.

And last is that it is great since it only requires a browser without needing to write native apps in myriad of languages.

Write for QT.

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

I guess so. Not everything can be offline-oriented.

bitfucker ,

Client still needs to call the server. How offline PWAs work then? They emulate server in ServiceWorkers.

Yes they do need server for initial resource loading. Usually with PWA, you need to fetch the static resource once from a CDN since every resource is bundled. And no, they don’t need to emulate server in service worker, wtf. You can if you want, but you can also store the data locally using indexeddb and sync periodically baked into the app. Service worker doesn’t emulate server, they just intercept a network call and check their cache. A man in the middle if you will. I think it is debatable if that is called emulating a server or not.

  1. Let’s call it page generation to not confuse with actual rendering.

Yeah, that is fair. Its just the usual web tech shenanigans.

  1. It not always saves bandwidth and processing time, but static resources can allow to hide CDN latency on initial load. Although it is not property of SPAs, just separation of static and dynamic part and generating dynamic part after static page already shows something.

When developing an application, you usually didn’t develop the dynamic and static part separately. Which data can be cached and which needs to be sent to the origin so it can be properly generated. If you fail to configure it correctly the static resource which should go to a CDN get sent to your origin instead. With SPA you just ship the frontend to the cdn and make the backend separately.

  1. It will still result in more requests, but may trasfer less data per request. May.

I mean, if you are making an SPA without splitting the bundle, there should only be a single html, css, and js. A bunch of images and some font too if you want to be complete. But if you are making the page server generated, you always need to transmit the HTML. ALWAYS. So I think it definitely saves requests.

Static web page after loading will not request more styles. SPAs imply client-side dynamic page, and they may request more data INCLUDING styles. Also client still need to load styles on page load.

SPA will not request more style if you are bundling them tho? Wtf are you talking about? Unless you explicitly split the style, once SPA is loaded every page navigation is just JavaScript replacing the whole HTML with the one bundled in the JS file.

Write for QT.

Sure, QT exist as a UI library for cross platform. But that doesn’t solve the iOS mafia. We only got Apple to allow 3rd party store now, we haven’t got sideloading yet. It is a hassle if you want to make an app that can be used in any devices. Especially if the app is just some form filling app.

muad_dibber ,
@muad_dibber@lemmygrad.ml avatar

Devs, fight!

https://media1.tenor.com/m/E7CWw3xkxHoAAAAC/wwe-royal-rumble.gif

yogthos OP ,
@yogthos@lemmy.ml avatar

😄

toastal ,

You can write a stateless server. You can’t do stateless front-end since you have to deal with user interaction.

areyouevenreal ,

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.

yogthos OP ,
@yogthos@lemmy.ml avatar

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.

areyouevenreal ,

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.

yogthos OP ,
@yogthos@lemmy.ml avatar

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.

areyouevenreal ,

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.

yogthos OP ,
@yogthos@lemmy.ml avatar

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.

areyouevenreal ,

So I was right then. Colour me surprised.

yogthos OP ,
@yogthos@lemmy.ml avatar

I mean if you’re going to be aggressively obtuse about this, I guess there’s no point talking.

areyouevenreal ,

How am I being obtuse? You have been trying to trivialise the backend and now frontend as well. Backend isn’t just writing PHP or whatever, it’s setting up database servers, authentication proxies, and all that stuff. Not everything can be stateless.

yogthos OP ,
@yogthos@lemmy.ml avatar

I’m not trivializing anything here. What I actually said was that when all the UI logic lives on the frontend, then the backend just has dumb fetch and store operations along with an auth layer. In this scenario, the backend code can indeed be largely stateless. Specifically, it doesn’t care about the state of the user session or the UI. The only one trivializing things here is you by completely ignoring the nuance of what’s being explained to you.

areyouevenreal ,

The only nuances here seem to be: a) very simple websites need little state (but still aren’t stateless) and b) that you can move the state around to make something look stateless within a narrow view.

yogthos OP ,
@yogthos@lemmy.ml avatar

not what I said at all, but you do you

areyouevenreal ,

Sure

yogthos OP ,
@yogthos@lemmy.ml avatar

Evidently you don’t understand what people mean when they talk about stateless backend, so let me explain. The point there is regarding horizontal scaling. If your backend code is stateful then it has user context in memory, and requests for a particular user session have to be handled by the same instance of the service. With a stateless backend all the context lives on the client, and the requests can be handled by any instance on the backend. So now you can spin up as many instances of the service as you need, and you don’t need to care which one picks up the request. The fact that you might be persisting some data to the db in the process of handling the request is neither here nor there. Hope that helps you.

areyouevenreal ,

Yes that’s a stateless service but not a stateless backend. A backend to me is everything that doesn’t run on the client, including the database. Databases are not stateless, even distributed databases are not stateless. You can’t just spin up more databases without thinking about replication and consistency.

yogthos OP , (edited )
@yogthos@lemmy.ml avatar

I’ve explained to you why the term exists, and why it matters. It refers specifically to application code in the context of horizontal scaling. Meanwhile, many popular databases do in fact allow you to do sharding in automated fashion. If you’re not aware of this, maybe time to learn a bit about databases.

areyouevenreal ,

You still have to consider ACID vs BASE when choosing a database software/provider. It comes from CAP theorem.

yogthos OP ,
@yogthos@lemmy.ml avatar

Again. the goal is not to eliminate the statefullness of the whole stack. That’s just the straw man you keep arguing against. The goal is to remove context from the server. Once you get a bit more experience under your belt, you’ll understand why that’s useful.

areyouevenreal , (edited )

The whole conversation was about backend being similar because you can write a stateless server. Have you forgotten? The issue here is a backend isn’t just one service, you can write a stateless service but you are in fact just moving the statefulness to the database server. The whole backend isn’t simpler than the front-end for that reason. It might be simpler for other reasons, though many popular websites need complex backends.

I am not arguing that a stateless service isn’t a useful concept. I get why people might want that. That’s not what this conversation is about. It’s about the backend vs frontend. Backend to me includes databases and other support services.

yogthos OP ,
@yogthos@lemmy.ml avatar

No, I have not forgotten. This whole conversation was me explaining to you the advantages of keeping the session context on the client. You are not moving statefulness to the database. The fact that you keep repeating this clearly demonstrates that you don’t understand what you’re talking about.

The statefulness lives on the client. Everything I said about the backend application also applies to the database itself. Any node in the db can pick up the work and store the value. The issue being solved is having everything tied to the state in a particular user session.

To explain it to you in a different way. There will be a certain amount of data that will need to be persisted regardless of the architecture. However, moving user state to the client means that the backend doesn’t have to worry about this. The fact that you’re having trouble grasping this really is incredible.

areyouevenreal ,

I don’t write web applications for a living and I especially don’t write front ends. I do have to ask though:

What information are you actually keeping in the front end or web server? Surely you don’t need any ephemeral state that isn’t already stored in the browser and/or for you like the URL or form details. Only thing I can think of is the session ID, and that’s normally a server side thing.

I mean I’ve written web sites where there is no JavaScript at all, and the server is stateless or close to it. It’s not a difficult thing to do even. All the actual information is in the database, the web server fetches it, embedds it into a HTML template, and sends it to the client. Client doesn’t store anything and neither does the server. Unless I really don’t understand what you mean by state. You might keep some of your server fetches data from another server using REST or SOAP but that’s only used once as well.

yogthos OP ,
@yogthos@lemmy.ml avatar

Well, I’ve been writing web apps for a living for the past 20 years or so, and I’ve written lots of full stack apps. There can be plenty of ephemeral state in a non-trivial UI. For example, I worked on a discharge summary app for a hospital at one time. The app had to aggregate data, such as patient demographics, medications, allergies, and so on from a bunch of different services. This data would need to be pulled gradually based on what the user was doing. All of the data that got pulled and entered by the user would represent the session state for the workflow. Maybe don’t trivialize something you admit having no experience with.

areyouevenreal ,

So you do include ephemeral state that’s a copy of database data? If we were including that then every non-static website has plenty of state, but so does every web server. Whatever definition you are using must be quite odd.

yogthos OP ,
@yogthos@lemmy.ml avatar

I don’t know why you have so much difficulty wrapping your head around the concept of UI state to be honest.

bitfucker ,

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.

uis ,

In many pages application url already bears part of state.

yogthos OP ,
@yogthos@lemmy.ml avatar

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.

sandman ,

Lol. I fucking hate websites that take up half the page with a navbar.

mr_satan ,
@mr_satan@monyet.cc avatar

Or a page that uses only half the screen width in the center. Just use the damn screen!

sandman ,

Yes! Let the user resize the window if they want it take up half their screen!

Djtecha ,

As an infra guy… What’s backend in this context?

JPAKx4 ,

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.

JasonDJ ,

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.

uis ,

Hah. I get it. Good one.

o_d ,
@o_d@lemmygrad.ml avatar

Not me!

NewDark ,

Try writing your backend with browser limitations and see what kind of wild wrappers you make to keep yourself sane.

hector ,

What are limitations of browser for backend?

notquitetitan ,

You mean NodeJS lol

xmunk ,

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.

OpenStars ,
@OpenStars@discuss.online avatar

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.

uis ,

ServiceWorkers?

Hugh_Jeggs ,

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

SturgiesYrFase ,
@SturgiesYrFase@lemmy.ml avatar

Well…depends on what the vertical distance is I’d wager…

avidamoeba ,
@avidamoeba@lemmy.ca avatar

That goose should be made mandatory in all customer meetings.

Honytawk ,

If that were true, you’d have more front end devs being able to do backend instead of the other way around.

avidamoeba ,
@avidamoeba@lemmy.ca avatar

Backend devs can do frontend?

PrettyFlyForAFatGuy , (edited ) 

<span style="color:#323232;"><!</span><span style="color:#63a35c;">DOCTYPE</span><span style="color:#323232;"> html>
</span><span style="color:#323232;"><</span><span style="color:#63a35c;">html</span><span style="color:#323232;">>
</span><span style="color:#323232;">  <</span><span style="color:#63a35c;">body</span><span style="color:#323232;">>
</span><span style="color:#323232;">    <</span><span style="color:#63a35c;">p</span><span style="color:#323232;">>Hello World</</span><span style="color:#63a35c;">p</span><span style="color:#323232;">>
</span><span style="color:#323232;">  </</span><span style="color:#63a35c;">body</span><span style="color:#323232;">>
</span><span style="color:#323232;"></</span><span style="color:#63a35c;">html</span><span style="color:#323232;">>
</span>

here i wrote you a frontend

imgcat ,

And yet it still works better than a MB of JS

NigelFrobisher ,

How are you managing the state?

uis ,

Join the dark side. We have cookies.

lastunusedusername2 ,

They think they can.

JoYo ,
@JoYo@lemmy.ml avatar

yes, according to every project manager i’ve worked with.

CanadaPlus ,

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.

frezik ,

Yes. It’ll look like a Geocities page, but yes.

xmunk ,

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?

Honytawk ,

Not all, but more than front enders being able to do backend is my point.

yogthos OP ,
@yogthos@lemmy.ml avatar

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.

CanadaPlus ,

From where I sit, it seems like frontend is closer to being a graphic designer than on backend.

yogthos OP ,
@yogthos@lemmy.ml avatar

Then you haven’t developed a non-trivial user interface before.

CanadaPlus ,

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.

yogthos OP ,
@yogthos@lemmy.ml avatar

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.

CanadaPlus ,

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.

xmunk ,

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.

yogthos OP ,
@yogthos@lemmy.ml avatar

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.

xmunk ,

Absolutely, it’s why at our company I laid the groundwork to eventually adopt a read replica based database approach but didn’t push to actually set up such an environment until about six years later when we had a compelling reason to switch. I work in PHP and the language itself is pretty irrelevant because most pages are just some validation and then shuffling the request off to the database - it doesn’t make sense to over engineer since you’ll end up paying to maintain things that don’t benefit you.

Using a single table is almost always a bad idea though - for prototyping it can make sense but strong typing ends off paying off quickly in not having to write defensive code.

People on all sides are guilty of over complicating things and it’s not helpful for building an agile product. I’d say that there’s a generally accepted assumption that “modern web” means react or some other flavor of SPA - these are amazing tools but aren’t always necessary. Tools are powerful, but you should understand what you’re using and have a justification as to why (or at least make it obvious that decisions were made arbitrarily since sometimes you’ve just got to choose one).

yogthos OP ,
@yogthos@lemmy.ml avatar

Nobody is arguing for overcomplicating things, and it’s true that a lot of projects out there are in fact overdesigned. However, there are also non-trivial applications out there, and front-end can in fact be complex in such apps. For example, I worked at a hospital at one point, and my team built an application that allowed multiple users to work collaboratively on shared documents seeing each other’s changes in real time. That’s a kind of app that is non-trivial, and where there’s plenty of legitimate complexity to be found both on the frontedn and the backend.

pingveno ,

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.

Grandwolf319 ,

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.

firelizzard ,
@firelizzard@programming.dev avatar

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.

hglman ,

You need to be able to do layout design to do good ux. The visual presentation is a critical aspect of usability. Also backend code needs to be consumable future readers (including the author). That’s something that is very often lost and you get terrible unorganized backed code.

CanadaPlus , (edited )

This is kind of what I meant. Appearance isn’t just colours and alignment, but also things like flow, organisation and layout. I can make the data theoretically accessible, but with all that stuff I’m completely out of my depth.

Write-only code can be an issue for either, while on the other hand complexity theory, big data structures and high math make me think backend.

lorty ,
@lorty@lemmygrad.ml avatar

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…”

ADTJ ,

Lol - POs looking at backend tests, as if

criticon ,

Than*

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • random
  • [email protected]
  • lifeLocal
  • goranko
  • All magazines
    •