5 ms·

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.

kayman 5y ago
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.
- zarzavat 5y ago
  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.
  - isoskeles 5y ago
    Can you expound on this idea a bit? I don't get what you mean, but it sounds possibly interesting.
    - zarzavat 5y ago
      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.
      - dalu 5y ago
        1995-2013 would like to disagree
- danjac 5y ago
  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.
- deleted 5y ago
  [deleted]
steve_adams_86 5y ago
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.
- morvita 5y ago
  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.
azophy_2 5y ago
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
scottlamb 5y ago
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...
3np 5y ago
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.

kayman 5y ago

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.

zarzavat 5y ago
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.
- isoskeles 5y ago
  Can you expound on this idea a bit? I don't get what you mean, but it sounds possibly interesting.
  - zarzavat 5y ago
    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.
    - dalu 5y ago
      1995-2013 would like to disagree
danjac 5y ago
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.
deleted 5y ago
[deleted]

steve_adams_86 5y ago

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.

morvita 5y ago
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.

azophy_2 5y ago

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

scottlamb 5y ago

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...

3np 5y ago

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.