Frontend Dev: That's not possible in Frontend, we should do it in Backend.
Backend Dev: That's not possible in Backend, we should do it in Frontend.

-- CIVIL WAR --

Why aren't we just doing it in Middleend?

@jonii nope better be on the front-mid end

@gitlog are you sure this isn't a back-mid end issue?

@jonii no...
Just do the js thingy...
My python ain't doing this

@gitlog But I don't know any Java!

@jonii then do it with C# or C++ !!!!
That's just too obvious.
Just load the visual studio on webpage and do it!

Haahhhh 😄😄😄😄

@2lazy2debug but what if we are 2lazy2doIt

No I don’t wanna

As a backend dev, my argument is always: You should do nothing in frontend.

Maybe allow them to mess around a bit with some styling, they could add some nice SVGs... but I don't trust them with a code editor.

https://brutalist-web.design/

rm -rf -- **/*.js

#maketheweb90sagain

@bittersweet I think in some cases you're right, some websites are just way too overdesigned for their purpose.

But for example devRant is just right.

P.S.: Still want a dark theme for simple sites pls

@jonii Yeah of course it's an exaggeration, but I do think there are too many react kids these days.

@bittersweet I wont say NOTHING on the frontend but I totally agree in some aspects. We have several SPA and mini SPA pages but every single frontend is Dumb and has to ask the API for every decision it wants to make and the backend provides the answers. The only logic in the FE deals with the UI (IE when to show/hide a component, when to navigate or cancel navigation, when to open the modal ect) and that logic is driven from data it got from the BE.

Also validation should NEVER be done on the FE! (Ok maybe to stop idiots from doing stupid stuff but the BE should be doing it again)

@bittersweet @pain0486 well if they are a bad then maybe they shouldn’t, but a good one still useful and we’re here to help reduce the request to server. For the validation you could make it work at both front and back if you didn’t trust them

I read these replies and my faith gets restored. Then I remember that in my company the FE has hardcoded user permissions (we currently have 8 user roles that often conflict in case of dual roles), no optimization nor uglify-zation of the code, average operation requires from 2 to even 10+ API calls (e.g. use and translation of user custom fields), no tests... and well, I am glad I am leaving.

The lead BE developer simply doesn’t want to do anything in fear of server performance, which - I dare say - is the least of our problems. Previous FE developers weren’t wise enough to fight this and we have so much stuff left behind. Did I say that I am glad I am leaving?

@pain0486 @devTea

From a security perspective, a backend team should provide a perfectly waterproof API, which gives back 422 errors for validation, etc.

What's built on top of that should not matter for functionality/security — there could be React frontend, mobile apps, an ncurses bash interface. It should not matter.

In browsers, I personally prefer old school frontends using basic HTML, a bit of CSS to make it look pretty, but still based on simple links, inputs and submit buttons. It's predictable, works on all devices, performs well, and is gentle on people's data bundles.

I'm currently working to get this done at my company: We do have a SPA using heavy Vue components, but I'm building an extremely light frontend in parallel on the same backend. This way, there's always a fallback for users with old devices or slow connections.

@jonii That's a job for the pigeon carrying the flash drive, right?

@kamen hell yeah, let's exchange new rants and comments via messenger pigeons in a txt file on a flash drive!

@pain0486 I would argue that validation MUST always be done on the bank end, for security reasons, and SHOULD always be done on the front end, for UX reasons...

@bittersweet I've been playing with Bulma, and I really like it so far. It's like Bootstrap, but sane. It's literally just CSS styles that easily provide a consistent appearance and a strong foundation, that can be overwritten by theme CSS files for actual styling.

The classes are all consistent and shared (I.E. the class .is-large works on buttons, inputs, etc. rather then having a separate class for each.) and it's all really well thought out, without any client-side Javascript.

It would work well for keeping the JS separate from the design and completely optional. Then you could have the webserver and client-side JS both consume the same API and templates. You get nice, light, modern, UI components, that are backwards compatible and noscript compatible, and SPA convenience when desired.

I will say though that simple webpages are a double edged sword with data usage. If a person is visiting MANY pages, it can actually be more data hungry then SPA apps that only load new data...

@On-fire

Yeah I used to have a small custom wrapper for ajax, recently have been using the typicode/pegasus lib instead.

It pairs well together with hyperapp/hyperapp, which is a micro-reactlike library for dom manipulation.

It adds up to only 1.3kb. When I need a bit more ajax (post requests), replacing pegasus with nanoajax brings it to 1.6kb.

For CSS I usually embed purecss (modular stylereset/responsive/grid framework), which maxes out at 3.6kb -- although now I only load the 1kb purecss core and do the rest with flexbox.

I write backends for personal websites in Haskell, where I select the response type based on the content, and clean/minify all css/js/svg and then inline everything into a single html response. If multiple routes depend on ajax/hyperapp, they're automatically sourced instead of inlined to allow for browser caching to kick in, while still inlining my own code.

Then if any page isn't fully loaded under 50ms locally, I start optimizing.

Next dev comes around with backend for frontend pattern 😅😅😅

@dodo Check this out.

@On-fire sorry I completely missed that you mentioned me. I would say a back end absolutely MUST do validation. You can't trust anything that comes from the frontend. Hell it's an API the could make a request then use something like post man to alter the request... rendering w/e frontend guards that were in place useless. Front end validation is mainly for UI and helping users correct mistakes, but its also useful to limit calls to the API. IE if the Frontend knows the request is bad or incomplete don't make a call to the API.

So I say we are in agreement😄

API Call format war haha 😄

@bittersweet I like the idea, one question though : that means you're back to handling your app state server side in a session? Or did I miss something?

@Commodore I handle my apps as binaries, and my websites as stateless documents. 😝