Hacker News Reader

Comment by robmccoll | Hacker News Reader

I have started to wonder if the axis of UI / no UI might be more useful. There is room in the front end for infrastructural code.

View on HN

I used to work on a product that had a bug component called (our product) > Frontend > Backend (of the frontend).

I worked on (our product) > Backend, and so whenever the frontend was sending me problematic requests I'd file bugs against the "Backend (of the frontend)". Their UI logic was irrelevant to me, more or less; I only observed their "backend" code's behavior.

Of course when I say I worked on the "backend" I mean the part of this product that talked to other backends and storage layers. In a large enough distributed system, "frontend" and "backend" are relative rather than absolute terms...

I agree with this. Modern applications in web browsers can be large and sophisticated enough that you have people building out business logic models while barely touching user interface code. I think this is fairly common based on my experience.

This maps to my experience (and preferences) well. On my current project, we have a Django backend with a Typescript/Vue.js frontend. I enjoy doing API access and data modelling code in Typescript, but will work to avoid picking up any pure UI tickets for the frontend. If I have to do UI work, it'll mostly be copying and pasting HTML and CSS from other parts of the codebase and writing the Typescript to tie it all together.

I feel like development has come full circle. Initially, it was all server side.

Then we had to use javascript to do some frontend stuff.

The javascript became frameworks which templated some of the patterns to make the frontend dev easier (led by React and Angular)

Frameworks like Blazor and Phoenix/Elixir are bringing the frontend dev back to serverside.

Frontend/backend is a speed of light issue. As long as the speed of light remains constant (and I've not heard any plans to change it) there will be a need to a have some code on the client and some code on the server.

Can you expound on this idea a bit? I don't get what you mean, but it sounds possibly interesting.

The latency of a communication travelling at the speed of light from say Japan to New York, is noticeable to humans. If you've ever tried to SSH into a machine on another continent, you know the feeling.

Even if the server is nearby, there's still many things that can add latency, most of which are not controllable (e.g. wifi interference, bad routers, bad ISPs, train tunnels).

So in general you cannot move all functions to the server because it will be terrible for UX. e.g. Google Stadia.

There's a bit more to frontend than knowledge of a framework. I can find my way around a Vue or React codebase, and I'm reasonably competent with CSS and associated frameworks, but there's a deep knowledge of the DOM and vanilla APIs, W3 standards, accessibility, device and browser differences and so on that really make a good frontend developer stand out. Often it's the frontend dev in the room - not the UI/UX experts - who calls out accessibility and usability concerns, as they've spent years working in the nuts and bolts of UI/UX.

If you moved to full server-side tomorrow and used Phoenix/Hotwire/HTMX/whatever, these skills would still be invaluable.

Couple months ago there is an HN Post about "front-of-the-frontend vs back-of-the-frontend" dichotomy. First time reading the title I thinks its complete nonsense, however those distinction may found follower in other places. I think your comment may have some similarity with that idea

Maybe even more specifically, GUI / no GUI.

With few exceptions, backend/infrastructure roles will still often involve exposing and designing APIs, CLI utilities, etc

I tend to agree, though. Most times when I talk about frontend vs backend profiles, this is what I actually mean.

Reply on news.ycombinator.com